All Activity

This stream auto-updates     

  1. Earlier
  2. Hi All, I'm posting v0.84 of the LPDS for your comments, questions, and suggestions. One note is that section 8 will end up living in an accompanying document. It's present at the end of the Standard just to serve as a location in which to manage the content. Please give that section some thought, as I'd like it to cover the frequently asked questions that one may have when attempting to mentally process the Standard. Within a week or two I hope to have a preliminary pass at the LDS to LDPS conversion utility available, so folks can see how a given LDS file would appear, translated into the LPDS format. Thank you for giving this your time, it's greatly appreciated! TVC Lens Product Description Standard 0.84.pdf
  3. Ah, and one more quick typo. On table A.13 " Process Status (“INF”) Packet ", the table lists the label STATUS as STATUSL . I don't see it on 3.11 (correctly STATUS), but I do see it on 3.12.
  4. Hi, We added support to REQ=INF reports on our machines a long while ago. And recently due to a talk with a lab I've taken a look at our implementation, and noticed that for some reason we were sending MODEL to the Host. Which seemed a little odd, it doesn't really make sense to me for it to be there, and it doesn't make sens to me anywhere without DEV and maybe VEN records. So I've checked the VCA DCS document and and section states "The INF request type will contain only request type, job, status, and (optionally) CRC and model ID records." . This is the same for v3.13 draft 30 PDF, which is the most recent VCA DCS document I have, section 7.3.5 on page 92 (by TOC) / 95 ("physical"), and for 3.06 (earliest I think I have) section 6.3.6 on page 44 (TOC) / 50 (Physical). Looking for "model ID" I see it mentioned just a few other times in the document, but always for MODEL (i.e. in a section grouped with what are or should be DEV and VEN). Even though in other places MODEL is just referred to as "model" or "machine model" (which is also how it's called in its definition). I'm pretty certain that the intent here was to specify MID (which we sent as well, despite that "only", since it was usable by Hosts we worked with), not MODEL. Which makes even more sense considering MID is explicitly stated to be optional on requests, similar to CRC. So: Is this indeed a typo/mistake in the DCS, and this should be MID? I should stop sending MODEL, and the DCS should be corrected for the next 3.13 version? Or am I understanding this correctly, MODEL should be here? In this case, can you please explain why? Also, how important is that "only"? This specific interaction started after seeing a communication sample to a Host from a fairly serious vendor where the sample didn't include MID, but did include both VEN and MODEL. Beyond probably being superfluous, is this "wrong"?
  5. Hi Robert, Extremely late response on my side as well, I missed your response at the time, sorry about that. 1. At the moment there are only three sections there (3.11, 3.12, 3.13), so the work of reordering (if it's agreed to do so) is just switching around 3.11 and 3.13. While it could be a lot of work in theory, in this case it seems to me to be very little work. That said, it's very little work, so of course I don't mind doing it myself. Except, I will need the original editable document to do so, not the currently published PDF. And I expect that the concern over compatibility between the editors (Word 365 that the PDF was made with, and my OpenOffice/LibreOffice) and wanting to verify correctness of everything, especially on a document with active change tracking, may cause Paul (or whoever would otherwise do this) a lot more work and concern than doing to quick select>cut>paste operations? 2b. If this was written as a recommendation of maximum length, so recommending terseness, I'd actually fully agree. It's acceptable for a Standard to recommend using short short values without enforcing them. It's even fine to require a maximum length with some specific exclusion criteria (value is made up of words and extending to finish the last word? there are multiple values which are very similar so a few more characters are needed to clarify the differentiation? Something else?). But this is presented as a requirement/specification of maximum length, combined with a complete waiving of that maximum length whenever it is wanted without any specific criteria. "There is no maximum length but it's recommended to limit to X characters" can make perfect sense. "There is a maximum length of X characters unless the length is longer" not so much.3 3. And same point, I agree that allowing for overrides is fine, but that requires specifying explicit cases for the overrides. If the override is completely free and unlimited, then the constraint is meaningless, and should be either waived or re-written as a recommendation. "You must/can't do X unless Y" is fine, except where Y is "you want to" instead of something a lot more specific.
  6. The reason to send to a conveyor DO data different from the default would be to have it match what is sent to a specific machine/device that the conveyor would need to consider. (e.g. If any and all devices on a line receive DO=L then also a generic device should receive DO=L and not DO=B) But in that case having a different device type for conveyor won't help in any way, the conveyor itself could be "at any part of the lab process". Knowing it's a conveyor rather than a generic device doesn't help knowing if it's a conveyor feeding a generator, engraver, polisher, etc... So a new device type won't change anything, you'd still need to tie it to a specific location (device it stands before). Which I guess the way to do will be to have different MID set for each conveyor, and configure the host to send different DO depending on MID? In this case, though, since the decision on the host is in practice entirely dependent on MID, then what is the benefit of having a "CVY" device type to check CVY+MID when you can just as well check for DNL+MID? The device type doesn't add or change anything since MID should probably be specific to a single device anyway. Or, to avoid doing the MID tailoring, since in this scenario the Host is already differentiating based on device type, it may be more practical to have the conveyor present itself as the relevant device. Conveyor before the generator/s can say it's GEN, the one before the polisher/s can say it's FSP (?), and so on. That should give the conveyor full knowledge on what the machines it feed should or shouldn't do. If the possibility of modifying the standard is considered, though, I think it would be a better idea not to add another DEV option, but instead of expand the set of DO___ labels. That would directly do the work of letting a generic device get the important data for all machines, as well as allow DO to be properly handled as a single job-status information instead of having the Host modify it per device. There currently exist such variations for some of the machines, like DOENG for engraver (i.e. If it's a two-lens job that shouldn't be engraved you can, and should, send for such cases "DO=B" and "DOENG=0;1" instead of changing to "DO=L" especially for the engraver), DOCOAT for coating, and a few more, but there are (as far as I know) no equivalents for other devices such as polisher or generator (DOGEN does something else). Expanding those seems like a good way to disentangle the general what-in-the-job-should-be-processed of DO (and let it be the same for all supporting devices without having to adjust it per device), with a very straight-forward and accessible way to indicate what individual devices should do.
  7. We are running into an issue where a customer uses a conveyor belt in the lab. As there isn't a device type specific for conveyor belts, they've been defining it as "DNL" for a generic download device. For generic download devices, we don't currently go through much job logic based on breakage situations, position in process, etc. It is by definition generic and could be at any part of the lab process. However, this means that the conveyor belt might receive "DO=B" when there is a breakage in the process and should instead be receiving "DO=L", for example. Is there a benefit to define a device type abbreviation in the DCS for conveyors? Do others have examples where a conveyor might be treated differently from a generic download device? I'd like to propose a device type abbreviation like "CVY" for a conveyor belt to be added to the standard.
  8. Dear Colleagues, Can anyone explain the difference between NOD and NWD as it defined in the DCS: NOD - (numeric;) Refracted object distance at near viewing point (meters). NWD - (numeric;) Working object distance at near viewing point (meters). We would like to use the one who fits most to describe the reading distance measured by the ECP. Thank you in advance for your support. Stay safe Haim S. - Shamir Optical Ind.
  1. Load more activity