Just wanted to post a finding.

We have been using a 90-30 setup communicating to an RMC100 for a few years now, communicating over Modbus TCP/IP. With some new devices on the bus we decided to re-evaluate our communication procedures and have simplified and improved our communication times.

One of the items that we focused on was the addition of a third channel to communicate with the RMC100. We used channels 1, 2, and 3 for the RMC100 and 4 and 5 for some Turck remote I/O. What we noticed when adding this third channel was the random closing of one or both of the first 2 channels. The solution which has yet to be understood by us is using all odd numbered channels. The only value that has been changed is the 8th word in the block move. Now we are using 1 3 5 7 9.

2 of the channels to the motion controller are constantly working and never close (1 reading, 1 writing) the third channel is always open waiting to send the next command across.

1 of the channels to the turck remote I/O is again always reading and the other is always open waiting for change of state to set an output.

Has anyone else come across this?

Andrew

Interesting but what is a channel? Etherent has IP addresses ports and connections. The GE implementation sounds very non standard. Do you know that the RMC100 has a built in Ethernet analyzer? Go to Windows menu. There are three Ethernet selections. One logs the connections ( not channels ).


This statment is not clear.
Read the modbus specification
http://www.modbus.org/docs/Modbus_over_serial_line_V1_02.pdf
Do a seach for channel. You will not find channels because it isn't part of the Modbus TCP specification.
The RMC knows nothing of channels. This point is that channels are a GE creation and implementation. You really need to pin GE down because the rest of the world does not know how GE implemented their version of Modbus TCP.

Look at the RMC Ethernet logs. That will be the easiest thing to do that may provide a clue as to what is happening.

The "Channels" referred to in the GE Fanuc documentation have nothing to do with Modbus but rather they are Ethernet channels. HTH
But this is still odd behavior.

So what is a Ethernet channel? An IP address and port? The point is that what goes across the wire is an IP address and port number. For instance, in unix there are sockets. A socket has an associated IP address and port. Is a channel like a socket or connection? The point is that the problem with channels appear to be a GE implementation problem and it is best to ask GE what is happening. However, I still think that the RMC ethernet diagnostic would provide useful evidence as to what the problem is even though it keeps track track of connections is more universal terms such as IP addresses and ports.

Peter this would have been a good place for you to tell who you are.... SMOKE, Stuart, or start with who you are.

How can you think I am Smoke, Stuart or any body else?
I am Peter Nachtwey president of Delta Computer Systems. We make the RMC100. I wrote most of the firmware for the motion control part.
The avatar is a RMC100

Guys,

Actually I had also not given all the information. By leaving 2 of the ports open to the RMC100 from the CMM321 we are seeing the ports close once in a while even though the ports are separated now by a factor of 1. The other interesting thing to note is that the fastest communication between device we have been able to achieve is 120ms. This is measured as an average by counting the successful writes or reads/time. Fairly simple math but we always come out with this average.

It seems that of the "16 channels" that are able to be opened by GE, any device is only able to accept 2 open ports at any one time. GE is the lowest common denominator between the devices so I have poured over the documentation and the only way I guess to get around this is to close the port after every COMM_REQ. This is not very desirable due to the slow communication times.

Am I asking too much from Modbus TCP/IP? (I mean with response times)
Is there a way to open 3 ports to any device?

I do know who everyone represents, that's why I come here. It's a quick way to have technical people answer my questions. Thanks for all the help.

No!!! you should be able to do much better.
http://www.deltamotion.com/dloads/download...tegory=Examples
Download the first example. I think it is called TCPDemo.exe. TCPDemo.exe demonstrates how one can talk to a RMC using one of many protocols but the best part is that there is a timer that can time the min, max and avg communication time. Use it to access the RMC from your PC or laptop. You should see times of about 5-6milliseconds. Note, if you move a window around it will slow down the Ethernet comms. Stupid windows.

Now use the TCP demo to access registers in the GE and other devices you have. This will point the finger at the guilty party. The limitiation is that the TCP demo will only access 40000 registers. It will be interesting to see what you find out? Also note the how the speed degrades are more Ethernet devices are added.

Personally, I think it is limitations in the GE Ethernet. You should be able to get much better through put than 120 milliseconds. I would trying adding one Ethernet device at at time. At some point you are probably using all the GE's buffers ( channels? ) so then in must open and close connections because the buffers must be shared. This will be slow. How many Ethernet devices are you talking to again? You may need to implement some sort of mutual exclusion to keep devices from 'stepping on each other'. For instance, the slow device might have to share a channel. You will need to make sure that only one device has access to that channel at a time. Each low priority device assigned to that channel will need to be polled or accessed in a round robin fashion and care must be taken to close the previous connection before openning the next connection for the next low priortiy device. Higher priority devices like the RMC should have its own channel an not share.

After all this time doesn't GE have anything to say?

What you are finding out is that not all Ethernet modules are created equal. Buffer memory and CPU speed play a big part in not missing packets and the ability to keep connections open.

I do not know but this may help others to understand.
http://www.ieee802.org/3/an/public/channel_models/
The problem described above does appear to be in the CMM321 module or the CPU's communication to this module. I recommend making sure that you have the latest firmware in both the CMM and CPU, a weak link in the 90-30 system is the slow communications across the backplane between "intelligent" modules. You may also want to think about a second CMM321 or upgrading to a CPU372 instead of the module.
If you "need speed" in a GE Fanuc PLC use the RX3i or RX7i.

That looks like some sort of wireless data. It isn't relevent.


This is relevent in that it explains the slow speed. Ethernet communications may be limited by both the bandwidth and the PLC scan since much of the comms are handled in the overhead part of the scan.


It does seem like that this particular GE does not have the ability to communicate as quickly as microcontroller wishs.



I would like to know what microcontroller found out using the TCP Demo program.

Okay so here is what I have, I knocked off the Highs and lows and averaged the rest.

My config:
Start Address: 1
# of Registers: 100
Modbus TCP/IP
Read Continuous

GE Fanuc CMM321
Avg. (ms) 22.37
Max. (ms) 67.95
Min. (ms) 14.43


Delta RMC100
Avg. (ms) 8.83
Max. (ms) 18.86
Min. (ms) 5.39

This was all averaged at approx. 10,000 cycles. I could leave this for an evening to test as well but I figured that it probably wouldn't change too much.

Russ, My CPU is the 374 which did not support Modbus TCP/IP at the time of conception and we are currently on a design freeze. (corporations, Yuck). I believe that it does now?

I did try to read through the CPU port but it was blocked.

We are reading consistantly from the RMC from addresses 1-98 (end of Axis 2 in the command window) and so this is very close to our reality. We have a bunch of customers in over the next couple of days and I will have to test on Friday adding more traffic on the network.

The numbers are a little faster than what you previously posted. I would expect that when only talking to one device. Now you have an idea of what the through put can be. Now I think you need to work on making sure that a channel doesn't get used until the previous communication is done. I would have a round robin system for each of the channels with the highest priorty channels being dedicated to the RMC. The lowest priority channels share between multiple devices. When all the channels are running I would expect the communications to slow down to what you previously stated. I don't think you are going to do much better with the PLC you have.

You will need to be able to upgrade to Firmware Version 12.?? which GE Fanuc calls the "IC693CPU374 Plus"
If you have this it is a free for the DL upgrade at http://support.gefanuc.com/support/index?p...amp;actp=search
Yes, you will need to register a GE 'SSO' to get it.