1734-rs232 ascii reading too long barcode messages

[Pandarojo2024]

Hi to everybody. I need to read the first 12 characters of the message that a barcode reader sends to the ascii card (1734-rs232 ascii) and I can't do it. The problem is that the message that the barcode reader sends is 170 characters, so the plc sees that the XX.ReceiveRecordNumber increases by 2 because it overwrites the data of the first part of the message and I have the characters in the buffer from 129 to 170.
How could I capture the data of the first message? I really need to read the first 12 bytes from the barcode reader message.


Thanks a lot.

 

[drbitboy]

Is there a delimiter at the end of each full set 170 characters that is sent by the barcode reader?

The trick is to focus on the unique and relevant characteristics of what the barcode reader is writing to the the serial interface, and modeling that in the PLC reader.

 

[Pandarojo2024]

Yes, there is a "#R" (carriage return) at the end of each full set 170 characters.


Received data looks like this:
"01-0123456789;02-1357902468;03-9876543210;04-9753186420;05-...................."


The string i need to obtain is "0123456789"

 

[drbitboy]

https://literature.rockwellautomati...ure/documents/um/1734-um009_-en-p.pdf#page=29


think about the data as a stream of characters i.e. instead of

• 01-0123456789;02-...<CR>
• 01-0123456789;02-...<CR>

think of it as

• ...<CR>01-0123456789;...<CR>01-0123456789;...

Set up carriage return ('$r'; <CR>; ASCII code 13) as the start delimiter, and semi-colon (';') as the stop delimiter. the serial module will ignore everything from the semi-colon to the carriage return from the previous barcode, so it will miss one initial barcode, but then extract everything from the carriage return to the next semi-colon on each succeeding barcode. You can then extract the required characters from the returned string.

 

[Pandarojo2024]

Thank you. I´ll try it next monday. I was trying with no start delimiter and ';' as the stop delimiter, so i received several incoming messages ..... one for each semi-colon.

 

[Ken Roach]

Welcome to the PLCTalk forum community !

This is a tricky one. The idea of skipping the first barcode makes some sense.

The essential issue is that the 1734-232ASC module has an Input buffer size of only 128 bytes, and this barcode string is 170 bytes long.

I don't know if the master/slave handshake will allow the contents of the overflowed buffer to be put in the Produced data connection while the not-yet-overflowed buffer is still filling up. It's worth looking into.

This application might require a device with a bigger buffer.

(I was still typing and had not seen the update)

Using the semicolon as the delimiter and reading each element might be the best way to do this if the RPI is fast enough or there's a delay between the delimited sections.

 

[Pandarojo2024]

Thank you for your welcome. Threre is not delay between the delimited sections. The RPI is set to 80ms, and I am not authorized to modify it due to factory guidelines, I will try other things before asking for authorization.

Losing first message is not a problem, if it really works.

 

[Pandarojo2024]

.....

I don't know if the master/slave handshake will allow the contents of the overflowed buffer to be put in the Produced data connection while the not-yet-overflowed buffer is still filling up. It's worth looking into.

.......

I was thinking about this, it could work.


Thank you!!!

 

[drbitboy]

The essential issue is that the 1734-232ASC module has an Input buffer size of only 128 bytes, and this barcode string is 170 bytes long.

Oof. I missed that, and it may be a deal-breaker for the approach I suggested.

That said, here is what the 1734-232ASC manual claims:

Once the Start Delimiter [<CR>] is received, all characters are stored until either the End Delimiter [';'] is received or the Max_Receive_Char_Length is reached. Once the End Delimiter [';'] is reached, the data string is updated and the ASCII module ignores all subsequent data until the start delimiter [<CR>] is received again.

So perhaps the 150+ characters, from the target semi-colon (End Delimiter) after the target 12 character to the next <CR> (Start Delimiter), will be ignored and not be charged against the available buffer.