Robert Shanbaum

Members
  • Content count

    7
  • Joined

  • Last visited

Community Reputation

0 Neutral

About Robert Shanbaum

  • Rank
    Newbie
  1. PROCBLK new record + SDFMODE extension

    I suppose that it's possible that a use case could exist wherein a set of repeating records might need to be replaced by another set of repeating labels (or, possibly, just one label - an ENGMASK might replace a set of ENGMARKs, for instance). I'm not sure how likely such a case is to obtain.
  2. PROCBLK new record + SDFMODE extension

    Yaron, we only send one tracing per packet, ever. And tracings are a special case, because I'm pretty sure that all LMSs can send whatever number-of-points or formats any device might specify in its initialization, without requiring PROC records (or PROCBLK datasets) at all. As I wrote, the standard is not presently explicit when it comes to which records (or datasets) might be repeating, but it seems to me that there's not really much doubt about which ones are, and which aren't. Can anyone name a record for which that is not true? I do not agree with the proposition that the presence of one record in a PROC record implies that another, different record should be changed.
  3. PROCBLK new record + SDFMODE extension

    We didn't expressly address in the standard device-specific records that can appear multiple times; but as I wrote, I always figured these would be additive. It may be that we should expressly identify such records ("repeating records") - I can tell you that we have to do that in our software.
  4. PROCBLK new record + SDFMODE extension

    It would appear that some elaboration of the definition of PROC records is called for. I think that my own interpretation has been that for records that can appear multiple times in a packet (such as ENGMARK or DRILLE) the operation of a PROC record would be to add the device-specific records to the records sent to the machine. We don't have a way to suppress sending particular records of that kind to a machine, but it's not clear to me that such a feature is necessary (and if it is, it will be challenging to implement in a robust way, requiring matching strings of characters across multiple "device versions" of a record). The more general case - wherein records are "singletons" (that is, only one record having a given label appears in any packet sent to a machine) - the usage is clear, is it not? I don't understand the comment above regarding a "non-optimal workaround"...
  5. PROCBLK new record + SDFMODE extension

    But that last idea is not very different from a PROC record, is it? I suppose the presence of a semi-colon in a Record Label would suffice to identify the record as machine-specific. Given that PROCBLK was a form of shorthand for PROC records (and a reasonable way to handle PROC datasets), I don't think this would be a great approach.
  6. Special Groove Rimless OMA File

    Tony is correct - there are very few requirements as to the sequencing of records in a packet out side of "datasets" (such as TRCFMT being followed by R records, and optionally, A, Z, ZA).
  7. DCS data tag for Segment radius on Multifocal curve top lenses

    Well - we can't describe a Panoptic seg either, or any number of features of various kinds of segments (radius of an Ultex?) .