interesting ASCII bugs in SLC-5/05 and RSLogix500

Greetings to all,

those of you who work with ASCII strings with SLC/Micro platforms might be interested in this ... I’ve been working with a guy named Dave on another forum and I think that we've found a bug in the RSLogix500 software and possibly (probably?) in the processor's string handling system ...

the objective was to take the ASCII code “110” for a lower case “n” character and concatenate (add on) the “n” onto the end of a text string ... you can find

the original thread

here if you’re interested in following the whole thing ...

and here is the program rung which I came up with to accomplish the task ...

[attachment]

at highlight #1 we see that location ST9:8.DATA[0] contains two ASCII “null” (or “nothing”) characters ... each null is represented by “\00” ... this basically means that the location is empty ...

at highlight #2 we see that location ST9:7 contains the sample text “TRY” ... ST9:8 and ST9:9 are both empty ...

at highlight #3 we have a Custom Data Monitor set up which shows that location ST9:8 is empty ...

at highlight #4 we have a Custom Data Monitor set up which shows that location ST9:9 is empty ...

now we’re ready to toggle bit B3/0 to an ON state and execute the rung ...

on to the next post ...

the story continues ...

now that the rung has been executed once, we take another look things ...

[attachment]

at highlight #1 we see that location ST9:8.DATA[0] now contains a lower case “n” character and a “null” character ... this is exactly what we expected to see ... the program has taken the ASCII code “110” which was stored at N12:0 and has converted it into the lower case “n” character and stored the result in ST9:8 ...

BUT ...

at highlight #2 according to the Custom Data Monitor, we see that location ST9:8 is still empty ...

but at highlight #3 we see that word [0] of ST9:8 contains a lower case “n” and a null character ...

so which one is it really? ... empty or not? ...

moving right along to highlight #4 we see that ST9:9 contains the text “TRY” ... we were hoping that our program would have concatenated the lower case “n” from ST9:8 onto the end of the word “TRY” from ST9:7 ... the result we were hoping for in ST9:9 should have been “TRYn” ... apparently this didn’t happen ...

and incidentally, I toggled B3/0 OFF and ON several times ... the results were exactly the same each time ...

at highlight #5 we see that ST9:8 sure does LOOK empty ... and the string length is still “0” ... so the question becomes: “what the heck are highlights #1 and #3 actually looking at?” ... they do NOT show ST9:8 as empty ... so MAYBE there really is an “n” character stored at ST9:8 after all ... but IF (BIG IF) there really is an “n” stored there, why didn’t the ACN (String Concatenate) instruction pick it up and add it onto the end of the “TRY” stored at ST9:7? ... it seems like the “n” should be showing up at ST9:9 in the string “TRYn” ... that didn’t happen ...

so is there something wrong with the program we’ve written? ...

on to the next post ...

and still there is more ...

now for a “workaround” to fix the problem ...

[attachment]

