RS485 Baud Rate Between Nano-10 and Fx1616-BA

[njlaw]

The manuals for both the Nano-10 and the Fx1616-BA indicate that they should support up to a baud rate of 230.4kbps; however, I am unable to successfully communicate between them over 100k.

The Fx1616-BA COMM2 is connected to the Nano-10 COMM port with 18 AWG shielded twisted pair.  They are less than 1 metre apart.  I have tried both with and without 120 ohm terminating resistors, but at this distance, it really shouldn't make a difference.

Fx1616-BA Test Code (Simplified)

1st.Scan                      Init
---| |-----------------------{dCusF}

Clk:1.0s                    ReadSlave
---| |-----------------------{dCusF}


Init
----
SETBAUD 2,&H09

ReadSlave
---------
T = STATUS(21)
READMB2 12,8,64,DM[1],8
R = STATUS(2)
V = STATUS(21) - T


Nano-10 Test Code

1st.Scan                      Init
---| |-----------------------{dCusF}

Init
----
SETBAUD 1,&H09


This setup works perfectly fine at the default, at &H07 (56.7k), at &H08 (100k), but not at all at &H09 (115.2k) and &H0A (230.4k).

Statistics (100 samples per baud rate)
Baud Rate | Mean ReadSlave Time | Std Dev
==========+=====================+=========
   38,400 |             17.59ms |  1.92ms
   57,600 |             15.11ms |  1.99ms
  100,000 |             12.77ms |  1.97ms

The ultimate goal in this is to minimize latency between the Fx1616-BA, which acts as the master and 3 Nano-10s along with a third party RS485 device that act as slaves.  From the time the user pushes a button on the HMI that requires a change in the devices controlled by the Nano-10s, too much time is passing before the slave devices receive the command via Modbus RTU from the Fx1616-BA.  Just as a note, we are working on other ways to optimize the speed (e.g., batching multiple WRITEMODBUS commands into a single WRITEMB2 command, etc.)

Any advice would be appreciated!

[support]

Thank you for your report.

Please note that serial port at 230400 bps has a bit time of 4.36us.   Serial port baud rate are usually derived from CPU clock after feeding through some prescaler and divisor and hence the bit rate is often just an approximation. Since not all devices run at the same CPU clock rate the actual serial port speed would vary slightly from one family of device to another.  Asynchronous serial communication such as UART requires both devices to be within +/- 3% of the agreed BAUD rate. i.e a deviation of  just +/-0.14us in bit period would fail the communication at that speed.

We conducted some tests by setting a Fx PLC and a Nano-10 PLC  RS485 port to 230400 bps.

Individually, both the Fx and the Nano10 PLCs are able to communicate with a PC at 230400 bps without any issue in short wire range. We used an internal version of i-TRiLOGI that we can set to 230400 bps and we can sustain online monitoring with each PLC separately.

However, when we setup the Fx PLC to send hostlink command to the Nano-10 PLC at 230400bps, the Nano-10 does not appear to accept the command as per your experience at 230400.

We then setup two Fx PLCs and we are able to use one Fx PLC as master to send hostlink command to the second Fx PLC as slave and the master Fx PLC is able to sustain good communication with the slave Fx PLC.

We believe that these two different family of our PLCs may be incompatible at highest baud rate such as 230400 or even 115200. This is because the Fx PLC and the Nano-10 CPU are clocked at different speed (Fx PLCs are faster) and the timing variation between them could be large enough to cause problem.

If you wish for higher communication speed you could try with Ethernet communication. The master Fx PLC is able to connect to each Nano-10 as slave one at a time. It is likely to be faster than serial port.

[support]

As explained in the previous post the Fx PLC and the Nano-10 are clocked at different CPU speed so the actual baud rate is the closest possible baud rate that could be derived from the CPU clock.

On further test we found the closest actual baud rates of the two PLCs to the "target" baud rate are:

target: 115200 bps  (PC serial port baud rate).
Nano10: 111607 bps
Fx PLC: 117188 bps

As you can see their actual baud rates are on two different sides of the target baud rate. On their own each is within the +/- 3% allowable variation from the target baud rate.  Unfortunately the difference between them are larger than the +/- 3% allowable range for successful communication at these higher baud rates.

These are hardware limitation and could not be resolved in firmware.

Anyway, the reason our PLCs support 115200 and 230400 is because these are the baud rates that are supported on standard PC serial port (a PC uses dedicated crystal to generate the full range of baud rate).  So the main purpose is to allow these PLCs to communicate with PCs at higher baud rate if necessary.  But these two PLCs unfortunately are not compatible with each other at these higher baud rates.



 

[njlaw]

Thank you kindly for the detailed response and testing!  We will proceed with testing communication over Ethernet if we can't achieve our target responsiveness via other optimization.

[garysdickinson]

If you are using serial ports or Ethernet to interconnect PLCs you will find that the latencies from on PLC to another are partly do to data transfer rates.  Your measurement latencies at 3 different BAUD rates gives you a big hint.

Your BAUD rate range is roughly 1:3 but your measured latencies are only about 1:1.4.  Most of your latency is NOT due to communication speed.

Ok.  Where does the rest of the time get eaten up?

• The TRI low level firmware handling of Modbus.  This code is actually pretty fast.  There are a few things that you can change that affects the RS485 driver turnaround delay.
• Ladder logic scan rate. If you are setting an OUTPUT on the slave PLC, that OUTPUT will not change until the end of the ladder logic scan.

To minimize latencies you will need to to ensure that your ladder logic scan rate is FAST. These are settings that you can change to maximize the scan rate:

• SetSystem 3,0  RS485 communications are 1/2 duplex.  The default behavior of the PLC when responding to an communication from a RS485 port is to delay for 10 ms to allow the master device to quit driving the communication bus before the PLC turns on its drivers and responds as a Modbus slave.
   
  This behavior fixes a problem with dumb USB to RS485 dongles and RS232 to RS485 gizmos.  Those devices have no knowledge of the communication protocol. As a result those devices just will keep driving the RS485 bus after the end of the Modbus query and no new characters arrive to be transmitted.  This can be many ms.
  
  You are not using these sorts of dumb devices.  The SetSystem 3,0 statement cuts the turn around delay from 10 ms to as close to 0 as possible add this SetSystem statement to every PLC that is on the RS485 cabling.
• SetSysetm 16,1  for Nano-10s. This statement "tells" the PLC how many digital I/O lines are active.  Your Nano-10s only have 4 sets of I/O lines, but the PLC firmware will still scan 128 inputs at the start of the ladder logic scan and then update 128 outputs at the end of the ladder logic.  Using this SetSystem statement will save measurable time on the Nano-10s.
• SetSystem 16,n. Fx series PLCs.  If you are only using 16 digital I/Os use SetSystem 16,1.  If you are using 32 or less digital I/Os then SetSystem 16,2 is the right answer.

Rerun your latency tests at a single BAUD rate. Add the SetSystem statements one by one and rerun the tests.  You will see reductions in latencies.  And it’s good science...

Gary Dickinson

p.s.  I attached a PDF of a bit of PLC code that you should add to your test PLCs. This code will allow you to directly measure the PLC scan rate with the test equipment that you already have.