Source control for industrial robots - does it exist? Would you buy it if not?

  • I know that taking backups of controllers before making changes is usually recommended but I think it's not usually done since it's a bit of a hassle. Plus, in case of issue restoring the backup can be a bit of a hassle as well.

    What do you guys think of a product that's essentially a GitHub for TP programming? It would automatically pull backups periodically and upload them to a cloud server. You'd be able to go back through changes easily and see just what changed. It could also have the ability to revert changes, visualize position changes, and keep track of setup and configuration as well as the program data. Does something like this exist? If not, would it be a good product?

  • Place your Ad here!
  • kwakisaki

    Approved the thread.
  • it could be... looks good on the surface and sounds much like Plant Archiver. but then you mention cloud which to me is an instant red flag. after all there are things like Stuxnet and I see holes in so many designs, then AI is getting more and more powerful and someone malicious could take things to another limit because virtually nothing is bullet proof.

    so i would suggest to think it though and address any issues and - be open about anything that it is or is not.

    1) read pinned topic: READ FIRST...

    2) if you have an issue with robot, post question in the correct forum section... do NOT contact me directly

    3) read 1 and 2

  • I've used my personal GitHub account to keep version control of my robot files. Well, the ASCII ones. For Fanuc and Nachi, the extra headaches involved in pulling or pushing ASCII files makes things more annoying.

    Fanuc LS files also add an extra wrinkle: line numbering within the file text, which makes small changes look like much larger changes to the GitHub diff algorithm.

    For PERS variables in ABB RAPID, or persistent .DAT variables in KUKA KRL modules, the dynamic variable values "snapshotted" in the program files also create "false positives" in the diff. To the point that I generally separate these variables into Contstant, Persistent, and Dynamic sections just to make it easier to ignore irrelevant changes.

    Version control for robot program files would need a diff system more granularly customizable than anything I've seen in the regular Git tool chains to date.

    One problem is that, for people working at the level most Forum readers do, every robot on every project is custom programmed to some degree, and most standardized code libraries are part of standard packages bought with the robot options. Version control only really becomes useful when you're writing programs for large-scale deployment. Small-scale, I've found it somewhat useful for tracking changes from backup to backup, but usually it's faster and easier to just run two backups through WinMerge or KDiff instead of firing up GitHub.

    I imagine that for their internal software development, Fanuc/KUKA/ABB/et al use some kind of version control in-house, since they are writing for large-scale deployment and have to maintain many different branches of the same code base.

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