New control system design suggestions - Page 1
Forum section: electronics / projects

author: kallileo
author_rank: Contributor
timestamp: November 05, 2017, 05:34:09 pm
content: My company manufactures farming equipment and we want replace and modernize our 10 years old PLC based control system for one of our products.Instead of using a PLC again we are looking to design a more application specific embedded solution.I think the system is not very complex as we need a control board with 20-25 DI, 20 DO (relays) and 5-6 AI for temp probes and a touch screen as control terminal.The system should also have a Web server for modifying the parameters of and IoT capability.We are getting different proposal for the architecture from some potential suppliers/designers but I would like to read some opinions on what kind of options we have for the architecture of the system and how to approach this project in a proper way.Thanks

author: IanB
author_rank: Super Contributor
timestamp: November 05, 2017, 05:40:28 pm
content: Possibly one strength of PLCs will be fault tolerance and environmental hardening for industrial environments. A key factor in industrial control equipment is safety. The controls must not malfunction, send the wrong output signal at the wrong time, or fail to send a required output signal when required.Have you thought about how you would replace this aspect in a home-brew solution?

author: kallileo
author_rank: Contributor
timestamp: November 05, 2017, 05:50:57 pm
content: I'm automation engineer myself working mostly with industrial PLC. We are not talking about industrial application but a milk cooling machine located on a farm. There are no real-time requirements and while it is important for this system to be reliable it's not a key factor as it would be in industrial environment. Safety isn't an issue as well. Most of our competitors are using custom boards which provide more flexibility and cost effectiveness.

author: IanB
author_rank: Super Contributor
timestamp: November 05, 2017, 06:05:45 pm
content: OK, I see. When you said "farming equipment" it was easy to imagine big motorized things with the capacity to mangle people.

author: kallileo
author_rank: Contributor
timestamp: November 05, 2017, 06:18:49 pm
content: The worst thing that can happen is for the milk to spoiled if not cooled properly. Not good for the farmer of course but not the end of the world.The first proposal we got is having a control board with Arm Cortex-m microcontroller which will do the all the control and IoT stuff and communicating via Modbus RTU RS485 with an 7' inch industrial HMI but I don't like this solution that much.

author: IanB
author_rank: Super Contributor
timestamp: November 05, 2017, 06:26:13 pm
content: The HMI is probably an important part of the solution. It should be rugged, easy to use and easy to configure. Does it need to be splash-proof or waterproof?

author: kallileo
author_rank: Contributor
timestamp: November 05, 2017, 06:40:25 pm
content: Yes, it needs to be splash-proof but we were thinking about getting open-frame touchscreen and making our own housing.Normally they are much cheaper than industrial HMI.Is it possible to have a display with LVDS interface or similar (like in the link below) directly connected to the control board instead of using an industrial com protocol like Modbus or CAN to communicate with the HMI because the GUI for the HMI has to developed separately.

author: hendorog
author_rank: Super Contributor
timestamp: November 05, 2017, 07:40:53 pm
content: I was involved in a milk vat monitoring project similar to this in the early 2000s.We developed three solutions in the end :-* PLC, which was used as a PoC and for demo's with HMI.* PC/104 running linux/embedded java with HMI* In house custom electronics with HMIThe custom electronics one was the cheapest by far and there was potentially a large enough volume to make it worthwhile. However it took much longer to develop and debug. The PC/104 solution was quicker to develop, flexible, reusable, but expensive.The PLC option was the fastest by far to develop, and was easy to troubleshoot on-site, but lacked flexibility, code wasn't really reusable in other projects, and was similarly expensive.I think in all cases we used an industrial HMI as at that point off-brand products were available reasonably cheaply. The custom electronics one might have had a different screen, I can't remember.I learned a lot on that project about payback. IMHO moving to a full custom solution is a big decision not to be taken lightly. Don't do it unless you know you have the volumes would be my suggestion, and consider a SBC solution instead as a middle ground option.

