RS232 ASCII, trouble getting HEX data

Hi, Guys
I'm trying to upgrade a device witch comms is thru a RS232.
The PLC is a Compactlogix L16ER to a remote PIO 1734-AENT then on this PIO a RS232 ASCII card (slot 7), I'm checking in/out info using RealTerm, my issue is as follow:
The Input Blocks of the RS232 is not getting updated as it should, my incoming info is getting shift to different blocks all the time, means i'm expecting 8 blocks of HEX data back, i'm getting 8 blocks back but 3 or 4 are from the last record, I think the issue may be with the buffer on the RS232 card not getting emptied or deleted.
And I'm using Realterm as an sniffer the in/out instructions are good (see picture), but my input blocks (PLC) are all scramble shifting blocks, sometimes one block some other times 2 or 3 blocks or more.
my PLC has limited ASCII instructions, now the question is how can I fix it?, how can I empty de RS232 Buffer?
Any help will be really appreciated, been working on this for a month now

How are you receiving the data (i.e. via what instruction, and how is it configured)? Can you post the entire program (put it in a .zip, also include a report printed as a PDF, and post that)?



Specifically, what triggers the change in Cabinet2:7:I.ReceiveRecordNumber?


I see the target device sends something like A....<checksum>; does it also send newlines and/or carriage returns at the end?

How are you receiving the data (i.e. via what instruction, and how is it configured)?, (see picture) im receiving the data after I ask for it then the unit attached to the RS232 send a reply/responce, then Im checking for a change on Cabinet2:7:I.ReceiveRecordNumber, using the NEQ to compare old and new record # if it is different im making Received_New_Data "ON" (rung 1), then on rung 2 moving data from blocks to Raw_XXX.

Can you post the entire program (put it in a .zip, also include a report printed as a PDF, and post that)?, yes, it is for now 3 rungs, nothing fancy.(see pic RS232 Send_Receive)

Specifically, what triggers the change in Cabinet2:7:I.ReceiveRecordNumber?, see question 1 or new data on Cabinet2:7:I.ReceiveRecordNumber

I see the target device sends something like A....<checksum>; does it also send newlines and/or carriage returns at the end?, no new lines or carriage return, just the check sum

thank you

RAYBRITO said:

...(see picture) ... (see pic RS232 Send_Receive)...

Click to expand...

No picture was attached to post #3; the OP has a pic called RS232_Response.jpg but it shows only two rungs.


Is it possible for an ASCII 'A' character (0x61) to be present anywhere in each record other than at the start of each record?

Sorry drbitboy, i skipped the click on the upload,
now is here, can not add .rar files

Is it possible for an ASCII 'A' character (0x61) to be present anywhere in each record other than at the start of each record?, no, at least I don't see it on realterm, each response starts with 0x41 and it may be 5 or 8 blocks, I'm interested on the 8 blocks, since 5 blocks is only a predefined response like, yes it is running, no it is not running or is faulted, on the other hand the 8 blocks contains much more info like pressure as xx.xx or only .xx, this data needs to be converted from hex to binary then using the mantissa to floating number, but for now I need to get the blocks in order, after Ill do the rest

thank you

What are the values in the [Configuration Assembly] cf. here.

RAYBRITO said:

Is it possible for an ASCII 'A' character (0x61) to be present anywhere in each record other than at the start of each record?, no, at least I don't see it on realterm

Click to expand...

Hmm, I think you're going to have to parse this byte by byte.


