5 ms·

Honestly i do not understand that large SV-Companies like Amazon or Tesla not just roll out there own equipment and steam-roll this whole deprecated industry. A

Honestly i do not understand that large SV-Companies like Amazon or Tesla not just roll out there own equipment and steam-roll this whole deprecated industry. Any IDE + git is superior to almost anything they have currently shipped. (Beckhoff at least tried) I can only imagine the scene of a PLC-Programmer explaining to Elon, that instancing the exact same machine will take the exact same development time again & again. Cause using Parameter & Configfiles is not done - instead its pasted into the code. Add a Steam like Online-Software shop (Dev to Dev) to it while basically vendoring the equipment for cheap and you got the whole Eco-system cornered happily forever after. This nightmarish pre-historic dinosaurs with copy & paste monks producing software - have to go. The 80s are over.

ishikawa 5y ago
They do that on a higher level, after the PLC. But for PLC, you need something robust and is not easy for them to it just for themselves without scale.
deleted 5y ago
[deleted]
zwieback 5y ago
Our technicians, who never took a programming class, maybe never went to college, can wire up thermocouples, motors, pressure transducers, etc. Then throw together some ladder logic to make everything work. You're right about the atrocious PLC SW environment but you're proposing to elevate all those jobs to an engineering function.
- CaciaraAsAServi 5y ago
  If one wanted to be a bit sneaky, one may ask to any tech-bro: and what about you, can you wire a thermocouple?
- OneTimePetes 5y ago
  No, i do not. But i suggest having environments, that teach those technicians over time the basics and shove them towards searching for engineering knowledge for solutions and incooperate best practices. I'm violently opposed to crunching those "self-thought" to death in no-code-marathons were they are expected to realize complex behaviour with declawed software-Lego-bricks. Software is eating their world too. Have you ever seen the eyes of a guy who copy pasted a "pallet" structure together, because he never knew about arrays? PostScriptum: >Nobody wants it and the few that want it don't want >to pay for it. Control engineering really isn't a >branch of CS, its culturally its own thing. I have heard these lines a thousand times by now. Its different - we have processes that require hard "Real-time"-capable hard and software.. So.. Space X and all those other projects using hard real-time in the lower decks, are not software controlled devices? Its different -we have physical processes we control at the end of day. So a amazon package logistic center is not a physical process? A self-driving car is not a physical process? Its different, reliability is huge if the process ever fails. So Google and AWHs DevOps do not have that pressure? Its exactly this. Just another, run-down department of CS. Run-down to save a few cents and now running into the limitations its No-Code solutions impose. Grinding good, untrained people to dust, because it wants to save money. And thus ready for disruption.
  - CaciaraAsAServi 5y ago
    eh, eh, I know what you mean, but in my opinion most vendors are honestly putting effort into modernizing development practices; sure, they're the usual money-grubbers we all know and love ( not! :D ), and gatekeeping is strong, but on the other hand, the sector is so vast, you are dealing with a culture which is so dragged back by past traditions, and last but not least, one's "gatekeeping" is the other's "professionalism". Edit: Not to say that most of the times we are talking about small operations, where the PLC programmer is also electrician, plumber, chemical eng., mechanic, etc. ... We are not only talking about big corps where hyperspecialization is the norm, the bulk of the users are (literally!) jack-of-all-trades, software is only a part, and in many cases a marginal one at that. People who have to do with PLCs are IMO far, far more diverse than the other kind of software developers.
    - karmicthreat 5y ago
      Allen Bradley has 60-70% market share in the US, is objectively terrible and has been for a long time.
      - CaciaraAsAServi 5y ago
        I meant "the most advanced" vendors ;-)
        OneTimePetes 5y ago
        Our company developed for twincat3. Yes there is progress. And yes it is very slow. None the less - the inheritance & interfaces work. And the community produces great stuff - low and behold. A wild UnitTest framework for PLCs appears. https://tcunit.org/ https://tcunit.org/ Im not pessimistic. Im just realistic. This is not enough speed to keep up with something disruptive brewed within AMZ or TESLA. All they have to do is piss of a billionaire with delays one to many times..
        CaciaraAsAServi 5y ago
