Paul Wade

Administrators
  • Content count

    40
  • Joined

  • Last visited

Community Reputation

0 Neutral

About Paul Wade

  • Rank
    Advanced Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

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

    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.
  5. 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?
  6. 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?
  7. 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).
  8. 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.
  9. 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.
  10. 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?
  11. 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?
  12. 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.
  13. 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.
  14. 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.
  15. 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?