6 ms·

I do a lot of PLC work. The Arduino IDE is totally unsuitable for it. No idea what they are doing about this. It would take an amazing amount of work to fix t

I do a lot of PLC work. The Arduino IDE is totally unsuitable for it. No idea what they are doing about this. It would take an amazing amount of work to fix this. As for PLC functionality people actually use, the product page says "Optional support for standard IEC 61131-3 PLC languages". This is what folks use for real. I presume this means "we didn't want to pay CodeSys but you can". Or something. That sucks. Maybe they are relying on MBed support as their basic realtime story but, as mentioned, their dev environment is unsuitable for this kind of work. There is no mention of expected scan time for ladders or guaranteed latency for anything else So for the intended market, this doesn't look interesting so far. It seems like it will go the way of the x8 and land with a huge thud. For a random person wanting an Arduino in a cabinet on a din rail, I can see maybe they'd use it.

numlock86 4y ago
The target audience is "industry/professional IoT". I guess this is mainly targeted at prototyping projects or hooking something existing up to the web with some "realtime" I/Os, giving people the opportunity to stick to 61131. Existing solutions that offer you BLE/WiFi in this sector are usually terrible and just branded routers with "industrial grade" components. This is probably not suited for or targeted at automating your next big high-runner molding machine or high-speed motion-controlled application, as you already figured out.
- readenough 4y ago
  I agree. It really helps to read the description and not just the title. I have been in industrial controls since 1980, so I'm I'm not so quick to dismiss the introduction of the next new thing. Ten years ago, when the Raspberry PI was introduced, I didn't expect to see it as the go to thin client for manufacturing floor HMIs. Yet, in some, very large and well funded plants, it is. Am I ready to put the Opta in mission critical control? No. Am I happy to see a more open option for IoT? Yes.
  - DannyBee 4y ago
    That's unfair - I read the description at length, and quite honestly, I still can't understand why i'd ever use it. It looks like buzzwords over real use-cases. The partner, Finder, is known for making these types of devices, and outside of the "Arduino" stamp, they've made a device that has been in-market (and relatievly unused) for half a decade already. This will not be a real option for IOT. For what they are trying to claim is the target, I'd either use a PLC, or to your point, i'd mount a raspberry pi or embedded arm device. As you say, the raspberry PI i understand - people need something to drive HMI/etc that isn't the horrible mess that most automation providers provide. They want something to just hook a camera up to and not worry about spending 2 years writing codesys drivers or whatever. This is trying to tread a middle ground, but the middle ground has better options - industrial PI with builtin PLC support, for example (https://www.industrialshields.com/industrial-plc-raspberry-pi-202007 https://www.industrialshields.com/industrial-plc-raspberry-p...) That's because Arduino is sort of the worst of both worlds - they are actually horrible at pretty horrible at WiFi. Bluetooth i haven't tried in a while but it was also really bad. They are okay at I/O, but nothing is guaranteed in a meaningful way. So as an option for IoT, it sucks. At a slightly higher level, NRF does a much better job of producing rock-solid devices and ecosystem that can do bluetooth/wifi well, and throw in I/O. At a lower level, everything equally sucks at wifi/bluetooth as this thing.
    - HeyLaughingBoy 4y ago
      > At a slightly higher level, NRF does a much better job of producing rock-solid devices and ecosystem that can do bluetooth/wifi well, and throw in I/O. Minor nitpick just because I want them to be credited properly. nRF is the product, nordic semiconductor is the company.
      - DannyBee 4y ago
        Yes, you are correct, i typed it too quickly.
    - readenough 4y ago
      You're right. I should not have judged like that and I apologize. What I should have said is that I have seen a lot of misplaced skepticism in this industry and I never really understood it. There is plenty of room for Arduino to enter this market and develop good products. We'll see what happens.
