tonyleblanc

Members
  • Content count

    7
  • Joined

  • Last visited

Everything posted by tonyleblanc

  1. tonyleblanc

    LPDS Data Structure Sample - Carl Zeiss

    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
  2. tonyleblanc

    OPCs for digital designs

    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.
  3. The recording starts about 7 minutes into the call (sorry about that). 2018-05-16 10.19 LPDS Working Group Meeting.mp4
  4. tonyleblanc

    Proposed ARNAM label

    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.
  5. tonyleblanc

    Proposed ARNAM label

    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.
  6. tonyleblanc

    Special Groove Rimless OMA File

    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)?
  7. tonyleblanc

    Handling of CRIBFMT and CRIB/ELLH

    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?