karmicthreat 5y ago
Nobody wants it and the few that want it don't want to pay for it. Control engineering really isn't a branch of CS, its culturally its own thing. Also, liability is a never ending hole with the actual PLC. If your web3 capable PLC keeps even 100-500K/Hr of production from running, then people will probably legally come after you. I've though several time about building a PLC ecosystem taking the best of modern systems. Building up new features to allow the actual equipment manufacturers (OEMs are under-served) to rapidly spin up and manage variants. And enough ecosystem security that at least your production systems won't be ransomwared. But unless there is a wealth person or huge company out there that just absolutely wants to fund it, it's not economically viable (If you are that company or person, contact me). The dealer networks and middlemen gatekeep the market pretty severely. You would have to essentially hand hold engineers into using it. And you are going to have a hard time selling it to risk-adverse C and D level managers.
CaciaraAsAServi 5y ago
You are partly right, but it is not so bleak, come on.[1] It is true that the average programming practices in the sector are pretty outdated, but we do have forms of code reuse like function blocks and functions, some form of code generation via the APIs of various IDEs, etc. The thing is, this sector is SO vast. (Modern) software will take quite a bit to eat this world, at least simply for its size. Industrial automation goes from smalltown electricians (this particular LOGO PLC lineup is targeted at these people), to builders of small machines still hugely relying on electro-mechanical components, to world-wide corporations, with varying levels of regulation, tolerance to risk, and so on. Not to say anything about truly advanced deployments in science projects, etc. We are basically talking about the WHOLE of what used to be called the "secondary sector of the economy", and part of the primary, AND part of the tertiary! [2] The IEC standard, the most advanced products of nearly every vendor, and the most advanced users, are going towards (sure, at their own pace, but still) modernity, but it's just a part of a vast ocean. I personally don't think I would exaggerate if I said that the variety of attitudes towards software in industrial automation is far, far greater that the one in the "normal" software industry; coupled with the other constraints expressed in other comments, that means that is not so simple for modern practices to win, they eventually will, but it will take a quite a bit. [1] many might laugh at the content, but have a look at the programming guidelines by Siemens https://support.industry.siemens.com/cs/document/81318674/programming-guidelines-and-programming-styleguide-for-simatic-s7-1200-and-s7-1500?dti=0&lc=en-WW https://support.industry.siemens.com/cs/document/81318674/pr... and while I am at it at https://www.plc-security.com https://www.plc-security.com [2] https://en.wikipedia.org/wiki/Three-sector_model https://en.wikipedia.org/wiki/Three-sector_model

ishikawa 5y ago

They do that on a higher level, after the PLC. But for PLC, you need something robust and is not easy for them to it just for themselves without scale.

deleted 5y ago

[deleted]

zwieback 5y ago

Our technicians, who never took a programming class, maybe never went to college, can wire up thermocouples, motors, pressure transducers, etc. Then throw together some ladder logic to make everything work. You're right about the atrocious PLC SW environment but you're proposing to elevate all those jobs to an engineering function.

