Posts by rf103

    PACs are still used, just not by regular customers, like you and me.


    Customers outside (north) america don't get load media with their robots.


    Any time new options need to be installed, only Fanuc can do that. They do exactly as ps0f0r describes: take an image backup, perform a procedure similar to how roboguide reserializes a robot and then send the image back.


    This still uses PACs, they just never get to customers directly.

    What I tried to explain is that Fanuc RSI is not capable of "controlling the position of the robot in real time".


    It will only output the current position.

    According to the documentation, the RSI option does not support input. It only outputs the current position of the robot using the RSI protocol.

    You might already know, but delays exist for a reason. At least this one.


    It prevents the round-robin scheduling from not being able to suspend your task.


    Runaway programs are much harder to deal with without some forced yielding every now and then.

    SHOW HISTORY is not Karel, it's KCL.


    And you shouldn't need to use Karel or any sockets: the built-in web server should be able to execute that KCL command and return you the result.


    Open http://1.2.3.4/KCL/show%20history%20atshell to see the history of ATSHELL for instance (replace 1.2.3.4 with the IP of your controller or roboguide):


    Code
       1 SHOW HISTORY ATSHELL
    
    ******  History Data  ******
    Routine depth: 0  Routine: ATSHELL                             
    Line:  1069       Program: ATSHELL                 Type: PC    
    File MF:\ATSHELL.KL not found


    It's basically what PRGSTATE.DG also shows, except it will show source if that's available.


    Quote

    Not using Karel for this because it seems 10x more laborious.


    you mean more laborious than reverse engineering the semantics of a set of pointers? :winking_face:

    The range of vulnerable software versions is impressive, though not unexpected. Basically all versions, starting with R-30iA. I guess the security researcher didn't have anything older available (he/she could also have used roboguide).


    I wonder whether Fanuc will provide software updates to customers who ask for them to address the vulnerability.


    CVE-2021-32998 (the second one) is serious:

    Quote

    may allow an attacker to remotely execute arbitrary code. INIT START/restore from backup required.

    FSAC could help, but better have backups.

    I would think if the Roboguide KAREL is a newer version, it would already recognize all the built-in procedures of a older system.

    the version of Karel you're working with was created multiple decades ago.


    Since then, many things have changed.


    Newer versions of software don't always support everything older versions supported, and in your case, the S420 version (v2.x v4.x ?) is just too old for the Karel compiler you're trying to use (v6.x ?).


    Fanuc decided to rename routines and change how things worked. In some cases, old routines were removed.


    if anyone has any way to get these functions to work on the Roboguide KAREL.


    you could implement SHIFT yourself as a Karel routine in your own program. Current versions of Karel support linear algebra, such as INV and the mixed vector and position operators. Refer to the Karel manual for their description.


    Write SHIFT yourself so you don't have to change all calls to SHIFT everywhere.


    Hermann is right though. MOVE TO is still supported, but TP programs will result in better motion (faster, smoother).

    What method are you using to check if you are on a simulated robot? I've been checking for the existence of a system var ($UD1_PATH) that only exists on the simulated robot, but I've wondered if there is a more elegant method.

    Nothing fundamentally different to what you're already doing.


    An alternative variable would be $VIRTUALTIME, which also only exists on simulated robots.

    This would be handy to have, but does not exist. Or: I've not been able to find it.


    because there is little I can do without having a major refactor before every robot deployment

    byte swapping a major refactor?


    That should not be the case.


    Many situations require swapping, so building that into a protocol implementation may be annoying, but should not be that difficult.


    Karel has swapping functions, so you could also swap on the robot. You could even do that based on whether your code is running on real or simulated hardware.

    I've written programs to dynamically change the payload via system variables, but never had a chance to test them.


    Really it comes down to what Lemster said.

    does that actually work?


    I've always understood the system variables are just the last (or first) step, and other actions are needed to really make the controller use the new data.

Advertising from our partners