RSLogix 5000 - Program error: Invalid Start or Quantity value

[Berkely]

Hi everyone, thanks a lot fer helping out here.

Ok, I tried a few things starting with the easiest.

Michael, Mike, making a new rung, creating exactly the same without copy paste didn't work. I exported the program and attached it here. The problematic rung is nr7. Rung 6 and 8 are temporary added to verify the SplitPos and LEN value of the used tags.

Iant, I tried with a LIM between 0 and CLXPort.SplitPos and also with a LES like you suggested but still the same.

Keith, I replaced the destination CLXPort.SplitPos with a temp DINT and then the fault is NOT longer generated. So I reverted and added a MOV 0 to the SplitPos before the find to be sure the FIND would start with a valid SplitPos but bad results that didn't work.

TConnoly, good idea with the Latch, I placed it after the CPT and it gets latched. So that means it's executed. *Edit, forgot to mention I also used a tag instead of the constant, same result.

Nwboson, I tried to exchange the CPT with an ADD, see an earlier post but the same program fault.

 

[Berkely]

Resolved

Ok, you guys made me thinking.

MichaelG, it seems you were spot on from the first time. The FIND fails on a zero length string like you mentioned.

Of course, it's obvious in the end. So what happens, disabling the CPT caused the string not to be 0 anymore so the FIND wouldn't fail on the next scan. Enabling the CPT caused the string to be empty and the FIND apparently cannot handle that.

I've added a GRT check on the string length in front of the FIND so it's no longer executed on an empty string.

Silly how the test pointed to the CPT, I should have know better instead of focusing on the CPT. But anyway, it's resolved and I learned something in the process.

Thanks a lot to everyone contributing!! It's really appreciated!

Regards,
B.

 

[kamenges]

I'm a little confused.

Originally posted by Berkley:

Of course, it's obvious in the end. So what happens, disabling the CPT caused the string not to be 0 anymore so the FIND wouldn't fail on the next scan. Enabling the CPT caused the string to be empty and the FIND apparently cannot handle that.

The CPT doesn't affect the string in any way. It is operating on the value that was originally the result of the FIND, which is not part of the string. This value had to be greater than 0 to get to the CPT in the first place. After that you ADD the length of the terminator to this number. I can't see how that could have ever been zero the next time the FIND was executed.

Keith

 

[Berkely]

Keith, you're correct the CPT doesn't affect the string directly. However, when I disabled the CPT, the SplitPosition remained 0. Since the SplitPosition was 0 the empty string was just concatenated with the new string in another rung and it wasn't longer empty so the FIND wouldn't fail anymore.

At least, the FIND would still fail a few more scans until the next string arrived but I never noticed that.
If I'm correct the execution was similar like below:

Original situation:
fault-fault-fault-fault-OK-fault-fault-fault-fault-OK-fault-fault-fault-fault-OK
Disabled CPT:
fault-fault-fault-fault-OK-fault-fault-[disable CPT]fault-fault-OK-OK-OK-OK...

If I could track the minor faults in a tag value instead of on the controller properties tab I probably would have figured it a bit earlier but I don't know if that's possible.