Best to filter ASCII in buffer or later?

I have posted on this app a couple of times already. It's almost done!

I have a barcode reader talking ASCII through Ch0 of a ML1500.

I looked around the forum and saw that ACB was recommended to check the buffer before reading. What I wasn't sure about is whether the characters arrive at the buffer all at once or not. It's called "serial", so I figured that they don't. So when I used the ACB, how do I know if there are more characters coming?

I am trying to read an 8 digit part number (including CR) and a 10 digit serial number (including CR). I wanted to prevent getting them mixed, so I was using the POS value of the ACB control word as the condition for firing an ARD to copy to one of two ST elements depending on how many characters.

Returning to the question of "When have I received all of the characters?" I use a self-resetting timer rung to "poll" the port with the ACB. (Every 200msec)

This seemed to be working, but I occasionally get a math overflow fault. I eventually determined that it was from feeding PN data into the SLN part of the program. (Gets converted to a number > 32,767 using ACI.) I thought I had that trapped using the method above, but it appears that it is often a fragment from a previous scan concatenated with the current scan that happens to meet the right number of digits.

My main questions are:
1. Is it better to check # of characters before actually reading the buffer, or just to copy whatever comes into the buffer into a register and then evaluate it?

If the latter is true, let's say "A" comes in. I write it to a register. Do I have to explicitly index to the next register for the each subsequent character, or is there an easier method?

Thanks, and have a good weekend.


Matt

It looks like it might be possible for your program to catch the buffer when it has eight of the ten characters and cause rung 5 to go true when it should be waiting for the termination character. This would only happen if the ACB executes when there are only eight characters in the buffer, since it will only set the done bit when it reaches the end of the buffer or a termination character.

You might want ot use the ARL instruction instead, and/or check for the presence of a termination character before processing the result.

The few times I have done serial ascii read logic in a PLC-5 or SLC I have had to deal with garbage getting into the buffer, so there is always some interim storage location and some length and contents checking done before I call it "good" data...

EDIT: Also, you should check the length of the string before executing the ACI instruction, and then right after the ACI, it would be wise to evaluate the status bits in case there is a bogus character in there or you overflow the integer...

Because your strings are always terminated with a Carriage Return (0x0d hex, 13 decimal), I would recommend using the ASCII Read Line instruction instead.

The default termination character for an ASCII port is entered as "\d" which means Carriage Return.

If you execute the ARL instruction and the buffer already contains data including a CR, then it returns the string almost immediately.

If you execute the ARL instruction and the buffer is empty, it just waits. and waits. and waits. When it finally sees a CR byte, it becomes Done and moves the line into the String file destination. If the buffer fills up to 82 characters, that overflow action also triggers the ARL and the String file will fill up.

An example, using the 2-port 1764-LRP and Channel 1 (lots easier to troubleshoot when you can be online).