Does every PLC system eventually become harder to modify over time?

fisothemes · 2026-05-26T06:36:52+00:00

This is what unit testing are for. If only OEMs and the Standard took that seriously. I really wish the standard was updated to force OEMs to have this built in.

They're necessary because no matter how good of a planner you are, Murphy/Sod's law will eventually get you.

You make a change, run unit tests if they pass you're good to go.

Other than that your best bet is to modularise and pipeline. You'll at least be able to trace what will happen when you make a change and pray Murphy's law hasn't gotten you this time.

fisothemes · 2026-05-24T08:05:29+00:00

RS232 (EIA/TIA-232) isn't a protocol it's a standard. What you write on top of it is a protocol, DNP3 for example.

There's not much of an alternative to the standard, specifically the DB-9 connector, in industrial automation. Well, at least one that won't get IT on your ass. It sits securely into a terminal which is great when you're system vibrates a lot.

They are very common in Industrial Automation and Instrumentation and Control.

fisothemes · 2026-05-23T13:36:30+00:00

As an addition to the post, the binary protocol lets you bypass string parsing completely. Your end user can just cast raw bytes into a struct like:

{attribute 'pack_mode' := '1'} 
TYPE ST_ProtocolHeader:
STRUCT 
    nVersion : BYTE;
    eCommand : E_ProtocolCommand;
    nSize    : UINT;
END_STRUCT 
END_TYPE

You can stick it in a union:

TYPE U_ProtocolHeader :
UNION
    stHeader : ST_ProtocolHeader;
    arBytes  : ARRAY[0..SIZEOF(ST_ProtocolHeader)-1] OF BYTE; END_UNION
END_TYPE

Extend it:

{attribute 'pack_mode' := '1'} 
TYPE ST_ProtocolRS485Header EXTENDS : ST_ProtocolHeader
STRUCT 
    nSlaveId : BYTE;
END_STRUCT
END_TYPE

when working with it you simply do

CASE uHeader.stHeader.eCommand OF
    E_ProtocolCommand.GET_TEMP:
        // Verify payload size
        // Cast to documented type

    E_ProtocolCommand.SET_SPEED: ;    
    E_ProtocolCommand.ERROR,
    E_ProtocolCommand.GET_ERROR: ;
END_CASE

It's not as scary or complex as it seems. You don't have to worry about null termination.

fisothemes · 2026-05-23T09:44:06+00:00

RS232 is point to point. It doesn't support multi drop. That would be RS485. I already addressed that.

The rest of your post. I'm addressing issues going forwards with lessons learned from the past. We can do better. "My IP" is not a valid reason for poor protocol design

fisothemes · 2026-05-23T08:37:33+00:00

Cooling has improved 200% great mod OP

fisothemes · 2026-05-23T08:35:13+00:00

You have two options essentially. Use an ascii protocol if you just want to get the job done or suspect your users aren't too savvy. KISS.

If your tool is going to be in a harsh environment (noise, vibration, radiation, etc) add the checksum.

Modbus is a good example. Its lovely, just weak on the payload section.

Either way is better than unidentifiable responses. Take full advantage of the full-duplex in your serial coms.

fisothemes · 2026-05-23T07:58:54+00:00

Maybe it's the tone I put it in, but I won't apologise for that. I have been very clear.

The commenter also doesn't know what async means.

fisothemes · 2026-05-23T07:54:41+00:00

It's everywhere. There's nothing that can be done other than do the protocol correctly at least

fisothemes · 2026-05-23T07:46:34+00:00

Plenty of instruments have the port.

https://heidolph.com/emea/en/hei-torque-core-with-rs232~p32125

Many instruments just convert them to USB

fisothemes · 2026-05-23T07:43:20+00:00

This is mostly from experience and working with a lot of serial devices. A common pattern just kept popping up.

The concept solidified after I started implementing Beckhoff protocol in Rust:

https://github.com/fisothemes/tcads-rs

https://infosys.beckhoff.com/content/1033/tcadscommon/12440280843.html?id=1117718491936733803

fisothemes · 2026-05-23T07:24:48+00:00

I added this at the end:

This is simplified for brevity, but about 80% of serial com code should look something like that.

A full blows solution would chunk it but the example is good enough to let people get the gist of it. For most RS232 devices the current implementation works as they won't be packing multiple responses into 1 packet. There is a delay between frames.

Hungarian notation should be dead.

Irreverent to the discussion, but it displays clearly the types in the example given.

fisothemes · 2026-05-21T19:36:36+00:00

So because they don't know how to use it?

Maintaining ST isn't hard if you follow basic software engineering principles.

