Yaron [LaserOp]

Members
  • Content Count

    52
  • Joined

  • Last visited

Community Reputation

0 Neutral

About Yaron [LaserOp]

  • Rank
    Advanced Member

Recent Profile Visitors

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

  1. 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.
  2. 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"?
  3. 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.
  4. 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.
  5. @SJO - ENGLOC seems to have not been changed from previous versions, it's still type Literal rather than changed to Literal[;] as you suggested. Are you looking at the same document that has been posted here?
  6. A few comments, on draft ID 30. None I see as extremely critical, except for the last (which is therefore very much an objection rather than a comment/suggestion/question). I'm basing this on the Revision History list, assuming anything changed in 3.13 so far is listed there, I did not read through all the document: Regarding the Revision History itself - I think the revision order (newer on top) is the wrong choice here. This ordering makes sense for thing like blogs and web on-page-updates. But in a part of a closed document older to newer would make more sense to me. Literal data - The updated definition (in 3.3 and 5.1.7.8) is a substantial improvement, and much clearer. That said: - 1 - There is some difference between the more general definition in 3.3.2 and the more specific one in 5.1.7.8 . The one significant thing that was done in 5.1.7.8 and I think would be an important addition to 3.3.2 as well, is that all possible values are to be enumerated in the record definition. Maybe change 3.3.2 from "...having permissible values specified in the standard" to something like "...having permissible values enumerated in the standard" ? - 2 - Since the standard is now clearer that all values are enumerated, is there a point in specifying maximum length? Especially when 5.1.7.8 both specifies maximum length of 12 and allows the definition of each usage to go beyond 12? This is effectively no length limit when defining a Limited record field (since it is explicitly allowed to override 12), and there is no point in specifying maximum length as an issue for anyone using a Limited record field (if all values are enumerated then specifying length is meaningless, maximum length is always the length of the longest enumerated value). Maximum length in the definition of Limited should either be waived completely, or be specified in a way that doesn't allow a record definition to override it. (I'd prefer the former, but either option is better, and internally consistent, compared to the current effectively "there is a maximum length and it can be ignored by everyone") Reference Coordinate System for Backside Engraved Lenses - Previous issues with terminology and usage aside, just a quick note that 5.2.3.1 has an internal reference error, I assume to the related Figure 2 below the section, stating "Error! Reference source not found." in the middle of the paragraph. Removed New DEFAULT label - The Revision History lists having added a new Label DEFAULT. Which is not actually added anyhwhere in the document. I see that it was there in an earlier draft, so I assume it was decided to drop the label, and it's just the Revision History which needs to be adjusted to match. ENGMARK coordinate system - Talked about it in the past, the changed definition of the ENGMARK coordinate system origin is highly problematic. From the previous revision I see that the definition changed from trying to define it on black center to trying to define it on block center, this is irrelevant for the practical objections and has the exact same problem. Again, there are plenty of labs who, for quite a lot of years now, rely on the fact that the coordinate source for engraving (using ENGMARK or ENGMASK records) is ER, not SB. (The Reference point for an Engraving operation being the Engraving Reference). Engraving is being decentered/offset from the Block center in plenty of labs by using SBBC__ + BCER__ records. Using the exact same set of job records, a change from 3.12 to 3.13 should absolutely not cause the engraving to move. It even more certainly should not cause the engraving to move to where the lab does not expect, or want, it to be. This definition expansion isn't clarifying things, it's changing things. And in a way that will have clear and significant and unwanted impacts on labs. I absolutely don't see any benefit whatsoever to doing it, just many downsides. Why change the origin of an already widely-in-use label?
  7. In theory you're correct. In practice, is this worth making a change? It doesn't serve any purpose: In current/new DCS version, ENGLOC indicates on what side the feducial (±17mm) marks would be located, for anything that tries to look for them after engraving. And HASENG indicates if there even are such marks. So the only case where ENGLOC needs to be chiral is if it's F for one lens and B for the others. Which I'd think would never be the case. (right?) Otherwise, there is no confusion or ambiguity. In your sample it would be ENGLOC=B , meaning that for this job the marks are supposed to be on the back side, and that only the left lens has those marks (which are on the back side). "which eye has marks?" and "where are the marks located?" can be (and currently are) independent questions. There is an N value for ENGLOC only for historical reasons, I assume, from before its purpose/meaning was changed (in 3.11 I think?), before there was HASENG. Maybe before there was DOENG (I don't have at hand older DCS documents to verify)? And just as a convenience factor to have a "nicer" value where no lenses have marks.
  8. I want to mention again that the options aren't only to go ahead with the increase as-is in 3.13, vs making a newer major version 4.0 . There are some possible modifications to the change that will prevent any breaking behavior, and so make it technically eligible for 3.13. Please check my last comment on the discussion thread, listing some options that occurred to me, including one that came from Paul. I also think a lot of people maybe didn't read the discussion, or notice the details of why I claim it's a breaking change, as for example: So, instead of yet another explanation, an example to illustrate the issue. This will show device->host initialization request, and host->device job data. These are simplified for the purpose, and to make it more readable this handles as if the previous limit was 20. Starting sitatuion, initialization, device to host: If the device and host were using DCS 3.07, and the device changed to 3.12, nothing happens. If the host changed to 3.12, nothing happens. Everything keeps working as is. Nobody cares what is the version on the other side, because it shouldn't matter when not using new fields/labels. But if the device changes to 3.13m, this happens automatically: And now, if the host is not up to 3.13, it's possible for it to either stop with an error because it doesn't have a valid D at all, or to just return ADD, SVAL, TIND, and LIND, completely ignoring the other three labels that the device needs. Most up do date hosts probably support receiving unlimited length anyway, but they don't have to, and not all hosts in all labs are up to date and well maintained. Not being able to process length beyond the official max is entirely 100% fine and in compliance with the DCS. Which is why this is a breaking change. The device was updated, there was no configuration changes, no new labels or new fields are used. But things stop working. From the other side, same thing, assume this is job data: If the host upgrades from 3.07 to 3.12, nothing happens. If the devices upgrades from 3.07 to 3.12, nothing happens. There wasn't any configuration changes, no new labels and fields are used, all is fine. But if the host changes to 3.13: And now, if the device isn't 3.13, it's possible for it to stop with an error, because it doesn't have the radius length it needs. So, again, breaking change, because merely updating the host, without any configuration changes, and without trying to use any new labels or fields, can cause some devices to stop working, for jobs and data where they worked perfectly fine with before. As with the host, it's likely that it won't cause any issue with most devices, who may not have a length limit for receiving. But they're allowed to, so some can have a problem with the limit. And no other changes along the way impacted them, at all, but this will automatically cause them to stop working properly.
  9. Christian, Main part of your comments, re usage of ER and re BE: When working with the same axis system, there is no difference between "where X should be place" and "where X was placed", for the same X. So "this is where the center point of the engraving is", would be identical to "what should the center point for engraving be". And, given how the Reference Points are all connected, it's very usable that way. Specifically in our use case (and I'd image other engravers), If something has to be engraved, and what the machine physically knows (common use case, engraving on the back side during surfacing) is where the block is located, to find where the center of the engraving should be (which, again, same as it would be after it's done), we generally use SBBC + BCER. (And, as a side note, notice that while it's true the usage labels include ERNR and ERDR, indicating ER usable as source/origin, there is and was also BCER, indicating ER usable as target to get to from somewhere else) I also think you're probably wrong when you write that ER is "most often" used for already marked points as reference for something else. It's entirely possible it was like that 20, maybe even 10, years ago. But at this point, and for a very long time now, the overwhelming majority of labs do engrave/mark lenses as a part of the process. And so, again, if that engraving should be centered on ER when it's done, then it should be done around ER. We're using BCER to position engraving for about since ENGMASK was first introduced (3.06, I think? around early 2007?). And it has been used (i.e. with non 0/? values) by various labs (and LDS vendors), as the main way to indicate decentration for engraving. That's pretty common, established, and industry-wide acceptable, use. And one which is usually done on the back side of the lens. For marking on the front side: I absolutely agree that at this point it's rarely done, which is why FB is rarely needed for engraving. But it is done in some places, and it's being done more and more. So, I think the question of "when being asked to engrave on the front side, where should I engrave, if I'm not explicitly told to engrave relative to the frame?" is a very valid question (together with its counterpart of "When we want an engraver to engrave on the front side, how do we tell it where to engrave, if we don't want it relative to the frame?" ) . And I think it's better to get a standard acceptable answer early, instead of just letting engraver vendors all do whatever they personally think is best, and try to sort it out later. I don't quite get the attitude of "no need to decide that before people are starting to use it a lot, lets allow wide usage with no rules and no specification in the standard before trying to figure out the best way to proceed".
  10. Basically yes. There can be a few other valid (in this case "valid" meaning technically usable to get the wanted result and without breaking anything) options, though probably more complex. As you request I'll list here briefly, without the reasons/explanations inside the options themselves. If anyone who reads this does have a specific question, and can't find it on this thread, I'll be happy to answer with at least my understanding of what and why I present the option. Options to increase the record value length (change max length limit from record length of 80 to record-value length of 255), without making breaking changes inside a minor version change: Increase record-value length for everything. Do a major version increase, to 4.0. Devices/hosts that support it should treat accordingly (not changing to 3.13 automatically without manual configuration, while 3.12- systems are still out in the field). Increase only for specific records, which will not change "automatically" (without anyone entering new job data in different ways/formats) anyway if the limit is extended, . XSTATUS, LDPATH, ENGMARK... , as well as all experimental/vendor-specific labels. All other records still limited to 80 record length. Increase only for single-record labels (and all experimental/vendor-specific). All multi-record labels (D, R, A, ZA...) keep the 80 max record length (except for those that already explicitly extend it, nothing changes there) Increase only for single-record labels (...), which have at least one Text field. All other labels keep the 80 max record length (...). Increase only when communicating with something (device/host) that clearly identified itself as supporting 3.13 (e.g. a device that sent OMAV=3.13+ during initialization). Add option during initialization for host to respond with its own supported OMAV. Any records written/sent without this (during initialization, to files, to devices/hosts that didn't report their version) keep the 80 characters record length. Notice that 1, 2, and 5, are guaranteed to not cause any in-minor-version breaking changes, regardless of usage of any other labels (2 will require some manual work "now" to decide which standard labels are included to begin with, 5 should be robust, and works similar to other like changes in the past such as TXTENC, but therefore makes adopting the change more complicated). 3 and 4 seem to me to be enough to prevent any breaking changes (by themselves, merely from increasing the length) in practice, at least I wasn't personally able to think of a use cases where a problem will occur with them. And they should be clear to define, and relatively easy to implement. 3 basically excludes what is likely to cause problems, and 4 tries to excludes anything that probably doesn't have a valid reason for "needing" the extension (with its current purpose). (As an aside, this works "correctly" by being the cause for 4.0 (and delaying the currently planned 4.0 to 5.0). It's not relevant for combining with the current planned 4.0, since that involves a data format change to things like (from my understading) JSON / XML, which already don't have any forced max length limit on most data types, like Text.
  11. The concept is always more important in theory, but the nomenclature (name, quick description) is what people process first, and what they process when they just quickly skim through something, or search for something, or try to just refresh their memory for reference. If it's not possible to understand what something is, or what is the difference between two things, without going full into the details, the names/descriptions are bad. I'm not sure if the final decision was to keep this as a 2-character name (e.g. BE) or a 3-character name (BER), but maybe instead something like "FO" (or "FOB" if 3 letters, "FOBE" if 4), with a description like (trying to keep as close to the existing description as I can while clearly changing the intent) "Find OC from Back Engraving. The observed midpoint between the semi-visible alignment marks seen on an already finished lens, used to find OC on finished lenses. Origin of the back surface reference coordinate system" . Both the name and description can't be easily confused with any of the other points, and the purpose and usage is clear. (Note: Not sure if "finished" is a correct word there, the purpose was to clarify it's not used when making the lens, so it will be obvious as not relevant for devices during production in lab, and similarly obvious as relevant for inspections/checks/diagnostics later. I assume there's a term for it, that can't be maybe confused with a lens during finishing/edging, but at the moment can't recall what it would be. People who actually work with lenses/jobs at that stage would anyway have a much better idea than me about the correct terminology, or if this is or isn't confusing between the two states as-is) Also, I didn't see anyone respond to the topic of whether this point should really be together with the other Reference Points (on Table 2), given that all of the rest share coordinate space and are translatable in the same way (I think?), and this one requires special and unique handling. Maybe it should have its own sub-section?
  12. Both, or either, depending on context. Most of the marks are done on the back side, semi-visible marks, during surfacing, on lenses attached to surface blocks. That's the main usage of our engravers in labs. But there are also cases where we mark on the front, on finished and edged lenses, attached to finishing blocks (again, usually for things like adding logos and such, visibly). The same LMS/VCA-Host should be able to provide instructions (e.g. view ENGMARK labels) for both. Which is fine, ENGMARK supports both engraving on front and back. So ENGMARK labels for back will go to the "regular" system, and these are oriented around ER. ENGMARK labels for front will go through the "logo" system/module, and these are oriented around... what we're trying to decide here. In practice this is usually oriented to the frame anyway, so it won't matter. But it can potentially not be, and there should a standard interpretation on what the reference is on those cases.
  13. Again, I think that (for anyone who doesn't know in advance what it's supposed to mean) this is indeed confusing and potentially ambiguous in context. From the same Table 2, let's show the two items in sequence, I'll copy the first (BR) from your quote above (different from the 3.13 draft I have, I'll assume you're using a newer draft), and the second (ER) from the draft I have, which haven't changed for quite a few versions anyway: You see the issue? Both are "Engraving Reference Point", both are "midpoint between semi-visible alignment marks". The difference being that BE is explicitly stated to be on the "back", which isn't really a difference since practically always the marks will be in the back for engraving, when using ER, so the definition of ER might as well have "Back" in it. And the purpose/usage is very different. "ER" is used to determine where to engrave. "BE" is used from observing the engraving, from a different angle, to get OC. So changing the name of BE, and describing them differently, is important.
  14. I actually read Mark G. comment as essentially agreeing, saying his LMS will keep sending existing labels with 80 character limit, even though that limit is no longer in the standard, in order to ensure that devices will be able to keep working. Just like I was saying devices will similarly need to keep sending relevant labels to 80 to character limit, in order to not cause some Hosts to stop working. Also, again, the alternative isn't necessarily a major version increase. That one is required if the change is kept as-is, simply increasing the length. But it's also possible to limit the scope of the size increase, so that nothing will break. The issue is with existing already used labels, where the increase will cause an impact, and won't be expected by older software. Which are, in practice, the multi-record labels (e.g. D, R, A...). So if the length limit will be kept to 80 on all of those multi-record labels (that don't already have explicit length in their definition), and increased only for single-record labels (which beyond being the majority, are also probably where the increase was wanted, and what the purpose of the increase is for), that solves the problem. Otherwise, again, as I think Mark practically agreed, the change won't cause a problem because everyone will ignore the change, in a way differing from what the DCS states ("only increase on labels where required" vs "across the board").
  15. To be clear, you're still talking about marking on finished lenses, on the front side, from data provided by ENGMARK? If it's marking on the front side, doesn't matter for the sake of this discussion how you physically hold the lenses (finishing block or something else). Same job data records. If it's marking on the back side, then I'd think the base/center position should be the same ER regardless of whether the lens is finished or not. The relation between OC and ER haven't changed, so the same logic should apply. No? The question here is "what should be the base position when marking on the front side, from ENGMARK record "ENGMARK=?;?;?;?;?;F; ?" . If marking on the back side I think it's always ER, but I don't see a clear definition on front. From the quote from you email above, I still understand for you it's always so far OC, and for us so far it was FB (which I see how may not available/relevant to you if you don't have it when you do this). And there should be something agreed upon by everyone, so different labs would work regardless of what devices they have (the purpose of the DCS)