RSL500 Strings

Hello to you all.
I have an issue with some string data in RSL500. I set up a new checkweigher in our plant a few months ago. It sends me a string via RS-232 to my PLC. My issue is, every once in a while(few weeks) my data string in ST10:0 will change. I have included a screen shot of what the data normally looks like.(Screen shot NOV.23/2013) and a screen shot of what the data looks like when it changes(Screen Shot NOV.23/2013_B). The data is staying the same but it will rearrange itself and move character B to the front of the string. When this happens it is usually during a product change and we start up with this problem. During the product change our PLC is not switched of or re-booted. Also in saying that re-booting of the PLC does not help this issue. In order to correct it I simply go to my ASCI READ INS and change the staring length to any other value, and test my changes. As I would expect this gives me a jumbled mess of data. Then I put the string length back to its original value by untesting the edit and my string is back to its steady proper configuration. I have posted the file so anybody who thinks they can hlep can have a look. I need to either correct this issue so that I always get the same string format or find a way to writh the code so that even if the format does change I can still extract the part I want. The part I want is the 4 digits that reresent my weight. (1250) The decimals are of no concearn to me. The logic in question is on ladder 5 rungs 0 and 1. This is my ASCI READ and my AEX.

Hope somebody can help.

Thanks
Pie Guy

Sorry I have to state a correction. The images I posted as before the error occured and after are mixed up. The file NOV.23/2013_B is what the strings should look like. Nov.23/2013 are the strings in the mixed up format. Sorry for the confusion, I should proof read a little closer next time.

The data is staying the same but it will rearrange itself and move character B to the front of the string.

Click to expand...

The two control characters Ctrl-C and Ctrl-B should always appear at the end of a line read from the ASCII Receive Buffer. Your string, if properly sent, should have 13 characters like this:

 

 1      2    3      4      5      6      7      8            9      10

space space number number number number number decimalpoint number number

 

 11     12     13

letter ctrl-C ctrl-B

If one or both control characters appear at the FRONT of a line of characters, it means that you had a line sent from your checkweigher that had no weight but only the 2 end-of-line characters (or some upset during the product change caused only part of a line to be sent or read).

You need to add a routine to check each line read to see if the first character is a space and the line is 13 characters long. If not, discard it and read the next line.

You can use AEX to extract the first character to a test string, then use ASR to compare the test string to a stirng with only a space character. If not equal, then discard the previously read string and read the next line fromn the buffer.

You can check the length of the last line read by looking at the value of R6:1.POS (the number of Characters Read of the ARL instruction). If R6:1.POS < 13, then discard last string and read the next line.

Thanks for the reply Lancie. I totally agree with what you have asked me to do. I do have a question though. Yesterday morning when this first happened I changed the value of my string length in my ARL instruction. I changed it to a random number of 5 then back to 13. The strings then started to flow again in the good format. Me not being able to leave well enough alone I started playing with this. I then changed my string lenth on my ARL to 5 again and back to 13. Since then I have been recieving every string with the B at the front. It seems stable and has been working that way since. The funny thing is that I know eventually, today, tom, or next week it will change back to the format I like to see with the space in front ang C^B^ at the end. Then I will need to change the index on my AEX instruction to follow suit. So not so much a question but something that has been bugging me.
So if I understand you correctly you are saying that my check weigher is sending me string after string of data in the wrong format? Keep in mind I get anywhere to 100 to 110 strings a minute. It happens so fast that the only way to follow my ARL.DN is with a histogram.

Instead of depending on the length of the message make sure your 'Termination Characters' are set correctly. Double check, from the weigher's documentation, that the two control characters occur at the end of a transmission.

Use ABL to determine that at least one message is in the buffer (count at least 13) and ARL to read just one message out of the buffer.

I don't know for sure what is happening to get a ^B at the front. When you change the ARL length, it causes an extra Read Line that gets part of the next 13 characters, shifting the position of the end-of-line characters.

It could be that your ARL instruction in File 5, Rung 000 sometimes does not have time in one PLC scan to read the entire line. If so, then your AEX on rung 002 will insert only a partial line into ST:10.1 (not the entire 13 characters). To prevent this, you could insert a XIC R6:1/DN in front, as you have on the following rungs to make sure that ARL is completely finished before you extract a string.

