• Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About tonyleblanc

  • Rank

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Even though Paul didn't ask for comments when voting yes, I'll interject an opinion anyway. I'm voting we include the change because there are already equipment or LDS vendors who send records/label values that exceed the limit, so we are just acknowledging an existing reality. I agree with Dave that this likely affects host systems more than equipment vendors, but LDS vendors could also be impacted, if host systems start sending lengthy records to As with Dave, we've already relaxed our limits, so the acceptance or rejection of the change in the standard won't make any difference to us. Even though we are not an equipment vendor, if I were in that role and was concerned about making sure my equipment would experience no issues with any host system, then I might well decide to honour the 80-character limit for some period of time. I can't see that there is any downside to doing that for an equipment vendor.
  2. Hi, Anat; Did you have a proposal for how you would represent the upper and lower limits, as well as the nominal base, for your Rx ranges, using a model similar to what Steve proposed? At first glance it appears that Steve's proposal could handle this by adding two additional columns for min and max base curve, using the existing column to represent "preferred" base curve, perhaps. The end result would be more complex and require additional boundary identifiers, but I think it could work. Is this along the lines of what you had in mind? (I do not want to presume to speak for you on this, but because this seems to be a Shamir-specific request you might be best able to suggest how this could be represented). A design such as you give may not be supported today by all LMS systems; I know in our case we would use upper and lower limits when they are provided by the LDS in response to a BRS request, which is what we do today for Shamir integrations, but we don't have a means of indicating multiple valid ranges of base curves for an Rx when we use a base curve chart. We can handle a 3-dimensional model, using sphere, cylinder, and add, but only to specify a nominal base. Of course, whether LMS systems today can support it does not impact how and whether we represent it in a new standard. Tony
  3. I agree, there does not seem to be any existing labels which return the location of the distance MRP for all designs. Should we also have labels which define the location of the distance MRP relative to the center of the blank, for use by analyzers which check the lens before mounting?
  4. For myself, I agree - it seems unnecessary to have a separate characteristic family which is uniquely used by the blank collection. I can't think of any requirement for characteristic family outside of the blanks.
  5. The standard does not specify what index SLBP should be expressed in - in the opinion of others, should SLBP be expressed in PIND as with other prism labels?
  6. Hi, Marcos - I sent you the link to the google document via email.
  7. Some questions for tomorrow from my reading of the document: 1) For design ZDES01, the first two material entries have a Treatment section in common - both contain TRT02, but with different blank collection IDs, and different Base Curve Chart references. it is unclear to me if these are two different design/material combinations, or if this is unnecessary duplication? 2) Understanding that the list of processing parameters may be for illustration only, note that CYL is given as an available parameter, but AX is not. I like the idea of allowing the LDS to include the list of labels required - do we need to specify that, if used, "all" labels should be provided (so as to provide a complete list of labels to be included in the LDS packet), or should we allow this to be all/some/none as desired? 3) Further to the processing parameters, should the limits on a particular label (for example, SPH), be set up as separate "processing parameters", or would it be better/clearer if SPH existed only once as a processing parameter, and the limits be included within the specific "product" or "design" sections? 4) I find the characteristic family and blank collection/family to be confusing. In characteristic family ZCHF01, does each of the TRT01 and TRT02 treatments apply to both the BLNK01 and BLNK02 blank families, or does TRT01 apply to BLNK01, and TRT02 to BLNK02? more to come
  8. From an LMS perspective, we don't require OPC codes for digital products at all, unless they are required by the vendor for reporting purposes (as Shamir does). At the risk of speaking out of turn, I believe some LMS systems do (or did at one time) require an OPC for each combination of base/add that correspond to the digital product that is created. Hopefully other LMS vendors will weigh in on this discussion.
  9. The recording starts about 7 minutes into the call (sorry about that). 2018-05-16 10.19 LPDS Working Group Meeting.mp4
  10. ACOAT is not limited to just AR coatings; the particular device vendor asked for a way to see only A/R coatings, with the brand name.
  11. We have a need to retrieve the brand of AR coating from our LMS - the suggestion is to add a new chiral text label "ARNAM" which would be the name (or brand) of the AR coating. I thought I would ask for comments before proposing this in September. All comments, suggestions, etc., are welcome.
  12. I would think GDEPTH and GWIDTH should be able to be specified anywhere in the file, following the REQ line, and respecting the TRCFMT/R block of data. If this frame is both a drill rimless and a groove frame, it could include drill point data as well. Would it be beneficial to have another ETYP which would indicate a frame has both drill and groove properties? (I wonder if all systems would recognize DRILLE data for a frame with ETYP=3, for example)?
  13. In discussions with an LDS recently, a question around handling of CRIBFMT and CRIB/ELLH came up. The DCS standard does not explicitly indicate which should have precedence if both CRIBFMT and CRIB/ELLH are specified, nor does it explicitly state that both should not be specified in the same packet. In our case, if CRIBFMT is present, we suppress CRIB and ELLH because of issues in the past with equipment complaining if both CRIBFMT and CRIB/ELLH are specified. Question - should the standard say anything about precedence if both CRIBFMT and CRIB/ELLH are present, or, should there be any restriction on both CRIBFMT and CRIB/ELLH being present in the same packet?