• 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. 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?
  2. 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.
  3. 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?
  4. Hi, Marcos - I sent you the link to the google document via email.
  5. 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
  6. 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.
  7. The recording starts about 7 minutes into the call (sorry about that). 2018-05-16 10.19 LPDS Working Group Meeting.mp4
  8. 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.
  9. 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.
  10. 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)?
  11. 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?