Device type for conveyors

[Jill DeLong]

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.

[Yaron [LaserOp]]

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.