author: kallileo
author_rank: Contributor
timestamp: November 05, 2017, 08:28:53 pm
content: We are talking about 150-250 pieces per year and I hope the volumes will be increased every year. I think that we could use the same solution for some other machines we manufacture by just loading a modified software/firmware without modifying the hardware.Another very important issue is that we should be able to provide spare parts for at least 10 years.I was thinking about a SBC and a touch screen display as well.Another solution could be a open frame Panel PC but then again as with SBC long term availability for 10 years could be a problem.In case of a Panel PC or SBC solution is chosen how could it communicate with the IO board? i2c? CAN?Should the control logic be running on the IO board or the Panel PC?

author: hendorog
author_rank: Super Contributor
timestamp: November 05, 2017, 09:18:37 pm
content: Haha, this is so much deja vu for meYes we also looked at panel PC's IIRC. They were pretty expensive at the time and we weren't too sure about robustness and front panel sealing - they were more powerful and compact than the PC/104 setup but ran hotter which was important given the sealed enclosure and unknown ambient temp. Also the potential for water ingress would mean replacing the entire unit - whereas the HMI's were more robust, and being standard industrial gear were easier for anyone with industrial nous to replace.You are in a better place than we were given it sounds like you are shipping units already. Our project was either going to go large or not at all - aside from demo units and test site etc - it was being marketed direct to dairy companies in countries around the world.Given you probably don't need speed and can cope with the odd failure, I would keep everything as simple as possible. I'd run the control logic on the PC if you go that way, and use ASCII Modbus RTU or similar for the comms - i.e. choose some well known, flexible and understood protocol that is implemented on everything and easy to debug. (I've been out of the industry for more than 10 years so bear that in mind

author: rstofer
author_rank: Super Contributor
timestamp: November 06, 2017, 01:59:20 am
content: I would look at using a Raspberry Pi for all the high level stuff including networking and web services. It can also handle the low level logic stuff and drive off-board relay drivers via SPI or I2C. The one thing I think will be a concern is modbus. I'm not sure how to get the Pi to keep up with incoming data. There is probably a way to queue the stream but I haven't done it myself.As to a display:https://www.amazon.com/Raspberry-Pi-7-Touchscreen-Display/dp/B0153R2A9I

author: kallileo
author_rank: Contributor
timestamp: August 05, 2018, 03:27:19 pm
content: The project is moving on... we have decided to design an I/O that will be able to handle all the necessary analog and digital inputs/outputs and communicate with a Panel PC using Modbus TCP. The GUI and the control application will developed on the panel PC. We will have a local electronic circuit design company to develop the firmware and the hardware.What I'm worried about is surge and current overload protection on the digital outputs. There will 20 of them with 10 being mechanical relays that can handle various voltages and 10 being 24V controlling solenoid coils and small dc motors up to 50W. Is it possible to handle 50W motor using Optomos or some other solid state technology? Should we insist on adding PTC and MOVs on each output?Any suggestion would be helpful.

author: ajb
author_rank: Super Contributor
timestamp: August 05, 2018, 04:01:21 pm
content: No fuse or PTC is going to be fast enough to protect the transistor against a nasty transient or a dead short, so I would look at protected power switches if you want solid state outputs. You probably still want some sort of fuse and clamping device to protect against gross miswiring or whatever, with the protected switch handling the more pedestrian overload conditions.

author: kallileo
author_rank: Contributor
timestamp: August 06, 2018, 01:39:11 am
content: We are going to use and external industurial 24VDC Power Supply with built-in overload and short cuircuit protection. Will it be enough to protect the solid state outputs in case of a short or should consider using relays for the 24VDC outputs as well?

