Posted by PackagingControls_Tim | 6 days ago

We're designing controls for a new pharmaceutical packaging line that needs to hit 600 bottles per minute and I'm trying to figure out the best way to structure the ST code in our Beckhoff setup. I've always done ladder for packaging but our new lead engineer is pushing everyone toward Structured Text for better readability and maintenance. My concern is performance - at those speeds we're talking like 100ms per bottle cycle and I don't want sloppy code slowing things down. For those of you doing high-speed packaging in ST, how do you organize your programs? Do you use function blocks for everything or is that overkill? Also any gotchas I should know about coming from a ladder background?

Reply by CodesysExpert_Maria | 5 days ago

Tim you're definitely going to want FBs for anything that's reusable across multiple stations - conveyors, reject mechanisms, gates, etc. The key is keeping your main program super lean and just calling the FBs with the right parameters. At 600 BPM you've got around 100ms per cycle like you said, but your PLC scan time should still be way faster than that, probably 2-5ms depending on your CPU. Where people screw up is doing complex calculations or string operations in the fast execution path - move that stuff to slower cyclic tasks if possible. We run a similar speed line and our main program is basically just state machines calling pre-tested FBs, works great. Also use CASE statements instead of nested IF-THEN-ELSE, way more readable and the compiler optimizes them better.

Reply by BeckhoffGuru_Steve | 5 days ago

Coming from ladder to ST is gonna feel weird at first but you'll never want to go back once you get it. One huge thing - avoid using global variables everywhere like people do in ladder, it becomes a maintenance nightmare fast. Pass everything as inputs/outputs to your FBs so you know exactly what's affecting what. For high speed stuff I'd also recommend splitting your code into different tasks based on priority - your critical motion control and I/O should be in a fast task (2ms or less), product tracking and recipe management can be in a slower task (10-20ms), and HMI updates even slower (100ms+). Don't try to do everything in one task or you'll have jitter problems. Also profile your code execution times in TwinCAT, there's built-in tools for that and you'd be surprised what functions eat up cycles.

Reply by pharma_automation_jen | 4 days ago

Since you mentioned pharmaceutical I have to ask - are you doing 21 CFR Part 11 validation? Because that changes how you structure everything, you need rock solid audit trails and version control. We use a lot of enumerated types instead of integers for states and modes because it makes the code way more obvious during validation reviews - like "eState.Filling" instead of "State = 3". Also document EVERYTHING with comments, your validation team will love you for it. For the actual packaging logic, we use a master state machine that coordinates all the individual station FBs, and each station has its own internal state machine. Sounds complicated but it's actually super clean once you get used to it. Make sure you have proper error handling too, not just setting a fault bit but actually useful diagnostics that tell operators what's wrong.

Reply by PackagingControls_Tim | 4 days ago

Maria that makes sense about keeping the main program lean, I was planning on putting everything in there like I would with ladder but I can see how that would get ugly fast. Steve the multi-task approach is interesting, we're using TwinCAT 3 so I should be able to set that up pretty easily. Jen yeah we're definitely doing Part 11 validation which is part of why they want ST instead of ladder - supposedly easier to review. The enumerated types tip is gold, I hadn't thought of that. Do you guys use any specific naming conventions? I've seen some people do Hungarian notation and others just descriptive names, not sure what's considered best practice in the industry.

Reply by CodesysExpert_Maria | 3 days ago

Naming conventions are almost religious wars in this field lol but here's what works for us. Function blocks get "FB_" prefix, like FB_ConveyorControl. Instances of FBs are lowercase with the machine section, like "fbInfeedConveyor" or "fbFillerStation2". Inputs start with "i", outputs with "o", so you get stuff like "iBottlePresent" and "oRejectCylinder". Booleans should be questions that read naturally - "bIsBottlePresent" not "bBottle". Keeps the code readable when you're writing IF bIsBottlePresent THEN. Also we prefix all our packaging line code with the line number so when you've got 5 lines in one plant you know what you're looking at. Don't get too crazy with it though, I've seen systems where every variable has like 8 character prefixes and it's impossible to read.

Reply by MotionControlDan | 2 days ago

One thing I haven't seen mentioned - if you're doing any servo coordination for your packaging (and at 600 BPM you probably are), keep your motion control code completely separate from your logic code. Use MC_MoveAbsolute, MC_MoveVelocity etc and don't try to get cute with custom motion algorithms unless you really know what you're doing. Also invest time in a good simulation environment, we use a digital twin in TwinCAT and it's saved us so much commissioning time. You can test all your ST logic before you ever get to the machine. Last thing - use version control like Git from day one, not that garbage built-in version system in TwinCAT. You'll thank me later when someone asks "what changed between v2.3 and v2.4 that broke the reject station.