Hi all! This is my first dive into using Mini-PC's. I am a PLC and PC programmer and have been writing software on both systems for some time. Writing programs isn't my issue. However, my company is looking into combining the PLC and PC and we have been reading about mini computers for sometime. We develop automated machines and use limit switches, light curtains, relays, motors (and motor controllers) and hydraulics. We are waiting four our UDOO Quad to arrive. What do we need, if anything, to work with the following: 1) Limit switch inputs (digital/binary input) 2) Binary output (to actuate relays and motor starters) 3) Analog output (control proportional hydraulic valve) 4) Analog inputs
I'm not sure your going to need a lot.. maybe a blank arduino due compatable shield to make your analog conditioning circutry, and wireing for all the inputs and outputs. and so that you can disconnect the udoo if needed. other than that, I think this should do what you want easily
What Firehopper said... Depending on how many inputs/outputs we're talking about, you might want to look for one of the "Mega" size protoshields. Then you can do all your connections on that and easily attach it to or remove it from the udoo. The Limit Switch binary inputs are easy, so long as you do any voltage conversion to keep them within 0V (off) - 3.3V (on). The binary output similarly. The analog outputs are only doable via Pulse-width modulation directly. If you need a true DAC you might need to add that on. Again 0-3.3V range. Analog inputs are simple, but you'll need to confirm that the Udoo's Arduino side has the resolution you require from it's built in ADC circuitry and that you have enough of them to do what you want. Again 0-3.3V range, so you might have to use some Op-Amps to adjust the signal levels to stay in range. Then you'll need to decide if you want to do this all from the Arduino side and just pump the data as needed over to the Linux side, or if you want to program it directly from the Linux side. There are pluses and minuses to both approaches. Hope this helps!
Thank you all for your input, they really help. Binary Inputs can number as high as 100. I would hope to find binary input module(s) (I guess you call them shields?) that I can plug into the UDOO. Hopefully these input modules (shields?) come in modules of 16 or 32 (similar to PLC input modules) and then stack them until I reach my needed quantity. What is the maximum addressable input/output space? Can UDOO accommodate 100+ inputs? The 3.3V has me concerend. We typically signal using 24V. 3.3V has almost zero conductive range therefore we will need to have an I/O card with relays to operate as an intermediary (step 24V down to 3V). And, you are correct, 3.3V doesn't have the power or resolution necessary to control an analog proprotional valve. For a Parker N.C. Proportional Flow Control Valve Series DF122C I require 12 VDC @ 2.45A or 24VDC @ 1.23A. You use amps to control the valve. I guess the question really is, to those out there with the experience, is the technology available and mature enough to replace a PLC and a PC?
Well you don't have anywhere near enough pins to do 100+ digital I/O in addition to the other stuff.. You'll probably have to use some sort of multiplexing to do what you want (like a 3->8 Multiplexer)... You can't just keep stacking over and over. Each pin is set up for use for 1 thing. You don't suddenly get another set of pins by stacking on another shield. The pins are more like a shared bus in that situation. (In fact, in nearly all situations, you do NOT want multiple shields trying to make use of the same pins.) Based on the voltages and current needs, you're certainly not going to do what you want through direct hook ups. You'll need to do relay boards and such... Use the pins on the udoo to control the toggle of the relays, or read their state as 3.3V. The Analog, you'll probably be best off with some sort of interface as well. So I don't think it's going to be as simple as you're hoping. It's not really the point of these sorts of boards. These are more for small hobby-type control and sensing projects. Not stuff that requires heavy load or voltages for large heavy mechanical structures.
In fact, I would suggest if you're looking for info on this, look over in the Ardiuno Mega/Due forums or on the web in general. The pins on the Udoo are really just an Arduino Due, so if it is possible on a Due, it's possible on the Udoo. The advantage the Udoo has over the standard Due is that you can also directly interact with the pins from Linux, rather than just the Arduino's mController, so you can do much more interesting things with a lot more memory to work with, but you have the Linux OS in the way which takes away some of the realtime advantages of the embedded microcontroller on Arduino.
AmenRa, you asked earlier "Can UDOO accommodate 100+ inputs?". A single UDOO (or Arduino Due) is unable to since it has a total of 76 pins for I/O. Multiple UDOO's I imagine can communicate or multiple Arduinos may be able to communicate together for additional pins though. This is something I'm less familiar with as I haven't attempted to have multiple Arduinos communicate with each other
Now, that being said, the UDoo has an I2C interface through several of the pins. You can use that to communicate with expansion boards that can provide additional IO pins, and usually you can chain several of those together to get more IO... But again, that's not a straightforward setup and will require extra hardware. Each of the 76 GPIO pins can only be set up for a single thing... And many are set up for specific features. For instance, there are several that can only be used for analog input. There are only so many that can be used for PWM output. All the rest can be set for digital Input OR digital Output. But you're limited to 76 total unless you do some of the tricks I mentioned in the previous paragraph. Honestly, what I would recommend, (in addition to my suggestion above about looking into the arduino forums for some of the electronics related to this) would be to start out with a small project - see what's involved to try to control a single Digital input, Digital output, Analog in and Analog out. If you can get each of those working, then you can figure out how to scale up to what you need to do the full project. If you can't get even the simple setup working, then there's no point investing the time and money to buy the parts to do the full arrangement.
All the other issues are not as important as this one (as they all have solutions). Microcontroller is a mature technology and have been deployed into industrial environment with proper design and I bet some of them is probably at the heart of some of the PLC. However, Arduino is originally design to educate student about electronics with ease of use and low cost as its primary aim. I think Udoo is also designed for this and the home user market. On the other hand, PLC can be deployed into environment which is noisy, hazardous and lot of interference. It may also be controlling equipment which may be worth lots of money or may endanger people's life if malfunction. So the design has to be resilient - can recover from fault in a graceful manner. If you are thinking about using Udoo or Arduino for these, I would say it is up to you to prove that your design solution is capable of doing it. But if you are thinking of simple home automation or light industrial application, then it should be capable (assuming that Udoo is a stable system - it is a new design, so will take time to establish whether it is stable enough for your use).
So you are looking to replace the PLC's with an Arduino? Well, I can tell you not a good idea because the Arduino will not have the same program memory that a PLC has, plus it is limited in it's input voltages, in the case of the Udoo it would be 3.3v. You would also have to do some electrical engineering to read 4-20mA sensors. Also, depending on what PLC platform you are using, Allan-Bradley, Seimens, Honeywell, etc, you use ladder-logic to program them whereas Arduino uses Objective-C. Plus, how would you interface the Arduino into any data historian software? That would have to be probably some Perl script and reverse-engineering of the database. I have extensive process control background working with Rockwell RSView, Emerson ProVOX, and Emerson DeltaV, so I am really racking my brain to understand why you would want to use an Arduino when you already have the PLC's?
PLC's are finite machines. What they do, they do well. But they can't think, they can't store, they really can't remember. I would prefer to write my logic in C/C++ over ladder logic anyday. We have material handling devices that we currently use PC's to do the thinking and storing and the PLC's to do work. It works. We have been discussing, for some time now, how to merge the two devices onto a single platform. It's just talk. Someone sent me a link to UDOO so I was just being curious.
the UDOO is a very capable and powerful embedded platform, but it is based on the ARM CPU architecture, and Linux/Arduino. Its also important to remember that is a very NEW platform, even though its build on pretty standard parts. it will likely be close a year before the software side is really solid. That said, i think its great to look at it for uses like augmenting and replacing PLCs, we just have to stay realistic about its capabilities. If you find something you think you can do with it, within the realistic limitations of what the platform is, then by all means lets get started. When researching your stuff related components look for stuff that works with the Arduino platform, specifically the Arduino Due and the Raspberry Pi.. the Ras Pi is similar in nature to the linux side so its a starting point for research.
While PLC's are finite systems that use ladder logic in most cases, most PLC platform's have a store-forward mechanism, but it would be small. Ladder logic is good for industrial automation because it's a simple if..then logic, which is easy to understand by most engineers vice learning C++. Also, you would want to offload the storage of the data points to a PC platform into a data historian, otherwise how do you consume and mine that data if it's stuck in a PLC? Don't get me wrong, I think the ATMEL platform is great for automation, but care needs to be exercised when talking about items that could impact safety. One thing about PLC's is that unless someone does something crazy, they can operate on their own to secure the process and ensure safety, so moving to a non-standard platform would take much more care and a strong PHA (Process Hazard Analysis). Also, you would have to write your own data historian and HMI (Human Machine Interface) when moving to the ATMEL platform vice using a PLC standardized system. With all that, I would say the Udoo is probably not the perfect platform to replace a PLC with as it would be massively overkill, but maybe as the interface between the IO and the historian/HMI would work. Plus, most industrial IO use something like DeviceNET or MODBUS, not CAN or PAN, or even Ethernet (unless you get an EtherIO bridge), so there's a massive challenge and expense in that. I do use ATMEL (Arduino) systems for home automation, but for anything industrial I wouldn't bet the farm on it just yet because of the lack of standardization, interface, and the safety concerns.
I think it is very interesting that codesys has a runtime for the Raspberry Pi for learning. I have just ordered a Udoo board. I have been messing with Arduino and have got Modbus TCP running on a nano with using the ENC28J60 board. I am thinking of using something like that for a remote device like a load cell. If you need speed then you need the wiznet chipset on Arduino which will offload the communications task. I am thinking it would be nice to use the Arduino as a watch dog timer for code that is running on the Udoo. It would be really nice if Codesys ran on Udoo. Lots of neat stuff to play with, if only I had more time.
With I2C connectors, with a simple serial BT conecction with a IO arduino card, extra IO card or arduino with ethernet, a simple shield with extra connector attached to I2C ports.....no is a problem. you can buy 100 arduino boards from china for a few dollars. For custom process instalations, you can managing some arduino or custom boards, with only one udoo conected for BT. Udoo as master and arduinos slave working like PLCs. The posibilities ara infinite... Excuse me for my english. Still, I see udoo Arduinos and if migration is not you will have a problem, either because it is their own business or to make an industrial simulation to see if the processes and their advantages would improve. Udoo and Arduinos do not see them for suitable for an industrial environment, and if not for your company, is a commercial use, you could have many maintenance problems because it comes out of the ordinary to what I used in the industry. In an emergency, stop by breakdown, you struggle to find a technician who knows the system is not available if the creator of the installation. That's assuming that you have made sure to have spares, tools and appropriate diagnostic control, the further you there will be created. In short, a company can not rely so heavily on one person or a small group of them. You must have a facility in which an external technician can repair it in a reasonable time.
I am thinking that if Codesys soft plc was running on Udoo it would be driving I/O via modbus tcp lot of industrial I/O talks modbus tcp .
