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.

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.

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-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.

> 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.

Yes, you are correct, i typed it too quickly.

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.

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.

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).

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.

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:6996148...

[2] https://www.automationdirect.com/adc/shopping/catalog/progra...

[3] https://revolutionpi.com/

Lead engineer for P1AM here. You're definitely right P1AM is not going to replace every PLC around. We've seen several applications, like you've mentioned, where it's used as a supplement to a traditional PLC. We've also seen many customers start to use it as their go to device in their systems. It's all about giving people flexibility in their options.

P1AM does support ladder (and the other IEC languages) through OpenPLC(https://openplcproject.com/). This is great if you want a blend of IEC languages as ProductivitySuite only does ladder. On the other hand, if someone decides the P1AM isn't the right fit, it's easy to pop in a P1-540 and go the traditional PLC route without having to completely redo the physical system since it's all the same IO.

Interesting. Given how much work that is, i have to imagine it's integrating a custom codesys (like beckhoff used to do) or something.

Hard to believe they could do it all on their own that quickly.

As for the rest - no disagreement, In practice though, i would trust the P1AM/etc over Arduino's product every day of the week. This is what they do.

The thing is that if i needed something a little different, i'd just move to a different part of the Productivity line - a p1000 or p2000 or a p3000 (or something else from Koyo, who owns them all).

If i needed ability to do "random things", i'd use a revolution pi, as you said.

There are plenty of good things in this market, and arduino doesn't seem to actually bring anything meaningful to the table.

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?

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.)

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.

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.

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).

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.

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.

I just got my feet wet with an s7-1200 and I could not have imagined how horrible the programming of a PLC is. I spent a day just to get the plc send out UDP packets at 25Hz.

Apparently going above 10Hz is not really supported so you have to do silly tricks. I ended up running the send command on every tick, and running a time triggered cycle that toggles a bit at 50Hz and then using the rising edge of that bit to actually start the secretly async task of sending 20 bytes on the wire.

Son far I have learnt that async tasks are hidden, memory is measured in Kb, there is no guarantee for cycle time whatsoever, the programming model is really awkward, lots of config cannot be stored as code, version control is a bolted on nightmare, etc, etc.

Really makes me wonder what a PLC can do that an arduino/esp32/rp2040 can not. I'm really struggling to see the value other than that the hardware is reliable and "industrial".

In industrial automation you are not supposed to do anything at 50Hz, the reasoning is simple: more times than not you are simply turning on and off something that is AC powered and you do that probably with mechanical relays and contactors, quite obviously it is pointless to do that faster than some multiple of AC line period. It is simply about trusting the supplier, certifications and perceived reliability of the thing.

On the other hand even brand name PLC hardware is not that expensive if you factor in the fact that interfacing with 24V and mains-level logic is somewhat complex engineering problem. Relays and optocouplers are expensive.

Edit: and as for what PLCs can do that random MCU cannot: the Chinese Mitsubishi GX/FX clones mentioned in the sibling thread are essentially STM32 eval boards with industrial I/O and preloaded PLC firmware, nothing more, nothing less, so there you go.

> 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.