All Activity

This stream auto-updates     

  1. Yesterday
  2. I took the CZV example and modified it to apply the changes we discussed during the working session. Namely, Having materials appear once with treatments owning the lenses used Adding processing parameter collections Having treatment reference IDs in three arrays to indicate Inherent/Required/Excluded treatments Moving the mandatory flag on the processing parameter to instead be implied in the name of the array the processing parameter appears in Including an example of region exclusivity, with a region override. https://docs.google.com/document/d/1W9JL-d93RfKZwRp_2K1hBtD27-PhyVI6_-WZjZdrKF4/edit?usp=sharing The document should be valid JSON at this point - I changed the comments to a JSON-acceptable format, so that it would pass through jsonlint.
  3. Adrian

    LPDS Data Structure Sample - Carl Zeiss

    Regarding the points mentioned: 1) The first two material combinations are listed separately as the first is a hard coated clear product and the second is a hard coated photochromic product. The photochromic product has a different range on the sphere processing parameter. 2) The processing parameters chosen were primarily for illustration. I imaged the optional tag on the processing parameter to indicate if it must be included, ie optional=true implies it doesn't have to be provided in the LDS packet whereas optional=false implies it must be provided. 3) This is worth discussing in our meeting. Perhaps just the limits for each variation would be better to reduce duplication, though this would add complexity when no variations are offered (trade off). 4) Both treatments apply to both blank sets. The different between BLNK01 and BLNK02 is that the BLNK02 is wide version blank set of the same material treatment combination. Hope this helps
  4. Last week
  5. 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
  6. Zeiss has sent a product data sample which has been uploaded to our Drive folder. https://drive.google.com/file/d/1cReSPZb7uoeK3jtH3Q_LikEi3MMhCkGG/view?usp=sharing
  7. until
    Data Communications Standard Meeting @ VEW
  8. until
    Lens Product Description Standard @ VEW
  9. until
    Lens Technical Committee Meeting @ VEW
  10. Earlier
  11. Paul Wade

    DCS 3.12 Review & Poll

    Dear Committee Members, Please find attached to this post the review draft of DCS 3.12. Please keep in mind that this document is a major refactor of the Word document from version 3.11 so it will not be possible to use Word’s comparison tool between the two documents. Instead I have left Track Changes on in this document which should show all of the substantive changes made between 3.11 and 3.12. After reviewing the document please indicate your vote in the poll. If you select “Approve w/ Comments” or “Disapprove w/ Comments” please be sure to either post your comments to this topic or send them directly to myself or Robert Shanbaum. This review will remain open until 8/8/18. If you have any questions or concerns please do not hesitate to reach out to me directly. Best Regards, Paul DCS v3.12_NEW Working_15.docx
  12. 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.
  13. Hi Everyone, Sebastien from Essilor has submitted their data sample using the new LPDS structure. I've copied it to our shared Google Drive folder: https://docs.google.com/document/d/1vELgj5JPZ61Kq0hGueb1B46175UD9dmQlrzIi5PR_FQ/edit?usp=sharing
  14. Paul Wade

    OPCs for digital designs

    I'm fairly sure Signet is already doing it this way. If I recall correctly, they switched to a single OPC per design several years ago. There's no reason I can think of that a manufacturer must use multiple OPC's per design. I feel that is complete up to the manufacturer. I don't think anything in the standard forces a manufacturer to use left and right OPC's for freeform designs but perhaps I missed something.
  15. DanielSimonetta

    OPCs for digital designs

    Hello everyone, I believe that I have have initiated individual conversations with many of the LMS vendors regarding the topic of OPCs for digital designs. With Semi-Finished progressive lenses it made sense to have an OPC for each eye but I am curious if this logic still holds true today. I am sure to over-simplify this and get reprimanded by the smarter members but it seems that digital design products would need only a singular OPC that represents the specific design for reporting purposes and not a singular OPC for each eye. What other uses/scenarios require two OPCs for a job containing a right and left lens of a digital design product. Thanks for not being too harsh :-)
  16. Hi All, This isn't very timely and I apologize. I thought I had put up the DCS audio at the same time as the LPDS audio and only realized my mistake when I tried to find it again. Here is the recording of our meeting at VEE 2018: https://drive.google.com/file/d/15cIw4E75OUl2snvh7F5bWrIi22tcAYWk/view?usp=sharing If you have any issues accessing the file please let me know.
  17. The recording starts about 7 minutes into the call (sorry about that). 2018-05-16 10.19 LPDS Working Group Meeting.mp4
  18. 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.
  19. SJO

    Proposed ARNAM label

    Hi, ACOAT will not give enough of information? ACOAT => text[;] => Applied coating
  20. Yaron [LaserOp]

    PROCBLK new record + SDFMODE extension

    I think this is the current consensus on the discussion here. Though if any silent readers of this thread have some contrary experience with handling of such labels, now would be a good time to mention it. I also agree with Etienne that it's probably then a good idea to make the singleton/repeated characteristic be made into explicit defined terms in the Standard. This is a Standard, so if this characteristic is explicitly referred to by something (which it will be now), then it needs to be explicitly and clearly defined. I do not think, however, that there is a need to then go and explicitly list in the DCS for each and every record how it falls (or make a list), as that would be very easy to infer for each record based on the definition. Related, in addition to mentioning this in PROC/PROCBLK, the same note should probably be in other methods of sending data to the LMS. Since the expected (but currently implicit and unlisted) behavior there is the source of assuming this should also be the behavior in the context of PROC, and LMS are probably acting this way anyway, this is a good opportunity to make it explicit in the standard as well.
  21. Paul Wade

    PROCBLK new record + SDFMODE extension

    So then perhaps a call is not necessary. Please let me know if we have consensus on the following: 1. Modify the definition of PROC to explicitly describe the behavior of non-singleton records like ENGMARK. Namely, that it is additive or cumulative in nature and that if a distinct set of non-singleton records is desired to be sent to a specific device then they must be entirely contained in PROC records. Probably should include some examples. 2. Ensure that PROCBLK's definition matches the defintion of PROC with regards to non-singleton records. Agreed? Or am I still missing the plot?
  22. Etienne JULLIEN

    PROCBLK new record + SDFMODE extension

    After carefully reading all the posts, I'm inclined to agree with Yaron. LMS obviously already have "intuitive" knowledge of the "repeatable" characteristic of a record. And they already have rules to handle records depending on this characteristic (Replace "GAX" or Add "ENGMARK" for example). So it makes sense to keep it simple and use the same ruleset for PROC records. Maybe the only thing we need, really, is for this repeatable characteristic to be explicit in the DCS records definitions.
  23. Paul Wade

    PROCBLK new record + SDFMODE extension

    I'm going to be setting up a conference call. I emailed a few of you to get a consensus on the time and then I'll send a poll to the committee.
  24. Yaron [LaserOp]

    PROCBLK new record + SDFMODE extension

    Robert, Sorry if I wasn't clear. I used tracing as an example to illustrate that there already exist cases of labels which can have different distinct instances even though technically these different instances have the same name. Of course traces aren't ever expected to be handled that way. But they can show the concept of having a label with the same name, passing the same sort of data, while still being distinct from another label of the same name, where pretty much everyone would agree wanting to modify one does not affect the other. (e.g. if you won't erase all existing traces if you receive just a new one, why would you erase all engravings or drills, when you receive a new one?). And we are already in agreement that having one record present shouldn't affect another different record. That, again, was the point I was trying to illustrate, that in practice non-singleton records like ENGMARK are all also different, even though they have the same name, so having one like that in a PROC shouldn't mean the others should be changed.
  25. Robert Shanbaum

    PROCBLK new record + SDFMODE extension

    I suppose that it's possible that a use case could exist wherein a set of repeating records might need to be replaced by another set of repeating labels (or, possibly, just one label - an ENGMASK might replace a set of ENGMARKs, for instance). I'm not sure how likely such a case is to obtain.
  26. Robert Shanbaum

    PROCBLK new record + SDFMODE extension

    Yaron, we only send one tracing per packet, ever. And tracings are a special case, because I'm pretty sure that all LMSs can send whatever number-of-points or formats any device might specify in its initialization, without requiring PROC records (or PROCBLK datasets) at all. As I wrote, the standard is not presently explicit when it comes to which records (or datasets) might be repeating, but it seems to me that there's not really much doubt about which ones are, and which aren't. Can anyone name a record for which that is not true? I do not agree with the proposition that the presence of one record in a PROC record implies that another, different record should be changed.
  27. Yaron [LaserOp]

    PROCBLK new record + SDFMODE extension

    Second, this still focuses on when everything comes from a single source. That is, in your example there are no ENGMARK records on the LMS before this data packet. But what when there are? Suppose the LMS is set to always engrave some feature the lab wants, so when a job is created it automatically populates it with "ENGMARK=Lab feature 1". (Let's even assume it's for area that will be removed by the edger, so no issues with other agreements/expectations by some LDS vendors on what will be engraved) Then one of the LDS vendors in the lab have their own engraving layout, so when the LMS asks them to calculate the job, they send a packet including ENGMARKs as in your example (either case). What should one of the "basic engravers" receive from the LMS? Option 1: ---------- ENGMARK=Plain feature 1 ENGMARK=Plain feature 2 Option 2: ---------- ENGMARK=Plain feature 1 ENGMARK=Plain feature 2 ENGMARK=Lab feature 1 I'd expect option 2. I get that Robert would also expect option 2. That's the basic difference of receiving data about pre-existing labels, between the singleton and non-singleton ones. So if even without PROC singleton labels should be replaced but non-singleton labels should be added, then providing more of then through PROC should follow the same process, because that is what is already being done without PROC. - As an aside, of course a problem with this "add" attitude for non-singleton labels is that there is no obvious way to replace/delete such labels if needed. But similarly with the "replace" attitude for non-singleton labels there is no way to add them. And not being able to add such labels (something that is useful and in demand and is already being done with workarounds) is a much much bigger problem than not being able to replace them (which seems less often useful, and which maybe can be easily provided by something else, like maybe an additional ACT to REQ=CMD for clearing specific labels? Can probably wait until and if someone actually asks for it. Or maybe allow to force-clear a non-singleton label by sending it empty to the LMS, the downside being that this will have to be ordered but at least for PROCBLK everything is already decided to be ordered ).
  28. Yaron [LaserOp]

    PROCBLK new record + SDFMODE extension

    Paul, First, regarding: That's not entirely correct. Or, well, it depends on how you look at it. A singleton record will behave that way, on account of being a singleton. When you send PROC=SBFCIN you replace ALL of the SBFCIN record. But you do that because there is only one SBFCIN. But with a non-singleton records, they may all have the same label name, but they're different entities. So bunching them together is not unlike saying that, for example, SBFCIN and SBFCUP are very closely related, so having a PROC with just SBFCUP should also remove (zero) an upper/general SBFCIN. That idea sounds immediately wrong, because they have the same name, but they do come together and serve a closely-related purpose. Non-singelton records are sort of like that too, they do share a name but they're otherwise different entities representing different things. ENGMARK="Plain feature 1" is not the same as ENGMARK="Plain feature 2", these are two different individual records, doing two different things. Or, better example, since it's sort-of-not-entirely-singleton, what about most datasets? consider: TRCFMT=1;128;E;R;F R=... TRCFMT=1;128;E;L;F R=... PROCBLCK=1;ENG;.... 1!TRCFMT=1;240;E;R;F 1!R=... If an engraver later asks the LMS for frame trace, for the right side there would be one based on (of course currently possibly interpolated otherwise) the 240 points trace. For the left lens sent to an engraver... do you think there should be one based on (and again possibly interpolated) the 128 points trace? or do you think there should be no trace sent? What seems to me like the natural expected answer is that the engraver would receive frame traces for both eyes, one from the 128 source and one from the 240 source. But, well, with the "replace for non-singleton" attitude, TRCFMT has been replaced for engravers. So engravers only have TRCFMT explicitly set for them. Which has a right trace, but doesn't have a left trace. This feels like the wrong interpretation. But it follows the same logic for labels like ENGMARK, the only difference is that there can be N copies of ENGMARK but 2 copies of TRCFMT. But, again, both these two TRCFMT copies are called TRCFMT, so... I guess you probably agree that both TRCFMT datasets are distinct, even though they both use the same names of labels. And agree that replacing that dataset for one eye in PROC wouldn't affect the identically-named labels for the other eye. So why is that different for ENGMARK, or for DRILLE datasets, or other non-singleton labels?
  1. Load more activity