Paul Wade

Administrators
  • Content count

    60
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by Paul Wade

  1. Paul Wade

    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?
  2. Paul Wade

    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?
  3. Paul Wade

    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).
  4. 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.
  5. 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.
  6. Paul Wade

    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?
  7. Paul Wade

    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?
  8. Paul Wade

    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.
  9. Paul Wade

    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.
  10. Paul Wade

    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.
  11. Paul Wade

    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?
  12. Paul Wade

    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?
  13. Paul Wade

    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
  14. Paul Wade

    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
  15. Paul Wade

    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
  16. Here is a link to the audio recording by Daniel during our last call. https://drive.google.com/open?id=1DrwYhjcPYoKNV5CY1ECTgO0u86Mb2bf9
  17. Paul Wade

    Lens Description Standard 2.2

    The poll has been closed. The new version was approved.
  18. Paul Wade

    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
  19. 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.
  20. 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.
  21. 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
  22. Paul Wade

    DCS Document Review - 3.12 Major Revamp

    Hi Yaron, Your feedback regarding the revision history section is noted and the section with appropriate annotations will be added to the document prior to the next round of review. The current round of review, intended to identify inadvertent errors that may have been introduced during the reformatting process, is approximately 0% complete.
  23. Hello Colleagues, As discussed at VEW 2017, please find attached the latest draft of the DCS document. Below is a list of topics from the table of contents. If you have completed a review or partial review of a section from the table of contents please let me know by replying to this topic. If there are items that need to be changed you can either email them to me and note that you have emailed them to me in your reply to this topic or you can put the changes right in your reply. As each section from the TOC is completely reviewed I will note it below so that section can be skipped by other reviewers. If you would like to take ownership of a specific section please let me know by replying to this topic and I will assign that section to you below so that others know it's already being worked on. If you have suggestions for changes or improvements to this review process please let me know. I'm eager to make this as painless and as efficient as possible. Thanks, Paul ==================== . 181 1 Scope 2 Normative Reference 3 Terms and definitions 3.1 General 3.2 Reserved characters 3.3 Data Types 3.4 Messages 3.5 Records 3.6 Sessions 3.7 Timeout 4 Overview 5 Requirements 5.1 Records 5.2 Reference point records 5.3 Generator records 5.4 Tracing datasets 5.5 Drilling Records 5.6 Side Drilling Records 5.7 Bevel Profiles 5.8 Shelf Datasets 5.9 Direct Surfacing Records 5.10 Cribbing and crib datasets 5.11 Surface Thickness datasets 5.12 Power Map Datasets 5.13 Weighting Matrix Datasets 5.14 Design Deviation Datasets 5.15 Marking Records 5.16 Device-Specific Records 5.17 PROC Records 5.18 TOKEN Records 5.19 Job Status Notification 5.20 Records with Multiple-Value Fields 5.21 Tolerance Records 5.22 Report Record 6 Packets 6.1 General 6.2 Deprecated Requirements 7 Sessions 7.1 General 7.2 Initialization sessions 7.3 Upload sessions 7.4 Download sessions 7.5 File-based information transfer 7.6 Command sessions 7.7 Lens Data Session 7.8 Communications 8 Other Requirements 8.1 Operator Messages 8.2 Host Requirement Annex A: Normative Record Labels A.1 Device records A.2 Interface records A.3 Preset packets A.4 Status codes A.5 Enhanced Status codes A.6 Process Control Records Annex B: (Informative) Packed Binary Format Example Annex C: (Informative) CRC Calculation Example Annex D: (Informative) Revision History DCS v3.12_NEW Working_3.docx
  24. Paul Wade

    DCS Document Review - 3.12 Major Revamp

    Hi Yaron, Yes, there are literally thousands of changes (over 7,000) and the vast majority (6,000 or so) are simply formatting. No content changes were intended other than corrections to existing issues (paragraph numbering corrections, typos, etc.). There may have been a couple of very small changes that inadvertently have been added already but once we finish this review will get listed in the revision area like normal. There will not be a list of these formatting changes or corrections since it's simply not practical. Once we have a good document for editing again we will proceed with actual content changes as normal. This was the decision of the group at VEW. It is also not possible to provide a Word document comparison review just in case that is the next question. Word cannot properly handle the number of changes and it can be very confusing trying to go through a compare when there are a lot of paragraph numbering changes as there are in this revision. I did that prior to turning this document over to the group to try and identify and correct the most egregious of mistakes. Let me know if you have any other questions or concerns regarding this process. It's definitely fluid at the moment since we've never attempted a review of this scale before.
  25. Paul Wade

    VEW 2017 MES Presentation

    I've attached a copy of the presentations from Dennis Brandl given at VEW 2017. 2017-09-12 Two Hour ISA 95 Tutorial.pptx Dennis Brandl - OPC-UA and Deep Domain Knowledge.pptx