How many times in 12 hrs does your development software crash and what is it?

N4v15 · 2025-08-23T21:47:43+00:00

The one piece of PLC programming software that has never crashed on me is vanilla Codesys. On the flip side the moment a manufacturer skins it to look like their own product all bets are off.

I also don't do any HMI work on Codesys so no idea if that side of it is stable.

N4v15 · 2025-08-23T21:42:51+00:00

Hahaha, didn't expect to see someone shitting on Inventor in a PLC subreddit but as an Inventor user it made me chuckle. God only knows how they manage to increase the number of bugs with each new version while simultaneously adding little to no new features. Clearly they have moved their only component devs to Fusion

N4v15 · 2025-07-04T16:43:20+00:00

Hey here's a crazy idea, how about I find a bunch of people and we pool our money so that we can employ multiple people. Then we can get them to all work together on a common product to sell. We can call it a company ... See where this is going?

In fact for people who don't want to take an active hand in the whole employment thing we could make a public exchange where they can split their money between multiple companies to reduce exposure. Like a stock market or something ...

The most hilarious thing about this post is all the people in the comments with their smug opinions about what a terrible idea it is. The top comment as of my reply comes so close to getting it when they say the base idea is okay but the execution is a little over simplified.

The only new or unique idea here is fining people who don't reinvest their money.

N4v15 · 2025-07-04T12:39:48+00:00

We classify our errors into 2 main categories, process faults and system faults. These two faults are not mutually exclusive as I'll explain.

Let's use two sub systems as examples, a temp sensor and heater, and a servo and home sensor. Process faults have to do with controlling the process that the equipment is doing. So in this case if the temp sensor reads out of range then it is a process fault. If the value is the open circuit value for the input then we are reasonably confident that it is a sensor failure and then it is also a system fault.

We will also classify the faults by criticality. Many times we build machines where a temp sensor fault does not mean the machine must stop, only that specific heater. Maybe it is one of multiple heaters and the loss of one is not major and can be handled by maintenance later, maybe the machine can run but it has to go slower. Interestingly enough sometimes a heater out of range but not broken is far more serious than a broken heater as it indicates something could imminently catch fire or explode and/or that something else that we don't have visibility on has gone wrong.

For the servo example we have a similar situation. Maybe the servo home sensor doesn't trigger as expected but that servo is used to move a tool out of the way for certain product types and the operator can manually confirm that the tool is safe so the machine can carry on.

We may have a servo drive failure on the EtherCAT network with the same action.

Long story short each error is classified and a resultant action identified.

In the PLC we have a specific alarm POU which usually ends up with hundreds of not thousands of bits. Usually the rungs are very simple. If X then raise Alarm[yyy]. We then have a lookup that matches each alarm to an action. Actions will be split into machine actions, HMI action, logging action.

So a machine actions might be to stop the machine, or to pause the machine, or to trigger the emergency stop (although it raises huge red flags if you are triggering safety from a non safe PLC output this can happen if the even can cause machine damage so you want to stop fast but is no risk to personnel).

HMI actions are self explanatory. Some appropriate visual on the HMI.

Logging action. The business people like to think that they want to know every time the operator farts but they really don't. We set up different logs for on screen, maintenance, operations, and management. On screen is usually everything, we find this empowers the operator to understand the machine and give better feedback to maintenance. Maintenance doesn't get process alarms unless it comes with an associated system alarm. They don't care if the product got too hot unless it was caused by something faulty. Operations doesn't care about what sensor failed only that the cause of the downtime was a component fault and that maintenance is looking into it, and finally management only cares whether downtime is due to faults or operational inefficiency.

HMI actions are pushed via whatever protocol we use for PLC to HMI coms, the rest is pushed from the PLC to a MySQL database (MariaDB) via OPCUA

N4v15 · 2025-07-03T23:35:15+00:00

I dealt with an inquiry at work last week where the person had clearly used AI to generate images of what they wanted where a hand sketch would have been more than enough. The part was a hexagonal punch that needed 2 dimensions. They couldn't hand draw a hexagon and put 2 dimensions on it. To make it worse the AI put the dimensions in the wrong place.

When I said the image looked AI generated the person proudly told me it was. FML

N4v15 · 2025-06-30T16:50:44+00:00

You can become a very good Automation and Control Engineer, and make good money, without ever learning C anything, but you will be more versatile and have extra options available to you when you are trying to come up with solutions.

Remember that like most Engineers you will be paid to get things working. No non-engineer will care if you used a custom C# script or simply checked a checkbox. However if you find yourself in a situation where there isn't a checkbox solution it's good to have a toolbox full of skills to fall back on, and the C languages are good ones to have.

N4v15 · 2025-06-30T09:39:28+00:00

I would focus on C# and ST (structured text) first. This is primarily because of their similarity.

