Has anyone had any experience working with a GE 90-30 series and a Delta RMC100 controller? We are having some trouble with the RMC dropping communications with the PLC and we can't figure out what is going on. If anyone has any experience with this hardware, I'd like to know what you think about it.

Joe

This should be a slam dunk. The RMC100 has had Ethernet capability for 8 years now. I am assuming you are using Modbus/TCP.
1. Is this a new installation?
2. If not did the communications ever work?
3. When the RMC100 appears hung can you access the RMC through a HMI or RMCWin. If so it is the PLC that is hung or perhaps you have exceeded the number of connections.
4. Does the PLC leave connecitons open without closing them?
5. Did you know that the RMC100 has excellent Ethernet diagnostics? Go to Window submenu. There are three things to look at
a. Activity Log This tells us how the connections are allocated.
b. statistics This is cool and interesting but usually not that helpfull
c. internal state. This will give a more detailed version of the Activity log
6 Call 360-254-8688. The tech support is very good.
7. there is a forum.deltamotion.com for tech support question but I think you should call.

The RMC supports four connections.
1. GE930
2. RMCWin
3. HMI
4. Other.
How many devices are trying to access the RMC100? As soon as the fifth device connects it will bump off one of the others that would active last. This keeps the RMC100 from hanging or refusing connections but you can see there is a down side. Since HMIs and RMCWin access the RMC100 much more often than the PLC can it is often the PLC that is given the boot. This usually doesn't happen if the PLC does a continuous read of the RMC's status and/or the number of connections is restricted to four.


When you call make sure you can provide the internal state and activity log info when the RMC appears to be hung.

Peter,

Thank you for the reply. Here's what I know:

1. Yes, this is a new installation. We are using Modbus/TCP.
2. The communications work most of the time. It drops out intermittently. There are two axes being controlled by the RMC and the drop out of communications only ever occurs when axis 0 is supposed to move. Axis 1 never has a problem.
3. Yes, they can access the RMC via RMCWin, so it looks like the problem is with the PLC.
4. I don't know about the connections being left open. I'll look in to the logic.
5. Our field engineer has sent in the Diagnostics information to Delta and they said that there wasn't anything in it that indicated a problem with the RMC.
6. We have contacted their tech support and they have been very helpful to this point.
7. I will check out the deltamotion forum to see if they have any other ideas.

We have the following connected to the RMC:
1. PLC
2. RMCWin (only when necessary)
3. LCD420 HMI

That's it. So I don't think we are exceeding the number of connections unless there is a way to have the PLC make multiple connections to the RMC. I'm assuming that's why you asked about item 4.

Thanks again for all the help!


Joe

There is a second CPU that runs the Ethernet. It knows very little if anything about what is going on with the commands as it is just shuffling data between the Ethernet chip and the dual port between the CPU. So, is it possible the Ethernet is still running and the command is just being ignored due to some error condition? You can look at the command log and see all the commands and command values that are sent to the RMC. It is possible the RMC would receive and ignore the command. You call tell if this happens by looking at the command log in the window sub menu.

It would be interesting to know if the PLC could jog either axis when you think the Ethernet communications are 'hung'. This would let us know if it is a axis problem, caused by ignoring commands, or the Ethernet really isn't working for either axis.


This is most likely but the first rule of trouble shooting is assume nothing. I would still try what I suggested above.


This information can seen from the RMC's point of view in the Ethernet activity log. This logs the opening and closing of the connections and provides the IP address of the device that the RMC is connected to. Did you look?


In that case you may need to use a program called Wireshark, the old Etheral.
What do the Ethernet logs on the PLC say?
When the communications stop, save the logs and e-mail them to Delta. We have people that a very experienced with Ethernet communications.


There isn't much there yet.


It doesn't look like it is even possible to exceed the connection count. The Wireshark logs would be most helpful. This way we can see if the PLC is even sending the commands. Send them to our tech support. They will forward them to our Ethernet Guru.

Peter,

Thank you for the reply. Here's what I know:

1. The commands from the PLC are not being logged at the RMC once the comms drop out. I will check with our field service engineer and have him try to jog the axis just to be sure.

