jtheis74

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

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.

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

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

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

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

ICONICS, RSView, iFIX, and Wonderware. Also listed in order of preference.

Right now, ICONICS is hands down my package of choice. I think the biggest reason I like them over the others is that their tech support is great. Email, forums, etc. are easy to find and use. It's also very easy to 'pack' a project and to move it from one computer to another.

Is it possible to create a calculation in RSLogix500 that can be hidden from anyone looking at the logic? What we're trying to do is hide a calculation that has three inputs and it generates one output. I think this can be done in RSLogix5000 but I didn't know if it was possible in RSLogix 500. I know that there is security for the entire program, but all we're looking to do is hide one calculation. Joe

I have had a lot of success using RSEmulate 500 with RSView Studio to test our ME HMI. While the emulator doesn't do everything (PIDs don't run, for example) it does work well when testing your HMI to make sure all of the tags point to the right place, all of the messages turn on and off as they should, etc. It seemed a little clunky to set up the first time, but now that I've used it a lot it isn't nearly as bad. I guess that goes for just about any software!

I am working on a new application (RSView Enterprise - SE Distributed - v.4.0) that is basically just a combination of parts of two existing apps. I will be using all of App A and only a few screens from App B. My issue is that I need to figure out what all of the tags are that are used in the displays I'm using from App B. These tags do not exist in App A. I could just merge the two entire tag databases together to be sure that I get all of the tags, but then I would have a ton of tags in the new app database that aren't being used. Is there a way to 'export' the tag names that are being used in a specific display so that I can then pick them out of the tag database? I have been doing a Select All on the displays from App B and then doing a Tag Replace so I can at least scroll through all of the tags in use. Is there a smarter/better/easier way to get a list of the tags in use on a display by display basis? Thanks! Joe