here I’ve gone into the data file window (at highlight #3) and manually typed in an “X” at ST9:8 ... you can see this “X” showing up at highlight #3 ... you can also see the “X” at highlight #2 ... and you can also see the “X” at highlight #1 ... so at least all of the displays now agree on the contents of ST9:8 ... that’s good ... and notice that the length of ST9:8 is now shown as one character stored at highlight #3 ... this is also good news ...

on to the next post ...

at last ... the exciting conclusion of our story ...

now we’ll toggle bit B3/0 ON again to trigger our program into executing ...

[attachment]

at highlight #1 we see that the “X” we left in ST9:8 has now been overwritten by the “n” character stored at N12:0 ... this is good ...

looking at highlight #2 we again see that ST9:8 DOES have the “n” character ... this is good ...

at highlight #3 we see that ST9:9 DOES have the “n” appended to the sample “TRY” string ... and this is exactly what we’ve been trying to accomplish all along ... SUCCESS! ...

and at highlight #4 we see that, sure enough, our desired string “TRYn” is correctly stored at ST9:9 ... and also ... the “n” character is correctly displayed at ST9:8 ...

summing up:

based on all of this evidence, I’d have to say that there are obviously some bugs in the RSLogix500 software’s ability to display the contents of the ST data files ... specifically, regardless of what data is actually located in ST9:8, all of the displays should at least indicate the SAME thing ... they don’t ... so SOMETHING is definitely wrong in that department ...

BUT ...

you can’t just say that there’s something wrong with the data file display window (example: highlight #5 in post #2) and let it go at that ... take another look at highlight #1 and highlight #3 in the same post ... those two displays seem convinced that the “n” REALLY and TRULY is safely stored in ST9:8 ... so maybe it’s just the data window’s display (highlight #5) that’s messed up? ... NOPE ... I don’t think so ...

if (BIG IF) the “n” just happened to actually be located in ST9:8, then the ACN instruction should have picked it up and hooked it onto the end of the “TRY” text string ... but I KNOW that it didn’t do that ...

because ... later I went back and programmed a couple of AWT (ASCII Write) instructions to send the contents of ST9:8 and ST9:9 out of the SLC’s serial port ... then I ran through the whole series of experiments again ... at each step, the contents of ST9:8 and ST9:9 - as shown on the data table window display – were exactly what the processor sent out ...

based on this, I’d have to say that there is PROBABLY something wrong with the way that the SLC-5/05 is executing its string handling instructions ... specifically, why do I have to “wake up” the ST9:8 location by manually typing some arbitrary value into it before I can start moving values into it by using my ladder logic MOV instruction? ... that just does NOT seem right to me ...

and so for a “workaround” ... it seems that you can just go to file ST9 in the data table window and type a character into the String Text location for ST9:8 ... it doesn't really matter what character you type - I used the letter "X" ... and when you run the program again, the ST location seems to work fine from then on ... at least in my case it did ... and so it seems that you need to "wake up" the ST9 location by using something OTHER THAN just a MOV instruction in the ladder logic ... once the location has had something (anything?) inserted, it seems to function correctly - even for future MOV instructions ... I’d say that this qualifies as a bug in the system ...

finally ... I've been using an SLC-5/05 processor (1747-L552/A; 32K memory; operating system OS501; operating system firmware revision number 5) and RSLogix500 version 6.00.00 running on Windows XP Pro for these experiments ...

I think I've followed your demo but it seems that all your problems hinge on the LEN variable. Just MOVing data into the DAT area doesn't aaffect the LEN variable. Therefor the display shows the data but also shows a 0 length string. When you try to add a zero length string to another nothing happens. it all depends on the LEN variable regardless of what's in the DAT. When you used the data table to manually put an 'X' in it SAW that and adjusted the LEN variable. Then it could add SOMETHING on to the end of another string. The LEN MUST be correct for the ASCII based operations to operate correctly.

Ron,

I think you need to set your string length to "1" before the concatenate will work.

I ran the following code (with and without B3:0/1 toggled). When I had a string length of "0", I had the same results you tried. When I toggled B3:0/1 so that I would have a string length of "1", everything worked fine. I think that is effectively what you did with your work-around.

I agree that this is not intuitive, and could probably be described as a bug.

Marc


PS: I used MUL by 256 instead of SWP . . .

thanks, Bernie,

it certainly looks like what you’re saying is true ... but what bothers me is that the same MOV that I used in post #1 (which didn’t work right) is the same MOV that I used in post #4 (which did work right)... and each time, I was trying to MOVE the same durn thing ... but the MOV instruction wouldn’t work until I manually typed something into the target ST location ... that seemed to “wake up” or somehow “enable” the ST location so that all of my future MOV commands worked ok ... having to make that “wake up call” for the ST9:8 location just “don’t-seem-right” to me ...

and another thing ... I can’t come up with ANY way to explain how the various highlighted displays in post #2 were showing different values for the same ST9:8 location ... it seems to me that they should all be consistent – even if they’re wrong ...

like you said, everything seems to hinge on the Length field having a non-zero value ... but I’d have thought that all of the displays should have consistently shown the same thing ...

again, thanks for your response ...

Greetings, Marc,

thanks for participating and especially for confirming that what I’ve been seeing does indeed happen on more systems than mine ...

I’d keep an eye on that MUL instruction if I were you ... when the value stored in N7:0 gets too high, strange things can happen to the sign bit in N7:1 ...

again, thanks for your response ...

Ron,

Yes - the MUL instruction could cause a problem, but since it seemed we were just using ASCII text I figured I could get up to "z" that way without a problem . . .

Marc

PS: I also tried MOV'ing the .DATA[0] value back to an integer register which works whether or not you can see the "n" in the String window.

msinclair said:

I also tried MOV'ing the .DATA[0] value back to an integer register which works whether or not you can see the "n" in the String window.

Click to expand...

now THAT’S interesting, Marc ...

[attachment]

so it looks like the data IS actually getting put into the ST9:8 location by the first MOV ... if it’s not, then how could the second MOV pick it up and put it into N12:1? ...

but then I tried using an AWT to write the value of ST9:8 out of the SLC’s communication port ... it wouldn’t work until AFTER I had manually typed something arbitrary into the String Text field of ST9:8 ... then the lower case “n” character came zipping right out into HyperTerminal with no problems ...

(at least for now) I’m going to say that maybe the ASCII “move” type instructions just don’t move data the same way that regular old run-of-the-mill MOV instructions do ...

hoodah-thunkit?

off line for the weekend ... party on guys ...

Ron - you're not looking at this right. Your first MOV did indeed MOV the value into the DAT area of the string. But, with a string length of zero the display disn't show a STRING of 'n'. The ACN instruction didn't ASCII CONCATENATE since, with a length of zero, it figured there was nothing to concatenate. When you used the data table to put in an 'X' this was equivalent to performing a STRING instruction which properly set the length to 1. The data table showed an 'X' as the contents. When you MOVed the 'n' over top the 'X' you just changed the data with the length remaining at 1. Now when the ACN instruction was invoked it saw there was indeed a 1 character length string to CONCATENATE to the end of 'TRY' aand it did it. The only change was that the length parameter was probperly set. The end is that the proper ways to get a string into a string variable are manually with the data table, using an ASCII/STRING command or (and here's the point) a MOV command WITH A CORRECT ADJUSTMENT OF THE LENGTH VARIABLE. The MOV command is not a STRING command and doesn't trigger the sdjustment of the length parameter. There is no bug.

As a test, in your very first example, after the MOV, add another mov of '1' to ST9:8.LEN. Then see how it works.

bernie_carlton said:

Ron - you're not looking at this right. ... The MOV command is not a STRING command and doesn't trigger the adjustment of the length parameter.

Click to expand...

you’re probably right about all of that, Bernie ... I’ll work on it some more this weekend and see how it looks after a good night’s sleep ... so maybe the SLC (bless its little heart) IS doing its string instructions the best way that it can ...

[attachment]

but (as of now) I still think that the fact that when TWO displays (highlights #1 and #3 in post #2) indicate that location ST9:8 has some data stored in it – BUT – two OTHER displays (highlights #2 and #5 in the same post #2) indicate that location ST9:8 is empty – then that’s a bug in the RSLogix500 software ... but that’s just the way I am ...

anyway ... I’ve GOT to go home now ... wife’s calling ... see you all Monday ...

Ron Beaufort said:

but (as of now) I still think that the fact that when TWO displays (highlights #1 and #3 in post #2) indicate that location ST9:8 has some data stored in it – BUT – two OTHER displays (highlights #2 and #5 in the same post #2) indicate that location ST9:8 is empty – then that’s a bug in the RSLogix500 software ... but that’s just the way I am ...

Click to expand...

Ron, bernie_carlton is right, everything hinges on the length element of the string structure. Consider - when a string is newly created and shows a length of zero and no characters within, there are still 41 words (two NULL characters per) allocated. Using a CDM you can enter anything you want in any of the 41 words and it will show up when the string is expanded using a CDM screen, assuming a non-whitespace character.

I poked your rung into a 5/40 and it acts identically. I went a bit further and used the CDM to poke "NX" into ST9:8. With a length of zero the data display shows nothing. When a '1' is MOV'ed to ST9:8.LEN, ( XIC B3/1 BST MOV 1 ST9:8.LEN NXB OTU B3/1 BND ) the display now shows "N". When a '2' is MOV'ed to ST9:8.LEN ( XIC B3/2 BST MOV 2 ST9:8.LEN NXB OTU B3/2 BND ) the display will now show "NX".

The point is, the 'X' was there all the time, it's just that RSLogix takes its cue from the length element retrieved from the processor and displays the data accordingly. If you now put the '1' back into the length element of ST9:8 the 'X' will disappear from the data display. It's still there though, the CDM proves it.

.02

life is a learning experience ...

Greetings to all,

ok ... I’ve come to grips with reality ... it is as Bernie says ... you have to look at data in the ST “string” files a little differently than “regular” data such as integers and bits ... I worked on it again last night and came up with exactly the same logical approach that Doug_P has suggested ... here’s a simple one rung program which demonstrates the idea ...

[attachment]

this just moves the seconds reading from the SLC’s real-time clock (a number which ranges from 0 to 59) into the Length field of ST9:9 ... I started out by manually typing the following sample string into the String Text field of ST9:9

ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz1234567890

then as the number in ST9:9.LEN is automatically incremented, more and more of the existing string is revealed ... just as Doug_P said it would be ...

at highlight #1 in the picture, the data shown in the Custom Data Monitor never changes ... in other words all of the data remains REALLY AND TRULY actually stored in the ST9:9 location ... but since this part of the Custom Data Monitor display doesn’t regard the data as “string” type data, it just goes ahead and displays the data continuously regardless of what value is stored at ST9:9.LEN ...

in the Custom Data Monitor at highlight #2, the number of characters displayed steadily increases by one character with each passing second ... specifically, as the value of ST9:9.LEN ranges from 0 through 59 (seconds), the number of characters displayed at highlight #2 increases ... and then when the value of ST9:9.LEN suddenly drops back to 0 (seconds), NO characters are displayed ... of course the characters ARE still safely stored at ST9:9 ... it’s just that the number of characters shown by a “string” type data monitor is determined by the value present in the .LEN field ...

and it’s the same story in the data table monitor at highlight #3 ...

at highlight #3, the number of characters displayed increases by one character with each passing second ... specifically, as the value of ST9:9.LEN ranges from 0 through 59 (seconds), the number of characters displayed at highlight #3 increases ... and then when the value of ST9:9.LEN drops back to 0 (seconds), NO characters are displayed ... once again all of the characters ARE still safely stored at ST9:9 ... it’s just that the number of characters shown by this “string” type data monitor is determined by the value present in the .LEN field ...

so it looks like there isn’t really a “bug” in this part of the software after all ... my apologies to the folks at Rockwell ... and thanks to Bernie and Marc and Doug for helping me come to grips with this ... it all makes sense to me now ... I am in tune with the universe once again ...

summing up:

if the data monitor (examples: the “what’s in here” display on a MOV instruction, or the .DATA[_] display on a Custom Data Monitor) works on the “word” level, then it doesn’t know diddly about how to display a “string” – and so it naturally does the best it can and goes ahead and displays what’s stored in the “word” it’s aimed at ...

on the other hand, if the data monitor (examples: the “String Text” field on the ST file data monitor or the ST_:_ display on a Custom Data Monitor) works on the “string” level, then it DOES know how to display a “string” – and so it naturally goes ahead and displays what’s stored in the “string” it’s aimed at ... BUT ... it takes into account the value stored in the string’s Length field when deciding how much of the string to display ...

it all makes sense ... now that I understand it ... many thanks to Bernie, Marc, and Doug for bringing me back to reality ... I feel much better now ...