- Dec25IsOct31 4y ago
  Talking about Portenta, to be fair, Massimo and Arduino people IMO have done a pretty good job at characterising the product as "useful for something not extremely complex under the control/automation/engineering requirements PoV but where expanded IoT possibilities can be a huge selling point, and especially useful for systems which are serially produced". So, no process control or huge machinery, think more like mid-size ovens [https://www.arduino.cc/pro/case-studies-rinaldi-ovens https://www.arduino.cc/pro/case-studies-rinaldi-ovens] or things like this. I think the Arduino people are being very aware of the industry needs and are not being unrealistic "wahh PLCs sux lets throw them all away" kind of people ( :D ). As for me, as an industrial controls professional, I welcome these new solutions, they're another tool in my toolbox. It's up to my engineering decision to evaluate the proper usage of tools.
- DannyBee 4y ago
  Sure, I'm not sure what industry/professional IOT really means, because it's too vague. I agree the BLE/WIFI in the industrial space is a hilariosu mess, but Arduino is actually much worse at both - libraries like wifimulti_generic exist because there is no true standardized API that is useful enough, and wifi itself is fairly unreliable on lots of arduino devices - it's very easy to get them to crash just using the standard APIs. I assume this is just arduino-in-din-rail format with other words on top. I would not say anything about "industry IOT" if i was them, nobody is going to use it in the industrial space.
osigurdson 4y ago
I agree. Make this for the typical node programmer personal projects. Normal programmers don’t want to deal with that weird/yucky ladder logic and pid tuning stuff (that happens to run the world).
oytis 4y ago
My understanding of "optional support" is that you can use these languages, but might decide for other languages too. Can't see why the platform is not suited for real-time too - it would be pretty absurd to release a PLC that is not real time. To me the most interesting differentiating feature seems to be OTA updates of the firmware really.
LeifCarrotson 4y ago
An amazing amount of work is being done, apparently: From this LinkedIn post [1], they say: > It will soon add PLC IEC 61131-3 programming (full set of 5 languages) + no/code fieldbus + Arduino sketch integrated with shared variables. There will be a new Arduino PLC IDE for that. I also do a lot of PLC work. I agree that this isn't going to replace my CompactLogix, S7-1500, or Beckhoff controllers...ever. But there are times when you need to speak I2C, LIN, or CAN, or do high-speed, low voltage digital IO, and this is a way to make that happen. It competes with the AutomationDirect P1AM [2] controller, which similarly integrates an Arduino IDE with their P1000 24V and 120V industrial I/O modules. They have a "ProductivityBlocks" software, which is more of a drag-and-drop MIT Scratch like environment for people allergic to text, but no ladder. That's fine because you're not going to be using it to replace your assembly line PLC, you're going to use it to supplement your PLC to perform a function that it can't. Same story with the RevolutionPi [3] - an industrial enclosure, with DIN rail mount and 24V power, for a Raspberry Pi. This is not a replacement for a PLC, it's a way to run, say, a print server or database (which I've used it for) that talks to your PLC over PyComm, or otherwise embed some Linux executable in your machine. There are lots of things that are trivial with 30 lines of Python that are next to impossible with a traditional PLC. I recently had to integrate a temperature sensor that used a proprietary variant of I2C. The variant could be made to work using the I2C peripheral of most microcontrollers...but there was no way to get an off-the-shelf I2C adapter to work with it, you had to be constructing individual I2C frames and responding to interrupts. Things that are trivial at 48 MHz or 480 MHz are impossible at network RPIs and scan rates on the order of 10ms. I built a custom little board with a set of headers for a blue pill, spoke serial with the Beckhoff PC, and spoke this weird I2C variant with the temp sensor. I once had to measure the RPM of a brushed DC motor in-situ, with no access to anything physical, and external vibrations that made accelerometers and microphones unreliable. I built a bandpass filter and comparator circuit, connected it to the high-speed counter of a Teensy, and did some DSP to count the individual current surges as the brushes skipped over each pole of the commutators. I suppose it could have been done with thousands of dollars worth of NI cRIO DAQ gear, but there was no sensor on the market that would do it off-the-shelf, and while I was implementing a custom PCB for the analog signal filtering it was easier to add a processor onboard than integrate a third-party counter. One of my favorite projects was when I got to build a controller that fit in a cylinder the size of a hockey puck, could spin at 500 RPM, would run for a month on a 9V battery, and operated a high-precision inductance to digital AFE. There's no PLC in the world that fits that form factor, but it was comparatively easy with a microcontroller that talked to my PLC and motion control over a Renishaw wireless interface. I've built automotive lines where they were trying to use a Picoscope with a Windows PC and Rockwell PLC to get LIN data off a body module that the line assembled. The Picoscope is a nice piece of gear, but would give false negatives to parts that the actual body controller was perfectly happy with; there was something weird about the timings of the sleep/wake cycle on the particular LIN transceiver they were using in the body controller. So we used that actual LIN transceiver that was in the BCU with a Teensy, and had zero problems thereafter. [1] https://www.linkedin.com/feed/update/urn:li:activity:6996148878827778048/?commentUrn=urn%3Ali%3Acomment%3A%28activity%3A6996148878827778048%2C6996373652107616256%29 https://www.linkedin.com/feed/update/urn:li:activity:6996148... [2] https://www.automationdirect.com/adc/shopping/catalog/programmable_controllers/productivity_open_(arduino-compatible)/controllers_-a-_shields/p1am-100 https://www.automationdirect.com/adc/shopping/catalog/progra... [3] https://revolutionpi.com/ https://revolutionpi.com/
faxmeyourcode 4y ago
Off topic, but this is the first time I've seen PLC mentioned on HN. Is there a well known path from transitioning from a normal style of "software engineering" job that isn't embedded focused, and into the PLC/industrial automation field? I have family working in chemical engineering plants and I think the machinery is badass. I feel like I would like a PLC job but I don't know where to begin. From the other comments in the thread, I'm guessing starting on this new Arduino PLC might not be the best?
- tehf0x 4y ago
  Also interested, I've always wondered what "the book" would be to learn to make a nice proper industrial control cabinet (PLCs, wiring, components etc.)
  - Gracana 4y ago
    I’m not sure if there’s a The Book (probably though… look for industrial automation course materials); I mostly learned by example, by reading standards (check out NFPA 79 “electrical standard for industrial machinery”), and by reading automation vendor literature.
- mediaman 4y ago
  The industry does not have a great reputation. You will make less money and in worse working conditions, likely with more travel. The machines are cool. Automation Direct has some starter PLCs that are in the hundreds of dollars, and they have good enough reputations (though you will find shops that turn up their nose at AD). That'll be enough to learn ladder logic. And you can buy servos or steppers and learn motion control as well. It'll be difficult to get a job without experience at first, but talent is short and you might be able to convince someone to do entry-level work with the material you taught yourself. And then it gets easier. But you might start missing your old software engineering job.
dfox 4y ago
My experience from integrating various automation systems (typically large-ish roller conveyor systems) is that often IEC 61131 languages are actually detrimental to productivity of the PLC programmers. It is this weird turing tarpit where anything that can be expressed as ladder logic is simple and point an click (modulo the horrible UI/UX of every single PLC IDE) but anything more complex than that is huge pain because you are constantly fighting against the dumbed-down programming model and constantly reimplementing simple algorithms that are part of standard library in essentially any other programming ecosystem. And that is just for the control of moderately complex process (eg. tracking positions of unit loads on the conveyor), any kind of communication with external world (which tends to be event based) is horrible mess in order for it to fit into the cycle based model (and the argument that it gives you predictable and consistent latency is pure hogwash, the cycle time jitter caused by branching and other threads running on the PLC's CPU tends to be huge, at least on S7-300/1200/1500).
- Gracana 4y ago
  Yeah, at my last job I had a similar realization. I went in agreeing with the conventional wisdom that you have to use ladder logic so that techs and customers ands other engineers can understand and work on your program. In reality, modern machinery (with networks and servo motion and smart sensors etc) is wildly complex. In seven years I didn’t meet a single customer or technician who felt comfortable making program modifications, and even qualified engineers would struggle to learn the ins and outs of an unfamiliar program. Ladder logic just didn’t provide the benefits that folks claimed were the reason we used it.
  - dfox 4y ago
    One thing that I have noticed is that often in the PLC projects done by seasoned automation engineers the logic that would make sense to be represented as LD is written directly as IL spaghetti code. I assume that this has to do with general unwieldiness of the LD editors in the vendors' IDEs. AFAIK the original idea behind LD is that you can do it on paper, and then hand-assemble the “bytecode” for the PLC and just manually key that into the PLC on some sort of octal/hexadecimal keypad without any kind of computer-like programming device. Obviously, this idea does not translate to present world with cheap and ubiquitous general purpose computers.
Alupis 4y ago
> The Arduino IDE is totally unsuitable for it No one that uses the Arduino library/hardware/ecosystem on a serious level actually uses the Arduino IDE - for what it's worth. The Arduino IDE is supposed to be for beginners to get started really easy. For everyone else, use what you want... be it vendor IDE's (ie. Atmel Studio), PlatformIO (for your favorite IDE), etc. There's nothing special about Arduino that requires using it's official IDE.

numlock86 4y ago

The target audience is "industry/professional IoT". I guess this is mainly targeted at prototyping projects or hooking something existing up to the web with some "realtime" I/Os, giving people the opportunity to stick to 61131. Existing solutions that offer you BLE/WiFi in this sector are usually terrible and just branded routers with "industrial grade" components. This is probably not suited for or targeted at automating your next big high-runner molding machine or high-speed motion-controlled application, as you already figured out.

readenough 4y ago
I agree. It really helps to read the description and not just the title. I have been in industrial controls since 1980, so I'm I'm not so quick to dismiss the introduction of the next new thing. Ten years ago, when the Raspberry PI was introduced, I didn't expect to see it as the go to thin client for manufacturing floor HMIs. Yet, in some, very large and well funded plants, it is. Am I ready to put the Opta in mission critical control? No. Am I happy to see a more open option for IoT? Yes.
- DannyBee 4y ago
  That's unfair - I read the description at length, and quite honestly, I still can't understand why i'd ever use it. It looks like buzzwords over real use-cases. The partner, Finder, is known for making these types of devices, and outside of the "Arduino" stamp, they've made a device that has been in-market (and relatievly unused) for half a decade already. This will not be a real option for IOT. For what they are trying to claim is the target, I'd either use a PLC, or to your point, i'd mount a raspberry pi or embedded arm device. As you say, the raspberry PI i understand - people need something to drive HMI/etc that isn't the horrible mess that most automation providers provide. They want something to just hook a camera up to and not worry about spending 2 years writing codesys drivers or whatever. This is trying to tread a middle ground, but the middle ground has better options - industrial PI with builtin PLC support, for example (https://www.industrialshields.com/industrial-plc-raspberry-pi-202007 https://www.industrialshields.com/industrial-plc-raspberry-p...) That's because Arduino is sort of the worst of both worlds - they are actually horrible at pretty horrible at WiFi. Bluetooth i haven't tried in a while but it was also really bad. They are okay at I/O, but nothing is guaranteed in a meaningful way. So as an option for IoT, it sucks. At a slightly higher level, NRF does a much better job of producing rock-solid devices and ecosystem that can do bluetooth/wifi well, and throw in I/O. At a lower level, everything equally sucks at wifi/bluetooth as this thing.
  - HeyLaughingBoy 4y ago
    > At a slightly higher level, NRF does a much better job of producing rock-solid devices and ecosystem that can do bluetooth/wifi well, and throw in I/O. Minor nitpick just because I want them to be credited properly. nRF is the product, nordic semiconductor is the company.
    - DannyBee 4y ago
      Yes, you are correct, i typed it too quickly.
  - readenough 4y ago
    You're right. I should not have judged like that and I apologize. What I should have said is that I have seen a lot of misplaced skepticism in this industry and I never really understood it. There is plenty of room for Arduino to enter this market and develop good products. We'll see what happens.
Dec25IsOct31 4y ago
Talking about Portenta, to be fair, Massimo and Arduino people IMO have done a pretty good job at characterising the product as "useful for something not extremely complex under the control/automation/engineering requirements PoV but where expanded IoT possibilities can be a huge selling point, and especially useful for systems which are serially produced". So, no process control or huge machinery, think more like mid-size ovens [https://www.arduino.cc/pro/case-studies-rinaldi-ovens https://www.arduino.cc/pro/case-studies-rinaldi-ovens] or things like this. I think the Arduino people are being very aware of the industry needs and are not being unrealistic "wahh PLCs sux lets throw them all away" kind of people ( :D ). As for me, as an industrial controls professional, I welcome these new solutions, they're another tool in my toolbox. It's up to my engineering decision to evaluate the proper usage of tools.
DannyBee 4y ago
Sure, I'm not sure what industry/professional IOT really means, because it's too vague. I agree the BLE/WIFI in the industrial space is a hilariosu mess, but Arduino is actually much worse at both - libraries like wifimulti_generic exist because there is no true standardized API that is useful enough, and wifi itself is fairly unreliable on lots of arduino devices - it's very easy to get them to crash just using the standard APIs. I assume this is just arduino-in-din-rail format with other words on top. I would not say anything about "industry IOT" if i was them, nobody is going to use it in the industrial space.

osigurdson 4y ago

I agree. Make this for the typical node programmer personal projects. Normal programmers don’t want to deal with that weird/yucky ladder logic and pid tuning stuff (that happens to run the world).

oytis 4y ago

My understanding of "optional support" is that you can use these languages, but might decide for other languages too. Can't see why the platform is not suited for real-time too - it would be pretty absurd to release a PLC that is not real time. To me the most interesting differentiating feature seems to be OTA updates of the firmware really.

LeifCarrotson 4y ago

An amazing amount of work is being done, apparently: From this LinkedIn post [1], they say: > It will soon add PLC IEC 61131-3 programming (full set of 5 languages) + no/code fieldbus + Arduino sketch integrated with shared variables. There will be a new Arduino PLC IDE for that. I also do a lot of PLC work. I agree that this isn't going to replace my CompactLogix, S7-1500, or Beckhoff controllers...ever. But there are times when you need to speak I2C, LIN, or CAN, or do high-speed, low voltage digital IO, and this is a way to make that happen. It competes with the AutomationDirect P1AM [2] controller, which similarly integrates an Arduino IDE with their P1000 24V and 120V industrial I/O modules. They have a "ProductivityBlocks" software, which is more of a drag-and-drop MIT Scratch like environment for people allergic to text, but no ladder. That's fine because you're not going to be using it to replace your assembly line PLC, you're going to use it to supplement your PLC to perform a function that it can't. Same story with the RevolutionPi [3] - an industrial enclosure, with DIN rail mount and 24V power, for a Raspberry Pi. This is not a replacement for a PLC, it's a way to run, say, a print server or database (which I've used it for) that talks to your PLC over PyComm, or otherwise embed some Linux executable in your machine. There are lots of things that are trivial with 30 lines of Python that are next to impossible with a traditional PLC. I recently had to integrate a temperature sensor that used a proprietary variant of I2C. The variant could be made to work using the I2C peripheral of most microcontrollers...but there was no way to get an off-the-shelf I2C adapter to work with it, you had to be constructing individual I2C frames and responding to interrupts. Things that are trivial at 48 MHz or 480 MHz are impossible at network RPIs and scan rates on the order of 10ms. I built a custom little board with a set of headers for a blue pill, spoke serial with the Beckhoff PC, and spoke this weird I2C variant with the temp sensor. I once had to measure the RPM of a brushed DC motor in-situ, with no access to anything physical, and external vibrations that made accelerometers and microphones unreliable. I built a bandpass filter and comparator circuit, connected it to the high-speed counter of a Teensy, and did some DSP to count the individual current surges as the brushes skipped over each pole of the commutators. I suppose it could have been done with thousands of dollars worth of NI cRIO DAQ gear, but there was no sensor on the market that would do it off-the-shelf, and while I was implementing a custom PCB for the analog signal filtering it was easier to add a processor onboard than integrate a third-party counter. One of my favorite projects was when I got to build a controller that fit in a cylinder the size of a hockey puck, could spin at 500 RPM, would run for a month on a 9V battery, and operated a high-precision inductance to digital AFE. There's no PLC in the world that fits that form factor, but it was comparatively easy with a microcontroller that talked to my PLC and motion control over a Renishaw wireless interface. I've built automotive lines where they were trying to use a Picoscope with a Windows PC and Rockwell PLC to get LIN data off a body module that the line assembled. The Picoscope is a nice piece of gear, but would give false negatives to parts that the actual body controller was perfectly happy with; there was something weird about the timings of the sleep/wake cycle on the particular LIN transceiver they were using in the body controller. So we used that actual LIN transceiver that was in the BCU with a Teensy, and had zero problems thereafter. [1] https://www.linkedin.com/feed/update/urn:li:activity:6996148878827778048/?commentUrn=urn%3Ali%3Acomment%3A%28activity%3A6996148878827778048%2C6996373652107616256%29 https://www.linkedin.com/feed/update/urn:li:activity:6996148... [2] https://www.automationdirect.com/adc/shopping/catalog/programmable_controllers/productivity_open_(arduino-compatible)/controllers_-a-_shields/p1am-100 https://www.automationdirect.com/adc/shopping/catalog/progra... [3] https://revolutionpi.com/ https://revolutionpi.com/

faxmeyourcode 4y ago

Off topic, but this is the first time I've seen PLC mentioned on HN. Is there a well known path from transitioning from a normal style of "software engineering" job that isn't embedded focused, and into the PLC/industrial automation field? I have family working in chemical engineering plants and I think the machinery is badass. I feel like I would like a PLC job but I don't know where to begin. From the other comments in the thread, I'm guessing starting on this new Arduino PLC might not be the best?

tehf0x 4y ago
Also interested, I've always wondered what "the book" would be to learn to make a nice proper industrial control cabinet (PLCs, wiring, components etc.)
- Gracana 4y ago
  I’m not sure if there’s a The Book (probably though… look for industrial automation course materials); I mostly learned by example, by reading standards (check out NFPA 79 “electrical standard for industrial machinery”), and by reading automation vendor literature.
mediaman 4y ago
The industry does not have a great reputation. You will make less money and in worse working conditions, likely with more travel. The machines are cool. Automation Direct has some starter PLCs that are in the hundreds of dollars, and they have good enough reputations (though you will find shops that turn up their nose at AD). That'll be enough to learn ladder logic. And you can buy servos or steppers and learn motion control as well. It'll be difficult to get a job without experience at first, but talent is short and you might be able to convince someone to do entry-level work with the material you taught yourself. And then it gets easier. But you might start missing your old software engineering job.

dfox 4y ago

My experience from integrating various automation systems (typically large-ish roller conveyor systems) is that often IEC 61131 languages are actually detrimental to productivity of the PLC programmers. It is this weird turing tarpit where anything that can be expressed as ladder logic is simple and point an click (modulo the horrible UI/UX of every single PLC IDE) but anything more complex than that is huge pain because you are constantly fighting against the dumbed-down programming model and constantly reimplementing simple algorithms that are part of standard library in essentially any other programming ecosystem. And that is just for the control of moderately complex process (eg. tracking positions of unit loads on the conveyor), any kind of communication with external world (which tends to be event based) is horrible mess in order for it to fit into the cycle based model (and the argument that it gives you predictable and consistent latency is pure hogwash, the cycle time jitter caused by branching and other threads running on the PLC's CPU tends to be huge, at least on S7-300/1200/1500).

Gracana 4y ago
Yeah, at my last job I had a similar realization. I went in agreeing with the conventional wisdom that you have to use ladder logic so that techs and customers ands other engineers can understand and work on your program. In reality, modern machinery (with networks and servo motion and smart sensors etc) is wildly complex. In seven years I didn’t meet a single customer or technician who felt comfortable making program modifications, and even qualified engineers would struggle to learn the ins and outs of an unfamiliar program. Ladder logic just didn’t provide the benefits that folks claimed were the reason we used it.
- dfox 4y ago
  One thing that I have noticed is that often in the PLC projects done by seasoned automation engineers the logic that would make sense to be represented as LD is written directly as IL spaghetti code. I assume that this has to do with general unwieldiness of the LD editors in the vendors' IDEs. AFAIK the original idea behind LD is that you can do it on paper, and then hand-assemble the “bytecode” for the PLC and just manually key that into the PLC on some sort of octal/hexadecimal keypad without any kind of computer-like programming device. Obviously, this idea does not translate to present world with cheap and ubiquitous general purpose computers.

Alupis 4y ago

> The Arduino IDE is totally unsuitable for it No one that uses the Arduino library/hardware/ecosystem on a serious level actually uses the Arduino IDE - for what it's worth. The Arduino IDE is supposed to be for beginners to get started really easy. For everyone else, use what you want... be it vendor IDE's (ie. Atmel Studio), PlatformIO (for your favorite IDE), etc. There's nothing special about Arduino that requires using it's official IDE.