Modbus TCP versus QJ71 Ethernet for OPC data collection

[cadomanis 0]

I have been working for awhile to develop the most highly optimised communication connection between a Q series PLC and a custom VB application we use for our entertainment motion control system. Currently we are locked into using OPC as the communication method between the VB app and the PLC. That being said, we have done a lotof work and testing to try to make this as fast as possible. Up to this point I have been using the QJ71 ethernet modules and adedicated set of drivers from Kepwware. I am currently considering switching over to the Modbus TCP module to try and improve this communication path. My theory here is that since the Modbus module on the backplane has a automatic refresh function built in, that it has less processing to do when my data request from the OPC comes into the module. In comparison, I know that the Ehternet module has to start making requests for processing time during the END updating, and so this can get very bogged down at times when the processor is busy trying to do other things. I have actually gone so far as to add a processor to my system purely to service the ethernet module, and in turn due process to processor comminucation using automatice refresh to get all of the data fro mthe second preccessor doing all the work. Does anyone have any experiences similar? Does anyone have experience with the Modbus module in an OPC environemnt? The one thing I find sorely lacking in all the documentation is how to do any real analysis of perfrormance. Additionally, this is really very littel explanation of how the various comm modules make use of the backplane and processor resource, so it is hard to really predict what might be better or worse. I am getting ready to deploy several new systems and am hoping to make any imporvements I can. Thanks, Chuck

[Peter Nachtwey 15]

Avoid using OPC. The transfers should be very simple where you just specify a block of data with an address and length and whether you want to read or write if. OPC often uses tag names that can slow down the transfers because the names must be looked up to find the address. This shouldn't take too long but it doesn't help. We never use OPC in a performance application. I know Mitsubishi has two Ethernet modules. One use Modbus/TCP and the other a Mitsubishi protocol. I am surprised they are so different. I believe we have the Ethernet Module that uses the Mitsubishi protocol. I didn't know the Modbus/TCP module pre loads the data. If this is true then it is a big advantage but I wonder how the Modbus/TCP module knows what data the VB program will ask for? This is possible if the same data is read over and over again. The Modbus/TCP module can just repeat gather the data from the last request. Smart. How fast do your transfers need to be? How fast are they? You can use programs like Wireshark to monitor the Ethernet traffic. Wireshark a good thing to have and know how to use if you do much Ethernet work. From your description you should get learn to use Wireshark.

[funfrok 0]

You can use Mitsubishi Mx-Component with Visual Basic. Communication speed is very good, and it will be more than adequate i think. If you need very fast communication, you can use a Q-PC which communicates directly with Q-CPU using Q-Bus.