Handling of CRIBFMT and CRIB/ELLH

[tonyleblanc]

In discussions with an LDS recently, a question around handling of CRIBFMT and CRIB/ELLH came up.  The DCS standard does not explicitly indicate which should have precedence if both CRIBFMT and CRIB/ELLH are specified, nor does it explicitly state that both should not be specified in the same packet.  In our case, if CRIBFMT is present, we suppress CRIB and ELLH because of issues in the past with equipment complaining if both CRIBFMT and CRIB/ELLH are specified.

Question - should the standard say anything about precedence if both CRIBFMT and CRIB/ELLH are present, or, should there be any restriction on both CRIBFMT and CRIB/ELLH being present in the same packet?

[Yaron [LaserOp]]

CRIBFMT is essentially a more accurate / higher-resolution presentation for the same data from CRIB/ELLH. As such the basic expectations should be, I think, as in all such cases:

• CRIBFMT takes precedence if it exists.
• CRIB/ELLH, if existing together with CRIBFMT, should still be as correct/accurate as possible, for machines that can handle them and don't handle CRIBFMT.   In this case I think meaning that the CRIBFMT shape is contained inside the circle/ellipse defined by CRIB/ELLH  (I'm assuming here that in general case for things that handle it more roughly it would be better to consider more of the lens as "important" rather than less, since the worse thing would be to remove/damage area that should be inside the crib).

That seems the natural way to handle all such differing presentations of the same data, regardless of specifics. Higher resolution takes precedence if both available and known/supported, lower resolution should still be accurate and err on the side of less severe consequences (when relevant).

( As an aside, I'm also not seeing how a device would have problem with both being present. At least not in cases when connecting to a VCA Host, rather than reading a file, after Initialization. CRIBFMT is only sent if explicitly asked for, and usually also CRIB/ELLH. If a device asks for both during initialization then it should be able to handle both.

This means that you shouldn't have to suppress CRIB/ELLH because if a device didn't explicitly ask for them then you probably shouldn't send them anyway. But it also means it should be usually very safe to suppress then, since if a device asked for CRIBFMT then it should be able to handle it and would probably prefer it anyway. )

It would be a good idea to slightly modify the standard to explicitly state the priorities/relationship if an ambiguity is possible. Obviously I think based on the same ideas. But in any case it shouldn't be a restriction on both being present, that would be unlike anything else (AFAIK) in the DCS, and the DCS does have other cases of different resolution/accuracy presentations of the same data. From a *correctness* aspect it should always be possible to send *everything*, and so even more so when it's everything that a device explicitly asked for.