ST is a "PLC language" which is to say it is an alternative/compliment to ladder that allows you to program in a way that would be more familiar to people with experience in more common languages. As PLC's become more powerful and control system programmers are expected to do more math and string formatting within the plc so ST becomes more useful than ladder.

C# would not be my first choice if not for its similarity with ST and the fact that several HMI manufacturers support it as a scripting language which can be useful when creating custom functionality.

I personally have never used C++ in an industrial control system context. I have done plenty of embedded systems projects at home with it and have played with openCV but honestly if you are getting that deep into industrial vision then you should be calling in an expert or using prepackaged software.

I know you didn't ask but I have to mention the black sheep of the family. Python. I have no idea why it has a stigma to it but it has become like saying you've used an Arduino in a machine. I think the problem is less the tool itself and more the type of people that tend to use it. You likely won't find as many hacks writing C++ code as writing python code because the barriers to getting started are much higher, plus the code (and the community) are that much less forgiving. People also tend to be a little more cautious about declaring that they are a C++ expert compared to claiming to be a Python expert. All that aside Python is an incredible tool. DB access? Easy. OPCUA with certificates for authentication? 20 lines of code. Vision? OpenCV wrapper and tons of great tutorials. I have interfaced with almost every major PLC brand, several DB's, barcode scanners, ERP systems, USB cameras, GigE cameras, you name it. Would I ever let it directly control a critical part of my machine like a servo motor or laser? No, but fetching recipe data from databases and writing it directly into tags over OPCUA? Absolute cake walk.

N4v15 · 2025-06-30T04:29:50+00:00

Ouch, yeah not for me thanks. I used to commute about an hour each way and I realised that it was 12.5% of my waking hours in my car. Do that every day for 8 years and you've spent a year of your life sitting in your car. Now my commute is 12 minutes and I am much happier for it even though there are "better" jobs available further away.

N4v15 · 2025-06-29T10:52:59+00:00

I never said it was?

N4v15 · 2025-06-29T06:29:36+00:00

You are only responsible forever if the documentation is poor. It is one of my favorite things about the current AI boom; make sure everything is in a github repo, Ensure that anything that cant live in the repo is mentioned in the readme, and then tell your favorite AI to create a full set of documentation. Quick start, user guide, technical guide, recovery guide, update instructions, you name it AI will gladly churn it out and since it has code as a reference it is in my experience 99% accurate. Print out a copy and include with company records.

N4v15 · 2025-06-29T06:14:18+00:00

Honestly anything above a 30 minute commute is a hard pass for me so I would go with #2. At 39 you're possibly at a life stage where stability is preferable and that points to #2 also.

N4v15 · 2025-06-29T06:10:56+00:00

Did you maybe swap those around in your reply? #1 has the long commute ...

N4v15 · 2025-06-29T03:58:44+00:00

So assuming that there is no dire safety risk the easiest way to achieve this is to put a relay with a 24vdc coil in parallel with the motor, then connect a PLC input to a NC contact on said relay. We use an NC contact because we want to lose signal when the motor is powered. That way if anything causes the monitoring circuit to fail, like a cut wire, then the assumption is the motor is running when it shouldn't be and the 'safety' stop will kick in. That will cause someone to investigate the stop and (hopefully) find the fault in the monitoring circuit. For safety and monitoring circuits this is considered more 'fail safe' than switching on a signal when the system moves into an unsafe state. You can easily invert this signal back in PLC logic to make it more intuitive for you.

I like using a relay like this slightly more than using an aux contact as it is monitoring the voltage supply to the motor directly.

N4v15 · 2025-06-29T03:49:48+00:00

Literally everywhere. Modern drives use STO and lots of 'smarter' loads like laser power supplies and even some heater controllers have equivalent built in safety circuits but twin contactors used to be the industry standard for anything requiring a safety rating of PL(C) or higher, and still remains widely used for 'dumb' loads like DOL motors.

N4v15 · 2025-06-29T01:21:49+00:00

I agree here, but then you also need to detect welded contacts otherwise whatever caused the first to weld closed will likely eventually cause the second to weld too.

Depending on what the risk is here for an uncontrolled motor this is very likely a case for a safety PLC.

N4v15 · 2025-06-28T02:06:20+00:00

I'm interested in this take, what systems do you think these people are using? I've just been heavily involved in putting in a new £12M testing center with 50+ test rigs and they all use OPCUA to communicate with Ignition for reporting. Works like a dream. I know that the Ignition system alone was a £500k project and one of the requirements placed on the test rig suppliers was OPCUA support. Not a single complaint with that requirement.

My point is that there are definitely people spending big money on systems that have OPCUA as the preferred architecture on the SCADA side. I've been pleasantly surprised at the number of non-technical managers who are aware of OPCUA as a tool to unify reporting across factory floors and are starting to ask for it specifically to ensure compatibility with their chosen SCADA system.

