ECOM Speed up

[ADRIAN21]

Hello,
I'm working for JTEKT company in France (21 department).
We are using a D4-454 CPU with an H4ECOM100 and a scan time at 40ms for a machine.
I have a problem with MODBUS multiple read/write RX/WX (about 16) with some slaves like FANUC robot,TURCK RFID or IOLINK .
There is a latency time > 0.5second of response from each slave.
We were obliged to change ECOM ibox by SET/RESET RX/WX so the MODBUS communication time is better .But WHY?
The H4ECOM100 firmware is OK.

Here are my questions :
1) What is the best solution to improve the MODBUS communication time with ECOM ibox between the CPU and the slaves ?
2) Is there an execution priority between ECOM IBOX RX/WX ?
3) Is it possible to know what is the execution time for each ECOM ?

Thanks by advance for your response .

Philippe ADRIAN
JTEKT
philippe.adrian@jtekt.eu

[franji1]

The logic you are showing is fine as-is.  The bottleneck is the PLC scan time - backplane comm is synchronous to the PLC scan.  4 ms PLC scan vs. 40ms PLC scan is 10 times faster just because more backplane comms can occur.

If you have 16 ECRX and 16 ECWX (one for each 16 slaves), let's assume slave response time is minimal (i.e. the slave responds quickly relative to the 40ms PLC scan time).  Each ECRX/ECWX is SYCHCONIZED to the PLC scan (it can only do 1 at a time - the EC* IBoxes have built-in token passing).  So that's AT LEAST 32 PLC scans.

So 40ms PLC scan time x 32 ECRX/ECWX = 1280ms.  If half of those are READs, that's 40 x 16 x 2 scans for the ECRX and 40 x 16 for the ECWX - that's 1920ms.

What some customers to help speed up the comm is divide and conquer - the put in multiple ECOM100 modules so that EACH of them can do COMM simultaneously across the backplane and out the Ethernet port.   Just 1 more will cut the overall turn around time in half.  That would be a second ECOM100 IP Config IBox right below the first one - identify THAT as K20 (or K11 or whatever, something other than K10), and use K20 in half your ECRX/ECWX IBoxes.

You can try to reduce the PLC scan time (Stage programming, reduce BCD and floating point math which are slow compared to binary math, only scanning logic that needs to run (subroutines).  This can be difficult and also causes bugs.  But I doubt you can cut it to 20ms to cut your overall turnaround time by half, something that a second ECOM100 module can do.  Note that ECOM100's must be in the primary base - they can't be in any expansion bases.

[franji1]

Here's another idea.

Instead of another H4-ECOM100, purchase a Do-more BX-DM1E-M PLC and have it do all the comms to the 16 slaves.  That's all it does - it collects the data.

Stick the results in DLV memory in the BRX (it emulates DirectLOGIC PLC octal V memory)  and then have the existing H4-ECOM100 do normal DirectLogic requests (yes, octal reads like V1777) with just ONE NETRX and ONE NETWX to the BRX.  Do-more PLCs have MRX/MWX instructions for Modbus/TCP.  I bet this might speed it up A TON!!

*** EDIT *** You may need to synchronize the reads and writes, so it may be better for the BRX to read/write from/to the slaves and write/read to the 405 PLC also, but the 405 comm can be one with TWO comm (one big DLRX and one big DLWX).

These could be done in Stages in the BRX PLC

SG S1 // Read 16 slaves data
// 16 MRX boxes in one rung
// last one uses Stage On Success, JMP S2

SG S2 // Write all that slave data to 454 in one contiguous block using native DirectLOGIC comm - needs to be one contiguous V memory block in the 454 to reduce comm to just ONE request
DLWX On Success JMP to S3

SG S3 // Read 454 data to be written to the 16 slaves - needs to be one contiguous V memory block in the 454 to reduce comm to just ONE request
DLRX OnSuccess JMP to S4

SG S4 // write that data to the 16 slaves
// 16 MWX boxes in one rung
// last MWX uses Stage On Success to JMP S1

Stage programming at its best!