Posts by jmd2777

    I don't think anything has changed regarding the pause between program CALLs. I think its due to the difficulty of motion planning across different programs. Normally, certain things are locked when a program is running such as position values. So the motion planner knows that nothing will change.

    A potential solution would be if Fanuc would allow you to "group" TP programs. Basically, your CALL instruction would be like a #include in C++ where its the same as pasting the contents of the program into your main program. All programs in the group would be locked when one of them was running.

    In my case, this would be helpful to organize the code and make it easier to troubleshoot and unit test.

    What software version is the Roboguide controller using? Is the HMI SNPX option loaded on the virtual controller?

    I have connected Kepware to real robots(it may be different for Roboguide). With software versions older than V9, I used SNPX and GE Open connection. For version 9 robots I used an OPCUA connection in Kepware.

    What I was trying to say is that I don't see the MOVE TO instructions in the newer KAREL manuals.

    The KAREL manual for V9.30 says:

    "Note The KAREL system provides a way to create and manipulate position data but it does not
    support motion instructions. All motion must be initiated from a teach pendant program. Instructions
    and built-ins are available for setting KAREL position data into teach pendant programs"

    The available instructions will depend on the Fanuc software version that you are using.

    There is a SELECT instruction (at least on version 9.1). Its in the IF screen when adding an instruction. But that uses a Register value as the condition. I don't know if that will work for you.

    You can also do a similar behavior using JMP and LBL.

    IF cond1 is NOT true THEN JMP LBL100

    action 1

    JMP LBL 900


    IF cond2 is NOT true THEN JMP LBL 200

    action 2

    JMP LBL 900


    action 3 (else or default case goes here)

    JMP LBL 900

    LBL 900

    I'm not trying to change the physical locations. I'd want to have the same locations, represented in User Frame #1.

    Can you explain more of what you mean by keeping the same physical locations? Do you mean the tool will be in same position in real-world? Or do you mean the same position relative to the user frame?

    Also there is a package called:

    RSI Interface

    Remote Sensor Interface (RSI) is a function that facilitates communication of position data, etc., with an external device such as a PC or 3rd party controller.

    I've never used it though.

    I don't have any hard numbers, but I don't think its likely you can get updates at 1 msec. I would recommend trying to get access to a Fanuc guru (Someone beyond the tech support phone line). If you have a Fanuc sales person they may be able to give you a contact.

    Who needs to know the robot position? Is it an external device such as a computer? Or is it a program running on the robot controller?

    If its a computer, then Fanuc offers PCDK (PC Developer's Kit) which lets you write Visual Studio programs to access robot data such as position. I don't know the refresh rate.

    Fanuc also offers software packages for streaming motion coordinates to the robot (Dynamic Path Modification or Motion Streaming). I have not used them. I assume that you can receive the current position as well as send desired positions.

    When this happened to me, it was another program (not Roboguide) that created an FTP server at with the same port that Roboguide was using. So when I tried to FTP to Roboguide I was actually connecting to a different FTP server.

    I looked in my Windows Services and found the other FTP (I think it was FileZilla) service running.

    Here is one way to remotely update a Karel program that is running:

    If I have a Karel program for example "k_prg_1", I sometimes create a separate kill Karel program named "k_prg_1_kill" and copy it to the robot. The kill program only runs the ABORT_TASK command on "k_prg_1". This will overrule the NO_ABORT directive in "k_prg_1".

    You can use the web browser interface to run "k_prg_1_kill". Then use FTP to update "k_prg_1". Then use the web browser to start "k_prg_1".

    We had an IT guru look at it.

    I did find an email from Fanuc where they give us this advice when we were troubleshooting:

    “he needs to make sure that the robot is isolated on a subnet, so that it is not exposed to all of the plant network traffic”

    I don't know exactly what they meant by that. We always use for the subnet mask.

    But I think the solution was to configure the port settings on the managed network switch. Since the robot IP address is static, they restricted that port to only forward data that was directed to the robot's ip address. So broadcast messages were not passed through to the robot.

    I'm not familiar with the details, our IT department fixed the problem.

    We did have problems with a robot freezing up. It would eventually recover after about 5 minutes. We did not get the "Disconnected From Controller" message.

    Our issue was with network traffic. It required some in-depth IT analysis to find the problem. The robots were connected to the plant network for SCADA and automatic backups. The robots were getting too many discovery requests etc from other devices on the network. The network switch port that the robots were using had to be restricted to only allow certain data through.

    Yes, screenshots will help.

    Here are some suggestions to check:

    1. In the Adapter configuration on the robot. The slot used for the connection determines the Input Assembly and Output Assembly Instance. For example, if you configure the Adapter in Slot 1 then the Input Assembly Instance is 101 and the Output Assembly Instance is 151. Slot 2 use 102 and 152, etc. You need to configure the PLC connection with the same Input and Output Assembly Instance.

    2. The size of the Input and Output in the robot and PLC must match. And if I remember correctly, the input size on one side is the output size on the other. I might be wrong about that, but if you are having trouble, just set input and output to the same size for testing. Once you get the connection working you can change it. For example set both sides to 1 16 bit word for input and output size.