4 ms·

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 langu

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/

FACTS_AdamC 4y ago
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/ 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.
DannyBee 4y ago
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.

FACTS_AdamC 4y ago

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

DannyBee 4y ago

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.