Anyway to change the endianness on Roboguide?

  • Roboguide utilizes little endian for their bytes but real production robots from the same company utilizes big endian. A) I'll have to change my socket code from test to production to account for the change of endianness and B) since I'm truncating bytes to send UInt16 from Uint32s on the robot side, it is truncating the wrong side in simulation but not production. Hopefully there is just an option to set on Roboguide to change how it handles the byte swapping because there is little I can do without having a major refactor before every robot deployment.

  • Place your Ad here!
  • 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.

  • 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.

    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.

    Check out the Fanuc position converter I wrote here! Now open source!

    Check out my example Fanuc Ethernet/IP Explicit Messaging program here!

  • 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.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account
Sign up for a new account in our community. It's easy!
Register a new account
Sign in
Already have an account? Sign in here.
Sign in Now

Advertising from our partners