Recieving RS232 data

[MisterB.Ohio]

I have written software to receive data from an RS232 instrument using Port 2 (V100-17-RS4 properly configured)  The issue is it does not receive a valid data packet.  I have gone into INFO mode on the V700 and am able to verify that port 2 is configured for RS232 and can see monitor the received data.  The packets are all missing the first 3-6 bytes of data.  I have verified with a laptop plugged into the same cable that the entire packet is arriving at that point.  Is there something obvious I am missing ?  does there need to be a delay in the PLC software?  Why would it drop the first several bytes?  

Oh and the data rate is not extremely high - 9600, 8, n, 1, no parity, no flow control.

Thanks for any insight.

[kratmel]

Please post your RS232 communication configuration.

If you use FB Protocol than you must (tips from manual):

---- A Protocol Scan FB, which enables the controller to receive data response messages from the device. Note that in order to receive new messages, you must clear the communication buffer after each message by using the Reset Buffer FB.

Maybe no resetted buffer cleared via com port timeout is main problem.

You can also use port 1 for testing (Ethernet connection to Visilogic must be used).

[MisterB.Ohio]

Just to add more information, I have verified that when the V700 is not running the program I wrote, while in INFO mode, the serial port monitor does show the complete message received from the instrument.

This is the snipet from my ladder.  Does there need to be a delay?

[MisterB.Ohio]

OK... I have started a fresh program to eliminate the rest of my programming from the equasion.  Here is the entire program, the serial port init, and the protocol scan setup.

An example of the hex message I am receiving is: 7B 4D 18 00 00 00 05 71 47 42 03 BC 4D 46 E0 AB F4 41 00 00 00 00 0F 7D

When this program is loaded into the V700 and run, it does not receive any valid messages from the Instrument.  If, using a laptop, I send "{Mabcdefghijklmnopqrstu}" the program says it receives message 1 from the computer.

If I go into INFO mode while running the program, the serial monitor function will show the complete message received from the laptop.  If I reconnect the instrument, it shows only the last 16 bytes received. 

One note - the instrument sends these packets out once a second.

The confusing part to me is when I delete this program from the V700 and install a program that does not configure COM2.  In INFO mode it shows Com2 to be configured for PCOM protocol instead of "Protocol".  With that and looking at the serial monitor it shows that the V700 is receiving the proper packets from the instrument.  All 24 bytes are displayed.

 

HELP please?  any more information needed?

Serial trial.vlp

[Ausman]

Actual device being received from is what?

Increase timeout?

Insert some delays of a few scans b/n actions to allow buffers to clear.   ie don't do the next action immediately on a bit changing that says a function (that inherently uses a buffer) has finished.  Trial waiting a few scans.

Have you tried simply letting the plc receive the stream without start and end, just to see what happens?

cheers, Aus

[kratmel]

Please post - what message is recieved via PC from instrument (terminal printscreen).

Please post instrument model or link to user manual with communication option.

 

In protocol  FB you post  used 22 byte scan string(0to21)+2byte start+ 1byte end=25byte message scan  - it is not parsed by FB protocol.

As Ausman recommend please try to scan string with 24 bytes length without ETX and STX.

 

[MisterB.Ohio]

The actual device that data is being read from is an Axetris TDL.

I increased the time out to 1.5 seconds and it had no effect.  I get the same results.

I installed a positive transition on the 1 second square wave (SB3) in the protocol scan line.  No effect, same results.

What functions would I use to allow the PLC to 'just receive the stream'?  If you mean setting the scan to have a 24 bit string?  yes I have and it makes no difference.

Does the Protocol function block change the serial buffer size?  how can the serial buffer size be set?

Thanks for any suggestions and help.

 

 

[Joe Tauser]

3 hours ago, MisterB.Ohio said:

What functions would I use to allow the PLC to 'just receive the stream'? 

@Ausman @kratmel - this is why I use screenshots.  Serial communication setup can be really confusing and verbose answers go right over their head.

 

Try talking to the device with a terminal program that can display bytes in hex such as Bray's terminal.  Hex mode will tell you exactly what the device is doing.

In your SCAN block you've set some rather strict rules allowing incoming data.

This means the block will ONLY work when the incoming block starts with "{M" and ends with "}".  Verbatim.  There's probably a carriage return (0D) and/or a line feed (0A) attached to that string that you don't know about. 'just receive the stream' means you remove those rules.

 

The SCAN block does not set the buffer size - it can be up to 512 bytes.  You set the size then you define the variable.  For testing, I'd dial it up to 50 bytes.  Just remember that there's a big block of MI's there and you don't want to stomp on them with other logic.  For that reason, I usually put serial receive registers up high, like at MI 500.

 

If you don't know how to use the Memory tab to view incoming SCAN data, have a look at this post-

 

Let us know what you find.

Joe T.

 

 

[MisterB.Ohio]

Joe, thank you for the suggestion of Bray's terminal.  Using this I was able to capture the attached.  it shows 8 packets received from the Axetris TDL.  Each begins with hex 7B 4D ( {M ) and ends with 7D ( } ). 

I did as you asked and changed the Scan to not look for a start of text or end of text.  I put a 25 word (50byte) string in and set the terminator to 10 mS silence and tried that.  In INFO mode I can see that the full messages are received once a second as I expected.  However the program itself is not recognizing them as valid since it is looking for 50 bytes.  so shortening this to 24 bytes the messages are saved in the MI's.

I then put the opening bracket back as the STX, but coded the M in the first position of the message and shortened the string to 22 bytes.  this also worked.  I then changed the variable to save one byte per MI and made the vector length 22.  This worked.  When I made the vector length 21 and put the closing bracket as the ETX it stopped working.  but if I code the end bracket as a control character at the end of the message line, and put the 10 mS silence back, it works.

SO I do have a work around, but any clue as to why the ETX method is not working?

Thanks for your help.

[Joe Tauser]

You've done some excellent troubleshooting.  I would have bet money that the instrument would have appended a CR (0D) to its string, but your empirical data proves otherwise.

The "}" should work as an ETX, but you've done the work and it isn't.  Did you try the "Add Null to End of Stream" checkbox?  As a general point, that will trigger the block on any incoming data regardless of length.

If that still proves elusive, I'd go with a working solution and turn my attention to getting the string blocks to parse and format the data the way you want it.

 

Joe T.