Paul Wade

Administrators
  • Content count

    60
  • Joined

  • Last visited

  • Days Won

    1

Posts posted by Paul Wade


  1. Hi there.  My name is Paul Wade and I'm a liaison for The Vision Council.  I'd like to see if I can help you with this but it might be better if you contact me directly.  You can email me at pwade@thevisioncouncil.org.  If you could include some more detail about the system you are trying to design I can try and provide you with some documentation that might help with your goal.


  2. I don't know how helpful or relevant it would be, but since we have hinted at TVC hosting the lens data at some point it might be helpful to start specifying how that system might work.  It will at least enable us (TVC) to start examining our infrastructure to see what would be needed to support such a platform.  Perhaps an open discussion around that?


  3. 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


  4. 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

    • Like 1

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


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


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


  8. 1 hour ago, Robert Shanbaum said:

    It would appear that some elaboration of the definition of PROC records is called for. ...  

    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?


  9. On 4/8/2018 at 12:43 PM, Yaron [LaserOp] said:

    Sorry, accidentally posted the previous one too soon. Full one follows here:

    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?


  10. 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).