Paul Wade

Record Length Increase Poll

Max Record Length Change Poll  

14 members have voted

  1. 1. Can we included the max record length changes in 3.13 or are they large enough they need to be delayed until 4.0?

    • Change is good to include in 3.13
    • Change should be postponed until 4.0


Recommended Posts

An objection has been raised to including the record length change in the upcoming 3.13 version of the standard.  The arguments against including this change have been made in the following thread:

http://forums.thevisioncouncil.org/topic/99-field-length-max-size/

Please read that information and then vote in this poll.

EDIT:  Also, if you vote against the change, please briefly give your reasons.

 

Share this post


Link to post
Share on other sites

Dave Wedwick's "no" vote response:

Quote

 

I'm voting that if anyone has an issue with it, it should be pushed to a later version.  I actually don't care myself - I don't remember who needs it or how soon.  My initial thought was that there are many machine manufacturers out there that may have an issue with it as they may not be attending meetings and paying attention.

But, now that I think about it, this mainly affects the host programs - if a machine starts wanting to send longer values, the host either takes it or not.  So, your main audience may be the host programs, and I as a host program would transparently handle any length (there's never been a length restriction in our software) - that's why I don't care either way.

So, that's it - if anyone has a problem with it, maybe it should be postponed.  But, the host programs are probably the target audience.

 

 

 

 

Share this post


Link to post
Share on other sites

Even though Paul didn't ask for comments when voting yes, I'll interject an opinion anyway. 

I'm voting we include the change because there are already equipment or LDS vendors who send records/label values that exceed the limit, so we are just acknowledging an existing reality.  I agree with Dave that this likely affects host systems more than equipment vendors, but LDS vendors could also be impacted, if host systems start sending lengthy records to As with Dave, we've already relaxed our limits, so the acceptance or rejection of the change in the standard won't make any difference to us. 

Even though we are not an equipment vendor, if I were in that role and was concerned about making sure my equipment would experience no issues with any host system, then I might well decide to honour the 80-character limit for some period of time.  I can't see that there is any downside to doing that for an equipment vendor.

Share this post


Link to post
Share on other sites

Thanks Tony.  I was thinking that since a "no" vote at this stage means countering the approval we just did at VEW it would be important to know why people changed their minds.  I do appreciate all feedback though.  We need more voices on the topic.

Share this post


Link to post
Share on other sites

I think if the new requirements are respected - which includes limiting record label length to 16 characters - this is unlikely to be a problem.  The problem situations that I've seen (where records exceed 80 characters) have generally been due to excessively long proprietary labels coming from LDS (for transmission, usually, to generators).  I suspect that most LMSs have already dealt with this.

The kinds of devices that might have issues with long records - I'm thinking of tracers and blockers - are unlikely to be receiving any such records in the first place.

Share this post


Link to post
Share on other sites

In the same light as Tony, I'm just explaining why I voted yes.

I'm OK including it either way so that would include the 3.13 version therefore I would not vote no.

Speaking purely from the ELoA Website perspective and pointing out that our actual calculations are conducted in XML, I'm quite certain that even though we do not limit the incoming size of data from the .lds file (we read until the record terminator) we will for now continue to comply with the 80 character limit on the .lms side.

I'm hoping we will see other comments posted from our actual calculations folks regarding any equipment data blocks that might contradict my statement.

Share this post


Link to post
Share on other sites

I voted Yes. 

 

The only lines that I have experienced so far that exceeded 80 characters were XSTATUS coming from a device to our LMS.

I don't believe that we are breaking anything with this new extension. I don't think anyone will start sending 255 character LTYPEs immediately with this new standard version. I think we are merely allowing for newer fields - which existing systems and machines won't be able to handle yet, anyway - to send up to this new limit of characters.

Share this post


Link to post
Share on other sites

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:

On 10/29/2019 at 9:42 PM, Jill DeLong said:

I don't believe that we are breaking anything with this new extension.... I think we are merely allowing for newer fields - which existing systems and machines won't be able to handle yet, anyway - to send up to this new limit of characters.

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:

Quote

DEV=GEN
VEN=Foo
MODEL=Bar
DEF=BLA
D=ADD;SVAL;TIND;
D=LIND;SBBCIN;
D=SBBCUP;ACOAT
TRCFMT=1;10;E;B
ENDDEF=BLA

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:

Quote

DEV=GEN
VEN=Foo
MODEL=Bar
DEF=BLA
D=ADD;SVAL;TIND;LIND;SBBCIN;SBBCUP;ACOAT
TRCFMT=1;10;E;B
ENDDEF=BLA

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:

Quote

DO=B
JOB=1234
ADD=1.75;1.75
SVAL=3.93;3.93
LIND=1.499;1.499
TIND=1.498;1.498
SBBCIN=0;0
SBBCUP=0;0
TRCFMT=1;10;E;R;F
R=2595;2600;2604
R=2609;2614;2618
R=2623;2628;2633
R=2638
TRCFMT=1;10;E;L;F
R=2595;2600;2604
R=2609;2614;2618
R=2623;2628;2633
R=2638

 

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:

Quote

DO=B
JOB=1234
ADD=1.75;1.75
SVAL=3.93;3.93
LIND=1.499;1.499
TIND=1.498;1.498
SBBCIN=0;0
SBBCUP=0;0
TRCFMT=1;10;E;R;F
R=2595;2600;2604;2609;2614;2618;2623;2628;2633;2638
TRCFMT=1;10;E;L;F
R=2595;2600;2604;2609;2614;2618;2623;2628;2633;2638

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.

Edited by Yaron [LaserOp]
Highlighted the 20-char-limit in samples

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.