VC has only recently became a thing that control systems people think about. Before that the mess was job security tbh. The companies in question on the meme try and make version control really expensive and something they sell you. Many of the files where you save simple scripts/logic aren’t readable.
Seems crazy to me that the code is paywalled so hard that VC is an expensive DLC.
Maybe right to repair will enshrine some basic free functionality into these systems? (Like the ability to side load anything even if the manufacturer is not happy about it?).
Git isn’t really great because it’s all binary files, and you can’t have multiple people working on them at once in most cases, so you want a centralised VCS with locking. There are some reasonable specialised solutions that can produce graphical diff between revisions of the binary files (in principle I guess you could run the same tools with git, but the lack of locking, and existence of branching/merging is still a problem).
Well I mean you typically just export at the scope of the change.
So if I need to change one piece of code, say non trivial control logic for a non trivial valve, I just export the block of code that is that valve.
I make my changes, and if it doesn't work in simulation or I don't like it, I just reimport the old module and download only that module.
If I make several substantial changes to a Reactor, I'll export the entire reactor unit as a back up. I also make routine full system exports, so in theory I can import the entire system or parts of its configuration as it was when the export was taken, or parse through it in notepad to find a piece of code I need if I fuck up a smaller import/export somehow or if I want to go back in time to see what some logic was before a change was made.
And of course, lots of changes can be made online, and so I often configure new code to have those levers available- like a "new code on" set variable/bool switch, so I can trigger the new logic and immediately revert if something starts to go south. Then if it works as intended I'll delete the switch. You have to be careful when the "production environment" is a running reactor consuming EO... 😅
But typically, I think it's different than what you guys deal with. Once the systems is comissined, you only change the parts of it you need to as you go, you will NEVER do a full download of the system configuration unless something truly awful has happened.
So what good would version control do you? I mean I'm totally ignorant here. Is the version control granular enough that you can just get blocks of code meticulously versioned as it's changed? Or is it like, project versioning? And does it give you a difference report natively? That would be great...
If I make several substantial changes to a Reactor, I'll export the entire reactor unit as a back up. I also make routine full system exports, so in theory I can import the entire system or parts of its configuration as it was when the export was taken, or parse through it in notepad to find a piece of code I need if I fuck up a smaller import/export somehow or if I want to go back in time to see what some logic was before a change was made.
You are just explaining how I used to work before learning about version control in engineering school haha.
Just dump it all into a final_final_v2.zip, ctrl+f for the bits that are interesting, Ctrl+Z until it works again...
Yes! Version control gives you all that:
* You decide on the granularity: you can save whatever you want, from a small part to the full reactor.
* You can natively compare versions yes: major versions, small checkpoints, what you have here vs what is there, etc. any two files really.
* You can time travel all you want from checkpoint to checkpoint.
* You can make branches to explore "what-if" scenarios at no cost. You regret? Come back. You like it? Merge the branch, it is now the new normal. You regret later? Time travel to before the merge.
* Handle merge conflicts: let's say your colleagues have been making changes, and you have been too, and you would like to have their changes and yours at the same time: you can natively review the parts that are dissimilar and pick and choose what to keep, what to drop.
Interesting. The merge functionality would have to know the proprietary DCS database schema in order to "merge" branches and stuff, right?
If it does anything like that, that's the barrier, that's why we haven't had this nice toy until only recently. It's proprietary so something like git would have no idea how to merge two FHX files for example. Sometimes I make bulk editing changes to fhx files that fail to import and it's not always straightforward why, as the way the DCS database interprets these files is proprietary. You can manipulate a lot of things in those configuration files... And some things you just can't, even though you totally should be able to? Anyway.
So I suspect we are only now seeing this pop up in various DCS packages as the vendors have taken their sweet ass f****** time making these tools available to us, whereas open languages wouldn't have this problem at all.
But that's just my intuition
I'm all for it! I'm upgrading the system version next year so I'll get to experience it then. Woo hoo
6
u/TheFrenchSavage 13h ago
I don't recognize any of the left material.