Desperately trying to get Ethernet/IP connection to work between Roboguide cell and Studio 5000

I've been just banging my head against a wall for the last few days trying to fix this, any random advice would be amazing.

So I've got a weird setup where I have a PC in our office with Fanuc's Roboguide software installed on it, and I need to get a virtual robot cell to talk with a PLC (a 5069-L310ER) using Ethernet/IP. I've pieced together from random forum posts and some actual Fanuc docs how to do all the setup, and as far as I can tell everything should be good on the Fanuc side. On the Allen Bradley side, when I set up a generic ethernet module to connect to Roboguide, I always get a faulted state, with the module saying it has an invalid segment type. Double and triple checked the data types, word sizes, IP addresses, and if there's an issue I haven't found it yet. The robot shows an enabled Ethernet/IP configuration but status is offline, Studio 5000 shows the generic ethernet module faulted, no comms are working.

Now, this setup is a bit niche because 1) I'm connecting to an emulated robot cell in Roboguide (but that should be possible, I've set some specific system variables to enable that in Roboguide) and 2) both Studio 5000 and Roboguide are on the same PC. But this doesn't seem to be working even when I just run it on the PLC as a stand-alone thing. I've done some (i.e. way more than I ever wanted to) reading and heard that there's a background process called FactoryTalk Linx OPC Runtime Service that can apparently interfere with Ethernet/IP, so I tried manually end-tasking it. Weirdly, when I do this, the status on the Fanuc Ethernet/IP connection changes to ONLINE, but I can't confirm that anything is actually working because no data is sent (as far as I can tell). I also don't know for sure if this OPC Runtime Service thing is even the issue, because if I close Studio 5000 the PLC on its own doesn't seem to be connecting to the Fanuc robot.

I know this is a long shot, but if anyone has any advice for this super specific issue it would be a lifesaver.

I never figured out what was causing this issue, and at some point after about a week of work, it just stopped happening. I'll tell you what I do know about it, but I never got to a really satifactory solution.

First, the cause of the issue is almost definitely that Roboguide and some background Rockwell process (the OPC Runtime Service) are fighting over the same port on the computer. Rockwell's software is flexible and if that port is taken, it'll grab another one. But Roboguide won't, it needs one specific port to be available. This is why using the task manager to kill the OPC Runtime Service works; it temporarily frees up the port and allows Roboguide to grab it.

When you configure the Ethernet/IP settings on the Teach Pendant, you choose how many 16 bit words you want to use. This gives you a total number of bits that you'll be using. When you set up the generic ethernet module in Studio 5000, you need to make sure that you are matching that number of bits. However, you DON'T need to use 16 bit words. It's fine to use the default DINT data type, which is 32 bits, as long as the total number of bits is the same. So for me, I had 4 16 bit words on the Fanuc side and 2 DINT words on the PLC side.

It's important to get the digital IO and UOP configuration right. If you are not using UOP signals, then you should have 64 input and 64 output registers configured to use rack 89 slot 1, and they should start at 1. IF you are using the UOP signals (like if you want the PLC is start or stop the robot remotely), then you need to adjust the digital IO setup to take into account how much of your message is taken up by the UOP stuff. So for me, I had 64 bits, but 20 of the output bits were used by the output UOP signals. I had the UOP outputs set to use range 1-20, rack 89 slot 1, starting at 1. Then I had the digital outputs using range 1-44 (since I have 64 total bits are 20 are used by the UOP), rack 89, slot 1, starting at 21 (since UOP is taking 1-20). Likewise for the inputs, except there are only 18 input UOP signals.

Finally, in case it helps, this is the procedure I used for setting everything up:

1. Create the cell, including the Ethernet/IP Adapter package.

2. In the cell browser select your controller and in the Network settings tab check the box allowing external connections (this will trigger a restart).

3. Configure the Ethernet/IP stuff (number of words, etc.).

4. Check the HostComm setup, make sure the ethernet address is correct (should use the same address as the computer you are on). Add the PLC address to the list of hosts, etc.

5. Configure the digital and UOP IO stuff. If you're using UOP signals there are some settings in the system > config menu to set, I don't recall off hand what they are but you can probably search for that. Probably try to get things working without UOP first.

6. At this point, you should see a warning saying the Ethernet/IP module is idle. This is what you will see when the port is being hogged by the Rockwell FactoryTalk OPC Runtime Service software.

7. Set up your PLC; create a generic ethernet module, set it's target IP address to your Roboguide computer's IP address, set up the data type and number of input / output words to match the total number of bits configured on the robot. I think the instance numbers for the Fanuc stuff are 101 for input, 151 for output, and 100 for config, but check their Ethernet/IP manual to be sure.

8. Download to the PLC. You should now see an error on the generic ethernet module saying you have an invalid segment type. This is the port issue I was talking about.

9. Now, open the task manager and search for OPC Runtime Service. Kill that process (it will come back within a few seconds on its own). This might give some temporary glitches in other Rockwell software, and you should HOPEFULLY see the ethernet/IP stuff connect. Fault will clear on the PLC, and if you reset errors in Roboguide the Ethernet/IP idle error should go away.

As I said, this didn't work for like a week and then has worked since. No clue why, if you have an issue respond or DM me, and maybe just try rebooting things a bunch.