For the majority of times that I have used the ASCII buffer, I have not used ARL but ARD instead. ARD lets you read a string of X length, regardless of where the end-of-line characters appear. This is useful for devices that do not always send the same number or characters (for example where the weight is a whole number and the decimal places are dropped and not sent). Then you can use ASR, ASC, and AEX and commands to extract the desired parts, then clear the Receive Buffer with ACL, then read the next batch.

Another possibility is that the XIO R6:1/EN (which will be ON for only 1 scan) does not allow the ARL time to always read 13 characters. The Help file states that it may take longer than 1 scan to finish.

(Done) bit is set opposite to a program scan when an instruction successfully completes its operation. An instruction can take longer than one program scan to finish executing.
Rockwell Software

Click to expand...

You might use the XIO R6:1/EN to start the ARL, but then use a flag relay to keep it ON until R6:1/DN goes on. See picture.

Thanks to you both for the helpful input. I will try these suggestions out and let you know how it goes.

Thanks again!

In looking at your program, I spotted a severe error - actually several cases of the same error.

For Lad 5 rung 000, your ARL instruction uses control words R6:1, R6:2, and R6:3. But in Lad 5 rung 019, you use again use R6:2 in a FFU instruction. The R6:2 in the ARL is the Length, so it will get reset by the FFU to something other than "13". Not good and that could easily be the cause of your errors! I think MOST instructions that use the R6 Control words always use 3 words in sequence. If they overlap, bad things happen!

For completeness, I looked at other places, and you have several other places where the R6 words are overlapping. That could easily mess up lots of instructions. You really should go to the tree menu "Database, Address/Symbols" and straighten out your R6 addresses so that each instruction has room for 3 words that are not used by any other instruction.

wow. Looks like I got some work to do.
Just for the record, I did not write this program, only pieces of it. I will look into staraightening this all out. Good catch though. Hopefully fixing all this will improve how my program is working. I am leaving now for the day so I'll have to start this in the morning. I will keep you updated on my progress and thanks again for the advice. I work in a rural area in a small plant. Taking online courses and self teaching this stuff sometimes it seems there is nobody to ask for help. Glad to have the forum people.

Thanks, and good luck with it. I think now you can get it to work correctly. You can use add new R6 addresses and use Find & Replace to move existing addresses to the new R6 addresses.

This should allow you to produce a bunch more pies! Send me a few of the extras!

Hello Lancie.
I wanted to tell you how things went with the strings after the fix. I changed the addresses on the ASCII instructions like you said. Now I have R6:12 as my control word and R6:13/14 are left empty for this instructions .POS and .LEN. What I have noticed is that my instruction does run better. It is faster as I can now more often actually see my DN bit setting. However my data format has not changed. I am still getting the data with my B at the begginning like this
(^B 31250.00G^C^)always 13 characters.
I am now going to try what you had previously suggested to me to use a flag bit to keep my EN bit on untill the read has set its DN bit. I will keep you posted on how it goes.

Thanks for the help!

Just to add!
So I made the changes with the flag bit to keep the ARL on and such. At first it wasn't working. What I did was keep changing my string lenth. To random numbers. Then after a few trys of going back to 13 for a length it finally started giving me the data in the proper format. Just as it was when I set this machine up. It is now coming continuously and it is stable. The odd thig is though, notice my char. read is only 12 and it doesn't seem to change. However I know it is setting from watching it on a histogram just always says 12 on my read length.
So, now I know I can chage my data format simply by juggling around the string length and putting it back to 13. ODD!!!
Any thoughts?

Any thoughts?

Click to expand...

I can only guess that the ASCII Receive Buffer had a bunch of old partial strings in it, and started working after you read it enough times to clear out all the old mis-read strings that were brought in with the old code.

However I know it is setting from watching it on a histogram just always says 12 on my read length.

Click to expand...

Could it be that there is only 1 space at the beginning of the string? What does it do it you set the ARL Length = 12?

If I use a string length of 12 in my ARL then the first character keeps shifting by one digit. Eventually after so many reads the first digit which should be a space, will move through the string till finally it reaches the beginning again. It kind of makes the string rotate. 13 is the only number I can make it work solid with.