OPC-UA in RoboGuide

    Good day, all. I'm looking to set up a robot in RoboGuide with the OPC-UA option, to test some IIoT development work we're doing. I've been following the directions in the "HMI Device Communications" manual (MARUCHOPM05191E), but it's written for "real" robots, and I think I'm tripping over some of the quirks RG bots have when it comes to network communications.


    I've installed the R553 option, and activated it as per the manual, but when I run a nmap test against my 127.0.0.1, the OPC Server port isn't open, and I can't get any response using OPC-UA clients running on my host computer. I can reach the virtual robot's web server by using the same address, so I know the virtual controller is running and responding on the "normal" ports, at least.


    Is there a trick I'm missing?

    I can't test in RoboGuide right now but here are a few notes from my experience:


    1. I first tried Prosys client (connecting to a real robot) and it would not work. UA Expert client did work. I think Prosys sends an invalid timestamp on the first connection and the Fanuc OPC-UA server rejects it. So try UA Expert if you have not already.


    2. What address are you using in the OPC-UA client? My guess would be: opc.tcp://127.0.0.1:4880/FANUC/NanoUaServer


    3. I don't think all network-based services are emulated in RoboGuide. For example, I have tried testing Ethernet/IP in RoboGuide and it does not seem to be running. Do you know if the OPC-UA server runs in RoboGuide?


    Search this forum for system variables: "EIP_ENBL_IO" and "MODB_ENABLIO". There are other threads where people have said that enabling this variable allowed them to use EIP or Modbus in RoboGuide. Maybe there is a similar variable for OPC-UA.


    4. Verify that your RoboGuide robot is running version 9.1 or newer. That is when they added OPC-UA to the HMI option.


    Update:

    I tested on a RoboGuide cell and I am able to connect to the OPC-UA server.

    This is the environment:

    RoboGuide V9 Rev. K

    The RoboGuide cell is made from a real robot backup. The rRobot software version is 9.10P/25

    I connected with UA-Expert using opc.tcp://127.0.0.1:4880/FANUC/NanoUaServer

    I did not change any settings in RoboGuide to make it work.

    Edited once, last by jmd2777: New information ().

    I was busy with other assignments and didn't have a chance to get back to this until today. And it does work, as you describe.


    I think I was tripping over a few issues: first, the E-Doc for the "HMI Option" (R553) says that the communications take place over the ModBus port, which defaults to 502. And when drilled down into the Host Comm settings, as described in the E-Doc, it was set for 502.


    However, there is a webinar (which I found later) that shows the same default URL as you showed above. And once I had UA-Expert set up for that URL, I got an active connection to the robot. The Webinar is from Jun 28, 2019, for those who have CRC access.


    I'm beginning to suspect the E-Doc is outdated or (more likely) not for "general" OPC-UA, despite being the only document that comes from a CRC search for "OPC". :face_with_rolling_eyes:


    What's still odd, though, is that nmap against 127.0.0.1 shows neither port 502 or 4880 open, even when I have active communication going over 4880 with UA-Expert. That's very odd, and one of the big things I was stuck on before -- any ports the robot is holding open as a server should show up in a port scan.


    Ah, well, I now have communication, and UA-Expert is showing me data tags from the robot. Now I have to figure out why they're all empty. The "Robot Position" node, for example, shows nothing but zeros, no matter how I move the robot around.

    So, working my way through the webinar. I've been able to successfully access the various discrete I/O in RoboGuide. However, once I got to the section of the webinar covering Holding Registers, I couldn't get data to move in either direction. With the default $SNPX_ASG settings, the numeric Registers should have been have been connected to the first 1000 Holding Registers in the Modbus data tree. But my OPC client (UA-Expert) shows nothing but 0 for every register, no matter what I put into the registers in the virtual controller.


    Likewise, any attempt to write from UA-E to the robot's registers has no effect.


    Changing $SNPX_ASG to exactly match the example in the webinar doesn't help, either.


    Is there an additional setting that I need to tweak? This is a fresh new v9.4 virtual controller I created for this study, with R553 as the only installed option. Aside from $SNPX_ASG, I've not touched any of the system variables or settings.

    I just tried connecting to my RoboGuide cell with UA Expert. At first it correctly showed the register values in the Holding Registers. The position data also was working(MotionDevices->Axes->AxisX->ParameterSet->ActualPosition). Then my RoboGuide did that thing where it becomes unresponsive for a few seconds. Then the Holding Registers showed all 0. I had to disconnect in UA Expert and then reconnect and then the Holding Registers were showing the correct values again.


    When the Holding Registers are working I was able to write a value back to robot. Beware, when I used the write feature in UA Expert it converted all of my data registers to integers.


    1. I am using the default $SNPX_ASG.

    2. The Holding Registers are truncating any value after the decimal point. For example if I have R[1] = 0.4 the Holding Register[1] shows 0, If R[2] = 10.2 the Holding Register shows 10.

    3. We have been using OPC UA in Labview to read and write data registers to a real robot and we have not had any problem. So it may be a RoboGuide problem or it could be a UA Expert to Fanuc Robot problem.

    Edited once, last by jmd2777 ().

    Yeah, I eventually got it to work by rebooting RG a few times. :icon_rolleyes: But after that, making new changes to $SNPX "went active" immediately, without needing a reboot. Dangit, Fanuc... :uglyhammer2:


    Yeah, I've seen the same issue with truncating Floats to Integers. I'll have to play with that some more. Also, SRs come across a bit strangely -- every %R in UA-Expert contains two characters (convert the integer to a 4-digit Hex value, and each pair of hex values is the ASCII value of a character), in reversed order, but the %Rs are in "normal" order. So looking at the raw ASCII values, "Hello World" in SR[1] comes across as: "eHll ooWlrd". Although IIRC this is fairly typical when moving data between Big- and Little-Endian contexts, so it shouldn't be hard to fix.

    Hi,

    I am trying the same, communicate TIA portal with PLCSAdvanced to the Roboguide.
    I have seen that you talk about a Webinar that I have not been able to find, I do not know if you could provide me with the link.


    I have found information using the Keepserver program but it doesn't seem to work for me with Windows 10.
    With UA-Exper I can read and write to the TIA Portal but i have not idea how to go foward whith Roboguide.


    Thanks a lot

    Hi guys, I am really interested in OPC-UA because I use Ignition SCADA that has OPC-UA.

    How can I start?

    Is this requires some license on the robot?

    Is it free from the robot side?

    Do you have some manual on how to set up OPC-UA?


    Thanks

    Not free. Requires adding the "HMI Option" from Fanuc, R553. This adds an OPC-UA server to the robot. And it only works on R30-iB+ or later controllers running OS version 9.1 or higher. Older versions can have the R553 option installed, but it won't have OPC-UA.


    Also only works over the A or B ethernet ports, not the C port.


    After that, any OPC-UA client can access the robot's OPC-UA server. The Fanuc webinar suggests a free program called UAExpert to do testing with, which I've used and it's pretty easy. The URL is:

    opc.tcp://ip address:4880/FANUC/NanoUAServer


    The OPC server "exposes" the robot's DIs, DOs, Registers, String Registers, and error messages. Fanuc appears to have simply "ported" their older ModBus addressing scheme to the OPC server, so each "type" occupies a different address range, which has been "padded" -- the DIs, for example. occupy addresses 1-10000, even though most robots have less than 1000 DIs max. Different variables are exposed as different OPC types, depending on whether they are read/write or read-only.

Advertising from our partners