All evidence points to a custom OS, or derivative of an old embedded OS.
I would not expect any unix or windows heritage.
All evidence points to a custom OS, or derivative of an old embedded OS.
I would not expect any unix or windows heritage.
From what I'm hearing, it seems like they're trying to phase Karel out and get full functionality with the tp language.
There are thousands of Karel programs in V9.X of the system software, ranging from simple utilities used by TP programs to the major parts of programming standards like VW.
I doubt Fanuc is going to "phase out" Karel any time soon.
When it is not, it is often possible but a lot of work and pretty risky.
You will have to change the parameters for the servo's and the encoders and the pinout of the cables will be different as well.
have you ever performed such a conversion?
Fanuc uses $VIRTUALTIME.
But that also does not exist if not virtual, so as PnStarter writes, would not work in TP.
Just a note of caution: that version field is there for a reason.
Changes between 8.x and 9.x have been quite significant in some places, and there is no guarantee your programs will run correctly by manually overriding that value.
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.
You should be able to look this up in the error manual for your controller.
You could also use A website: Know FANUC alarm codes
You could take a look how https://github.com/gavanderhoorn/dominh does it.
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.
4wheeled: what is it you actually want to do?
Discussing these Karel VM scheduling details is interesting, but perhaps not the most efficient way to go about achieving what your goal is.
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.
Such hostility
I hope you get your HMI working the way you envision.
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):
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.
QuoteNot using Karel for this because it seems 10x more laborious.
you mean more laborious than reverse engineering the semantics of a set of pointers?
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:
Quotemay 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.