Ecom-100 Operation

[sgsims]

Can someone list the steps that occur during a Modbus TCP/IP Read Request using an Ecom100 card in a 205 Base with a 260 CPU?  Trying to understand the relationship between scan time and communication speed of the ECOM100.

I need a MRX command in the ladder to initiate the READ request but I am clueless about what happens next.  Will the scan time expand to however long it takes the ECOM100 to initiate the read request to a Modbus slave and then receive the requested READ information back?  In other words can I use a MRX command to read the values of a slave so that those values are updated every scan?

Sorry if this sounds a bit clueless.

[Greg]

First of all, in a DL205 PLC you cannot use MRX/MWX instructions with the ECOM100. Those instructions are for Modbus RTU only, not Modbus TCP. Instead you need to use the IBoxes called ECOM100 (IB-710), ECRX (IB-740) and ECWX (IB-741). To utilize these instructions to do Modbus TCP instead of just UDP/IP, you must have a Modbus TCP entry in the ECOM100's peer-to-peer table (using NetEdit, or an Internet browser).

As far as the relationship between the scan time and the communication speed of the ECOM100: Every PLC scan there is a communication time slice (see the DL205 manual). During this time slice a maximum of 128 bytes (64 words) can go between the ECOM100 and the PLC. Thus, if you have an ECRX/ECWX that is larger than 128 bytes, it could take multiple scans just to get the data across rather than extending the scan time waiting on data. In most cases the bottleneck will indeed be the backplane communications (running at 128 bytes per scan [milliseconds]) since the Ethernet side is usually running at 100 Mbps (i.e. microseconds; hundreds of times faster than the scan).

[sgsims]

Greg,

Very well written!  Roger your information in the first paragraph. 

At the risk of wearing out my welcome I'll ask a few more questions relating to the information in your second paragraph.

The time splice you refer to...is that the CPU Bus Communication Step shown in the flowchart on page 3-19 in the 205 Manual?

Is everything related to the ECRX I-Box occurring during that "Time Slice"?  So I guess that time slice expands or contracts to fit the maximum amount of information (128 bytes) that makes up the particular I-Box instruction.  If it is less than 128 bytes the time slice is smaller if it is more than 128 bytes the time slice will end after 128 bytes have been processed and the remaining bytes above 128 will be processed during the next scan's time slice.

Am I sort of on the right track?

Many thanks

[Greg]

You ask, "The time splice you refer to...is that the CPU Bus Communication Step shown in the flowchart on page 3-19 in the 205 Manual?"

Well, in the latest manual I don't see that on pg. 3-19. But rather it is approximately the same place. It is called "CPU Bus Communication" and is shown in the flow diagrams and explained in the text near there.

You ask, "Am I sort of on the right track?"

Yes.

[franji1]

This is an ASYNCONOUS operation.  It may take 1 scan, it may take 5 scans.  It may take 10 scans.  The RX/WX type instructions are NOT "blocking" instructions, i.e. the CPU does not "sit" there waiting for the communcation to complete.  It sends the request across the backplane (IF THE BACKPLANE IS NOT BUSY).  But the remote side may be slow, or the connection may be down, so the ECOM100 may have to timeout and retry, so you may not even see an "error" condition for a bunch of scans.

[sgsims]

Ok so one more question.  Can a ECRX instruction be completed in one scan if it is less than 128 bytes?  I guess what I am really confused about is during a read instruction.  Does the read request happen during the first time slice then the information coming back to the cpu take place during the time slice on the second scan.  Or,  can the entire transaction occur during one CPU time slice given that the amount of information is less than 128 bytes and all the other variables cooperate?

[Greg]

Yes, both the request generated by the ECRX to the ECOM100 in the base, and the data transfer could happen in the same time slice. The reason is the ECOM100 communications over the wire can happen in microseconds. Like franji1 said, it is asynchronous. Well, actually franji1 misspelled it, so he actually said it was "asynconous". The spell-checker doesn't work on all caps. (Grammar police strikes again.) 

Anyways, because it is asynchronous, there is no guarantee that even an ECRX with < 128 bytes would happen in one scan. My network instructor used to say that because of the nature of Ethernet, the telegram might never reach the communication partner, but it is still working.  What this means for you, like franji1 explained is the communication over the wire might timeout (for whatever reason), and then the ECOM100 has to issue retry telegrams, which may all timeout. In which case he would error on that request. Then in your PLC code, you could issue retries based on errors if you wanted, etc. etc. etc.

But, yes, both request and data could happen in one scan.

[franji1]

I'm guessing a READ will take a MINIMUM of 2 scans.  One scan to send the request down the backplane from the CPU to the ECOM100, and the next scan to get the READ DATA from the ECOM100 to the CPU.

[Greg]

You're probably right, franji1. I've never tested the backplane stuff to actually tell. If we got Tim, BobP & Don together for a discussion, they might could tell us.

[sgsims]

That would be interesting information!

[rlp122]

Franji1 is correct.  A read would take an absolute minimum of two scans since one backplane transaction would be needed to get the data to the card.  A second backplane transaction would be needed to get the data from the card.  Of course time on wire and slave replay speed would factor in along with scan time to determine if it would take more than two scans, but there isn't any way for it to happen in a single scan.