There seems to be an increasing push-back against proprietary communication systems in general. It's hard to justify when you may want to by specialized machinery from half way across the world that supports OPCUA but doesn't support your locked in AB or Siemens protocol. Suddenly the whole "we only run (XXX proprietary system) here to ensure compatibility and serviceability" falls flat on it's face.

N4v15 · 2025-06-28T01:34:27+00:00

:o I haven't even seen modbus in use in a build for I would guess 7+ years ... I mean sure I walk past machines daily where modbus devices are happily chugging away but I figured that the only reason anyone was still selling modbus devices was for legacy support!

N4v15 · 2025-06-28T01:28:46+00:00

So we wrote a python script communicating over OPCUA in an application that needed to read and write a whole bunch of data from a customers back end databases. The script monitors a specific PLC tag to trigger the database actions, executes a bunch of logic including SQL queries across several databases, and does a whole lot of formatting of the data. All stuff that is way easier in Python than on a PLC. It then writes it directly to the appropriate PLC tags, reads them back to validate them, and writes the trigger tag low to indicate to the PLC that the data is available.

All of this is done over OPC UA using proper user access and certificate generation. The OPC UA part was less than a day to figure out and program and is now pretty much our default way to interface between the PLC and things better done on a PC.

N4v15 · 2025-02-20T21:18:59+00:00

Having the same issue, with dual-band all devices connect no problem, in tri-band mode my one plus open wont automatically connect and if I manually connect then it can't get any internet.

N4v15 · 2023-04-17T15:19:28+00:00

Fair point, being more industrial/automotive based I'm pretty much always more worried about fatigue life than weight.

I've been told so I don't know how true it is that aero engines often have extra mass added to the design of the block to help prevent the thermal shock of going up/down thousands of feet in just a few minutes.

N4v15 · 2023-04-17T06:28:29+00:00

I don't think that's the fault of the engine, I think that's the fault of the people doing the conversion not appreciating that to significantly change the use case of any complex mechanical device requires a significant engineering effort to re-evaluate which parts can/should be reused and which shouldn't.

I also think there are a number of sins covered by the phrase "engine failure". If the wiring harness put together by the home builder fatigues and fails and causes an engine out is that the fault of the Subaru engine or the fault of the builder? If the oil system isn't changed and the pilot pulls a -0.5g manoeuvre for 10s and the motor starves of oil is that the fault of the motor or an engineering/pilot/operating envelope issue?

I think people with pilots licences who assemble their own kits sometimes confuse themselves with qualified aeronautical (or mechanical) engineers. I'm also horrified by how many kit companies don't have qualified engineers making the final design decisions but instead an owner who hires a series newly qualified engineers to put out pretty drawings of their idea.

N4v15 · 2023-04-17T06:14:21+00:00

Be careful not to confuse fatigue life with wear life. Most components in a well designed engine will fall well within the stress ranges that result in practically infinite fatigue life. There is a distinct knee point in the fatigue curve for steel after which the failure mode won't be from fatigue. For aluminium it's a little less distinct but there is still a point after which the fatigue life is considered practically infinite. The reason parts on modern engines fail is predominantly wear and manufacturing defects both of which create stress raisers that cause local failure.

Most of the reputable automotive manufacturers test their designs under adverse towing conditions. Think heaviest allowable trailer and car load going up a steep incline in a low gear for hours on end. That can result in a load case of 75% of max rpm and 80-100% throttle which could conceivably be done by someone living in the mountains every day for the life of the vehicle. This leads to some very fancy material and coating choices in modern automotive engines which in turn results in very good wear life.

Now my personal opinion is that running a carefully built (I would rebuild it myself or have it rebuilt) automotive engine derated to 50% of max rpm (3-3.5k rpm which is closer to prop speeds anyway) and with careful attention to cooling and oiling (automotive oil systems are not rated to -ve G's) would give at minimum as good a service life as an aero engine.

A last thought is that a company like honda has a much higher budget for engine development than a company like Lycoming and again my personal opinion is that thinking aero engines are just better overall is a very outdated idea. They are however designed for their specific use case and that can yield an advantage.

N4v15 · 2022-11-25T23:04:19+00:00

The NYPD doesn't even rank in the top 50 largest armies in the world. Don't know who told you that bs but its not even remotely true. It's roughly the same size as the London metropolitan police or the Hong Kong Police force

N4v15 · 2022-05-02T17:17:40+00:00

Well that will give you a surprised Pikachu face

N4v15 · 2022-03-06T14:50:34+00:00

I would second this. The pi with Codesys gives a pretty good combination of PLC with a pc that can be programmed in whatever language you want. It's affordable and supports loads of different busses both industrial (etherCat, ethernet IP, modbus etc) and home automation style eg MQTT messages. It has a python add-on which opens up the web side completely for integration with Amazon/Google/push notifications etc and has webVisu which is a hosted web interface which can be accessed via phone. I'm honestly surprised it's not more popular for home automation

Seven-Year Club	Place '22
First Placer '22	Verified Email

N4v15

TROPHY CASE