Great! Reach out for a free consultation meeting by filling out our contact form, or shoot us an email at sales@simple-automation.io.

We support any PLC Platform that adheres to IEC-61131-3. This allows to work with hundreds of PLC brands.

Not all platforms are the same, some have brand specific functionality and IDEs. We have extensive experience with CODESYS, Beckhoff, Allen Bradley and Siemens. We have a decent amount of experience with Automation Direct products.

CODESYS is the backbone behind many PLC platforms like Bosch CtrlX, Wago, Phoneix Contact’s PLCNext, Yaskawa and Lenze PLCs just to name a few. CODESYS experience transfers to all the platforms that use their runtime under the hood. CODESYS is under the hood of more than 500 manufacturers.

IEC-61131-3 is the international standard that governs the syntax of the 5 PLC languages: Structured Text (ST), Ladder Diagram (LD), Function Block Diagram (FBD), Sequential Function Chart (SFC), and Instruction List (IL).

Note: Instruction List will be deprecated in the next release of IEC-61131-3

We have a couple solutions for this!

If you want to keep your current control system platform, there are third-party solutions that we use that allow us to leverage modern version control. To leverage TDD, we can take the code base and duplicate it in a modern PLC platform like CODESYS and create test logic. This approach is not our preferred approach though, as it will create multiple code bases to track.

Instead, our preferred solution is to upgrade the control system in your machine to a modern PLC platform! Simple Automation will handle the electrical and software design of the retrofit. Reach out to us if this is the route you would like to take!

We employ standards from both the Control and Software Engineering Disciplines.

Control Engineering

We follow the PLCOpen standard for motion control as well as their standards for Function Blocks. For PID loops we use Lambda tuning methods. Our programs are setup using industry standard I/O buffering techniques to allow for simulated hardware signals and to avoid race-condition code.

Software Engineering

We use OOP and have developed libraries that employ TDD. We use Git for version control and we use Static Analysis tools to enforce Simple Automation coding syntax. We try to use SOLID principles wherever they apply within machine software architecture.

Simple Automation Internal Standards

Simple Automation has internal Simple Libraries that have incorporated Unit Testing. This is used in conjunction with PLCOpen motion control and OOP programming methods to help speed up development with code that we have verified will work. TDD implementation allows us steadily improve our libraries without fearing that current bug fixes won’t turn into future problems.

OOP stands for Object-Oriented Programming. In Industrial Automation, this simply means that the code architecture is structed into objects rather than pure sequential logic.

This is extremely advantageous for code maintainability, readability and flexibility. A common example would be a simple machine with 3 conveyors and a variation of normally-open (NO) and normally-closed (NC) switches. A sequential program would directly call each conveyor in sequence, and checking of sensors would be specific to whether the sensor is NO or NC. The code would copy-and-paste the logic for each conveyor and all the sensors.

This is bad for a few reasons. Copy and paste code is extremely hard to maintain once deployed. If a different developer comes to adjust the conveyor logic a year after its deployed, but forgets to copy the code to the other two conveyors, you now have a problem. Likewise, if a NO sensor is replaced with NC on one line and not the rest, then the logic for that line now has to be different. So if we revisit the developer that failed to copy and paste code - if we change the scenario so that he doesn’t forget to do this, but now the sensors are different, he would end up making one line non-functional with the code. This is a nightmare.

Lets take the OOP approach. Conveyor code would be written ONCE in a re-usable piece of code called a Function Block. The conveyor code shouldn’t care whether the sensors are NO or NC, so we abstract that information away using a code structure called an Interface. The Interface will just tell the conveyor code that the sensor has tripped.

Now if we make conveyor logic changes, it automatically is copied to all lines. If we change out a sensor, we would write additional code in the Interface to handle that, and the conveyor code would look at the interface to simply tell it whether the sensor has tripped, not caring about the sensor type (NO vs NC). This is much simpler to maintain and change the program over time.

Test Driven Development (TDD) is the practice of writing test code before writing the actual implementation code. Simple Automation uses this approach with our library code.

The benefit of doing this that our libraries have test suites that verify the original functionality of the code. As we update and change our library, we verify that this original functionality is preserved. If we find bugs in the field, we create new test code to identify the bug. Then we add this test code to our suite of tests and run it for every future change to ensure we do not re-introduce the bug.

TDD is how Simple Automation ensures that our code improves steadily over time. We also can ensure that once we’ve fixed a bug we will never reintroduce the same bug.

Simple Automation engineers are highly trained in software development. Software development usually requires the ability to quickly learn and use new programming languages.

Long story short - we will be able to learn whatever syntax your PLC requires!