The Vision Council

  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by The Vision Council

  1. Hi Again, We have three days left in the poll. If you have not done so, now is the time to place your vote. Thanks, Paul
  2. Hi, I wanted to post a brief update. I've had some individuals email me some small changes privately so I wanted to keep the group informed. So far there have only been a few minor layout and grammatical changes. Nothing substantive. We're about half way through the voting period with a little over two weeks to go. If you haven't had a chance to peruse the document yet it will be greatly appreciated if you can find time to do so. Thanks, Paul
  3. Zeiss has sent a product data sample which has been uploaded to our Drive folder.
  4. until
    Data Communications Standard Meeting @ VEW
  5. until
    Lens Product Description Standard @ VEW
  6. until
    Lens Technical Committee Meeting @ VEW
  7. 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
  8. 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:
  9. 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.
  10. 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: If you have any issues accessing the file please let me know.
  11. 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?
  12. 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.
  13. In a contrived example, we have three engravers. Two high resolution laser and one lower resolution mechanical. We have a complicated lens feature which can only be engraved on the high resolution engravers. Which of the following is the way we'd want this handled if we used only PROC? Method 1 - Non-cumulative ========================= ENGMARK=Complicated feature ENGMARK=Plain feature 1 ENGMARK=Plain feature 2 PROC=ENGMARK;Dumb Engraver;Plain feature 1 PROC=ENGMARK;Dumb Engraver;Plain feature 2 Method 2 - Cumulative ===================== ENGMARK=Plain feature 1 ENGMARK=Plain feature 2 PROC=ENGMARK;Smart Engraver 1;Complicated feature PROC=ENGMARK;Smart Engraver 2;Complicated feature In both examples we want both plain ENGMARK records to get to the dumb engraver but to have the complicated ENGMARK only go to the smart engravers. The first method is non-additive so that we have to declare the features explicitly. The second is cumulative where we only include the additional features. In the first it would be easy to exclude non-singleton values but in the second it's more difficult and granular I think. I would prefer to work with the first method I think. Despite it's higher verbosity I like the explicit nature of seeing exactly what will go to "Dumb Engraver" without having to check the other records. It's how a singleton record behaves as well so it's consistent. This is a tough one.
  14. I was thinking along the same lines. If using just PROC like this: ENGMARK=MASK;MainDesign;.... ENGMARK=TXT;A;.... ENGMARK=TXT;B;.... ENGMARK=DCS;ADD;.... ... PROC=ENGMARK;ENG;;;TXT;D.... PROC=ENGMARK;ENG;;;TXT;E.... Is that additive so that 6 ENGMARK records are sent to the engraver? Or is it replacing ENGMARK so only the two PROC ENGMARK records are sent? What was the intent? If we define that then the definition of PROCBLK needs to match, doesn't it?
  15. Hi Yaron, I deleted the superfluous post. I'll wait for Jullien to respond but perhaps just the example is confusing. I would have thought that the LMS would only send whatever ENGMARK records existed in the PROCBLK so if those other records needed to be included they would have to be in the PROCBLK as well. To my understanding that seems to be the only way to be consistent with other record handling. What am I missing?
  16. I don't have much meaningful preference one way or the other though I voted for 120 character lines. I feel that is the least likely to cause any issues and solves the existing problem. I do not like the concept of unlimited line length in general and I don't see that as providing any benefit and leaves too much room for impractical implementation. I do not feel strongly about this, however, so my position will go with the majority. I think valid reasoning is possible from both positions. As for the one specific reason mentioned, I was merely pointing out one of the issues raised by members of the committee both during and after the meeting. That's why there are three options instead of just two (keep or eliminate).
  17. As discussed at VEE. I voted for the 120-character limit to prevent an issue raised by a couple of people. If there were no limit then we could end up entire data sets on a single line.
  18. The working group meeting recording is now available here (155MB): Summary: The group made several revisions to the outline and to the sample data. In the end multiple additional changes were made to the sample data and an action item was assigned to me to take the sample layout and translate it into the outline. Additionally the group agreed to schedule their next meeting for the early part of May. If anyone has additional highlights they wish to draw attention to please do so by replying to this post.
  19. Etienne, do you and your team want to draft the initial language to put into the document? If you guys draft the initial language then I can insert it into the document and Robert can edit it as he sees fit. Just need a starting point and I think the proposal has changed quite a bit. What do you think?
  20. In response to your three points: 1. We will be polling companies to determine the impact of relaxing the 80 character limit. The consensus at the meeting was similar to yours, that it is probably OK but we will need to check before making the change. 2. & 3. If I understood the committee's intentions correctly, all matching DEV would get A=2;2 and B=2;2. All matching DEV;VEN would get A=3;3 and B=2;2. My impression and belief is that inheritance was an expected benefit of this method. However, it may not be that everyone on the committee was thinking the same in that regard. I suppose we shall see based on this post. An interesting case to consider is that if for some reason you did not want your more specific DEV;VEN to get that overridden value you would have to do something like this: A=1;1 B=1;1 PROCBLK=1;DEV; 1!A=2;2 1!B=2;2 PROCBLK=2;DEV;VEN 2!A=3;3 2!B=1;1 That allows as much overriding and inheritance as one would prefer I think. Does anyone see any pitfalls with this approach? Or have I misinterpreted the inheritance discussions?
  21. Unless you guys feel further need to discuss I’m reading a consensus here. If I’m understanding the discussion at this stage then I will move forward with adding the proposal the group agreed upon at the meeting to 3.12 as it seems there is further consensus here that the prefix method is “good enough”. Further comments can be collected as part of the review process for 3.12 if necessary. If someone feels that my conclusion is premature please let me know.
  22. What would be the difference between this and just refactoring PROC to support data sets? I mean, other than requiring more characters ("PROC=" for every line) it would seem to be the same thing and to me is cleaner since it's in keeping with the existing record formats in the standard. We would simply need to indicate that PROC records for data sets must be contiguous. I'm not fan of that solution as I felt the prefix idea from the meeting was clean and very simple but if we're going to go with this sort of approach I would think just tweaking PROC would be a more homogeneous solution.
  23. You are as astute as always... I almost posted an pre-explanation of why we didn't just do away with the prefix altogether. There was a lengthy discussion about it and your summary of why we kept it is spot on. The convenience factor outweighed terseness. At least I feel that is a fair assessment of the result. For the alternate format you proposed, it seems less clean to me than what we ended up with at the meeting but I'll let others comment. The version above will be put into the 3.12 draft for comment as well. Also, related to 3.12, the SDFMODE/LDPATH proposal has been postponed until a future draft so further work can be done. A revised proposal will be forthcoming.
  24. Yaron: I wanted to post this follow-up based on our discussions from the DCS meeting today so you'd have a chance to offer your thoughts. Your insight on this proposal was extremely valuable and helped the group avoid taking a wrong path, so thank you very much! To members of the group please feel free to correct me where I've gotten any details of the consensus wrong. The group agreed to essentially adopt a modified version of your prefix label proposal: PROCBLK=Prefix;DEV;[VEN];[MOD];[SN] Where "Prefix" is an integer value. Instead of using "=" as a delimiter for the prefix the group settled on "!" (not already in use, not reserved, unlikely to be strongly desired to be part of a real record label name). By using the prefix the PROCEND record is no longer needed (all [prefix]! records belong to that PROCBLK). Examples of this PROCBLK format that the group came up with during the meeting would look like this: PROCBLK=1;FSG;;; 1!LMATID=70;70 1!_SCSBRD=2.50;2.50 1!_SCSBCCA=0;180 1!GAX=0;0 PROCBLK=2;FSG;SCH;HSC; 2!LMATID=72;72 2!_SCSBRD=2.50;2.50 2!_SCSBCCA=0;180 2!GAX=0;0 The standard will require PROCBLK to precede any prefixed records and that the prefixed records be contiguous. This would be similar to the other dataset definitions. Do you see any issues with this solution?