Yaron [LaserOp]

  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About Yaron [LaserOp]

  • Rank

Recent Profile Visitors

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

  1. I think this is the current consensus on the discussion here. Though if any silent readers of this thread have some contrary experience with handling of such labels, now would be a good time to mention it. I also agree with Etienne that it's probably then a good idea to make the singleton/repeated characteristic be made into explicit defined terms in the Standard. This is a Standard, so if this characteristic is explicitly referred to by something (which it will be now), then it needs to be explicitly and clearly defined. I do not think, however, that there is a need to then go and explicitly list in the DCS for each and every record how it falls (or make a list), as that would be very easy to infer for each record based on the definition. Related, in addition to mentioning this in PROC/PROCBLK, the same note should probably be in other methods of sending data to the LMS. Since the expected (but currently implicit and unlisted) behavior there is the source of assuming this should also be the behavior in the context of PROC, and LMS are probably acting this way anyway, this is a good opportunity to make it explicit in the standard as well.
  2. Robert, Sorry if I wasn't clear. I used tracing as an example to illustrate that there already exist cases of labels which can have different distinct instances even though technically these different instances have the same name. Of course traces aren't ever expected to be handled that way. But they can show the concept of having a label with the same name, passing the same sort of data, while still being distinct from another label of the same name, where pretty much everyone would agree wanting to modify one does not affect the other. (e.g. if you won't erase all existing traces if you receive just a new one, why would you erase all engravings or drills, when you receive a new one?). And we are already in agreement that having one record present shouldn't affect another different record. That, again, was the point I was trying to illustrate, that in practice non-singleton records like ENGMARK are all also different, even though they have the same name, so having one like that in a PROC shouldn't mean the others should be changed.
  3. Second, this still focuses on when everything comes from a single source. That is, in your example there are no ENGMARK records on the LMS before this data packet. But what when there are? Suppose the LMS is set to always engrave some feature the lab wants, so when a job is created it automatically populates it with "ENGMARK=Lab feature 1". (Let's even assume it's for area that will be removed by the edger, so no issues with other agreements/expectations by some LDS vendors on what will be engraved) Then one of the LDS vendors in the lab have their own engraving layout, so when the LMS asks them to calculate the job, they send a packet including ENGMARKs as in your example (either case). What should one of the "basic engravers" receive from the LMS? Option 1: ---------- ENGMARK=Plain feature 1 ENGMARK=Plain feature 2 Option 2: ---------- ENGMARK=Plain feature 1 ENGMARK=Plain feature 2 ENGMARK=Lab feature 1 I'd expect option 2. I get that Robert would also expect option 2. That's the basic difference of receiving data about pre-existing labels, between the singleton and non-singleton ones. So if even without PROC singleton labels should be replaced but non-singleton labels should be added, then providing more of then through PROC should follow the same process, because that is what is already being done without PROC. - As an aside, of course a problem with this "add" attitude for non-singleton labels is that there is no obvious way to replace/delete such labels if needed. But similarly with the "replace" attitude for non-singleton labels there is no way to add them. And not being able to add such labels (something that is useful and in demand and is already being done with workarounds) is a much much bigger problem than not being able to replace them (which seems less often useful, and which maybe can be easily provided by something else, like maybe an additional ACT to REQ=CMD for clearing specific labels? Can probably wait until and if someone actually asks for it. Or maybe allow to force-clear a non-singleton label by sending it empty to the LMS, the downside being that this will have to be ordered but at least for PROCBLK everything is already decided to be ordered ).
  4. Paul, First, regarding: That's not entirely correct. Or, well, it depends on how you look at it. A singleton record will behave that way, on account of being a singleton. When you send PROC=SBFCIN you replace ALL of the SBFCIN record. But you do that because there is only one SBFCIN. But with a non-singleton records, they may all have the same label name, but they're different entities. So bunching them together is not unlike saying that, for example, SBFCIN and SBFCUP are very closely related, so having a PROC with just SBFCUP should also remove (zero) an upper/general SBFCIN. That idea sounds immediately wrong, because they have the same name, but they do come together and serve a closely-related purpose. Non-singelton records are sort of like that too, they do share a name but they're otherwise different entities representing different things. ENGMARK="Plain feature 1" is not the same as ENGMARK="Plain feature 2", these are two different individual records, doing two different things. Or, better example, since it's sort-of-not-entirely-singleton, what about most datasets? consider: TRCFMT=1;128;E;R;F R=... TRCFMT=1;128;E;L;F R=... PROCBLCK=1;ENG;.... 1!TRCFMT=1;240;E;R;F 1!R=... If an engraver later asks the LMS for frame trace, for the right side there would be one based on (of course currently possibly interpolated otherwise) the 240 points trace. For the left lens sent to an engraver... do you think there should be one based on (and again possibly interpolated) the 128 points trace? or do you think there should be no trace sent? What seems to me like the natural expected answer is that the engraver would receive frame traces for both eyes, one from the 128 source and one from the 240 source. But, well, with the "replace for non-singleton" attitude, TRCFMT has been replaced for engravers. So engravers only have TRCFMT explicitly set for them. Which has a right trace, but doesn't have a left trace. This feels like the wrong interpretation. But it follows the same logic for labels like ENGMARK, the only difference is that there can be N copies of ENGMARK but 2 copies of TRCFMT. But, again, both these two TRCFMT copies are called TRCFMT, so... I guess you probably agree that both TRCFMT datasets are distinct, even though they both use the same names of labels. And agree that replacing that dataset for one eye in PROC wouldn't affect the identically-named labels for the other eye. So why is that different for ENGMARK, or for DRILLE datasets, or other non-singleton labels?
  5. The problem with option one (everything is "replace", including non-singleton labels) isn't just record duplication and so it being less graceful. That is indeed the problem, but only for the case of an initial upload of data for an empty (at least of related label) job. But for all other scenarios (e.g. LDS uploading data to a job that already has some initial records because it was created earlier by the LMS or another customer/lab system, or alternately any other device that is modifying job data - which is something that can and does happen and is supported by the standard) this is not the case. Because in all such cases the machine that sends/uploads the data knows what it wants to send, but not what is already in the LMS for that job. Which brings back the same issue. If something wants to modify a singleton (BTW, Robert, thanks, I think it's a good term for this) label, pretty much by definition it wants to replace it, and this only happens when it "knows" that what is was before doesn't matter and should be replaced. But for a repeating (not that crazy about this term, but usable) record this isn't the case. It doesn't have to be the case, and I of course think similarly to Robert that it's not even the usual/normal/common/expected case. For these repeating records it's much more likely (though my opinion is again admittedly skewed by familiarity mostly with ENGMARK) the desire is to add something rather than overwrite/replace all other instances (which may have come from several different sources anyway). - It's true that the third option (default behavior is "replace" for singleton labels but "add" for repeated ones) will require LMS (and other devices sending/using them) to know which label is singleton and which isn't. But... they sort of have to do that now anyway, even if it's not given an explicit term in the DCS. Because an LMS has to know how to handle these anyway, and knowing how many copies are valid is already a part of that. So it shouldn't put an extra effort on anything/anyone, it's an effort they already have to do. Again, if an LMS receives a job update with e.g. GAX it already must know it's a singletion, and if it receives one with e.g. ENGMARK it already must know it isn't. It's not just an issue with PROC, it's an issue with regular job data updates. PROC just makes it more important that the standard will be explicit in the handling, rather than having people make implicit assumptions as must have happened so far (e.g. just like Robert's LMS). The logic of how it happens on PROC must match the one of how it happens without PROC. Which, again, is very probably adding repeating records and not replacing them (which is for sure what is happening in real-world cases with ENGMARK. I personally don't know about real-world cases with other repeating records, but would assume similar simply by the fact that they are indeed repeating).
  6. Paul, That would be consistent, but has a few problems and disadvantages: Not so much a technical problem as a semantic one - it's not as obviously the intent as in other cases. When something tells the LMS that "GAX is X in general, and Y for device M" it's obvious that it's just Y for device M, and couldn't possibly mean anything else in any case, because any other possible interpretation is meaningless. But with records like ENGMARK it's not obvious, but rather an arbitrary decision. Because it can make sense to replace, but can also make sense to add (e.g. "ENGMARK is X in general, and Y for device M" can sensibly mean either "device M would just have ENGMARK of Y" or "device M would have ENGMARK of X and Y". it's a different case, compared to the "normal" case that is so obvious that the interpretation was more naturally assumed than discussed and decided upon. A major part of the purpose of PROCBLK over PROC is efficiency. But if for multiple ENGMARK labels there is a device that just needs one more, then having to list all of the main/general ones again is counter productive. PROCBLK should work essentially like a series of PROC labels, the differences being to avoid re-sending the same type/vendor/device qualifiers multiple times, and to allow data sets. But, and I think it's a very big but, if PROC interprets ENGMARK as "replace" rather than "add" then... the behavior of PROC is suddenly a bit weird, a single PROC with ENGMARK will replace *all* general ENGMARKs with the new single ENGMARK. But a second PROC, for the same device, with ENGMARK will... add to that device? That would be the correct behavior in context. Which means that already for such labels the default action is to add rather than replace. Related to the previous point, again I assume the default behavior overall for these types of labels is to add rather than replace, no? What would happen on an LMS that has an existing job, with several ENGMARK records and a GAX record, if it receives a REQ=CMD with ACT=MERGE that has an ENGMARK label and a GAX label? I'd expect it will "replace" GAX, but will "add" ENGMARK. So same sort of logic should apply. Unless I'm wrong in the basic assumption on the previous two? In that case, how does anything tells the LMS to add an ENGMARK (or DRILLE, or whatever other multiple-instance labels there may be) record to what it already has? There are potential uses for wanting to have different ENGMARK (and such) records between device. But there are also potential uses for wanting to have a common set of ENGMARK records and then add one/some to specific devices. Which is the more common/wanted/helpful one should be a consideration. Personally I already know of various labs who use our machines in a way to combine additional labels with what the LMS is sending the laser by default, and these pretty much invariably are used to "add" ENGMARK/ENGMASK labels, and sometimes to "replace" other labels. With PROC/PROCBLK support in the LMS this would be something that can (and probably should) be transferred to happen through the LMS, since the LMS would be capable of handling it. But automatic "replace" means that even an LMS capable of different per-device records won't be able to replace the current workarounds for sending different labels to the engraver. Anecdotally while I'm aware of quite a few labs adding ENGMARK records this way, I'm not aware of any using the same method to replace all ENGMARK records. Related, the different-records-for-different-devices ability is potentially useful enough that it will likely go beyond just initial packet from LDS when creating new job details. This is useful for integration with various management/maintenance systems and such, as a way to put additional data into the LMS. Something which I assume is already sometimes happening, just for the general for-all-devices option (e.g. using REQ=CMD with ACT=MERGE or upload packets, or whatever). Expanding those to include PROC/PROCBLK seems like a natural usage for the new feature. And again, for multi-instance labels it can make a lot more sense to add for specific cases, rather than replace. Notice that for the original main LDS packet, both possibilities are doable. to "add" when the default is "replace" they just, as you mentioned, re-send everything to each device. And to "replace" if the default is "add" they just avoid sending these labels in the general section and duplicate for all relevant PROCBLK types. In either case the "do something differently from the default" would be more verbose, so it's probably better to make the default the more common case. But, for any other device/software modifying job data later, it's not possible to "add" if the default is "replace", and not possible to "replace" if the default is "add". So the very important question is what are such devices/programs more likely to want to do? Which again, I think (and know at least for ENGMARK based on experience) would be "add".
  7. Sorry, accidentally posted the previous one too soon. Full one follows here: One comment, Sorry for not catching this earlier, this is per my #2 points earlier, which on re-read Paul's response didn't explicitly cover, and I think that the implicit assumption (now made explicit with the ENGMARK example in the modified proposal, which otherwise on a quick read seems good) now is wrong. Specifically, everything now seems fine for most labels, for which there is only a single valid value (e.g. GAX for a lens, for the same machine, cannot be both 90 and 0). The problem is for labels which can have multiple different copies, all valid. The main example that springs to mind for me (since it's what our machines deal with) is ENGMARK, but I'm sure this isn't the only case (like maybe DRILLE records? others?). That is, on data packet like DO=B ADD=1.75;2.50 ENGMARK=MASK;MainDesign;.... ENGMARK=TXT;A;.... ENGMARK=TXT;B;.... ENGMARK=DCS;ADD;.... ... *all* of the ENGMARK records will be used (depending on other data labels like front/back left/right and ENG/INK, not relevant in this context). An engraver would engrave all 4, the main design mask, two explicit texts, and one text with value of ADD. So then what happens on: DO=B ADD=1.75;2.50 ENGMARK=MASK;MainDesign;.... ENGMARK=TXT;A;.... ENGMARK=TXT;B;.... ENGMARK=DCS;ADD;.... ... PROCBLK=1;ENG;VEN1;... 1!ENGMARK=MASK;ExtraVen1... With the current (and logical and correct) attitude towards labels in general, the engraver by VEN1 would *only* engrave the mask "ExtraVen1". That's... a valid interpretation. But I think in most cases for such labels it would make more sense if this was in addition, rather than a replacement (that is, all engravers would have 4 things to engrave, ExtraVen1's engraver will have 5). Both can make sense in different situation (which is why maybe worth considering in the future so more explicit way to decide, but that can get very complicated very fast). But from what I can think about in these situations I'd assume that "add these" may make more sense, more often, than "replace these". Though opinions from anyone who may theoretically send these things would certainly be better than mine in this context, as to the likeliest interpretation. (And I'm also thinking about a natural expansion of the usage of these, in labs where maybe they have another system that knows of some "tweaks" a few devices need which may not be considered by the LDS. It can make a lot of sense for these to also send additional job data to an LMS taking advantage of PROC/PROCBLK, and again in those cases single-value labels make absolutely sense for replace/override, but multiple-valid-values labels could make more sense as "also add this for that device", which I know for sure is a wanted usage since we already have labs doing this in general)
  8. Paul, What are the additional issues with no limit? Can you please elaborate? If people are voting preferences then giving reasons could help people who aren't sure. For a machine/software it doesn't matter, for a person they'll maybe need to perform the (very minimal) effort of scrolling anyway so just how much scrolling shouldn't really matter (and word-wrap exists and is very very common if scrolling sideways is really not wanted). For datasets... to clarify this won't create an option for the entire data set on a single line, since datasets contain multiple different labels, and individual records/labels still need to be on different lines. You instead meant about each different single label (and single logical data record) in a dataset being just once in a single line instead of spread over multiple lines, yes? That seems to me like an advantage, rather than a problem, for the following reasons: Semantically it makes sense. If all those multiple records are logically just a single continuous record (e.g. R records after TRCFMT), then sending a single record is a better fit than splitting. Instead of taking a *single* record and sending it as if it was *multiple* record, you just send a *single* record as if it was... a *single* record. It will probably actually be easier for a person wanting to read the record, once the limit is such that scrolling sideways is needed anyway. With a single record/line you always know where you are, and how/where the data continues. You want to keep reading, you keep scrolling to the right. With a split over multiple records you keep scrolling back and forth (e.g. right until the end of one line, then back left to the beginning of another, then right to the end of that one, then left to the start of the next one). More effort, more context switches, more hassle. It's easier for people going through the data who don't care about that particular data-set/record. Instead of having to skip down over multiple (sometimes pages-full of) lines, these take the same one line (or just a few for a dataset) and then on to the next label. I mean, assume you don't care about the trace, which of these is easier to go over (this sample is mostly junk, copied and increased from a sample in the DCS, not real data, intended for visualization purpose only) ? LIND=1.53;1.53 JOB=12345 SVAL=7.52;7.23 TRCFMT=1;400;U;R;F<CR/LF> R=2479;2583;2605;2527;2394;2253;2137;2044;1975;1935<CR/LF> R=1922;1939;1989;2072;2184;2322;2471;2599;2645;2579<CR/LF> R=1909;1914;1941;1983;2033;2089;2140;2200;2277;2371<CR/LF> R=2479;2583;2605;2527;2394;2253;2137;2044;1975;1935<CR/LF> R=1922;1939;1989;2072;2184;2322;2471;2599;2645;2579<CR/LF> R=1909;1914;1941;1983;2033;2089;2140;2200;2277;2371<CR/LF> R=2479;2583;2605;2527;2394;2253;2137;2044;1975;1935<CR/LF> R=1922;1939;1989;2072;2184;2322;2471;2599;2645;2579<CR/LF> R=1909;1914;1941;1983;2033;2089;2140;2200;2277;2371<CR/LF> R=2479;2583;2605;2527;2394;2253;2137;2044;1975;1935<CR/LF> R=1922;1939;1989;2072;2184;2322;2471;2599;2645;2579<CR/LF> R=1909;1914;1941;1983;2033;2089;2140;2200;2277;2371<CR/LF> A=0;90;180;270;360;450;540;630;720;810<CR/LF> A=0;90;180;270;360;450;540;630;720;810<CR/LF> A=0;90;180;270;360;450;540;630;720;810<CR/LF> A=0;90;180;270;360;450;540;630;720;810<CR/LF> A=0;90;180;270;360;450;540;630;720;810<CR/LF> A=900;990;1080;1170;1260;1350;1440;1530;1620;1710<CR/LF> A=35100;35190;35280;35370;35460;35550;35640;35730;35820;35910<CR/LF> ZFMT=1;100;U;R;F<CR/LF> Z=322;331;342;328;314;308;300;295;288;280<CR/LF> Z=316;318;324;328;333;343;349;352;357;362<CR/LF> Z=316;318;324;328;333;343;349;352;357;362<CR/LF> Z=316;318;324;328;333;343;349;352;357;362<CR/LF> Z=316;318;324;328;333;343;349;352;357;362<CR/LF> Z=316;318;324;328;333;343;349;352;357;362<CR/LF> Z=316;318;324;328;333;343;349;352;357;362<CR/LF> Z=316;318;324;328;333;343;349;352;357;362<CR/LF> ZA=0;360;720;1080;1440;1800;2160;2520;2880;3240<CR/LF> ZA=0;360;720;1080;1440;1800;2160;2520;2880;3240<CR/LF> ZA=0;360;720;1080;1440;1800;2160;2520;2880;3240<CR/LF> ZA=0;360;720;1080;1440;1800;2160;2520;2880;3240<CR/LF> ZA=0;360;720;1080;1440;1800;2160;2520;2880;3240<CR/LF> ZA=0;360;720;1080;1440;1800;2160;2520;2880;3240<CR/LF> ZA=32400;32760;33120;33480;33840;34200;34560;34920;35280;35640<CR/LF> TRCFMT=1;400;U;L;F<CR/LF> R=2517;2450;2379;2318;2247;2168;2086;2014;1958;1923<CR/LF> R=1909;1914;1941;1983;2033;2089;2140;2200;2277;2371<CR/LF> R=1909;1914;1941;1983;2033;2089;2140;2200;2277;2371<CR/LF> R=1909;1914;1941;1983;2033;2089;2140;2200;2277;2371<CR/LF> R=1909;1914;1941;1983;2033;2089;2140;2200;2277;2371<CR/LF> R=1909;1914;1941;1983;2033;2089;2140;2200;2277;2371<CR/LF> R=1909;1914;1941;1983;2033;2089;2140;2200;2277;2371<CR/LF> R=1909;1914;1941;1983;2033;2089;2140;2200;2277;2371<CR/LF> R=1922;1939;1989;2072;2184;2322;2471;2599;2645;2579<CR/LF> A=0;90;180;270;360;450;540;630;720;810<CR/LF> A=900;990;1080;1170;1260;1350;1440;1530;1620;1710<CR/LF> A=900;990;1080;1170;1260;1350;1440;1530;1620;1710<CR/LF> A=900;990;1080;1170;1260;1350;1440;1530;1620;1710<CR/LF> A=900;990;1080;1170;1260;1350;1440;1530;1620;1710<CR/LF> A=900;990;1080;1170;1260;1350;1440;1530;1620;1710<CR/LF> A=35100;35190;35280;35370;35460;35550;35640;35730;35820;35910<CR/LF> ZFMT=1;100;U;L;F<CR/LF> Z=322;331;342;328;314;308;300;295;288;280<CR/LF> Z=316;318;324;328;333;343;349;352;357;362<CR/LF> Z=316;318;324;328;333;343;349;352;357;362<CR/LF> Z=316;318;324;328;333;343;349;352;357;362<CR/LF> Z=316;318;324;328;333;343;349;352;357;362<CR/LF> ZA=0;360;720;1080;1440;1800;2160;2520;2880;3240<CR/LF> ZA=0;360;720;1080;1440;1800;2160;2520;2880;3240<CR/LF> ZA=0;360;720;1080;1440;1800;2160;2520;2880;3240<CR/LF> ZA=0;360;720;1080;1440;1800;2160;2520;2880;3240<CR/LF> ZA=0;360;720;1080;1440;1800;2160;2520;2880;3240<CR/LF> ZA=32400;32760;33120;33480;33840;34200;34560;34920;35280;35640<CR/LF> GAX=0;90 ADD=2.75;150 or: LIND=1.53;1.53 JOB=12345 SVAL=7.52;7.23 TRCFMT=1;400;U;R;F<CR/LF> R=2479;2583;2605;2527;2394;2253;2137;2044;1975;1935;1922;1939;1989;2072;2184;2322;2471;2599;2645;2579;1909;1914;1941;1983;2033;2089;2140;2200;2277;2371;2479;2583;2605;2527;2394;2253;2137;2044;1975;1935;1922;1939;1989;2072;2184;2322;2471;2599;2645;2579;1909;1914;1941;1983;2033;2089;2140;2200;2277;2371;2479;2583;2605;2527;2394;2253;2137;2044;1975;1935;1922;1939;1989;2072;2184;2322;2471;2599;2645;2579;1909;1914;1941;1983;2033;2089;2140;2200;2277;2371;2479;2583;2605;2527;2394;2253;2137;2044;1975;1935;1922;1939;1989;2072;2184;2322;2471;2599;2645;2579;1909;1914;1941;1983;2033;2089;2140;2200;2277;2371<CR/LF> A=0;90;180;270;360;450;540;630;720;810;0;90;180;270;360;450;540;630;720;810;0;90;180;270;360;450;540;630;720;810;0;90;180;270;360;450;540;630;720;810;0;90;180;270;360;450;540;630;720;810;900;990;1080;1170;1260;1350;1440;1530;1620;1710;35100;35190;35280;35370;35460;35550;35640;35730;35820;35910<CR/LF> ZFMT=1;100;U;R;F<CR/LF> Z=322;331;342;328;314;308;300;295;288;280;316;318;324;328;333;343;349;352;357;362;316;318;324;328;333;343;349;352;357;362;316;318;324;328;333;343;349;352;357;362;316;318;324;328;333;343;349;352;357;362;316;318;324;328;333;343;349;352;357;362;316;318;324;328;333;343;349;352;357;362;316;318;324;328;333;343;349;352;357;362<CR/LF> ZA=0;360;720;1080;1440;1800;2160;2520;2880;3240;0;360;720;1080;1440;1800;2160;2520;2880;3240;0;360;720;1080;1440;1800;2160;2520;2880;3240;0;360;720;1080;1440;1800;2160;2520;2880;3240;0;360;720;1080;1440;1800;2160;2520;2880;3240;0;360;720;1080;1440;1800;2160;2520;2880;3240;32400;32760;33120;33480;33840;34200;34560;34920;35280;35640<CR/LF> TRCFMT=1;400;U;L;F<CR/LF> R=2517;2450;2379;2318;2247;2168;2086;2014;1958;1923;1909;1914;1941;1983;2033;2089;2140;2200;2277;2371;1909;1914;1941;1983;2033;2089;2140;2200;2277;2371;1909;1914;1941;1983;2033;2089;2140;2200;2277;2371;1909;1914;1941;1983;2033;2089;2140;2200;2277;2371;1909;1914;1941;1983;2033;2089;2140;2200;2277;2371;1909;1914;1941;1983;2033;2089;2140;2200;2277;2371;1909;1914;1941;1983;2033;2089;2140;2200;2277;2371;1922;1939;1989;2072;2184;2322;2471;2599;2645;2579<CR/LF> A=0;90;180;270;360;450;540;630;720;810;900;990;1080;1170;1260;1350;1440;1530;1620;1710;900;990;1080;1170;1260;1350;1440;1530;1620;1710;900;990;1080;1170;1260;1350;1440;1530;1620;1710;900;990;1080;1170;1260;1350;1440;1530;1620;1710;900;990;1080;1170;1260;1350;1440;1530;1620;1710;35100;35190;35280;35370;35460;35550;35640;35730;35820;35910<CR/LF> ZFMT=1;100;U;L;F<CR/LF> Z=322;331;342;328;314;308;300;295;288;280;316;318;324;328;333;343;349;352;357;362;316;318;324;328;333;343;349;352;357;362;316;318;324;328;333;343;349;352;357;362;316;318;324;328;333;343;349;352;357;362<CR/LF> ZA=0;360;720;1080;1440;1800;2160;2520;2880;3240;0;360;720;1080;1440;1800;2160;2520;2880;3240;0;360;720;1080;1440;1800;2160;2520;2880;3240;0;360;720;1080;1440;1800;2160;2520;2880;3240;0;360;720;1080;1440;1800;2160;2520;2880;3240;32400;32760;33120;33480;33840;34200;34560;34920;35280;35640<CR/LF> GAX=0;90 ADD=2.75;150 The purpose behind data sets, as far as I can see looking at all existing ones, is to allow related sets of *diferent* labels (e.g. you can't replace entire TRCFMT with just a complete R label, and same for each one, they all have more than a single current label will contain). The length limit means that potentially data sets have to be also used for what can be just a *single* label. This is indeed an existing side-effect for the fact that the length limit currently exists, but I really don't think it's the *purpose* . Plus, and this one is important for that concern, for people who don't want scrolling to the side, pretty much every text viewer/editor these days has built-in word-wrap feature. Which should make this much much easier for anyone who considers this important: Keeping the 80 limit could make sense for machines/software that were made with the 80 characters as an explicit assumption in the code. But once that is waived (as would be needed anyway for an increase to 120 characters, and as is already waived for some label individually so essentially those machines are already not compatible and not supported) then forcing a new limit doesn't seem to me like a good idea. And keeping it will make it hard to create future labels that maybe need more data, and could very easily fit inside a single label, and instead keep it a requirement to create them as datasets (as a quick example, ENGMARK was created explicitly to be generic enough for future types of data. In theory if someone needed it, it can be easily extended to allow sending complete set of coordinates of shapes to engrave, in a single record. But with the line limit, suddenly for something that would work just fine in a single ENGMARK, you'll need to create a special new data set, to hold the exact same data. And again, this is just an example, the same can happen in multiple other cases).
  9. Actually 3 more comments. All of these are also relevant to original PROC, which entered without dealing with them, so probably don't justify delaying adding PROCBLK to the standard if there isn't a quick agreement on them: 1. Record length. If any record can reach the 80 characters limit, then PROC (and prefixed records in PROCBLK section) carrying the same data would overrun that limit. And these records must be able to carry the same data, so by definition can overrun the limit. There aren't any really good options beyond dropping the limit altogether, which I personally suspect is fine (probaby nobody reads the data on fixed-length terminal screens, which I assume was the original reason), but it seems somewhat out of scope to just happen as an implicit byproduct of adding PROC+ without further discussion. 2. What is the handling of non-singular records? That is, of course there is only one LIND so if there is a better-fitting one in PROC+ it takes precedence. But what if a label makes sense multiple times, like for example if someone sends ENGMARK inside a PROCBLK? Should these replace ENGMARK (and such) records in lower-fit (or general) areas? Be added to them always and never replace them? Should there be a further modifcation to the structure to have a way to indicate this explicitly, since both could make sense depending on the individual case? 3. If something is defined/replaced in a lower-fitting area, and then not mentioned in an existing higher fitting one, should they be taken from general area or the best-existing area? I expect the intent is the latter, but without it being explicitly stated in the standard it's entirely possible for an LMS to decide to only consider the general and best-fit areas and ignore interim ones. To clarify, if that was too unspecific, imagine: 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 For devices not of type DEV both labels are 1. For devices of type DEV by a vendor that isn't VEN, both are 2. For devices of type DEV from vendors VEN, it is clear that A is 3, but it is not explicitly clear that B is 2 and not 1. Should the logic be "try to find the best fit for each label", or should it be "find the best fit block for each device and only use that with the general/global labels"? Again, I'm pretty sure it's the first, but see how the second could seem like a reasonable interpretation, so whichever is true should be mentioned explicitly.
  10. The "have all the details in every line" is indeed not different from PROC. And since the whole idea behind PROCBLK was to avoid listing all the details over and over per each label, and since the discussion wouldn't have gotten this far if there wasn't general agreement among members that it's a good idea... this one probably shouldn't be it, it's just a more complex way of saying "no, just using PROC is fine". Which, again, it's considered to not be. About the unique prefix/identifier or not, again I see the main benefit as the ability to not keep things in order. So if it seems like a good benefit then having a prefix/identifier and no order requirement is the way to go, otherwise not having a per-block identifier is probably better. Why I don't think having a per-block identifier, while still keeping order, is a good idea: Technically, for machines/devices/software processing the data it's entirely useless. This is additional field, and data, and processing complexity, that serve no technical purpose, since if the labels are ordered then it's already completely known without being listed. Regarding: That may be true, but... well, why would the support/technical people reading the lms files (or communication logs) using notepad instead of one of the very many better text editors that can provide syntax highlighting? There are even lots of fantastic free ones. And they make life much easier for a lot of reasons. I mean, using a copy from the example file provided by Steve, do you really have any difficulty locating PROCBLK here: Or, alternately, same topic, if the purpose of the identifier is only to be human-visible anyway, why not instead specify that any PROCBLK label must be preceded by a few REM ones? That would create a very distinct visible break all by itself, while adding no complexity/logic for any device having to parse the data: Easier for everyone, and a lot less work to implement. Regarding These all have to be ordered, though, not just in terms of what they relate to (e.g. this R is related to that TRCFMT ), but also on individual sequence (this R is immediately after that R which is immediately after that R...) . But these PROCBLK sections only has the first aspect (which since section/dataset they relate to), without having any care about internal order beyond that. Well, unless there's another dataset inside a block, but that one would need to be ordered anyway regardless of where it is, and is not related in order to other labels. Not using an identifier per bloc, justifies having these follow the block in order, since there isn't another way to do that first type of connection. But having an identifier means that this relation is already done, and doesn't have to be maintained further. At which point it's no different from any other label in the standard that can be anywhere, and not enforcing order is the common case on the standard, not the exception. So, again, I like the prefix/identifier idea and think it was a good suggestion, but I don't see the benefit if it isn't used to remove the order requirement. Whether the order requirement is a good idea, is a different topic. I like "no" as the answer, but am not sure there's a good enough reason to add the effort of identifiers for it. What I see as potential reasons/usage-cases for not forcing order is mainly that I'm not sure there is a benefit to force order, and so why force a limitation without good reason? There are two main not-entirely-haphazard ways to send this type of data (main common record pool, and per-case exceptions): By case/device. As in the current ordered examples, an entire section for the general/common pool, and individual sections per case. It makes sense for the device/program creating it if they order things logically per case, and is useful when reading it (by a person) caring more about "what should everything be for case/device X?" By record/label, as is currently done most of the time, and as in the previous/ordered case is done internally per each section. All LMATID are together, all GAX are together, and so on. It makes sense for the device/program creating it if they iterate over available labels, and is useful when reading it (by a person) if caring more about "what is going on with label X?" . I'm not at all sure that the second scenario is more common/important/useful than the previous one. It's just that I'm also not at all sure that the previous one is that much more common/important/useful than this one. But forcing order enforces the previous one, while not forcing order leaves the decision to whatever creates the data blocks (nothing prevents them from still listing everything in order per PROCBLK, they just don't have to if they think it will be better otherwise). The main reason I saw mentioned for forcing order relates to: While I don't think scrolling a few lines up to PROCBLK is a problem, it can be a noticeable increase in effort to then search for "PROCBLK=prefix" and go back (minor for someone used to taking advantage of text editor features like bookmarks and "go-to-previous-location", but a bigger hassle otherwise (due to either habits or using a limited viewing tool). On the other hand, while the above problem is entirely true if checking a single label (e.g. LMATID), it's not so much if caring about multiple labels anyway. Since the work (scrolling up, or search then go-back) it split among multiple labels. And so that real but small effort would quickly become relatively negligible. Also, as a person going over a file that has multiple PROCBLK sections, I won't start by searching for LMATID, I'd start by searching for PROCBLK. Because there can be more than 1 that affects a device. e.g. in: If I need to know what happened for FSG;OPT;PLR then the labels needed may be spread among general/common ones, block 4, and block 5, in that increasing order of priority. At which point sorting out, say, all of LMATID, GAX, LIND: I have a very easy time finding which one I care about, and I already know what index values I want and which I don't. And this is from a file where they're not in order. Actually I think that having the identifiers (e.g. look for 4 or 5) makes it easier than if everything was in a line. Once you know what "5" is, it's easier to keep parsing (visually) than repeated "FSG;OPT;PLR;", it's less visually condensed and information-heavy. Having these in order would make things a bit easier here, but isn't really that much of a difference.
  11. Paul, thank you for that, it's good to have followup. (And I think can be a good idea in general to maybe post all topics post-meeting, to give even the people who were involved time to think things through more than is possible during a live meeting). Generally this seems good, just a few thoughts: The big, and only, benefit I see with having a variable/dynamic prefix per block is the ability to ignore the ordering requirements, since then the records then don't really have to be contiguous, and it's obvious which in-block line belongs to which block. But if they have to be contiguous and follow the PROCBLK record, like other datasets, then the different numbers add complexity with no benefit. In such case a fixed prefix (e.g. "B!" or always "1!", or whatever) would do just as well since anyway there can only be one active block at a time (same reason for existing datasets none of the "following" labels bothers to identify the first one it relates to, they're already strictly related by the order). Adding complexity for a potentially useful feature (and reducing the amount of exceptions to the no-order rule) is very valid, but adding it and then explicitly not using it and its benefit... isn't so much. Maybe it can be better to avoid having a new element (and separator) add to the "record" type, and instead just add a label for block content that accepts as first two fields the block identifier (prefix currently) and original label name (e.g. instead of "1!LMATID=70;70" use "B=1;LMATID;70;70") ? That avoids the need for a special record element and separator type entirely (no need to touch the definition of a record), in exchange for just one other label. Same functionality, about same amount of effort to parse. Is the "there's a new element type in a record" change not a bigger one than adding one more label?
  12. I won't be in the DCS meeting, which is why I'm trying to be very clear and detailed about the comments, so all the points will be available for the people involved in the discussion. (plus, well, I think it's a very good idea in general to consider things in advance, without the time limit of a live meeting, and so it's unfortunate that it seems nobody but you raised any planned discussion point here in the forums before the meeting) Regarding PROCBLK, yes, I think it's well covered at this point. Thank you. On SDFMODE... almost. Yes, I think full URI should be in LDPATH. No, I don't think SDFMODE should be completely removed. Unless, that is, the decision in the meeting is that the LMS value is unused and should be deprecated. In that case, yes, I do think SDFMODE can be completely removed as well. The functionality of it... is not stating the protocol to access LDPATH, but rather the mode of operation with the surface data referred to by LDPATH (FILE: on Host copy LDPATH as is, on device read surface data from LDPATH. LMS: on Host read surface data from LDPATH and send inline, on device read surface data inline and disregard LDPATH) No, I disagree that this position is a change of the original design/intent for SDFMODE and LDPATH, and I disagree that SDFMODE was originally intended as a way indicate the "protocol" to use. I claim that this change (having full URI for surface data in LDPATH, regardless of where the data is coming from) is very much in accordance with the original intent and definition. - That third point (not an actionable item itself, but probably a valid consideration when deciding about the actionable items) may need some explaining. These are what I see as strong indications that putting full URI in LDPATH, while keeping the same FILE value (or removing altogether) in SDFMODE, is as per the original design, and that specifying protocol in SDFMODE isn't: SDFMODE currently has 4 possible types of values. Two of which (LMS, FILE) are very clearly defined. The other two have a lot of vague/open parts in their definition (which I assume you agree with, as it seems a part of the reason you wanted to improve things). So for figuring "original intent" the better defined parts should weigh more. The two better-defined values don't actually specify a "protocol". So SDFMODE can't have been intended to specify the protocol of LDPATH. FILE isn't a protocol. Notice that right now it can be used (and often used) for local Windows file system paths (NTFS, FAT, ... ), or for local Unix/Linux file system paths, or for network shares using samba/SMB protocol (which is pretty much assumed as built-in for Windows, but certainly isn't/wasn't for earlier Unix/Linux systems and would have required special handling from such computers, or other devices). So already there are several different protocols that can be used to access surface data from LDPATH, none of which are explicitly named. So current uses of SDFMODE+LDPATH are, at about 100% of them, taking protocol data from LDPATH. LMS also isn't a protocol for how to parse LDPATH either. For a device receiving it, it means LDPATH isn't used. For an LMS using it... it means that LDPATH still contains a file source data path, but without any data on how or what it is. While I didn't see the original version of the DCS where SDFMODE was added in, and I wasn't involved in the discussions prior, I feel very confident (but please correct me if I'm wrong) in assuming that LMS and FILE were the main (or even only at first) values that the VC committee wanted to include, and the ftp/http mentions were added later or as a rough afterthought for "just in case we'll need something like that in the future". When sending data LDS->LMS it's possible (as per current definition of these labels) that SDFMODE will be LMS and then LDPATH will still contain a URI to the file path (in fact it's practically required). The Host is required to get the surface data from LDPATH, even though SDFMODE doesn't specify any "protocol". So the intent *can't* coherently be for the protocol to be in SDFMODE. The Host reading surface data from LDPATH (when SDFMODE=LMS) needs *exactly* the same info that a device needs to read surface data from LDPATH (when SDFMODE is something else), they're doing the exact same thing at that point. But for the Host... SDFMODE is already used. e.g. If on LDS->LMS communication SDFMODE=LMS, then it's possible that LDPATH=\\server\share\file.sdf , or that LDPATH=/mnt/somwhere/file.sdf or LDPATH=c:\folder\file.sdf . Without the FILE value being anywhere. But what if a new/future LDS will *still* want the Host to forward the data as in SDFMODE=LMS, but will share it files with the LMS/Host through an ftp server? It *can't* send both SDFMODE=LMS *and* at the same time SDFMODE=ftp://... . So it must send SDFMODE=LMS, and then LDPATH=ftp://... . Unless you're suggesting to either A) add another label, so there will be one for the LMS/host forwarding mode (how LDPATH could be used now, according to the definition, with FILE/LMS) and another for the protocol used by LDPATH . Or B) Remove the LMS value from SDFMODE while expanding it for protocols. None of these matches the claim that SDFMODE was originally intended to be used for protocol of LDPATH, since one of these is absolutely *required* to send "protocol" outside of LDPATH while still keeping other original value (LMS) usable. As mentioned before, LDPATH is already defined as can contain a fully qualified path. Which is a term that covers several types of a complete/full URI. So obviously LDPATH can contain a full URI, protocol signifiers included, as currently defined. So, I don't see any problems with original intent with just removing the current ftp/http options from LDPATH (or dropping it if LMS isn't needed) and only using LDPATH for surface source reference. The changes needed are pretty small, consisting of: Changing LDPATH definition to state "URI" instead of "path" (with matching syntax/phrasing changes) Adding a comment that actual supported protocols/formats will be dependent on agreements-with/support-by devices. This is the status today *already*, considering samba network shares aren't 100% supported out-of-the-box on everything already, and different O/S on devices will need file paths in a different format anyway. So that's not really a change but rather an already implicit assumption that isn't written in the DCS even though it should be. And it's about similar to what will need to be added anyway, just to SDFMODE on your original suggestion. That's simplifying things, and (as I hope I managed to express) keeping with original intent. It's also a change that "automatically" makes things future-compatible for future protocols, since it removes the current explicit mention of just several protocol, without explicitly mentioning any new ones.
  13. Just as a quick addition, since you explicitly mentioned example of username/password which I didn't explicitly responded to: This is the same as any other type of data, except that one *does* have to be configured on the machine. But usage is the same, there is no benefit to splitting the URI between LDPATH and SDFMODE. Imagine, again, an ftp (or http, same format) URI. Option 1, splitting: SDFMODE=ftp://server:port/folder LDPATH=123.sdf which the device needs to convert to ftp://username:password@server:port/folder/123.sdf . This is not different from getting LDPATH=ftp://server:port/folder/123.sdf and turning it into the exact same ftp://username:password@server:port/folder/123.sdf . Not only that, but notice that in this case, which is your own example of the need to split to a "static" part in SDFMODE, in fact the data in SDFMODE is not static. Because the device took "static" data of "ftp://server:port/folder" and changed it to "ftp://username:password@server:port/folder" . Calling that one "static" is not strictly or necessarily correct.
  14. Hi Etienne, thanks for the response. Regarding PROCBLK, I fully agree with all of your "should" handled otherwise and never sent to devices. But from past experience other labels that similarly "should" be handled differently and not sent to devices, do sometimes get sent to devices. So since this sort of thing does happen, it seems reasonable to assume that it will happen again. Certainly it seems like a more likely assumption than that it will indeed never happen in practice. The DCS can try and go very strict on this, define "must" explicitly and more strictly (and change some current uses of the word which are currently more like common usage than a standard-defined term), and then explicitly state that these blocks MUST never be made available to device. That would be a much larger overkill, and much more difficult to assure (since it can be a setup issue rather than an individual LMS/device, in which case the person in the lab that does that doesn't even directly uses the DCS and it can't be enforced), than simply doing something like the suggested additional label for such embedded data. To be clear, such a label isn't the only way to do that (and certainly instead of "text copy of another label" it can be a "variable field count label where first field is a label and the rest are fields for that label" if it seems more in spirit with the DCS), just what seemed to me as the quickest/easiest with least amount of extra data/work/changes. The only important criteria are that it will be very clear to aware devices, and will be ignored by default by non-aware devices. As far as the LMS side is concerned, the majority of the effort would be to handle context-awareness where now labels that didn't care about order are now in a state where the order (after/before PROCBLK/PROCEND) matters. So whatever is inside the block will need to be treated/read/parsed differently anyway. I'd be surprised if stripping it from an internal label would be a significant extra effort. On SDFMODE, there are two related points, which are why I think keeping it all in LDPATH is still the correct thing to do: 1. This is a general thing, but related to the treatment specific here: There is no intrinsic meaning to the term "file" other than as a distinct defined data source. There is no coherent general definition for "file", that isn't dependent on individual implementation and file-system/index. D:\folder\123.SDF could be a chunk of a few sectors on a local hard drive, in locations indexed by the file system on that drive, and reading it will read the data from these sectors and return it. Or it could be on mapped network drive and reading it will send a network request that will return a bunch of data. Or it could be mapped to an ftp server, in turn asking that server to send a file. And that server may not have "real" files, it can be an ftp protocol front-end to a different type of database, or to a program that generates the data on-the-fly. Or one of great many other things. All of these would be entirely transparent, and meaningless, to whatever program tries to read that "file", because all it wants is to get the data, where and how it is stored doesn't matter to it in any way. Similarly two URIs like http://server:port/files/surface/vendor1/hi/123.sdf http://server:port/calculate-surface-now.php?job=123&vendor=vendor1&res=hi are exactly identical for a program calling one of them to get the data. They'll receive the exact same thing back. In fact the server may be configured to accept one of them and automatically convert it behind the scenes to the other and return the response from the other. Which means, in our context, a type of "FILE" just means the ability to get some sort of reference (file name/path, web-URL, ftp-URL, all and any other URI type) that can be read, which when read should return surface data. Differentiating from the current alternative option of "LMS" which indicates that the surface data is being sent inline with the rest of the job data (which, again, I'm not sure is actually used anywhere, but it doesn't really matter for the sake of this discussion). Anything which is "this is where you have to read in order to get the surface data" is a surface file location regardless of whether a surface file even exists anywhere. 2. There is, at least as far as I can see, no practical usage scenario where splitting to location of the "file"/data-source matters. Because if the final location isn't just a direct combination of the two parts, then the device receiving these will need to know the final structure and be able to modify it. And if the device anyway needs to know how to modify the URI given, regardless in how many parts it's given, then there is no benefit in splitting it. That is, in other words, if the LMS knows how everything is combined, then it can combine it. If the LMS doesn't know how everything is combined, then the device needs to know how to parse/modify the URI anyway, so giving it in two parts doesn't help. Also, as an aside, by definition LDPATH, having that "path" part of the name, seems more fit to hold a URI (which path is a type of), rather than SDFMODE, which seems named fitting to hold a mode rather than full location structure. And re point 1, "that there is a location where the surface data is at" is fitting for a "FILE" mode, both labels working as-they-are correctly. - To illustrate point 2 above, a sample of what I think you're aiming for, and why splitting over two labels doesn't help: To be clear, this is absolutely the "advanced"/"complex" case, which is where I think you see the need, simpler cases are of course simpler and aren't different from what is already done now with LDPATH. Say the end result is something dynamic, which I assume is the case you're working for supporting, that requires additional modification, like the aforementioned http://server:port/calculate-surface-now.php?job=123&vendor=vendor1&res=hi If I understand you correctly, what you want to do is have the LMS send something like: ... LDPATH=123 LDVEN=vendor1 ... SDFMODE=http://server:port/calculate-surface-now.php?res=hi ... And then have someone configure each and every device to know that if SDFMODE matches that specific pattern (because for other vendors the patterns may be entirely different with entirely different SDFMODE format) then it should GET it adding a parameter called "vendor" which will have the value of LDVEN, and a parameter called "job" which will have the value of LDPATH. And that... would work. But : It's special configuration for all devices for each type of SDFMODE, and if you have multiple devices you need to make sure to configure all of them the same All those "magic" values (like LDVEN being sent as parameter "vendor") are completely invisible to a person trying to maybe diagnose a problem and going over communication logs, you have to be aware of the specific format to make sense of it. Which is fine for some custom data, but seems ill advised for something very basic and common like surface data. Isn't different from sending "LDPATH=http://server:port/calculate-surface-now.php?res=hi&job=123" and leaving the device configuration to know that LDVEN should be sent as "vendor" for this configuration. Or, since we're doing custom configuration of labels on the device anyway, sending the same SDFMODE in LDPATH as "LDPATH=http://server:port/calculate-surface-now.php?res=hi" , and having the device know to use JOB, or current job number, or some other label for "job" parameter. It's the exact same data, allowing and requiring the exact same type work on the device, only without any artificial splitting. Because, again, if dynamic structure that is different between vendors/whatever (so for you needing different SDFMODE) isn't needed (can be just one SDFMODE) then no point in splitting. And if dynamic structure (you will need different SDFMODE values for different cases) is needed then it's going to be dynamically parsed on the device anyway, so the split is, again, not needed, the "dynamic" part is going to be inserted into the "static" part, meaning that the "static" part isn't "static". - If a vendor came to be with that specific scheme, where individual labels need to be placed in different locations with different names, I'd tell them that if they need it dynamic based on additional labels then they should make it explicitly dynamic, at which point no need to configure all devices, and the LMS or lens vendor can make changes whenever they want. So it's enough to send any of (just as a list of samples, varying in structure, varying on whether the identifier that you would place in LDPATH as the dynamic part is another label or not): LDPATH=http://server:port/calculate-surface-now.php?res=hi&job={JOB}&vendor={LDVEN} LDPATH=http://server:port/surface/{VENDOR}/hi/{JOB}.{LDTYPE} LDPATH=ftp://server:port/surface/{VENDOR}/hi/123.sdf LDPATH=C:\Data\{LDVEN}\{JOB}R.xyz;C:\Data\{LDVEN}\{JOB}L.xyz Whoever puts the scheme into the LMS already knows where they need "their" surface files access, and so how a single URI for a single surface source is to be created. So no need to add opaque configuration on the device. Anything sent as a pair of "static"+"dynamic" data labels, can be sent as a single data label. (I mean, really, this part of the discussion is all an overly complex way of saying that you can easily send "A+B" together instead of sending "A" and also "B" separately, especially where there is already a label dedicated to sending both A and B in, which it has been doing successfully for a while, and so can work even for sending "A,B" or "A-B" or "BA" )
  15. A few comments: PROCBLK/PROCEND : I realize that the intent is for this to only be used communicating to the LMS, but it's important to be aware that such types of data often do find themselves sent to devices as well. Usually because some LMS in labs are limited home-brew systems, or light systems that do very little logical processing, or even labs don't have a working VC Host server but rather just feed devices with text files containing DCS-style data. So it's entirely realistic to expect that some devices will receive... everything, and will need to sort it all themselves. In this case, to parse this data blocks. For devices already aware, this is of course easy. Just ignore everything PROCBLK indicates is for a different device, and prefer/override with a matching block. The problem is what can happen with older devices that don't support it yet. Such devices will ignore the unknown labels (PROCBLK/PROCEND) but will try to process familiar labels inside the blocks. I think that the best way to avoid these problems is to still have all data inside the blocks pass using another label. That would be a trivial change for anything new that will be made to handle these blocks, but will make older/non-supporting devices ignore the data. e.g. instead of (to copy an example from the document): PROCBLK=FSG;;HSC LMATID=70;70 _SCSBRD=2.50;2.50 _SCSBCCA=0;180 GAX=0;0 PROCEND maybe use something like: PROCBLK=FSG;;HSC P=LMATID=70;70 P=_SCSBRD=2.50;2.50 P=_SCSBCCA=0;180 P=GAX=0;0 PROCEND This would probably require that label to be exempt from the 80-character limit (since some of the included data may be there already), but I expect that this limit isn't really an issue for any system that still keeps up to date with new DCS functionality anyway (or is that wrong?), and there are already some exempt labels in the standard. SDFMODE : I understand the benefit of the LMS value when sending data from the LDS to the LMS, so the LMS will know not to transfer LDPATH as-is to devices but to inline it (though, as an aside, does that really happen anywhere? I don't think I ever encountered an LMS that just sent to our devices SURFMT and ZZ/etc... labels in the main data packet instead of provide a file listed in LDPATH ). But I don't really see the benefit of any of the other potential values, given that they will all anyway need to be combined with the identifier in LDPATH, and that the LDPATH identifier anyway cannot be interpreted correctly without knowing it. That is, what is the practical benefit of something like SDFMODE=ftp://server:port/dir/subdir/ LDPATH=file.sdf over just LDPATH=ftp://server:port/dir/subdir/file.sdf regardless of SDFMODE? Why is a file retrieved from an http or ftp URI different from a file retrieved from a local file system or an SMB URI? I completely agree that specifying the access method as a fixed set of value in SDFMODE is not a good idea, and would require to make needless modifications for each new access protocol. But I don't see why specifying anything beyond the current send-location/send-inline differentiation is needed when LDPATH is already capable of (and practically needs to) holding the entire protocol and location. (e.g. local file access is done with a different protocol than network access over SMB/samba shared folders, but I really don't think anyone here would suggest that LDPATH can contain "c:\folder\file.sdf", but over the network LDPATH should just contain "file.sdf" and SDFMODE should contain "\\server\share\folder\" , right? It makes sense to handle this as it is currently, SDFMODE assumed FILE and LDPATH "\\server\share\folder\file.sdf", even though it's using a different access protocol behind the scenes. It shouldn't be different when the URI schema starts with "ftp://" rather than "\\" , semantically they're about the same in this context) If anything, the first case (splitting the protocol/location) is potentially worse, because if it happens to reach a device that doesn't support the mode (e.g. FTP ) and doesn't check SDFMODE (because it's been mostly useless for most devices so far), there is a chance that instead of throwing an error it will process the wrong data (like reading a file from a default shared network folder, for a lab that re-uses job numbers). And there isn't really a benefit for the first case, since otherwise in any case the first can work, the second can as well, and any case the first can't work, the second can't as well. There isn't any suggestion to add mode/access-protocol negotiation (and I think it would be a mistake to add one), so in any case the receiver of the data (regardless of whether it's a device or and LMS) will need to handle whatever it receives. So why split the single data point (location of the surface data) into two parts? Also, SDFMODE really don't play nice with multiple LDPATH records. And while it's true that ideally PROCBLK blocks can replace those entirely (so each PROCBLK section can have SDFMODE and LDPATH), these two things (vendor/device data blocks, support for more surface file acquisition modes) can theoretically be separate, but putting back the focus on SDFMODE just entangles them (can't support multiple different SDFMODE without also supporting PROCBLK. But absolutely can support multiple LDPATH where some are local files and some are http or ftp or whatever, without supporting PROCBLK).