 Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me. |
Forum Index : Microcontroller and PC projects : Using a Micromite as an industrial programmable controller
Page 1 of 2   |
|||||
| Author | Message | ||||
Mixtel90 Guru  Joined: 05/10/2019 Location: United KingdomPosts: 7937 |
A few words for those who might be considering using a Micromite for industrial control purposes. Apologies if I'm preaching to the converted, but some may not realise the special environment needed. I used to work in the control panel manufacturing industry and I've not seen anything like this posted anywhere before. It may be of some interest. First, the watchdog is your friend. It absolutely must be used as there must be no chance whatsoever of your program getting stuck in an unwanted loop. It's almost always far safer to switch everything off and restart the system than lock up the equipment being controlled. If it isn't, then hardware should be taking care of that. There must be no safety interlocks in software. The software is only there for control, not for either plant or user protection. So, for example, motor overload trip signals must act directly on the motor starter, although they may also have to signal to the software that the motor has tripped so that the operating system can change or an alarm generated. In particular any Emergency Stop MUST bypass the control system and shut everything down, even if it means damaging the plant in the process. This is a life-critical stop. If at all possible if the software says "start motor" then the starter should signal back "motor running". If the "run" signal is removed then it should signal back "motor stopped". This is to help protect against welded contacts on the motor starter contactor. The auxiliary contacts on that are almost always operated simultaneously with the main contacts so a true indication of them is given. There are really two sets of software in a PLC. The "operating system" is usually invisible, the user program could be written in several ways - relay ladder language, logic diagram etc. For this text I'm assuming that the two are both replaced by MMbasic. The software isn't written in a way that many programmers find natural. Industrial machinery doesn't need a fast control system. Most of it is deliberately slow anyway. Basically it goes something like this: Startup: set all outputs to off make all output registers outputs ;there must be no surprise outputs switching on! make all input registers inputs zero all input flag registers zero all output flag registers set up timed interrupt for, say, every 100ms ;this controls system response speed Main: do reset watchdog timer loop Interrupt routine: copy all input registers to input flag registers ;update from the input pins reset watchdog timer run your program, reading from the input flag registers & writing to the output flag registers copy all output flag registers to output registers ;update the output pins end interrupt End: Note that the program *never* operates directly on the input or output pins. In the real world all the inputs are constantly changing so it's important that the program works on a snapshot of the world at that time. All input reads and output writes to and from the pins should be working on the complete register, not on individual bits, so that all pins change state virtually simultaneously. This also applies to analogue inputs. They must be read with the digital registers and stored for future use. PWM outputs must also only be changed after the program has ended. Because the system is time interrupt-driven we can have pretty accurate, synchronous, timers in the program with the same fixed resolution for all of them simply by counting program scans. Programming on many systems usually dictates keeping interrupt routines as short and fast as possible, industrial control doesn't usually work this way as you can see. There are occasions when interrupts are used, but they are fairly rare and normally used for catching fast counts from positioners etc. Note that the program has exactly one watchdog period to complete unless further watchdog resets are written into it. It has to complete within the interrupt period anyway. If it is going to take longer than that then the interrupt period has to be increased and the system response will be slower. A scan every 0.1s is actually reasonably fast in the industrial world. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
Cyber Senior Member  Joined: 13/01/2019 Location: UkrainePosts: 161 |
Thanx! Interesting to read. |
||||
goc30 Guru Joined: 12/04/2017 Location: FrancePosts: 435 |
Hi Mixtel90 Congratulations for your post which defines very well the needs and constraints of an industrial system. Against the use of MMBasic, I would be very pessimistic, for one main reason is the inability to manage correctly, several events in real time. I am trying to control the management of a GPS, which looks like a Modbus type communication management with PID, alarms, various conversions, etc ... Results: in some cases, the processing time sometimes exceeds the second , then we must forget the use of timers at 10 ms The only solution is the use of a very fast processor (minimum 250Mghz), and only the Pizero resists constraints, but unfortunately, it does not have enough analog and digital inputs / outputs. On the other hand given its price, why not put several |
||||
| zeitfest Guru Joined: 31/07/2019 Location: AustraliaPosts: 581 |
I would not use a home-brew system near an industrial plant. Most commercial plants require (often by law) serious insurances against damages...and a legal firm would look at damages possibly traceable to a home-brew system as a christmas gift !! A case in point - if you are a contractor needing to even walk around offices in a refinery, you are required to have typically at least $10 million damage insurance before you are allowed on-site...and even then, your vehicle has to be parked outside the site fence, in case it causes a problem. And thats before you actually so much as lift a biro. Granted, many accreditations are little more than a marketing joke these days, but they are often a first requirement. The cost of checking new versions and so on means many industrial systems are truly ancient...I can remember a "modern" plant using a Foxborough industrial controller, originally supplied in the fifties, kept going like a zombie robot. |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 7937 |
goc30: You might be surprised at what passes for software on some of the cheaper PLCs! MMBasic appears to be remarkably stable now and, providing the user program is good and the watchdog is used correctly, it would almost certainly be ok for industrial control. Many PLCs use multiple processors now. I know for certain that Siemens use them in individual modules on their modular systems. The bus system linking them simply scans every module on each scan, to update the outputs then read the inputs. Each module does it's own thing between scans, so PID controllers, counters, comms etc. aren't restricted by the program scan time. zeitfest: That's a very good point. However, when you look at the real world there are many, many sites where poor electronics are installed. :) I've used "low cost" PLCs that, frankly, I'd be unhappy to use normally, but these jobs are built down to a price. Specify good equipment and you won't get the job. This is exactly why safety interlocks are *never ever* done in software. When a site is inspected for safety it's those interlocks that are tested - what the control system does and how reliable it is are by agreement between the manufacturer and the client. Interestingly, Crouzet, Omron, Telemecanique and some others do a range of small PLCs, sometimes called "Intelligent relays". These typically have 8-16 inputs and 4-8 outputs (it varies indifferent combinations). Most are programmed in relay ladder and/or logic blocks. They are very similar both outside and inside. What looks like a single microcontroller, some isolated inputs & some output circuitry. I specifically noted that there is no separate watchdog monostable, which I would like to have seen, or obvious brownout protection. Not a lot of filtering on the supply either. There's also a soldered in lithium cell to maintain the RTC, so that gives a restricted life if you want to use the RTC at all. There are hundreds of thousands of these "brick" PLCs in operation all over the world. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| zeitfest Guru Joined: 31/07/2019 Location: AustraliaPosts: 581 |
>> >> Ain't that the truth !!!  |
||||
| goc30 Guru Joined: 12/04/2017 Location: FrancePosts: 435 |
hi Mixtel90 You are right. The worst is that in an automaton, the most expensive is not the CPU but the connection and especially the barriers of isolation, so it's hard to understand why we are looking for ridiculous savings on the price of CPU by putting products of mediocre quality and especially software made on a corner of table by amateurs of the industrial world. But it's clear that the real leaders are the R & D directors who only think about making money rather than making reliable products. |
||||
| Tinine Guru Joined: 30/03/2016 Location: United KingdomPosts: 1646 |
The problem is not the hardware, it's the implementation. Any system can be dangerous. The OP states that safety systems should be external to the controller....absolutely true! The watchdog/deadman should also be external (I use Brentek devices). What the OP hasn't mentioned is the fact that the controller is responsible for initiating machine movement in the first place. Take a START signal for example; how often do you see this requiring BOTH a high-going AND low-going signal, simultaneously? Furthermore, how many "programmers" understand the need for debounce (hardware or software)? I come across some horrendously dangerous equipment and the fact that it has Siemens or Beckhoff hardware, doesn't make it any safer when some self-proclaimed "expert" installer/programmer is ignorant. I am using Mm-Basic controllers for my CNC systems and actually ripping out big-name hardware when I retrofit older machines. Safety is job #1. I use state-machine programming in lieu of interrupts and my entire loop scans at <1ms on a 100MHz Explore. |
||||
| Tinine Guru Joined: 30/03/2016 Location: United KingdomPosts: 1646 |
Should the CPU go brain-dead, the outputs could freeze in whatever state. |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 7937 |
All true, Tinine. :) Control systems are potentially dangerous. That's what makes them fun to design. You get to figure out what *can* potentially go wrong while sorting out what human stupidity can also do. :) On all-relay systems wires drop off, get trapped & short to earth, supplies fail, timers don't (or do when they shouldn't), contacts get stuck open, closed and indeterminately... the list is endless. Electronics just adds another entertaining dimension. Users are notorious for ignoring low battery warnings and overriding automatic systems to extend the tea break. :) I've seen motor starters pushed in with a stick then jammed in with wedges... Emergency stop loops (at least the ones I used to design in) were generally designed to kill power to all the outputs from the PLC so that everything drops out. An input from the loop also tells the PLC that it's lost control so it *should* reset everything and raise an alarm (if it can still do anything). On some systems I've killed power to the PLC too, but that's not always a good idea, in my experience, as it can make debugging difficult. Some of the early PLCs used battery-backed RAM to hold flags, timer settings etc. Guess what? The battery has failed so if you power the PLC off all that has gone. One of the first things you learn is to trust nothing, especially anything where you can't see the contacts physically move. lol I think I was probably in that job too long... :) Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| Tinine Guru Joined: 30/03/2016 Location: United KingdomPosts: 1646 |
Funny that you bring up this machine safety issue. Since relocating to the UK (from US), I have discovered a serious problem/opportunity. There are thousands of the type of machines that I specialise in, fitted with either safety mats, barriers or laser-scanners. True, these are approved safety devices but not implemented in a safety circuit. They simply feed a HOLD input which tells the equipment to move at zero velocity. Energy is not removed from the electrical or hydraulic servo systems at all. Operators and set up personnel trigger this stop condition and proceed to stick their hands in potentially finger chopping areas because they believe that they are safe!!!! In North America, we would have to remove all energy, it is termed Zero Energy Hold (ZEH). Just recently, I was visiting a client and overheard a manager, talking to his maintenance guy "as long as we are safe when standing on the safety mat". I interrupted and informed him that if anything, they are in more danger when on the mat. At least when the machine is in motion, it's obvious that you don't go sticking your hands in there. A sudden loss of feedback on a closed-loop servo system will result in a full-speed flyaway. So much for safety inspectors...they ain't got a clue. I am putting together a proposal for a retrofit ZEH system. Who's gonna refuse?  |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 7937 |
This is always a problem. The presence of a safety device leads people to think that they can depend on it to keep them safe. That isn't the case. It is there in case something goes seriously wrong, in which case it will *attempt* to keep them safe. Safety is primarily something for the operator to look after, not the hardware and certainly not the software. I'm not sure about ZEH on a hydraulic system. I used to work on fork lift trucks and the starting and stopping of hydraulic pumps isn't recommended too frequently. I suspect something like a ZEH system would use a normally open solenoid valve from the output of the pump back to the tank, effectively bypassing the hydraulic controls until it's energised. That way the pump runs continuously but can't pressurise, which I suppose isn't really ZEH. :) Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| Tinine Guru Joined: 30/03/2016 Location: United KingdomPosts: 1646 |
Inverter drives are inexpensive, just spin the motor down and back up again. No abrupt stop/start routine. But yeah, I would also open the lines to tank. There have been issues where a person has been trapped and releasing them required re-pressurising the circuit...ugh, not a pretty sight. |
||||
| BrianP Senior Member Joined: 30/03/2017 Location: AustraliaPosts: 292 |
Guys, I am uplifted! What a refreshing commentary on life in the REAL world - so missing these days. I am reminded of the Internet maxim TNO - Trust No-One. Here's an abbreviation - TN - Trust Nothing! (applies to electrical & mechanical & everything else). During my working life (still working) I have always tried to be aware of the surroundings & take extra care accordingly. Such as the sparky rule "touch with the right hand - not the left one" (if you get zapped your heart is on the left). I remind you of that Irish gentleman called Murphy - he has multiple rules to remember: ) If anything can go go wrong it will - at the most inconvenient time... ) Expect the unexpected... etc. etc. etc. So if you think your code is perfect then it is most likely NOT... And because we think we are invincible we love to put our toes in all sorts of ponds... Cheers B |
||||
| Tinine Guru Joined: 30/03/2016 Location: United KingdomPosts: 1646 |
For me, the ultimate controller is a combination of the MM and a Parallax Propeller. The Prop has eight independent processors with shared memory. No need for interrupts at all. Might sound a bit daunting but it really is easy to work with. Several languages are supported, including BASIC. I particularly like PropBASIC because it translates BASIC syntax directly to equivalent Assembler code (PASM). I wrote a quadrature decoder in PropBASIC that can handle close to 2MHz (chip runs @80MHz). Standard industrial, rotary encoders max out at 500KHz. No interrupts required. One of the eight processors, performs the decode, increments/decrements the count and shoves it in the shared memory. Other processors can then grab the count and use it for whatever purpose. Nice! The new Prop, dubbed P2 will soon be shipping and this one is simply mind-blowing. Every pin is a smart pin, capable of several functions. Of particular interest to me is the fact that every pin can decode quadrature signals at very high frequencies. Heck, the most I have ever seen of any other ucontroller is a maximum of two QEIs (quadrature encoder interfaces). The P2 still has eight processors but much more memory, more pins and greater speed. "FastSpin" supports Basic, C and the proprietary Spin languages...and they can all be mixed! MM interpreter on the front end and Prop for real-time, deterministic control.  |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 7937 |
I like the KISS principle for control. The less active bits the better. Plug-in relays for outputs. Opto-isolated inputs if at all possible. If you want special high speed stuff then farm it out to a dedicated chip. Everything should be compartmentalized. Putting too much on one chip is asking for trouble. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| Tinine Guru Joined: 30/03/2016 Location: United KingdomPosts: 1646 |
That's the beauty of the Prop; it has eight independent, high-speed compartments (32bit processors @80 MHz). And they can be configured as soft peripherals. Examples: I have a project where my MM needs an extra 16 com ports. Any single Prop processor can be configured as 4 com ports so I dedicate 4 processors to be soft com ports. I need my MM to drive 6 coordinated stepper motors. The Prop becomes the driver/coordinator. I need my MM to drive 3 servo motors which require a PID of, say 2KHz, a velocity profile generator and high speed position feedback (typically a quadrature encoder). No problem for the Prop. I need my MM to keep track of high speed counters. The Prop has 2 counters per processor, each able to count @80MHz. I need my MM to drive 24 PWMs. The prop can drive 8 PWMs per processor. I need my MM to drive a VGA display. One Prop processor becomes a VGA driver. The list is endless but my point is that I can cover soooo many diverse control applications with the same two devices and here I am referring to the lowest performing MM and the lowest performing Propeller. Eight slave processors @20MIPS each, on a single chip and it's even available as a 40 pin DIP. Edited 2019-11-04 16:58 by Tinine |
||||
| JohnL Senior Member Joined: 10/01/2014 Location: SeychellesPosts: 128 |
I did look at prop at few stages but it looked very odd. Following is not my opinion but a quote from another forum. |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 7937 |
My arguments against the prop for industrial control would be: 1. Supplier dependency. Ok, the PIC is single supplier too, but most of their chips have several almost-equivalents and many are backward-compatible to a large extent. It's difficult to avoid the single supplier trap now, unless you design with microprocessors rather than micro-controllers, but the bigger the manufacturer's range the more likely he is to stay in business for the next 20 years. If you can't support it for the next 20 years then don't bother. :) 2. 8 cores may well be fine, but not on a single chip. Spread them over 8 chips - even if the system is much slower - and the system is more reliable. The Micromite range isn't great for industrial control either. Primarily it simply hasn't got the I/O capability. You *need* distributed I/O running to a minimum of 256 I/O points for most systems. Sometimes thousands of I/O. The best bet is to use COM1 to handle remote I/O modules over a multi-drop RS485 system. A suitable library might then allow access to individual I/O points as if they were local. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| Tinine Guru Joined: 30/03/2016 Location: United KingdomPosts: 1646 |
@JohnL Yes, I have seen that forum post before. The author completely misses the point. For me, *industrial control* is about controlling not only digital I/O but also motion. The robotics and CNC industries continue to grow. Show me an ARM device that, without any support devices can read up to 16 quadrature encoders. Heck I don't even know of any dedicated motion chips that can do this....and I'm talking about a 2006 device, not the new P2. The Prop is absolute child's play to program....one can be up and running in a heartbeat. Now, have a look at the tool chain required for the XMOS devices...pretty darned scary. What if you wanted say 10 I2C ports on the ARM or 16 Com Ports? With the ARM, you get what you are given, Period. Parallax decided *not* to be a me-too supplier of ucontrollers. Ever experienced interrupt hell? The Prop gives us multi-processor multitasking. The small memory? True, the P1 has 2K dedicated to each processor *BUT* 32K of shared memory. The P2 has 512K. There are several memory models available...the time critical stuff is usually only small anyway and so you can elect to have one or more processors running on their own 2K for maximum speed. Then you can have other code that might not be so time critical (4 times slower) utilising the larger memory. Each CPU can be dynamically and rapidly loaded with altogether different code at any time. @Mixtel90 The P1 is open source. You can have as many as you want without spending a dime with Parallax. Just buy the FPGA and load it up. Reliability is not an issue and a half-duplex bus cannot compete with the speed. Anywhere you have wires and some klutz of a maintenance guy can bring the show to a standstill. |
||||
| Page 1 of 2 |
|||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
