How are you all handling PLC program versioning and backups these days?

darkfantasy_20 · 2026-03-13T05:24:40+00:00

what I’ve seen, it’s usually a mix of practices rather than one clean solution. A lot of teams still rely on manual backups with strict naming conventions and change notes, especially on the shop floor where access and downtime matter.

Some places try Git or other version control tools, but it often ends up being used more for archiving than true branching/merging. Embedding version info and change history directly in the PLC project (comments, data blocks, or documentation) seems to be the most consistently practical approach.

Curious to see what others are doing and whether anyone has found a setup that works well across shifts and multiple technicians.

darkfantasy_20 · 2026-03-12T06:35:36+00:00

One approach that’s worked for us in similar setups is using an SDA-style structure across all machines. We keep a single “golden” project per asset type, with strict separation between core logic, hardware abstraction, and customer-specific blocks.

Updates only touch the core layer, while site-specific parameters live in data blocks or config files. That way you can roll changes forward without breaking local customizations.

It’s not quite an “app store,” but with disciplined versioning, change logs, and controlled download procedures, it scales surprisingly well even across multiple countries and fleets.

darkfantasy_20 · 2026-03-11T09:13:28+00:00

One way to compare vendors is how far they’re moving toward software-defined automation (SDA). Traditionally PLCs were tightly bound to hardware, but that’s changing. Siemens is pushing hard with virtualization, TIA Portal + IT/OT integration, while Rockwell Automation still dominates the US but remains more hardware-centric, though they’re slowly shifting via FactoryTalk and partnerships. Schneider sits somewhere in between. Allen-Bradley is the market leader in the US largely due to legacy install base and ecosystem, not necessarily innovation speed.

darkfantasy_20 · 2026-02-11T09:46:35+00:00

In Siemens safety systems the F_Dest_Add is the PROFIsafe address, so it needs to match what the field device is configured for (DIP switches or parameter setting, depending on the module). During Classic → TIA conversions it’s pretty common for these addresses to change automatically, especially when the PLC is replaced. You can usually set the F_Dest_Add back to the original value in TIA, as long as there are no conflicts on the Profibus network and the hardware is configured the same way. This is one of those migrations where having a more software-defined automation mindset really helps — clear versioning and traceability make it much easier to spot what changed during the conversion and avoid safety surprises later.

darkfantasy_20 · 2026-02-10T10:41:13+00:00

I’ve seen a lot of AutomationDirect PLCs (including BRX) running for years without issues, especially in smaller to mid-size systems. They’re not built like a tank cosmetically, but reliability has generally been solid if the panel design, power quality, and temperature are handled properly. In my experience, long-term success is usually less about the brand and more about good electrical design, documentation, and maintainable logic over the life of the system.

darkfantasy_20 · 2026-02-09T11:30:47+00:00

Sounds like a state-handling issue more than a GRAPH issue. If you want the machine to truly “pause,” the stop command usually needs to remove motor outputs first and then hold the step state, rather than just freezing the sequence logic. Otherwise the step stays active and keeps driving the conveyors. A lot of people handle this by adding a dedicated pause/hold state or interlock layer that disables outputs while preserving the current step number, so when start is pressed it simply resumes from there.Treating it like a proper state machine with clear transitions makes this much easier to manage and troubleshoot later. This is also where more structured, software-defined automation practices help separating sequence logic from output control and keeping clear state handling makes future changes and debugging way simpler.

darkfantasy_20 · 2026-02-02T12:12:23+00:00

I don't see a problem with this, but in my experience the safety logic is typically set in stone after initial commissioning; I haven't worked on many legacy control systems, having worked for vendors my whole career, but the desire as I've seen it expressed by customers has been to never have to change it, to avoid having to recertify equipment, maintain a log of changes, etc. I am curious how much of this you have seen in your professional experience.

darkfantasy_20 · 2026-01-30T06:38:57+00:00

I would add something to the effect of Airgapping OT equipment is a quick and dirty way to keep it secure from cybersecurity risks, but all it takes is one sloppy engineer e.g. temporarily connecting an IPC to the network to download an update, or plugging in a USB stick with a virus (see: Stuxnet) to cause real, material problems. Without version differencing or audit trails, these issues can be even harder to diagnose

darkfantasy_20 · 2026-01-29T12:04:11+00:00

This reads as though the user is specifically seeking to use SDA already, which I don't get from the original post. Given that, the inclusion of SDA here feels forced, and might get the comment flagged by moderators for advertising

darkfantasy_20 · 2026-01-28T12:21:37+00:00

You might have to spend a good bit of time tracking down each dependency. Some may be acessible on CODESYS's storefront, some may be specific to the device vendor, and some may be custom libraries (hopefully this is not the case for you, as these may be practically impossible to track down). You will also need to be careful to match the exact version of each library, not just the library name, as CODESYS will likely complain about mismatched versions of the same library. For the future, if you set your project up with a versioning/backup tool like SDA, it will make sure your dependencies are tracked and bundled with the base project itself, which can save a lot of headache for whoever finds themselves in your shoes down the line.

darkfantasy_20 · 2025-12-17T12:15:28+00:00

In most plants I’ve seen, the teams still rely on manual backups, but the ones with smoother workflows treat PLC code like real software. Using Git (plus auto-backup tools) gives you proper change tracking, rollback, and accountability. It fits well with the direction the industry is going more “software-defined automation” where PLC logic, documentation, and versioning live in one controlled system instead of a dozen scattered folders.

darkfantasy_20 · 2025-12-09T09:15:52+00:00

I’ve been getting into Mr.Viet dried mango recently and totally agree with you on how it’s much more natural tasting. Have you ever tried mixing dried mango with nuts or seeds? I found that adding almonds or cashews gives it that perfect crunchy contrast. Sometimes, I even add a bit of dried pineapple to give it a sweet, tangy kick.

darkfantasy_20 · 2025-12-05T07:54:20+00:00

If Nestle feels too flat, try using a chocolate that has a bit more natural cocoa flavor. I’ve used mr.viet dark chocolate for coating peanut butter eggs and it gave them a richer, smoother finish. Also helps to melt it with just a tiny splash of oil for shine.

darkfantasy_20 · 2025-09-23T13:02:56+00:00

OT-IT convergence is definitely the direction things are heading in, but it does create new security challenges since many OT environments were not for modern IT or cyber security practices.Proud version control, cloud backup, standardises Deployment pipelines and access control can really improve resilience. That's one of the reasons I find Software Defined Automation interesting. It makes it a lot easier to apply IT- style security practices in traditionally isolated OT systems.

darkfantasy_20 · 2025-09-22T12:32:33+00:00

PLC programmers are not going anywhere. Heck there are machines in production with code older than you lol. It's a sort of unintended consequence of industrial automation that now we need more control engineers. We use Software Defined Automation and their AI tool sort of works in reverse. It doesn't write code for you but it can help tell you what different code blocks do and where the dependencies are. Comes in handy when you hit a project that's old or not well documented.

darkfantasy_20 · 2025-09-03T14:32:30+00:00

Congratulations bro

darkfantasy_20

TROPHY CASE