Or use a timer and assume the response is complete until proven otherwise (the length of the response is the value in the third byte plus four (A=0x41 in first byte; something (address? request type?) in second byte; length in third byte; checksum in last byte).

Specifically, what triggers the change in Cabinet2:7:I.ReceiveRecordNumber?, see question 1 or new data on Cabinet2:7:I.ReceiveRecordNumber

Click to expand...

The answer to question 1 explained how the ladder code detects a change to Cabinet2:7:I.ReceiveRecordNumber, but that was already clear from the rungs posted in the OP; I was asking about upstream of that i.e. what makes that change to Cabinet2:7:I.ReceiveRecordNumber i.e. how is the ASCII card configured: line termination - probably none; receive buffer size; etc.


From the RealTerm PNG, it seems that some responses are shorter than 8 characters; since there is no termination character, how does the ASCII card (1734-232ASC?) know those short records are complete and that it is correct to increment .ReceiveRecordNumber, and how do those three rungs respond to those shorter cases?


In the RealTerm example, how does RealTerm know where to terminate each line? Does it insert a newline+carriage-return when you send a new command?

In the RealTerm example, how does RealTerm know where to terminate each line? Does it insert a newline+carriage-return when you send a new command?, I enter/start a new line after I send a command, otherwise it will be one long line of data.

From the RealTerm PNG, it seems that some responses are shorter than 8 characters; since there is no termination character, how does the ASCII card (1734-232ASC?) know those short records are complete and that it is correct to increment .ReceiveRecordNumber, and how do those three rungs respond to those shorter cases?, Short responses are not needed, Im not checking them.
How the ASCII card knows to increase the ReiveRecordNumber, no idea, I guess after it gets new data it increase or change the number.

what makes that change to Cabinet2:7:I.ReceiveRecordNumber i.e. how is the ASCII card configured:
Baud rate: 9600, data bits:8, Parity:None, Stop bits: 0.
Receive data :
Start Mode: Ignore Delimiter
Termination Mode: Exclude delimiter

Transmit Data:
Termination Mode: Exclude Delimiter

RAYBRITO said:

Short responses are not needed, Im not checking them.

Click to expand...

Then how does the code know to ignore them?

RAYBRITO said:

How the ASCII card knows to increase the ReiveRecordNumber, no idea, I guess after it gets new data it increase or change the number.

Click to expand...

Eliminate "no idea" and "guess," and the solution should be obvious. Until then the code will have no idea, or more specifically, no guarantee, what is in the receive buffer.


One approach is issuing a reset/clear-receive-buffer to the RS-232 card just before every send, and that might be part of the eventual solution, but that alone is only sweeping the problem under the carpet, and some obscure even-more-difficult-to-diagnose event will cause a problem later.


Bon chance .

Then how does the code know to ignore them?,
to get a short response I need to ask for it, since I know the short responses I do not ask for them.

One approach is issuing a reset/clear-receive-buffer to the RS-232 card just before every send, I can not find the reset/clear-receive-buffer instruction, if I reset the module and I ask/send a value the response is in the right location until I ask again then it starts to shift/move.

last but no least Eliminate "no idea" and "guess," and the solution should be obvious. Until then the code will have no idea, or more specifically, no guarantee, what is in the receive buffer., the correct response to your question is until the rs232 buffer is full then it changes/increase the Cabinet2:7:I.ReceiveRecordNumber, sorry for using "no idea" and "guess".:nodi:

thanks.

The 1734-232ASC module is not appropriate for receiving hex or binary coded data of variable lengths that has no ASCII termination character.

I am very familiar with this issue, but have found no good workarounds.

Here's why: the "RecordReceive" value, and the associated Input data tags, are only updated when the module thinks it has received a frame of data.

It can determine that by looking for a unique termination character, or by looking for a fixed number of bytes.

It cannot do it with a timeout or by examining the incoming data byte-by-byte to deduce which bytes are the checksum.

There is no way that I know about to trigger the update of those tags or to read the buffer with an explicit message.

In my opinion, it would be better to replace this function with a device that *does* allow you to use timeouts or examine the incoming data byte-by-byte, like a Red Lion DataStation.

Drbitboy, thank you

Ken R., thanks for your response, ill see if I can get my hands one one of them $$$ is the issue.

Thank you all.

Ken Roach said:

I am very familiar with this issue, but have found no good workarounds.

Click to expand...

I see what you mean in general. However, for this particular case:


It's not pretty, but couldn't the receive buffer length be set to 1, then parse the data byte-by-byte? If the baud rate is low enough (say 2400baud ~ 4ms/char) then the rungs might be able to keep up.



Also, and again it is not pretty, but

• Set A=0x41 as the receive termination character
• Set the receive buffer large (at least 24)
• Transmit a second follow-up request that will receive a known response e.g. "are you there?"
  • This response must not have an A in it after the initial A

the returned data will be
which will trigger at least two .ReceiveRecordNumber increment events, with the following content:

1. previous yes I'm here, possibly empty
2. actual response desired, possibly short
3. multiple balance of actual response if there are internal As in 2

Then the code could

• Read and ignore (1)
• Take (2) as a response
• While response is short (< 7 bytes), append an A to it, read again and append the result.
• If response length is 7, append A to response (checksum)

Yeah, that might work, but Ken is right that it is better to buy a card suitable to this application: the right card will be cheaper than the incremental time it takes to code this up.

I understand the pain of sunk costs and budget constraints, but I can reliably predict that even if you do create a workaround, it will be unsatisfying and cost more.

An HMS Communicator AB7072 should be around $750, and I know that its Generic Data Mode allows a timeout delimiter instead of an ASCII character delimiter.

A Red Lion DA10D should be just over $600.

Both are widely available from major electronics distributors.

drbitboy, you read correctly that the word "good" was significantly modifying the phrase "no workarounds".

And you got the idea of what I did; enlarged the fixed buffer and sent multiple commands so that they exceeded the fixed buffer size, which triggered the transfer of the data to the Input data image.

Then I reset the buffers to discard the extra data, and started over again.

It was ugly, hard to troubleshoot, painful to write, and slow. If presented with the same challenge today, I would not hesitate to buy an HMS Communicator AB7072.