5 ms·

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 fo

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
        > All they have to do is piss of a billionaire with delays one to many times.. ...and nobody will follow their lead [as quickly as you comment seems to suggest]. I've just come out from a discussion with a customer (young guy, circa 30, not a "boomer"), head of a major wastewater treatment plant in my circa 4 million ppl. metro area...he doesn't trust software, he would rather put relays everywhere and go on like that. The problem is not only the velocity of those who produce the systems, it is also the mentality at the end users' side. This is why I say that the transition will be slower than it could be; there are so many parts involved. If it only were a problem of "rate of innovation produced per unit of time" I would 100% agree with you (and not only 50% as I do :-) ) (BTW, any industrial automation person living in Northern Italy: be wary when working for the company whose name is like "ZIP code" in Italian, there is lots of work to do there, but the technical org is suuuuuch a mess)
zwieback 5y ago
I didn't write what you quoted but, okay, nice rant. I think we need to distinguish SpaceX, Tesla, Amazon, where of course highly qualified embedded systems engineers are needed from the guy in Kansas automating some straightforward production tools. Horses for courses.

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
      > All they have to do is piss of a billionaire with delays one to many times.. ...and nobody will follow their lead [as quickly as you comment seems to suggest]. I've just come out from a discussion with a customer (young guy, circa 30, not a "boomer"), head of a major wastewater treatment plant in my circa 4 million ppl. metro area...he doesn't trust software, he would rather put relays everywhere and go on like that. The problem is not only the velocity of those who produce the systems, it is also the mentality at the end users' side. This is why I say that the transition will be slower than it could be; there are so many parts involved. If it only were a problem of "rate of innovation produced per unit of time" I would 100% agree with you (and not only 50% as I do :-) ) (BTW, any industrial automation person living in Northern Italy: be wary when working for the company whose name is like "ZIP code" in Italian, there is lots of work to do there, but the technical org is suuuuuch a mess)

zwieback 5y ago

I didn't write what you quoted but, okay, nice rant. I think we need to distinguish SpaceX, Tesla, Amazon, where of course highly qualified embedded systems engineers are needed from the guy in Kansas automating some straightforward production tools. Horses for courses.