A number of Chinese companies produce DIN rail mounted PLCs which already cover this market, cost virtually nothing and actually emulate Mitsu GX ones so work with existing off the shelf tools and have the same real time guarantees as the commercial units. If you're going to cheap out, these are fine.
But this isn't the problem. The expensive bit of a PLC is the dude perma-welded to the cabinet. Last thing people want to do is rock the boat by expanding the risk to a vendor like Arduino, which quite frankly doesn't have a great reputation or history of tested industrial or reliable hardware. It's better to pay 3x as much for a well established vendor.
I'm thinking (but can't confirm) that the intended market for these is companies that are too small to care about things like "well established vendors", where budgets are measured on the magnitude of hundreds of dollars and not thousands, and things are built from scrap or misc parts. I'm guessing that in some countries other than EU/Americas/etc, where things are done by "I know a guy that can figure it out", and people wearing safety sandals, this device would be convenient. I have reason to believe this market segment is both invisible and massive.
For a small scale industrial process, even a really hacked together setup can work surprisingly well, and while you have a chance of running into some show stopping problem, there's an equal chance of the hacked together setup continuing to function for the required time. If labour to fix stuff and/or small enough scale to temporarily have a little downtime are effectively free, this can work out positively.
I can see that things like these would be a good step up for those who were originally not even using PLCs. I think it provides a good "entry point" from Arduinos to something at least DIN rail mounted, and it's a way to experiment with ladder logic and whatnot. I personally would consider using it just for the convenience of that option.
> I can see that things like these would be a good step up for those who were originally not even using PLCs
I agree that that's what Arduino thinks the market is, but I disagree that their conceptual market will buy this.
Arduino-branded hardware is typically 5x the cost of the clones (remember, it's OSH) at no noticeable improvement in quality. DIN-rail mountable arduino clones and modules with I/O isolation that run on 24V power already exist at very reasonable price points, and from reputable dealers such as Automation Direct. I've used ruggedized modules such as Industruino (although their prices have definitely gone upmarket) and they're nice. IME, the only people who buy actual Arduino hardware are either beginners who don't realize that the much less expensive clones are every bit as good, or business buyers who don't really care, because it's not their money.
But maybe I'm wrong and there's enough of a price-insensitive market to make this a success. I certainly hope so. I'm a freelancer, so the bigger the market, the better for me :-)
I have designed & built an arduino clone-based product that mounts on DIN rail because the hardware it communicates with also does. Multiple installations running large machine control applications without a hitch. The clones are fine.
I definitely see where you're coming from and I think these are valid points. In my personal experience though, there definitely does exist a market of "price insensitive, as long as it's under x". I think Arduino probably fits in there.
I feel like at least based on the quality of some boards vs clones that I have, there are definitely cases where I would have been "fired for not buying Arduino [IBM]" due to stuff like weird USB serial chips requiring driver hackery etc.
And I've definitely been in the situation where you tell someone it requires some part that costs "several hundreds of dollars" and they're like "oh no problem that's not an issue at all", because they were looking at the magnitude and not penny pinching.
I suppose that would be the market for this kind of thing. There's the other thing that you mention, where if you're using Arduino for this purpose, you might not be experienced enough to trust yourself to choose the right clone. Arduino provides sane defaults and generally the installations I've seen in the wild tended to use fairly close to "defaults".
You may have run into a counterfeit FTDI chip, then. The normal $5 arduino clones from reputable manufacturers often have genuine chips. The $2-3 ones are trouble.
Most of the clones have stopped even using the FTDI knockoffs nowadays. There are alternative USB-to-serial chips from other manufacturers, like the CH340 series, that work very well.
Yeah Automation Direct is already in this space with their Arduino PLC[1] which has compatibility with their existing modules/etc.
I'm only adjacent to the space and have use their stuff for some home automation but from what I've seen it's more important that you can get replacement parts and reliability.
> For a small scale industrial process, even a really hacked together setup can work surprisingly well, and while you have a chance of running into some show stopping problem, there's an equal chance of the hacked together setup continuing to function for the required time. If labour to fix stuff and/or small enough scale to temporarily have a little downtime are effectively free, this can work out positively.
Can confirm that this is happening to some extent in biotech startups. Most of them don’t have the resources to hire grad students en masse to do the tedious labwork so they’re investing into lab automation. At the seed/series A level there usually isn’t enough money to splurge on brand name lab equipment beyond a few core pieces of equipment and with experiments running, there’s enough tech savvy downtime to experiment with hacky but cheap solutions. I’ve even seen HomeAssistant driven lab automation setups driven by AppDaemon apps with ESP32s used to control a mix of pumps and sensors (with CI/CD, though the whole thing was backed by a proper LIMS). It felt incredibly hacky but uptime was stellar once the SD card was replaced with an SSD.
It used to be that I had to go to Staubli or similar manufacturer and spec out a $50k robotic arm just to move plates from a liquid handler to the fridge. Now the same can be had for a few grand or less and there’s even open source options.
I see this PLC along those lines, where a lab might need to control a bunch of pumps and syringes with some synchronized via RS485 for realtime control and others on WiFi for less time sensitive stuff. A low cost PLC in that sweet spot between enterprise PLC and bare dev board could do really well.
These PLCs would be the perfect complement to ESP32s and RaspberryPi if they’re cheap enough to stockpile like RPis were preshortage. It’s unfortunate they haven’t published pricing yet, which tells me that it’ll be too expensive for hobbyists.
You can just go put "PLC" into AliExpress and you will get a bunch of FX01 clones, or you could put "GX Developer" since all of these seem to be compatible.
Unfortunately GX Developer doesn't appear to be free, but apparently Delta makes PLCs too (with actual UL certs too) which sell for about 130 USD on AliExpress and the software appears to be free (unsure). They also have reasonably (~80$) priced HMI LCD touch screen displays.
I think this is an attempt to break monopoly of those traditional PLCs. There are definitely going to be good use cases for ladder logic and "tried and true" programming model which was hasn't changed since 1990's. And in this case you are correct, the new Arduino makes little sense.
But sometimes you want something more modern, that you can program in the same language your main product is in, and apply the same expertise and tooling you already have.
I am not sure Arduino is the best option, given that their ecosystem is often very low quality, but there is definitely space for regular MCU in rugged case with protected I/O.
Arduino has a very good reputation for reliable hardware. Obviously this applies to official products. Shitty chinese clones have bad reliability issues...
Even some of those chinese clone PLCs are not spectacularly reliable...
This is a professionally made device, developed in partnership with Finder which is a company with 70year of experience in making relays and other mission critical industrial equipment..
No the current Arduino ecosystem does not have a good reputation for reliable hardware at all. It does in your product echo chamber but quite frankly it's laughed out of the building in many professional settings and for good reason. The Chinese PLCs have somewhat more credibility there. The current hardware has little to no protection, poor power management, the software ecosystem is quite frankly dangerous in a lot of cases and the IDE only recently gained feature parity with tools we had 30 years ago.
I'm quite willing to entertain that you are trying to get into the market and that these issues may be resolved with this product but you have a large reputation mountain to climb first.
You have to build reputation not try and add it afterwards.
To note I use Arduino projects usually for one off simple bench automation but nothing further than that. I tend to use them as a host for flat avr-libc / avr-gcc projects though, mostly because the old IDE and toolchain was absolutely dire.
True or not, "reliability bordering on childproof" can be a compelling sales pitch. And reputation is bound by recall, of whuch Arduino has plenty: brand X might have the best reputation imaginable amongst those in the know, but if you aren't in the know and you haven't ever heard of X all that reputation won't affect you. For all you know, X could be terrible. If there's another brand Y you have heard of, and only half of what you heard was negative, brand Y has at least some reputation (the non-negative half) positively affecting you.
That's the basic mechanism of why so much advertisement is just about brand awareness, not talking about quality at all: "I've heard a lot about them, and not everything has been bad" is less bad than "never heard about them, even if they were really terrible I wouldn't know"
I don't think you understand the industry. Reliability is qualified through testing, certification and support. It isn't a function of marketing.
Marketing gets you to the testing table. But better not have any skeletons in the cupboard.
Edit: I suspect you're confusing engineering for the niche sector of makers, the latter of which are driven by fads and marketing (sorry if I piss anyone off there).
“The industry" isn't a single uniform group. Sure, people who spent their career procuring industrial controllers won't look at Arduino even once when they introduce a non-maker form factor, and chances are they wouldn't be impressed if they did. But I can easily imagine that there's an underserved space between the extremes of the maker juggling dev-boards not really intended for him and the career specialist who goes to all the right trade shows. Some company for example that has barely enough controller needs to set aside full time staff for that, but does not want to outsource either.
It's possible that Arduino fantasizes about taking over large fractions of the industrial PLC market and if that's the case I'll chuckle agreeingly with everybody ridiculing them, but I believe that there could far more reasonable and realistic opportunities for them to stretch a little in that direction.
Arduino is a marketing company that makes amateurish overpriced dev kits and sells them to amateurs. They have that market largely thanks to marketing moves.
Arduino products rarely sell to people who do any form of QC or comparison shopping - they sell to people who buy the first thing on their mind.
Most of the Chinese embedded companies are engineering groups that understand they are filling the low end of the professional cost-quality curve, but they are still on that curve. For what you pay, they make a great product.
I see multiple comments recommending random Chinese PLC device from Aliexpress over this one. Where is the reputation and brand recognition of Arduino positively affecting anything here?
It also seems to me that your definition of the word "reliability" isn't agreeing well with others - to me it seems that these industry guys are using the word along "semi believable certification documents and soft established likelihood of not catching fire" whereas yours are more along "blind idolization for moral qualities seen in individual corporate employees". That might need a fix.
Arduino has a terrible reputation for hardware and software from a professional, reliable point of view.
It's fine from a easy, hacked together hobby project point of view, but that's an entirely different thing.
It's like Python vs Rust. I wouldn't introduce a beginner to programming with Rust, but I also wouldn't program my manufacturing line (or whatever) with Python.
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.
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).
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.
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.
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.
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.
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.
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] 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.
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.
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?
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.
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.
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.
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.
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.
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).
The main problem here is that the Arduino brand is currently paired with "maker". This was intentional, as they pushed so hard to reach this current status. Now the "maker" market seems to be declining. They have to go PRO.
I know they have the "PRO" line, but the problem is that in professional settings it almost became a joke to even mention Arduino. For a time we had a lot of internal jokes around it (for example, one coworker, in interviews with candidates, always leaves the room as soon as the candidate mentions Arduino).
Myself, I loved the UNO, the concept, the support and the community. Now I use it sometimes to test a 5V sensor or other I2C/SPI peripherals, when I'm not in the mood to use a 3.3V level translator.
On the other hand, if the product is not a success, they might leave the product to die (anyone remember Arduino MKR Vidor 4000? the project last major update is 4 years ago). In that case, to me it means that I prefer to fully qualify and validate a chinese brand, purchase 10000 boards and forget about it.
It will be very difficult to turn the things around for Arduino, to consolidate itself in other markets. I will take a while.
No, but it's not a huge growth market either. Makers tend to prefer products which are relatively inexpensive and close to "raw" hardware; neither of these factors are particularly favorable to manufacturers.
> Raspi don't seem to have any trouble selling.
Ironically, a lot of this is because it's become popular for use as an embedded Linux controller, often for applications that the BCM283x isn't even particularly well suited for. It's used in a number of musical synthesizers, for example.
Is there any pathway to creating something that's like Arduino but suitable for professional use? The primary benefits of such a solution would be 1) Freely reuse code and open source ecosystem 2)"Professional Grade" technical viability and reliability, and it would be suitable for people who want to handle support by themselves and do not want to pay the entry price for professional software and tooling.
Right now there's a lot of new IoT devices being put on the market and a large number of them are undoubtedly based on Arduino, but of course, there are supposed reliability and code issues with it.
However, people write and open source so much drivers and example code for Arduino. Wouldn't it be nice if the Arduino platform could become "production ready" so that people can actually leverage these drivers and example codes in their own projects instead of having to rewrite drivers for every combination of MCU and peripherals?
Ideally, making a product with Arduino shouldn't be a derogatory statement about its quality.
There are already arduino-based products that are suitable, but as stated before, a large part of the problem is getting past the "maker" association.
If you look at Industruino, Controllino, Ruggeduino products, and then the domain-specific arduino variants such as those for home automation, automotive hobbyist, lighting control, you'll probably find a lot of already OSH/OSS arduino-based hardware on the market.
And on the development side, ditch the (beginner-friendly?) Arduino IDE for VS Code and the PlatformIO plugin and you're all set.
The most fundamental miss here is the lack of live code editing. One of the basic things that makes PLCs a separate thing is that you can edit code live without stopping execution of the device. In real automation applications you can't shut down a plant or a line or a generator or whatever just because you want to add a new E-stop or change the timing on an actuator slightly or tune a PID etc.
If you have to kill the machine to recompile this is not a PLC by any stretch of the imagination, it's an Arduino with a fancy box.
I don’t think this is discussed enough when PLCs are compared to other embedded systems (such as this product).
Through a PLC’s IDE, which is almost always proprietary software provided by the PLC manufacturer, a developer has the ability to view variable values, edit their values, “force” or “lock” a variable to a specific value (making assignments to that variable a no-op), and make edits to the code logic. This can all be done while maintaining the realtime guarantees of the system. These features (called “online editing” by PLC manufacturers) are essential in many applications where PLCs are used and are the biggest differentiator between a PLC and any other embedded system, such as Arduino’s products.
GDB-style debugging of a desktop program or JTAG/SWO debugging of a microcontroller can do some of what a PLC IDE can do, but it’s not as reliable and safe as PLC products.
I looked at the specs, I didn't see a dedicated processor doing the Ladder Logic / Modules part. Perhaps they dedicate one core to it... but that's a lot more janky than a separate CPU at about a dollar or two.
I wouldn't want WiFi, Ethernet, or any other IO crashing the Controller. It has to be rock solid.
Being marketed as an IIoT device differentiates it from classical "mission critical/rock solid" PLC modules I guess. Treat it as an Arduino with WiF and Ethernet but with friendly screw terminals and connectors instead of needing a shield for interfacing te traditional sensors and actuators. And with an woefully overpowered microcontroller.
Hi the main processor is made of 2 separate cores and they can run different software. The processor we use it's the top of the line for STM so it's not a dollar or two. The separation between the two cores is much more well defined that people might think. The Wifi BT is managed by a separate module with its own separate processor (The Wifi/BT is also optional on most models)
> The separation between the two cores is much more well defined that people might think.
What separation do you think there is? The M7 and M4 cores on a dual-core STM32H7 share all of their peripherals and memory (with the exception of CCM and I$/D$ on the M7). There is virtually no separation between them; they can even run the exact same code with a bit of wrangling. There isn't even any provision for firewalling the two off from each other.
If you were planning on treating the fact that the part had two cores as a safety feature, you need to reconsider that.
The STM32 series don't have any BLE/WiFi solutions built in yet. Since it's "Arduino" I assume it's a NINA module or similar from u-blox as a "co-processor" over UART with an AT command interface, which is basically a brandlabeled ESP32 with some firmware enhancements they already use on other products that focus on IoT.
Good to know, so it's something to avoid. I had to deal with a lot of the wireless modules from Infineon and let's just say the support was ... hm, I guess terrible would be a pretty mild term in that regard.
Who the hell writes this stuff and why can they not be bothered to get even the simple basics right?
> uses an STMicro STM32H747XI dual-core microcontroller,
> which includes a single high-performance Arm Cortex-M7
> core running at up to 480MHz and a lower-power Cortex-M4
> core running at up to 240MHz alongside a shared
> floating-point unit (FPU),
The cores do NOT share an FPU. The M7 core has a built-in FPU capable of single and double precision. The M4 core has its own FPU, capable of only single-precision.
Wouldn't be the first time that Arduino got basic product specs wrong. They're still advertising the Vidor 4000 [1] as supporting "Mini PCI Express [...] for connecting your FPGA as a peripheral to a computer or to creat [sic] your own PCI interfaces" -- on an FPGA that lacks PCIe support.
Arduino, for some God forsaken reason, is trying to appeal to the professional market with the most backward decisions possible. This will be the same thing as the Portenta, which sucks because of the software lockdown (they don't even have an Yocto layer for it and pretty much force you to use Foundries.io).
Hi we're working in the professional market because the market is requesting it. The Portenta is a family made of a number of devices. I think you're referring to the Portenta X8. Obviously we favor the use of Foundries because it provides the user experience we need for a lot of our customer. The Portenta X8 is not "lockdown" you can install what you want. Customers can request a different system software and we help them run it. I think it might be possible make a generic Yocto layer available for download if there is enough request
I blame this on the implicit demands of the industrial markets endless fascination on the Raspberry Pi “platform” which has made actually getting your hands on one very difficult. Arduino is trying to also satisfy this market by offering a more targeted/discrete solution rather than a full Linux system. I think where they are misguided is that there are these sort of PLCs available at a lower cost today and people opt for the Raspberry Pi precisely for the flexibility afforded to them by a full Linux system.
In some cases they've never been. It depends on the series. A lot of their portfolio is being made in external fabs like TSMC, whose allocations they gave up when Corona started as they were thinking the chip demand will go down. (Oh boy were they wrong.) On the other hand they still had allocations (in their "own" fabs), so depending on what you want they deliver. Problem is basically anything "mainstream" was in external fabs, e.g. the entire STM32F0 to STM32F4 series. In contrast, if you want an STM32L0 oder STM32L4, you can still order like nothing happened.
Based on what you could buy through distributors, less than 5% of the STM32 lineup is available to buy. The situation was worse, 6 months ago there were 27 variants available on Digikey of the 3000 or so they make.
The G series seems to have good availability at the moment, if I was going to bet on a MCU for a new design that would be it. L series has only just gotten better, couldn’t get them a few months ago.
Some F3 chips have been looked over (didn’t go out of stock) despite being more advanced than their F4 counterparts. That’s marketing I guess.
Yes, for small players at least. I've been refreshing Octopart for G4s and H7s (in certain footprints) for a year with no luck, other than scoring a few G4s for prototyping that soon went out of stock. I'm assuming larger players have access.
There are some variants/footprint combos you can get. For example, I've been able to get G431s for a while in the right footprint, which is similar to the one I'm looking for , but with less flash and ram. Or, I can can an H7 in a way-too-big footprint.
Other MCUs like Nordic and ESP went through the shortage with no unavailability. Not sure if STM's comparatively large product lineup (as opposed to there only being a handful of Nordic and ESP variants) played into this.
Espressif has an advantage that they don't have on board flash. That boosts yield and volume per wafer. At this point I won't be doing new designs with STM32 because ST can't deliver.
Maybe they took it because it's dual core? Running everything connectivity-related on one CPU and have real-time code own the other one completely seems to be a good idea to me.
Is "brand loyalty" actually a thing? Personally I lean towards a thinking that product loyalty likely exist but the brand is just an aesthetic.
To me, this one looks like a Starbucks branded coffee maker, or a Toyota branded bicycle, a company swag product line that are not what the brand represents but do technically belong to the similar extremely generalized categories.
And, this won't take genius to figure out, so the real question is, why it's kept being done? This only erode a brand and plant doubts on corporate integrity into customer's minds.
In the last 10 years the cost of small PLCs have plummeted. This is obviously a play to get users to buy into an ecosystem. You can buy one of these with a small amount of I/O for $1k. It includes a local distributor who will show up to your door and help you spec out equipment as well.
The largest cost is the plant support techs who can troubleshoot and potentially modify PLC code. Many plants rely on electricians for this role. Electricians who can nearly follow ladder logic, which is modeled after wiring schematics.
A number of Chinese companies produce DIN rail mounted PLCs which already cover this market, cost virtually nothing and actually emulate Mitsu GX ones so work with existing off the shelf tools and have the same real time guarantees as the commercial units. If you're going to cheap out, these are fine.
But this isn't the problem. The expensive bit of a PLC is the dude perma-welded to the cabinet. Last thing people want to do is rock the boat by expanding the risk to a vendor like Arduino, which quite frankly doesn't have a great reputation or history of tested industrial or reliable hardware. It's better to pay 3x as much for a well established vendor.