|
|
|
|
|
|
by joelhaasnoot
5298 days ago
|
|
|
You're right, I should have quantified that statement a little better. The PLC manufacturers I'm sure have good software engineering practices. I'm just not sure the rest of the ecosystem is as developed as for instance the "web development" ecosystem, atleast from my experiences. Mind you, I do live in the Netherlands, and it seems lots of PLC systems are designed by electrical engineers who started out in that or something else and don't know about much on the Joel Test. But I can be proven wrong. A contributing factor is probably that each vendor has his/her toolkit which in some sense is proprietary, and so the market for general tools is smaller, and it's an enterprise market making it harder to sell to. |
|
|
That's probably true, given that PLCs were originally for electrical engineers as means of having "software relays". The concept of computer engineers came much later, and for computer science, they typically have zero electrical background which means that even if they program really well, it can be the case that they don't understand the physical implications of the code that they've just written.
In computer science, writing True might mean it's magically on, but in real life, a valve actually has a small delay before it physically is open. So a time delay has to be placed on the output. That's a simple example, but there are other such nuances of electrical/physical devices. Also, much of PLC programming (especially in process control) is control theory (PID controllers, essentially differential equations so that devices actuate "smoothly" instead of in a "jerky" manner). This also seems to not be covered in a CS curriculum.