2. Our field engineer checked the Ethernet log and it does show the connections opening and closing.

3. We will be getting an Ethernet switch at the site and downloading Wireshark to test. Right now, we are using a crossover cable so we can't be online with both devices talking to each other. Once we get the switch we'll send in the logs.

4. This last bit of information came from the RMCWin manual. It is for an Omron PLC but I think the same rules would apply to a GE PLC:
---
In this example, the RECV(098) instruction will be triggered each time the Communication Port 0 Enabled Flag (A202.00) is set. This flag will be set any time port 0 is not busy. Therefore, the PLC will read these registers from the RMC continuously as fast as it can. Depending on the load of the PLC, this will read the RMC's status as often as every 18 ms.

The SEND(090) instruction uses port 1. It is important that this is a different port number from the RECV(098) instruction. It is possible to use the same port number for two network instructions, but this reduces performance and requires additional synchronization ladder logic. Examples of doing so are given in the Omron documentation.

---
I'm confused by this comment because I don't understand how to use port 0 versus port 1. I'm assuming that they are not talking about separate physical ports on the RMC, but rather something that can be configured in the PLC and/or the RMC. I think this is probably where our problem lies because we have all of the communication happening on one port. Any ideas/suggestions on what/how to go about splitting it up?

Thanks!

Joe

This means the motion control isn't seeing the commands or there are error that prevent the RMC from receiving it.


For each transfer? That would be inefficient! On some PLCs the connections are open until the power is turned off or the PLC or RMC is reset. This can be months.
Also are the ports closed when there is a hang up?


good.


The MSTR command on a modicon PLC does not require the use of 'ports'. If I remember right the Omron is a little non standard in tha one must manage the connections and the Omron can have only 8 transfers in progress at one time. That shouldn't apply here. I think Omron's use of the word ports is not good.


Modbus/TCP doesn't require this unless this is also something that GE must have. TheI can see why you are confused..

It looks like it will come down to the WireShark logs.

Peter,

Thanks for the reply. It sounds like our field engineer has corrected the problem. I don't have all of the details yet but it sounds like it was related to the 'ports' being used for communications. Everything was going out on the same port, but when they were split so that reads were on one port and writes on the other, it maintained communication. Once I get the logic I'll get a better handle on what was done and will post the details of the answer here.

Thanks again for all the help!


Joe

Just to bump this thread...Our field engineer is back in the office and I should have a better description of what he did to correct this problem in the next day or so. I'll post the fix here when I have it.

I am still monitoring and watching.

I finally got a chance to sit down with our startup engineer and I think I've got a handle on what he had to do in order to get the communications to work.

We do a block move in the GE PLC to open a Modbus/TCP client connection (command 3000 in the GE PLC) when the PLC first powers up. Word 8 in the command block is the channel number. We originally had this channel set to 1 and it was the ONLY client connection command being executed. With everything (reads and writes) trying to happen on the same channel, we had all kinds of communication issues. So we replace the one client connection with THREE client connections - channel 1 to write to Axis 0, channel 2 to write to Axis 1, and channel 3 to read back from the RMC. There were some other changes to the logic that had to be made to clean it up, but the concept of the multiple channel/client connections was the big "eureka!" moment. Hopefully this is clear as to what we did.

Thanks again for all the help!


Joe

I think a channel is just a GE way of keeping track of transfers in progress. In this case you should wait for the channel to be done before sendind another message. Normally you only need 1 channel to write commands to all axes at once. The normal practice is to set up a block that has the command area for all axes so that all axes can be commanded to move at the same time with one transfer. This is much more efficient that writing to each axis individually. The only catch is that you must zero out the command field for those axes you don't want to move AND you can't issue another command until that transfer is done. Writing to each axis individually is simpler but much less efficient because there is a lot of overhead for each packet so the packet might as well be a large one. Since you are treating the write to each axis separately it is good you have a channel for each one, but know this.. we have projects out there where there are 4 or 5 RMC connected to one PLC. If each axis has its own channel then two RMCs would use up all the channels. You are OK for now with just 1 RMC.

Hopefully you are reading the status for all the axes in one transfer with its own channel too. The number of active transfers that can be in progress is PLC limitation.