Sign in to follow this  
Followers 0
jtheis74

GE 90-30 and Delta RMC100

11 posts in this topic

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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
I am still monitoring and watching.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0