Posts by rf103

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

Quote from dnaumann

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.

Quote from Nation

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.

Quote from pdl

I don't know if the old controllers support multiple motion groups, but I know the newer ones from version 5 (I think) explicitly state with a very serious warning that they do not and bad things will happen.

I know, and I'm aware of that warning.

Programs are working though.

Quote from jmd2777

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

Karel supports motion, even if the newer manuals do not mention it any more. But that is not a problem in this case. Manuals are present, as well as a copy of ktrans.

You can still build programs with motion statements in them. They will just not go as fast as TP programs.

And personally, once you get used to the Karel way of doing things, it is not that bad.

Most controllers run their Karel VMs at 125 hz and scan times have to be integer multiples of the period. 250 hz is possible with special options (probably those were what the engineer you talked to had in mind).

Whether the jitter on the scheduling running those condition handlers is 1 ms I cannot tell you. I would suggest to experiment with it. Karel does have access to a micro second clock.

If that is all acceptable to you, using Karel may work.

R891 though will make things much easier, as you can just configure some system variables and that's it. The system takes care of the rest. No Karel needed.

Local company has asked me to look into helping them support a really old application running on RJ2/RJ3 controllers with Karel. They still have the source code of most of the programs.

They also have manuals, but it's all very sparse on details about MOVE TO and other motion related functionality. Syntax is explained, but nothing much more.

I'm hoping someone here with experience with these old systems would have some code to share which shows how to use these old Karel statements.

Interesting would be programs with coordinated motion between multiple groups and IO related code.

Nothing has been touched yet, and I haven't been near the controllers, so all info I have comes from their engineers.

You won't get 1000 hz, but ask for option R891, the High-Speed Position Output.

Maximum frequency is 500 hz on iB+ controllers.

Gets you Cartesian pose and other data. But higher rates will probably reduce the data you can get out of the robot.

Another option would be to not use the robot, but use an external system which tracks the position of your scanning sensor. Even moderately priced laser scanners can do 1000 hz these days, but it will probably still be more expensive than R891.

Yes, but that is how RMI works.

So you're implementing a Remote Motion Interface client in C#?

This guy seems to have figured out how to do what Skyefire describes and wrap it in a software: https://github.com/gavanderhoorn/dominh

The readme says you don't need any special options for it.

I found https://github.com/gavanderhoorn/dominh which appears to use what Nation shows but then with Python.

This is actually a very relevant question, but unfortunately the answer has already been posted by Nation.

There is no support for secure sockets in Karel. And it would require quite some dedication to implement something like SSL or TLS in that language.

Quote from Nation

But I am not sure if this is needed. Industrial networks should be airgapped from the internet.

This doesn't seem reasonable to require any more these days. What about predictive maintenance? Remote monitoring? ERP integration?

Even without direct internet connections, attackers could have ample opportunity to hop from host to host, until they arrive at the host they're interested in.

Securing all incoming and outgoing connections would be a simple, but effective measure against some of the more simple types of attacks.

Unfortunately it's not possible right now.

As I already wrote: it depends on what Darkbound actually wants to do.

Overhead of any HTTP/FTP based action is going to be on the order of a couple hundred milliseconds in the best case. In my world, that reduces its utility to "off-line" use cases.

Hence my question.

If that is a problem, using the PCDK might be an option. There have been various reports here on the forum which claim the assemblies installed by roboguide are sufficient to perform some basic tasks. If I remember correctly, the PCDK does not require any additional options to be installed on the robot, so perhaps this would work better for Darkbound than the Web/FTP server.

What does two way communication really mean?

You write "I want to calculate points/trajectories with MATLAB for example", but that could be both offline and online.

If you are looking for any kind of "real time" interactivity, then using the WebServer (R626) is probably not going to work too well.

If all you want to do is generate trajectories and then execute them, I would suggest to look at generating TP programs and upload those to the controller. Every R30iA I know has the FTP server if you have the WebServer.

If I'm not mistaken the break there forces a break in the look ahead of the Karel runtime.

So the runtime will not attempt to execute any instructions following that line until after it has completed the motion instruction.

The karel runtime is an 8 and 16 bit system, so 64K is the maximum it can address.

I don't believe this can be changed easily.

What exactly do you want to make bigger than 64K?

Are we discussing altering motions or completely externally controlling motions?

The former can be done with DPM, the latter would need a different option.

And latency is certainly something you would need to account for: I believe the DPM manual specifies a 5 * ITP delay.

I've seen some applications assume that a read() on a socket file descriptor will return a single packet/message, which is fundamentally incorrect for TCP/IP. If that is the case with your Linux processor, that should be fixed.

According to the Karel documentation, the default write buffer size is 256 bytes.

Have you configured the socket FILE with ATR_UF? If not, there could be a CR byte in your data that is triggering a buffer flush.

TCP is stream based, so it has no concept of a message or a frame. Only applications using TCP connections can interpret the data like that. Perhaps the closest thing would be a segment.

Are you communicating with software that does not accept partial messages?

Apparently $FILTER_EMPT should exist on 6.40 and is almost the same. Got that from here: https://github.com/ros-industrial/fanuc/issues/88.

Quote from lan1301

Hi hermann:

As you said, which language should I use now?

TP