Paul Wade

Administrators
  • Content count

    39
  • Joined

  • Last visited

Everything posted by Paul Wade

  1. 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?
  2. 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.
  3. PROCBLK new record + SDFMODE extension

    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.
  4. PROCBLK new record + SDFMODE extension

    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?
  5. PROCBLK new record + SDFMODE extension

    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?
  6. DCS Poll - 80-Character Line Limit

    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).
  7. 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.
  8. The working group meeting recording is now available here (155MB): https://drive.google.com/file/d/1Y0zC-YgzrSt6Dbhb-icFoQDLNhdacbZ4/view?usp=sharing 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.
  9. PROCBLK new record + SDFMODE extension

    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?
  10. PROCBLK new record + SDFMODE extension

    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?
  11. PROCBLK new record + SDFMODE extension

    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.
  12. PROCBLK new record + SDFMODE extension

    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.
  13. PROCBLK new record + SDFMODE extension

    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.
  14. PROCBLK new record + SDFMODE extension

    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?
  15. Special Groove Rimless OMA File

    I'm posting this question on behalf of David Laing at Silhouette: We have a new collection coming in April that is a drilled rimless with a groove to hold a decorative element and we need special groove width and depth. An example of the current OMA file for this special rimless collection is below. As you can see, it has groove specified in ETYP but has no groove dimensions. 1. I was wondering if you had an example of where GDEPTH and GWIDTH values would be placed in the OMA file? 2. Is there any other data we should include to have a better end result?
  16. VEE 2018 Agenda

    The agenda for the meeting at VEE 2018 has been posted here: https://www.thevisioncouncil.org/sites/default/files/2018-VEE-LPDS-Agenda-FINAL.pdf
  17. VEE 2018 Agenda

    The agenda for the VEE 2018 meeting has been posted here: https://www.thevisioncouncil.org/sites/default/files/2018-VEE-DCS-Agenda-FINAL.pdf
  18. Current Draft Document

    Here is the current draft of the DCS. Change tracking has been turned on in this document. DCS v3.12_NEW Working_5.docx
  19. Greetings Colleagues, We are soliciting input from the committee members regarding topics for discussion at VEE. Please reply to this post with a list of items you would like included on the agenda. Thanks! Paul
  20. Here is a link to the audio recording by Daniel during our last call. https://drive.google.com/open?id=1DrwYhjcPYoKNV5CY1ECTgO0u86Mb2bf9
  21. Lens Description Standard 2.2

    The poll has been closed. The new version was approved.
  22. Lens Description Standard 2.2

    Attached to this post please find version 2.2 of the Lens Description Standard. After review, please vote accordingly and be sure to post any comments below. From Mike Vitale: The only changes that have been made are listed below. I have highlighted the changes made on page 3. 10 and 27 of the document. Category Literal Abbreviation Filter High Energy Visible HEV Color Violet VIOn In addition I revised the revision paragraph (1.3) to more clearly identify changes in each version since 2.0. This mirrors what we've started doing with the Data Communications Standard. THE DOCUMENT IS LINKED BELOW TVC Lens Description Standard 2.2 Draft_pw.pdf
  23. This is a recording of our web meeting from 12/7/17. https://drive.google.com/open?id=1O2Zj7-b4RhEIEVa6cJF-9tY9XhBj60mi Conclusion: We will build the outline based on the combined UML diagram provided by CZV and edited by Essilor. I will update the document on Google Drive with the appropriate changes and the group will reconvene after the holidays.
  24. Hi Everyone, The minutes of the most recent working group have been uploaded to Google Drive: https://drive.google.com/open?id=105q6TCC4kglChPrCbOTwpSgjLj9ecFG2 Special thanks to Sebastien Piraube for putting these together. Thanks-P P.S. If you guys would prefer documents like this be uploaded as attachments on the forum instead of put on Google Drive please let me know. I have no preference.
  25. until
    Dear Colleagues, This is the date the majority said was acceptable. I realize some of you indicated you could not attend on this day but I’ve included you just in case. Additional information will be forthcoming. NOTE: Please be sure you have registered for the forums. The majority of information will be shared via the forums. Daniel Simonetta has recently posted some items from our meeting at VEW 2017. Best Regards, Paul Meeting Details LPDS Working Group Tue, Oct 31, 2017 8:00 AM - 9:00 AM PDT Please join my meeting from your computer, tablet or smartphone. https://global.gotomeeting.com/join/356811141 You can also dial in using your phone. United States: +1 (646) 749-3131 Access Code: 356-811-141 First GoToMeeting? Let's do a quick system check: https://link.gotomeeting.com/system-check