Serial Communication

thekrel · April 2019

Hello,

I am working on a serial communication project utilizing the RS UNI - 2688666 module. I am programming using PLCnext Engineer 2019.0 LTS HF1 (Build 3.13.533.0), PLC firmware 2019.3 (19.3.0.18509) and the AXL Comm Serial 4 function block.

I am reading a Garmin 19x HVS GPS. The GPS transmits in the NMEA 0183 standard over RS-422. I am configured at 38.4 Kbaud 8n1, with the GPS sending an update every 200ms. I am using the end-to-end format with CR and LF as my delimiters. It works, I can read position, heading and speed. My issue is that the receive buffer is constantly over-flowing and causing an axio bus error. I utilize the NDR output from the control function block to re-trigger the read command. I am only reading 75 bytes/characters. The GPS is a "talker" it does not need to be prompted to transmit nor does it need handshaking with the listener.

Is there a better way to read the data and avoid the buffer overflow? All of the sentences begin with $,G and end with CR,LF.

Thank you,

Josh

Martin [PLCnext Technology Team] · April 2019

Hi Josh,

What is the cycle time of the program that is calling the Comm Serial function block?

The reason is, the Serial module has a reasonably large input buffer, but it can only transmit this input data to the CPU in 17 byte chunks (see the manual for details - it has 20 bytes of process data in each direction, but 3 of these are for commands).

So a 75 byte message will take at least 5 scan cycles to transfer, and maybe a few more scan cycles between messages. So if your task cycle time is more than about 40 ms, then you're cutting it fine, and at 50ms you can expect the input buffer to fill up.

If you don't need such a fast cycle time for the rest of your program, you could put your GPS reader in a separate task with a fast cycle, even on a separate CPU core (ESM) if you want, and transfer the data to your other program instance(s) via Ports or global variables.

===================================

EDIT: You will also need to make sure that the Axioline I/O is being updated at the faster rate. By default the Axioline I/O is updated every 50ms, which means the input buffer in the Serial module will fill up regardless of how fast your program is running. You can tie the update of the Axioline I/O to a specific ESM task in the Controller Settings page - in this case, it should be the (fast) task that is calling your Com Serial function block.

===================================

Hope this helps.

Martin.

thekrel · April 2019

Thank you so much Martin. The cycle time was the problem. I moved the GPS read function to its own Cyclic task set to 25ms. I am no longer getting bus over-flow errors! I read through the manual in regards to the buffer size and I am curious as to why it is only 17+3 bytes. Is this a limitation of the Axio bus? Thank you for your help.

Martin [PLCnext Technology Team] · April 2019

Great, glad to hear.

To answer your question - each Axioline I/O module has a defined set of "Process Data" that is detailed in the user manual for that device. This is the data that is transferred between the CPU and the module on each I/O cycle. Every cycle, a maximum of 512 bytes can be transferred between the CPU and all the I/O modules on the local Axioline bus. I guess that, in theory, one module could define 512 bytes of process data, but then it could not be used with any other I/O modules on a local bus. Most types of I/O modules, the ones that deal with digital and analog I/O, can transfer all their data in just a few bytes, but for comms modules like the one you're using, it's a trade-off between transferring large amounts of data each I/O cycle, and leaving enough room on the bus for other modules.

For very demanding applications, or where you have multiple serial devices, you could process the serial data in an external module, something like the one below (which comes in variants with up to 4 serial ports), and transmit the data to the PLC over Ethernet.

85333 1000 int 01