Host Engineering Forum
General Category => Do-more CPUs and Do-more Designer Software => Topic started by: sgsims on February 02, 2015, 01:20:40 PM
-
I have read quite a bit about how much faster and easier ethernet comms are with the Do-More platform. Was wondering how that is accomplished.
-
Faster CPU - Backplane Delay = Faster Comms
As for easier, the instructions are higher level and all interlocking is handled internally. Drop multiple boxes and turn them on. The boxes support interval mode and event mode, and if you are sequencing them in Stages, the box itself handles the Stage transitions.
And Do-more itself is just so much easier to use than DL. Hard to describe why...there are so many reasons...but once you make the transition, you won't want to go back.
-
So is the Do-More still restricted to one I-Box instruction per scan or is that different as well?
-
Do-more doesn't use IBoxes, all instructions are native. But to answer the question, all Ethernet comms are multi-scan instructions. The key is that Do-more scan times are far faster than DL.
-
OK...I think I get it. Just sort of comparing my ECOM Card set-up with the DL line with best practices for the Do-More line. So is it still the same strategy to use a single ecom card for each slave device in order to avoid the one instruction at a time per card token passing? In other words if I have two slaves plugged into a stride switch that was connected to one ecom card the read/write instructions for both would round robin one at a time via token passing. So it might take 8 scans or so to get all the way through two read and two write instructions.
Versus placing another ecom card in the rack and connecting each slave directly to it's own ecom card. then it would be something line every 4 scans.
Is there any advantage to using the native Ethernet port on the Do-More CPU vs an ECOM card in the rack? Backplane time???
Lastly I know this is sort of a question without enough information but I have a ladder program (Stage) now in a DL260 that is about 450 lines long that is taking about 12ms to scan...I thought that was pretty good. How much faster might that scan time be with the DO-More CPU?
-
Is there any advantage to using the native Ethernet port on the Do-More CPU vs an ECOM card in the rack? Backplane time???
The CPU has to process the message in either case. Eliminating the third party (ECOM) and backplane time will always be faster. If you have a bunch Modbus going on, multiple ECOMs can be useful since the TCP/IP stack tends to be heavy, and there are also advantages of being able to segregate traffic...but in general...if you want fast, do it on the local DM1E port.
Lastly I know this is sort of a question without enough information but I have a ladder program (Stage) now in a DL260 that is about 450 lines long that is taking about 12ms to scan...I thought that was pretty good. How much faster might that scan time be with the DO-More CPU?
Hard to say exactly, but Do-more will smoke it. If your logic is primarily boolean and integer math, it could be 20x faster. Higher level instructions may be more like 5x-10x faster. I wouldn't be surprised to see the average scan time be ~2ms.
If you have a piece of code you'd like us to test, send it to support@hosteng.com. We'll load it up and let you know the results.
-
Good information...so if I send you the Direct Soft 5 stage program can you convert it to Do-More for the test?
-
Good information...so if I send you the Direct Soft 5 stage program can you convert it to Do-More for the test?
No, sorry. There is a DL to Do-more migration tool in Do-more Designer that can help you do that though. We would be happy to run any Do-more program you have on actual hardware and let you know what the numbers are.
-
QUESTION?
If the ethernet instructions are only for onboard Ethernet Port, then why do you still have a Device Selection Box?
Scene the instructions are device specific then only show the instruction if that device is the one being programed.
-
Future controllers are likely to have more than one port, and we may eventually add support for more functions through the ECOM100.
-
If the ethernet instructions are only for onboard Ethernet Port, then why do you still have a Device Selection Box?
In Do-more, some "Ethernet" devices are SOFTWARE devices, not SPECIFICALLY THE @IntEthernet "Ethernet Port hardware" device. For example, you may have multiple Modbus/TCP "devices", one for each Modbus/TCP slave. All are limited (currently) to that physical Ethernet Port, BUT, the TCP connection can be maintained for each Modbus/TCP device.
Say you are polling 5 slaves with 5 different IP Addresses with ONE "Do-more Modbus/TCP Master" device, the Do-more driver for that device must establish a TCP "connection" to slave 1, perform the Modbus Transaction with slave 1. Then Slave 2's request comes on that same ONE Modbus/TCP Master device. Seeing that Slave 2's IP Address is different than its current TCP connection, it must HANG UP on Slave 1, establish a connection with Slave 2, then perform Modbus Transaction with Slave 2. Then Slave 3's request comes up. Seeing the IP Address is different, that device must shut down its TCP connection with Slave 2, establish one with slave 3. Etc. Etc. Etc.
So you have the overhead of disconnecting/connecting on EVERY Modbus/TCP request when you have MULTIPLE IP ADDRESSES with ONE Modbus/TCP Master device in Do-more. BUT, you are NOT limited to ONE Modbus/TCP Master device. You can configure MULTIPLE Modbus/TCP Master devices, even on the SAME PHYSICAL ETHERNET port.
If you want to minimize TCP overhead, network bandwidth, etc., you could create 5 different "Do-more Modbus/TCP Master" devices, one for each slave, but all configured on that one local physical Ethernet port. So in the Modbus instruction that talks to slave 1, you enter slave 1's device and slave 1's IP Address for those parameters. In slave 2's Modbus instruction, you use Slave 2's device and IP Address. In Slave 3's, use Slave 3's. Etc. This way, each device can establish its own TCP connection ONCE, and maintain it, and never need to disconnect. What this also means is that you could have 5 Modbus requests going on SIMULTANEOUSLY, getting faster throughput on your data. (Note that Do-more has a limited total number of ACTIVE TCP connections, so it may need to "hang up" every once in a while so that other active TCP-type requests can connect, e.g. EMAIL, STREAMOUT on a TCP Client device, et. al.).