Logix Watch-out: RTOS Overrrun

[Mispeld]

Context: We had an AOI that would stop working correctly at seemingly random times. It was noticed that a string tag would mysteriously lose its contents, thus causing the AOI to produce incorrect results. The tag in question was internal to the AOI, and not referenced as a destructive tag.

Set-up: The AOI contained RTOS instructions, with the result going into a string tag of length 12, based on the expected data range of the floating point operand. That REAL operand was the result of many additions and subtractions over time, and when it was supposed to be zero, it would end up with something like -9.50677431e-007, which is to be expected.

Watch-out: When a floating point value like the one mentioned goes into an RTOS with a destination string whose size is less than 16 characters, the result is truncated (see technote reference below), and there is no program fault. However, that truncation appears to over-write part of the next tag in memory.

Technote Reference (TechConnect access level):
Behaviour of RTOS with different STRING data sizes - Type 04 Code 52

This technote references an attached test program which was not available in my browser. Also, the screen shots are so blurry it is difficult to see exactly what they are doing. It is not a particularly helpful technote.

Steps to reproduce this behavior are as follows.

Test system: CompactLogix 5370 (L33), Firmware 32.13, Studio 5000

Test Tag w/ Data before executing test rung (note: STRING12 is a 12-character string type, and .S4 is a standard 80-character string):



Test Rung before toggling testBits[101]:



Test Rung after toggling testBits[101]:



Test Tag w/ Data after test rung (note change in strTest.S3):



Expanded Test Tag w/ Data after test rung (note characters still there, only .LEN seems to be affected):



There was no program fault, presumably because the result was truncated to fit in the 12-character string per the referenced Technote. There is no discussion of RTOS truncation in the online help.

The easy solution is to modify the RTOS target to be at least 16 characters in size. Or pre-round numbers near zero to be exactly zero, for the context and set-up described above.

 

[drbitboy]

Heh.

I suspect the RTOS instruction writes a "null terminator" at the end of a string, but mistakenly fails to include that as part of its length check:

​

If Logix is LSByte-first, and the RTOS string written is of length 12 exactly, (e.g. "-9.53674e-07") then that null (zero) would overwrite the low byte of the 4-byte DINT .Length at the beginning of the next string; since that next .length is a small number, the rest of the bytes in that DINT are already 0, so the whole .Length ends up with a value of 0.

That would be a serious bug.

 

[Mispeld]

I suspect the RTOS instruction writes a "null terminator" at the end of a string, but mistakenly fails to include that as part of its length check.

This does seem to be the case. In a small modification to the test rung, I add an FLL to pack the end of .S4 (the 80-char string), beyond the initialized value 'four' with non-zero SINT values. I can see where the RTOS did put $00 after the last character of the converted real value, after executing the rung.

On a side note, the AOI that I referenced earlier was not written to handle values in exponential notation. It actually would have failed without this apparent memory violation in the RTOS implementation. Using the example values, it would have produced the result -9.536 instead of zero if allowed to operate on the converted string.

So that is kind-of another watch-out: which is to either look for the 'e' in the result string, or limit-test-and-clear for values between, say, -0.0001 and 0.0001 before the RTOS on the source value when it can be unintentionally small and non-zero.

 

[drbitboy]

This does seem to be the case. ... I can see where the RTOS did put $00 after the last character of the converted real value, after executing the rung.

High-larious!