ASCII help please!

Hello there all.
I am having an issue with ascii. I have a SLC5/05 and I am connected to CH.0 from my checkweigher. Each pass of a product is supposed to send the weight to my PLC. It does seem to work. I get the appropriate weight in my ST10:0 string but the ACI that is sending it to an Integer is normally 0 or 1. Then it will work for a couple weights and then back to 0 or 1. Sometimes on my ARL instruction it will show that it read 8 characters and then for a while it will add and not clear itself. I know my explanation may be a bit vauge but this is my first kick at ASCII stuff. The program is the same program I used for the last checkweigher I just removed. Nothing has changed. In my checweighers settings I have the following.
transfer speed = 9600bps
parity = none
stop bit = 1
no flow control
output is fixed length
outputs 6 ASCII digits

I am lost on this so any help will be appreciated.
I have attached my RSL500 file.

Thanks

Piw Guy, on Rung 0000 of the Lad 5 WEIGHT subroutine, why do you only read one character from the ASCII buffer each time?

Normally, you should read the entire length of the weight (up to the next Control character sent by the checkweigher, usually a Carriage Return or Line Feed).

By reading only 1 character at a time, then clearing the buffer after each of these 1-character reads, it seems that you will delete the remainder of each weight (unless it is only a 0 or 1). I would look at the checkweigher manual and find out its SEND routine, and how many characters it sends (up to the end-of-line character) for each weight.

If the number varies of characters sent varies for the weight, then you could read one character at a time, but each time check to see if the character is the end-of-line character. If not, save the character in a temporary string, then use the ACN (String Concatanate) to append or concatenate the new character in the temporary string to the end of the string S10:0. If it is the end-of-line of the weight string, then reset or clear the ASCII buffer with the ACL instruction.

An easier option would be to set the the ARL String Length to some number that is always => than the length of the weight being sent by the checkweigher. Then the ARL will be forced to read the entire weight (until it sees the end-of-line character), and you will be assured of always getting the entire string.

ARL [ASCII Read Line]
Rockwell Software
String Length (.LEN) is the number of characters you want to read from the buffer. The maximum is 82 characters. If you specify a length larger than 82, only the first 82 characters will be read. (A 0 defaults to 82.) This is Word 1 in the control block.

Characters Read (.POS) are the number of characters that the processor moved from the buffer to the string (0-82). This field is updated during the execution of the instruction and is display only. This is Word 2 in the control block.

1 The ARL rung goes from false-to-true, setting the EN (Enable) bit.

2 The instruction is put in the ASCII queue, setting the EU (Queue) bit.

3 The instruction executes and the RN (Run) bit is set.

4 The requested number of characters (including the end-of-line characters) are moved from the buffer to the destination string.

5 The number of characters moved is placed in the position field (control element Word 2).

6 The number in the Characters Read field is continuously updated, and the DN (Done) bit is set once all of the characters have been read. If the processor finds termination characters before reading is done, the number of characters found is stored in the POS word of the control block in addition to setting the DN (Done) bit.

7 When the program scan finds the DN bit set, the processor sets the EM (Synchronous Done) bit.

Click to expand...

hey Lancie, thanks for the reply.
I believe that the characters read was simply the numbers of characters on my last read before I saved the program. Sometimes it comes in as 13. When this happens it works properly. I get the weight I am looking for in my string and it will move into n13:19 as intended. It may work three or four times and then go nback to what you see here. It seems when I pass a unit over the scale and it is a 4 digit weight like 1250 grams, it normally works better then say with a 450 gram unit. When the smaller values come in it will sometimes not read a string value at all or it will read the vale in the string but in my n13:19 it will oly display a 1. I should mention to you that I am doing this with only two wires. TX and gnd from the serial device and RX and gnd on my 5/05. there is no communication from the PLC to the checkweigher.

i have had best results when I set my string length to 8 on the ARL.

EDIT: Try removing the ACL (ASCII Clear Receive Buffer). In your program, you continuously read the buffer so that if there are more than one pending weight (lines) in the buffer, you will eventually read all lines of data UNLESS YOU CLEAR THE BUFFER.

In this case I don't think you need the ACL at all. Set the ARL String Length to the max expected line (number of characters for each weight).

Hello there Lancie1.
If you are still following this thread I want to tell you where I am at with this. I am reading string values no prob. However, some of my values are landing in my string something like this- B C 75.0A when I should be seeing values like 750.00G or sometimes like 750 . The other thing I see is that my ARL instruction even though set for 8 characters is reading a different amount of characters each time. Once 2 then 4 then 3 then 8. its random. I put a histogram on my done bit and it looks to be setting with every read no matter how short the string is. I would think that because the machine outputting the string to my PLC is set to fixed length it would be the same every time. I did try removing the clear buffers instruction from the logic but it made no difference in how I recieve these strings.

Thanks

Hello Lancie1.
I have figured it out. I increased my string length to 0 (84) and started to notice that my buffer was filling up with strings that were 13 digits in length. Then I went to my ARL and set the length to 13. After a few moments I started getting a consistant string value. Then I used an AEX to pull out digits 6 to 9 and voila all is good. I had many hours of noodle scratching to figure this one out. I thank you for all the advice you provided me with. Also that link to the SLC 500 instruction set was a huge help. I have a similar publication but not as detailed.

Good job. I think the way the ARL works is it looks at the String Len setting (0 to 82) and trys to read that many characters from the ASCII buffer. However, because this is "Read Line" command, if it encounters an ASCII end-of-line characters BEFORE it reads in the number of characters set by String Len, it stops and sets the DN bit. So now you have one string, but in the meantime another sting may have been sent to the buffer (or two or more may have already been in the buffer). If you don't clear the buffer, then the ARL will read the next line on the next ARL activation. If you clear the buffer after reading one line, if there are any more lines in the buffer, they will be lost.

On the other hand, if you set the ARL String Len to be LESS than the maximum number of characters in the longest checkweigher line, then you will get only part of the string (which will be a jumbled mess).

I think String Len should always be set to the maxium number of expected characters in each line of the buffer. Some programmers always set it to 82, and some set it to 0 (which makes it default to 82). There is no penalty for setting it to 0, because it still will read only 1 "line", whatever that line length may be from 1 to 82 characters.

I increased my string length to 0 (84) and started to notice that my buffer was filling up with strings that were 13 digits in length.

Click to expand...

If the ARL "Characters Read" word is reporting "84", it is most likely because it includes the 2 end-of-line ASCII characters (LF and CR). Those two characters are not considered to be part of the official 82-charactrer String Length.

I do not see those characters coming in on my string. The only characters I see are like this ( C^B^ 31250.00G )To me I see 13 characters If I count the two spaces between ^ and 3. My useful data is the 1250 . This is the data I take with my AEX instruction.

I'm pretty sure that the characters C^B^ are the end-of-line characters that Lancie1 is referring to. Not all devices use the same end-of-line characters. They might also be start-of-line characters. If so, you may or may not have to provide different logic to handle them.

My guess about what is happening is that the ARL reads until it sees at least one normal character, then it starts looking for the end-of-line characters. Once it finds those, it stops and reports the previous characters. In your case, because on the first read, it does not report the end-of-line characters, those are left in the buffer and show up on the front of the line for the next and subsequent reads. Probably C^ stands for keyboard entry "Ctrl-C" or an ASCII character Carriage Return, and B^ stands for keyboard entry "Ctrl-B" or ASCII character Vertical Tab.