Recent Posts

Pages: [1] 2 3 ... 10
Opinions & Feedback / Add automatic phone Call, Sms and more to SuperPlc
« Last post by brophy on July 01, 2020, 11:48:28 PM »
These products look amazing. They support the standard modbus TCP and could be used in an alarm system with an android phone. The following apps (  is reading and writing digital and analog IO  of modbus TCP.  It’s possible to associate a trigger level to each individuals IO. When the trigger level is activated the phone has the ability to call, sms, email,wake up,play a sound, grab a picture from any IP camera, activate an output from any board on the network,…, entirely automatically.  More details at

Technical support / Re: RS485 sometimes not working well
« Last post by support on June 08, 2020, 02:18:40 PM »
What are the other controllers? Are they third party controller?

Do you know if the actual baud rate of those controllers?  Most controllers that advertise 115200 don't actually communicate at that precise baud rate but a close approximation (up to +/-3% of the target baud rate). So is the Fx PLC.  The closest baud rate that Fx PLC support is  117200 which allows it to communicate well with a PC at precisely 115200 bps. But if the other controllers actual baud rate is lower than 115200 then it is likely that the actual baud rate difference is larger than +/-3 %, which can lead to more errors.

Try to communicate at a lower baud rate if the highest baud rate don't work well.
Technical support / RS485 sometimes not working well
« Last post by Netanel on June 07, 2020, 09:52:53 AM »
I working with fmd1616 i try communicate with other controller Rs485 com3 , 8,n,1 baud=115200

Sometime the slave controller not respond for readmodbus command and sometimes yes.

When i working with computer and usb to 485 - the slave controller respond for all commands.

What can be the problem?
Technical support / Re: RS485 Baud Rate Between Nano-10 and Fx1616-BA
« Last post by garysdickinson on June 06, 2020, 12:07:09 PM »
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.
Technical support / Re: RS485 Baud Rate Between Nano-10 and Fx1616-BA
« Last post by njlaw on June 04, 2020, 03:10:23 PM »
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.
Technical support / Re: RS485 Baud Rate Between Nano-10 and Fx1616-BA
« Last post by support on June 04, 2020, 02:59:34 PM »
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.

Technical support / Re: RS485 Baud Rate Between Nano-10 and Fx1616-BA
« Last post by support on June 04, 2020, 01:57:41 PM »
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.
Technical support / RS485 Baud Rate Between Nano-10 and Fx1616-BA
« Last post by njlaw on June 03, 2020, 03:00:56 PM »
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}


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

Nano-10 Test Code

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


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!
Technical support / Re: FMD88-10 and UL 61131-2 and UL 60730-2-9
« Last post by support on April 15, 2020, 12:32:12 PM »
The FMD88-10 is designed and built to comply to applicable sections in the IEC61131-2 standard. As per the IEC61131-2 standard, our PLCs are designed to safely operate within the specified operating temperature, voltage and current ranges and they are built to withstand momentarily over voltage, over current, reverse polarity and environmental contamination up to pollution degree 2 with no safety issues. Various tests are conducted during design and manufacturing to ensure the PLCs operate properly within their stated specifications. However, at the moment the FMD88-10 PLC is not yet externally certified as a UL-listed component. But that  would not prevent its use in most of the UL listed OEM equipment. We have many OEM users who have incorporated the FMD/Fx series PLC in their UL-listed or even FAA certified equipment. The actual technical requirement of the PLC would be dependent on the particular UL standard applicable to the industry in which the OEM equipment is built to operate. You can inquire with your UL rep for any specific technical requirement that the PLC must meet in order to satisfy the applicable UL standard and we would be able to advise you if the FMD88-10 is suitable for the application.
Technical support / FMD88-10 and UL 61131-2 and UL 60730-2-9
« Last post by nealbert on April 13, 2020, 12:27:36 PM »
Can someone please tell me if the FMD88-10 conforms to UL Standard UL 61131-2  OR  UL 60730-2-9 ?   I've designed the FMD88-10 into a vending machine where the PLC controls a cooking device.  The UL representative is telling us that the FMD88-10 MUST comply with one of the above Standards per UL Standard UL-197 (Standard for Commercial Cooking Appliances), or we can't use it.

Neal Cooper
Pages: [1] 2 3 ... 10