CaciaraAsAServi 5y ago
If one wanted to be a bit sneaky, one may ask to any tech-bro: and what about you, can you wire a thermocouple?
OneTimePetes 5y ago
No, i do not. But i suggest having environments, that teach those technicians over time the basics and shove them towards searching for engineering knowledge for solutions and incooperate best practices. I'm violently opposed to crunching those "self-thought" to death in no-code-marathons were they are expected to realize complex behaviour with declawed software-Lego-bricks. Software is eating their world too. Have you ever seen the eyes of a guy who copy pasted a "pallet" structure together, because he never knew about arrays? PostScriptum: >Nobody wants it and the few that want it don't want >to pay for it. Control engineering really isn't a >branch of CS, its culturally its own thing. I have heard these lines a thousand times by now. Its different - we have processes that require hard "Real-time"-capable hard and software.. So.. Space X and all those other projects using hard real-time in the lower decks, are not software controlled devices? Its different -we have physical processes we control at the end of day. So a amazon package logistic center is not a physical process? A self-driving car is not a physical process? Its different, reliability is huge if the process ever fails. So Google and AWHs DevOps do not have that pressure? Its exactly this. Just another, run-down department of CS. Run-down to save a few cents and now running into the limitations its No-Code solutions impose. Grinding good, untrained people to dust, because it wants to save money. And thus ready for disruption.
- CaciaraAsAServi 5y ago
  eh, eh, I know what you mean, but in my opinion most vendors are honestly putting effort into modernizing development practices; sure, they're the usual money-grubbers we all know and love ( not! :D ), and gatekeeping is strong, but on the other hand, the sector is so vast, you are dealing with a culture which is so dragged back by past traditions, and last but not least, one's "gatekeeping" is the other's "professionalism". Edit: Not to say that most of the times we are talking about small operations, where the PLC programmer is also electrician, plumber, chemical eng., mechanic, etc. ... We are not only talking about big corps where hyperspecialization is the norm, the bulk of the users are (literally!) jack-of-all-trades, software is only a part, and in many cases a marginal one at that. People who have to do with PLCs are IMO far, far more diverse than the other kind of software developers.
  - karmicthreat 5y ago
    Allen Bradley has 60-70% market share in the US, is objectively terrible and has been for a long time.
    - CaciaraAsAServi 5y ago
      I meant "the most advanced" vendors ;-)
      - OneTimePetes 5y ago
        Our company developed for twincat3. Yes there is progress. And yes it is very slow. None the less - the inheritance & interfaces work. And the community produces great stuff - low and behold. A wild UnitTest framework for PLCs appears. https://tcunit.org/ https://tcunit.org/ Im not pessimistic. Im just realistic. This is not enough speed to keep up with something disruptive brewed within AMZ or TESLA. All they have to do is piss of a billionaire with delays one to many times..
        CaciaraAsAServi 5y ago

karmicthreat 5y ago

Nobody wants it and the few that want it don't want to pay for it. Control engineering really isn't a branch of CS, its culturally its own thing. Also, liability is a never ending hole with the actual PLC. If your web3 capable PLC keeps even 100-500K/Hr of production from running, then people will probably legally come after you. I've though several time about building a PLC ecosystem taking the best of modern systems. Building up new features to allow the actual equipment manufacturers (OEMs are under-served) to rapidly spin up and manage variants. And enough ecosystem security that at least your production systems won't be ransomwared. But unless there is a wealth person or huge company out there that just absolutely wants to fund it, it's not economically viable (If you are that company or person, contact me). The dealer networks and middlemen gatekeep the market pretty severely. You would have to essentially hand hold engineers into using it. And you are going to have a hard time selling it to risk-adverse C and D level managers.

CaciaraAsAServi 5y ago

You are partly right, but it is not so bleak, come on.[1] It is true that the average programming practices in the sector are pretty outdated, but we do have forms of code reuse like function blocks and functions, some form of code generation via the APIs of various IDEs, etc. The thing is, this sector is SO vast. (Modern) software will take quite a bit to eat this world, at least simply for its size. Industrial automation goes from smalltown electricians (this particular LOGO PLC lineup is targeted at these people), to builders of small machines still hugely relying on electro-mechanical components, to world-wide corporations, with varying levels of regulation, tolerance to risk, and so on. Not to say anything about truly advanced deployments in science projects, etc. We are basically talking about the WHOLE of what used to be called the "secondary sector of the economy", and part of the primary, AND part of the tertiary! [2] The IEC standard, the most advanced products of nearly every vendor, and the most advanced users, are going towards (sure, at their own pace, but still) modernity, but it's just a part of a vast ocean. I personally don't think I would exaggerate if I said that the variety of attitudes towards software in industrial automation is far, far greater that the one in the "normal" software industry; coupled with the other constraints expressed in other comments, that means that is not so simple for modern practices to win, they eventually will, but it will take a quite a bit. [1] many might laugh at the content, but have a look at the programming guidelines by Siemens https://support.industry.siemens.com/cs/document/81318674/programming-guidelines-and-programming-styleguide-for-simatic-s7-1200-and-s7-1500?dti=0&lc=en-WW https://support.industry.siemens.com/cs/document/81318674/pr... and while I am at it at https://www.plc-security.com https://www.plc-security.com [2] https://en.wikipedia.org/wiki/Three-sector_model https://en.wikipedia.org/wiki/Three-sector_model