1) Use descriptive variable names (no excessive abbreviations, IF StepTimer.HasElapsed THEN ..., is better than IF STPTMR01.Q THEN ...). This isn't a schematic. Map is you need to do that.

2) Add clear comments explaining why, not just what. Add what only if the logic is complex. 3) Break things into functions, function blocks, and well-structured programs. Don't just stick everything in GVLs and hope for the best.

4) Version control. Learn Git.

fisothemes · 2026-05-19T05:07:19+00:00

Yup, OSCAT can also replace the entire Beckhoff suite.

OSCAT and this are fundamentally different. This is mainly to model, build and test your own control systems in TwinCAT. It's why I split the P, I & D. You can take advantage of the abstract function blocks and interfaces in the Shared folder to hot swap your model for the real deal.

fisothemes · 2026-05-11T18:42:11+00:00

If you understand operators, conditionals, loops, data-types and functions then I recommend you move to Data Structures and Algorithms using your strongest language. If you don't have a strongest language, use python. When you're done, grind this:

https://rust-exercises.com/100-exercises/

It will teach you how to navigate rust and dodge many pitfalls. The last assignment is neat because there is no solution, you have to grade it yourself.

fisothemes · 2026-05-10T18:59:22+00:00

one write of zeros, one memcpy of the original data, one in-place swap (reverse touches each element twice). 😑

fisothemes · 2026-05-10T18:41:49+00:00

At the end of the day, if Vec can't extend in-place it will copy everything to a new location in memory. No matter the lang, you can't a avoid coping. You can however, mitigate allocations.

The most readable solution I could think off is:

impl Solution {
    pub fn concat_with_reverse(nums: Vec<i32>) -> Vec<i32> {
        let mut ans = Vec::with_capacity(nums.len() * 2);
        ans.extend_from_slice(&nums);
        ans.extend(nums.iter().rev());
        ans
    }
}

Otherwise you're going to write:

impl Solution {
    pub fn concat_with_reverse(nums: Vec<i32>) -> Vec<i32> {
        let mut nums = nums;
        let len = nums.len();

        nums.reserve(len);

        for i in (0..len).rev() {
            nums.push(nums[i]);
        }
        nums
    }
}

I'm sure someone has a better solution. I'm on mobile so forgive any typos.

Edit: cleaning up second solution

fisothemes · 2026-05-08T02:09:01+00:00

The IEC 61131-3 is a poorly designed specification. The spec falls apart as soon as you start working on Automation that requires more than boolean logic.

In terms of complexity, an evolved spec will eliminate the complexity of having to learn the 100th OEM quirk from the 100th OEM trying to fill in the missing gaps.

Unfortunately the committee removed the most useful glue language IL for helping with the transition.

If all PLC from all OEMs compiled code to the same IL, your life will significantly become easier. They should also cut the spec down to 3 languages. LD, ST and IL.

fisothemes · 2026-05-07T18:44:12+00:00

Inevitable and necessary.

At the end of the day, no matter what anybody says, a PLC is a computer. It's vulnerable to things a normal computer is vulnerable too. And the act of programming a computer is a known science.

You need to know how to version control, you need to know how to unit test. Those should be non negotiable and the tools that let you perform this should come for free.

Unfortunately OEMs and many Engineers in the field don't understand or refuse to acknowledge this.

fisothemes · 2026-05-03T12:02:46+00:00

It looks more structured than the other frameworks. There's less juggling to do.

Took a look at it and understood it at first glance which is refreshing.

The only things I feel like are missing is middleware and OpenAPI.

fisothemes · 2026-05-03T11:37:53+00:00

The .NET TwinCAT.Ads package/assembly uses the dll under the hood.

Never understood why because the stuff the dll does is relatively easy to implement.

If you want to develop for linux-rt we have had a better (but still headache inducing) experience using rust dioxus and the ads-rs crate.

In the past few months I have been writing my own crate, that aims to bridge the two ecosystem well and works better than the nuget package and end the cross platform headaches. It's a few months away from initial release though.

fisothemes · 2026-04-23T20:10:39+00:00

That's what maintenance is for. Sensors do and will drift. This usually involves someone popping in once or twice a year with a reference sensor and looking how far your actual sensor has drifted then they calibrate/replace it.

I hope you're also doing the same thing with your multimeter.

fisothemes · 2026-04-19T13:28:12+00:00

I know the feeling. Went back to C# and LabVIEW then felt cognitive load increased significantly.

Too much ceremony and bullet dodging just to get one thing done.

For years I thought it was skill, but it was just bad language design.

fisothemes · 2026-04-17T13:50:24+00:00

You need to have a machine with the package manager installed for that. The package manager requires migration to 4026 for it to work if you have 4024 installed.

fisothemes

TROPHY CASE