Internet PLC Forum

The best way to troubleshoot communication problems between two devices is to be able to see the communication going on.

So you should use a USB-RS485 adapter (e.g. U-485) connected to a PC. Connect the RS485 port of the U-485 to the RS485 bus connecting the FMD PLC and the device. Now run a terminal emulation software that can display binary data and trigger the custom function to send Modbus command from the FMD PLC. You should observe the correct Modbus command packet sent from the PLC to the device.

If the PLC has correctly sent the Modbus packet and the slave is of the same communication parameters and correct ID you should see a response packet returned by the slave device.

If there is something wrong with the communication then you may be able to figure out what went wrong.

In your sample program "Initialization" you run SETBAUD to COMM1 but COMM2 was commented out. That means COMM2 (RS485) port will still be operating at default 38400,8,1,n

But your "MBRTU" function contains READMB2 12,....    which means you are trying to use COMM2  (RS485) to talk to your device.

I am not sure why there was the  line SETSYSTEM 12,1  in your initialization code. Are you trying to use Modbus TCP to talk to a device that is connected to COMM1 of the PLC using Modbus RTU? That is one purpose of SETSYSTEM 12,1, which is to act as an Modbus TCP to Modbus RTU gateway

Perhaps you want to just define one COMM port at a time for your test to avoid confusion.

Also was there any data received into DM[4], DM[5].....DM[9]?

You can remove the FOR NEXT Loop in the Checkstatus1 function because READMB2 function will run to completion and STATUS(2) will immediately indicate whether the communication was successful so there is no need to put a FOR NEXT loop to test for STATUS(2).

You can remove the checkcom function as it does not serve any purpose and only will slow down the program.

Thanks for helping to document the timer behavior. You are mostly right simply based on your observation! The followings describe exactly what happens during the timer updates:

1. Following reset, the input state for all TIMERs is set to zero to indicate that the TIMERs are inactive.
   The contact associated with each TIMER is set to 0 to indicate that the TIMER has not timed out.
   The timer present value are all set to -1, indicating that the timer is inactive.

2. On the each scan of the ladder logic the evaluates the control input state for each structure during the
   ladder logic scan.  This state is maintained in the data structure associated with the TIMER.

3. If the ladder logic scan determines that the TIMER control input is 0 or false, the contact associated with the
   TIMER is set to 0 or de-asserted and the timer PV is set to -1.

4. If the ladder logic scan detects that the TIMER control input has transitioned to l, then the TIMER is active.
   The TIMER PV is reloaded from SV and the TIMER's contact is set to 0 or FALSE. These changes happen when the
   rung of ladder logic that controls the TIMER is executed.  These changes are visible to all other rungs of ladder
   logic that follows the rung that controls the TIMER.

5. Every 0.01s the timer countdown task is run. If a timer's PV is >= 0 it will be processed either every time the
   timer countdown task is run (for high speed timers with 0.01s time-base) or every 10th time the timer countdown
   task is run (for regular timers with 0.1s time-base). Timer countdown task runs on interrupt and
   is independent of the PLC program scan time so that the timer can count down accurately even if the program
   scan time is > 0.01s.

   At the start of each ladder logic scan, each TIMER that is active at the end of the previous scan may have its PV
   decremented based on either a 0.1 second or 0.01 clock., the I/O scan cycle check and if the TIMER's PV is now 0,
   then the contact associated with this TIMER will be set asserted (set TRUE).  Please note that contact
   transitions for 0..1 at the start of the ladder logic scan and NOT at the rung of code that controls the TIMER. THAT"S RIGHT!!

The most important points to take away from this long winded guess on TIMER behavior is that a TIMER's contact is set TRUE (1) at the beginning of the scan and the contact is set FALSE (0) at the ladder logic rung that controls the TIMER is evaluated.   THAT's RIGHT!!

Try using a PC based Modbus software to test the communication with your device and see if the address and data wrtten is acceptable. That gives you better visibility of what's going on between the Modbus client and the Modbus server. Once you can confirm that the address or data is valid you can then use the same function, address and data to send from the PLC to the device.

One such tool is the Modbus Poll software that you can download from:

http://www.modbustools.com/

They have a free evaluation version that will run for a few minutes and then stop. You can restart it again.

Also try using Modbus function 16 (0x10) to execute the WRITEMODBUS command instead of function 06 in case the device does not support function 06 at this particular address.

Is the FMD88-10 the master to read 32-bit data from a slave device?

All Modbus registers are accessed in 16-bit only. To access 32-bit data you normally would need to read two adjacent Modbus registers into two DM16[] and access them as a DM32[] variable.

The PLC handles number in Big Endian. If the slave (server) arrange the data in Little Endian you will need to use TBASIC to swap the two adjacent DMs so that the are arranged in  Big Endian.

Are there any other interrupt intensive activities going on at the same time. E.g. High speed counter or pulse measurement?

What is your PLC firmware version? If it is >= r83 you could try upgrade the firmware to the latest where interrupt service routine has been improved to avoid overrun of the interrupt service queue where there are lots of interrupt happening at high speed, as reported by Gary. The improved interrupt service has worked well for Gary and eliminated the issue he mentioned, although his issue is quite different from your report.

Are you using the touch screen to trigger an input?

Note that the PLC physical input is refreshed every end of the ladder logic scan. That means that if the HMI triggers a physical input when the ladder logic program has already passed the rung that uses the input (to latch a relay or count down a timer), the input bits will be refreshed at the end of the ladder logic scan and the changes from the HMI is lost. This can cause the input trigger from the HMI to be unseen by the ladder program.

The correct way is always for the HMI to turn on an internal relay bit and the internal relay bit is then used by the ladder logic program for decision making. The program can then clear the internal relay bit after the command has be executed. This ensure that the input will not be cleared by the I/O refresh cycle.

Topics is related to TRI PLC

http://www.triplc.com/yabbse/index.php?board=1;action=display;threadid=2300