author: JS
author_rank: Frequent Contributor
timestamp: August 06, 2018, 04:36:04 am
content: I'm working on my final project for my degree and it's an industrial controller based on an arduino, because it was laying around and it did acomplish the task without issues. The thing has been working for over a year with no problems, now I just need to finish the documentation to be done with it.Since then I've also worked on other projects involving PLCs, I'm glad I did it with a µC and develop the power control for myself.I don't know what you are controlling with relays, they are reliable to some extent but have a limited number of cycles, I did use them but it switches a few times a day. Depending on your needs you could use other type of switching, like SSR for AC or MOSFET for DC. Using relays for DC is kind of a problem unless your currents are quite low, I'd try to go with MOSFETs. I used dual isolation from the load, the µC to optocouplers to relays, the relays run on a completely separate PSU to the µC. This has proven good for safety and reliability so far. The thing I was automating needed a simple enough code to be worth for a one of, now I could make the program with ladder in an afternoon but the C code would take much less now than it took back then.If I would start something like that now (and I'm about to) I'd probably go for some RTOS to makes things simpler, one of the problems I faced was to pool the UI which was just a few buttons often enough, on previous versions of the code you would have to press the button up to a few seconds till it reads it. I didn't use interrupts but buttons are read in less than a second now, with an RTOS this would be really easy to make much more efficiently.Now, you are going for a high volume, you can get a good use out of the flexibility and cost savings, so for me it makes a lot of sense to go for a µC design. If you are worried about availability of the µC in question your volume isn't that big you can't get enough of them to be safe for 10 years, getting 5k chips will probably get you through about 10 years and you can get a really good deal for them, all the other parts should remain available or have situable replacements to need, worst case, a quick re-disign of the PCB and be ready. If the code is good enough shouldn't be such a pain to bring it to a different µC either for a few years span if you don't want to have 5k µC sitting around, anyway, life span of µC is much longer than µP for instance, look since when atmel models are around. Today STM looks to be here to stay, getting a nice share of the market and getting really nice products out, so I would take a look at them for something like this.For protection, as I said it would depend on the load type, for 24V I wouldn't trust the protection on the PSU to protect the output devices, as I expect the PSU to be much beefier than any individual output device and I'd like the rest of the thing to keep going if one output gets shorted. We are not talking huge volume here, so likely to be ok to throw a few extra components to limit the current, protect from reverse polarity and other conditions. Expend some time looking at all the posible fails, design a circuit to stand for them and run some abuse tests, this shouldn't take too long in the scale of a project like yours.For the digital inputs, optocouplers seems to be the best approach, with a reasonable easy design they are reliable and if you use sockets repair will be a breeze in case something goes wrong. Using a PTC to limit the current to something the device can handle easily, plus a reverse polarity protection is about all you need, except you get a really fast transient. For that I would use a TVS and feed the optocoupler from a resistor to there, so PTC, TVS, resistor, optocoupler and I'm starting to trust in it now for quite some adverse situations. I'm using H11AA1 with a 100k 2W resistor connected directly to big AC motors, up to 40kW or so, that's it for my inputs, they switch in and out under load, so that should represent a really big spike every once in a while. The thing has been connected to that load for 2 years now and it didn't show any sort of problems so far. So, I'd worry more for the reverse polarity (H11AA1 doesn't have reverse polarity, it goes both ways) and for extra reliability add something for spikes if you are worried.In your case, maybe a RS485 HMI makes sense, spinning your own HMI seems a bit too much for this, might worth in a next stage once you get this working and you spin your own HMI to be compatible and you can go back and forth depending on what you want.JS

author: kallileo
author_rank: Contributor
timestamp: August 06, 2018, 02:54:33 pm
content: Thank you for your very long and detailed message.Of course we are going for Ethernet Modbus TCP HMI with Codesys SoftPLC for fast and easy develoment of the control application in stuctured. The GUI will probably take more time to develop as it will ba quite a complicated application. All the aforementioned issues will be handled by a industrial grade HMI touch screen so I don't worry at all.I just worry about the IO board that will be custom made and I would like to avoid any upleasant suprises.We will mostly controlling 24vdc coils and motors with maximum 1,5-2A load current.Maybe in the future we will get a Linux Panel PC and develop our own control application using Qt or something like that.

author: max_torque
author_rank: Super Contributor
timestamp: August 07, 2018, 05:13:10 pm
content: IME, touchscreen and PC based systems are a nightmare, and actually rarely needed for basic controls applications.The problem is that a multicolour touch screen makes a product look "flashy and expensive" when compared to some LEDs and a rotaary switch or two. However, ime, anything PC based WILL fail to work regularly for some reason completely out of your control (windows update anyone???)Right now, i'm instructing suppliers of the systems i buy from my clients (automotive OEM test equipment) to stop using anything PC based because it's causing huge problems and massively expensive down time.For a basic control system, that say reads a level sensor, or a thermocouple / PRT and then opens a valve or turns on a pump, use an 8 bit micro with robust I/O and power filtering, drive some basic, simple, user information panels (LED's, perhaps a character LCD) and leave it at that!!

author: max_torque
author_rank: Super Contributor
timestamp: August 07, 2018, 05:17:26 pm
content: BTW, solid state, smart (ie protected) switches now cost less than relays!I use infineons range of automotive rated smart switches (Overcurrent, overtemp, overvoltage protected and with output current feedback, single switch, Half and H bridge layouts) for all my products.

author: nctnico
author_rank: Super Contributor
timestamp: August 07, 2018, 06:59:20 pm
content: @kallileoThis sounds very similar to something I offered to one of my own customers. My solution: let a microcontroller do the actual control work and have a single-board-computer running Linux do the display and ethernet interface stuff. Even if it is just milk a farmer will be fed up when it fails for the third time.For the volumes you are talking about it makes sense to go for a full custom design. Using SoC modules will turn out to be expensive in the long run. There are not many flavours of SoCs to choose from if you want long term availability: TI and NXP.

author: hendorog
author_rank: Super Contributor
timestamp: August 07, 2018, 09:21:56 pm
content: Have been down this rabbit hole about 15 years ago now - also related to distributed control/monitoring of milk storage on farms.Our project started with PLC's and then migrated to a custom PCB. We ended up also building an embedded linux version, IIRC this was due to delays with the PCB. The project never went fully live for various reasons.Making a custom board was the lowest unit cost option by far, but it came with many caveats. There are more options now that we didn't have back then, but some things I remember might be helpful to you. I'd think carefully about the reasons why you want a custom solution so you understand what your motivations are. If it's unit cost, then remember to amortise development costs and remember development costs are variable and usually will be much more than you predict. Fixed price contracts are unlikely to stick. If it's just a brand identity thing, then consider rebranding something off the shelf.Thoughts:* PLC parts are easy to get.* Switching to a different PLC brand is possible if you had to.* Full stack single board custom control systems can take a long time to design and perfect. It is easier now than when we did it, but anyone that says it's easy doesn't have a clue.* Custom builds are only cheaper than PLC's in volume. If you run short of stock then how long to do another run.* What is your backup plan if 10's or 100's of these boards need to be swapped for something else after install due to some significant fault. Switching to another custom board isn't likely to be an option so keep your options open with enclosure size.* Need to distribute replacement stock all of your support people.* Need to manage the rev's of the hardware and firmware.* Need to have a way of updating firmware in many devices and some sort of bricking recovery.* Need to manage any local settings for each device so a replacement can be installed.* We planned for devices to report proactively back to a central server and upload settings and logged data. Having a web server is a good backup plan, but you need a way to know the IP address and which unit it is that you are talking to. Install records might not be available or reliable and parts might be swapped between sites without you knowing.* We didn't think polling many field devices on a schedule would work reliably so we cached the data locally and uploaded it instead.If you made it this far, I think a one step at a time, progressive, modular approach is the way to go. You don't get all of the cost gains for a while, but you reduce the risk significantly, and spread the development cost over a longer time frame. You also can involve everyone in the team much earlier in the process and maybe find a major issue earlier rather than later. The people who will install it are important, and so are the people doing the IoT web site.e.g. you might develop a custom I/O board first, then replace the controller with an off the shelf embedded PC (in my day it was linux on PC/104), and finally develop the final, lowest cost custom controller with everything on board.You could use the PC controller solution as a test rig so that you can get started with your off board development early. I am sure it will pay for itself on this factor alone.