Sorry, no isolation. Input resistor selectable voltage (on bottom, easy to modify), outputs Infineon high side power switches (FETS). Propeller on board. As a stand alone, isolated RS485 communication possible
Over the decades I have been involved in developing systems to control many things. In industry, in the military, whatever.
Never seen a PLC. I have no idea what they are about.
I encountered them for the first time about 4 years ago while working on a commercial product (emissions monitoring systems for tankers, cruise ships, etc.). The reason they were using PLCs was because the bulk of the system was originally designed without any input from a software engineer, only electrical and mechanical engineers. Once I understood the electro-mechanical origins of PLCs (and Ladder Logic), I totally understood why they chose to use PLCs. The system made heavy use of relays, contacts, pumps, valves, etc. Exactly the kind of thing PLCs were intended to interface with. Mind you, I didn't agree with the choice, just that I understood the choice. As it turns out, it's good that I didn't have a say in the use of PLCs! Without exception, every ship we've installed the system on heavily rely on PLCs to run their engines and related systems, and they always expected communication between our system and theirs to be via MODBUS. Now, obviously, you don't need a PLC to use MODBUS, but the interface strongly favors a PLC back-end!
Interestingly, modern PLCs and Ladder Logic bear a passing resemblance to the same concept behind FPGAs and HDLs, but for a very different domain. Yeah, I know. It's a stretch. But not as much of one as you think once you start delving into the way these things actually work under the hood.
@Seairth: the communication bus type depends on the PLC manufacturer. Other brand uses profibus/profinet, unitelway, ....
Nearly every brand supports ladder because when the PLC's born their main aim was to replace the relay logic in industrial machinery control boxes. Thus to make it smoother, you can take the same wire diagram of the relay logic and draw into the PLC obtaining the same function. Easy for electricians (that are not programmers).
The instruction list is more similar to assembler than forth I think. In any case there are cases where you are forced to use it (or structured text) because there are things that with ladder logic are simply impossible.
All of the IEC 61131-3 standard languages are generally interpreted by the PLC that have its own operating system that is acting behind the schemes.
Basically in all the PLC you have3 phases: inputs acquisition, program execution, outputs driving. Some PLC reverse the phase order but the functioning doesn't change.
During the inputs acquisition a picture of all the inputs is taken and stored in internal "shadow" ram. During your program execution you read input state from the ram and drive outputs into the ram (another shadow copy of phisical outputs). After the program execution the ram copy is transferred to the outputs.
So eg in microcontrollers if you:
S Out1
R Out1
S Out1
you will see the output toggling based on mcu sysclock (clocks/instruction) rate.
With PLC only the last state is transferred to the physical output, what toggles is output image in ram. Same happens for inputs. All the program will see the same state. In MCU between an input test at the beginning and the same test at the middle-end of the program can give you two different states if the input is physically switching. That means that you can't drive inputs/outputs faster that the whole program scan cycle.
Also you can't wait in loops for a given condition because the whole program execution time must be less than the watchdog period (which for siemens defaults to 650ms, but you can change it).
All supports realtime state debugging, many single stepping (if not forbidden due to hw config, where there is time critical programs).
This is some aspects from the sw side. The hw of a PLC is based on 1 (or more) CPU cards and input/output/function cards as expansion, all with industrial grade temperature ranges, optoisolated inputs/outputs, many times with galvanic isolation. A PLC warranty you at least 10 years after EOL of spare parts.
In more complex systems you have high availability with double set of cpu/input/output cards running the same program. Now a days also the emergency system runs over a bus safely from a security point of view. Over the bus you control inverters and you drive motors with virtual shafts .....
From a PLC point of view the max complexity is in paper mills and iron mills industry and usually PLC manufacturers are fighting to sell their PLC brands in these industries and often time develop and/or support the machinery directly with their employed engineers. Because this shows how powerful are their PLCs and how well they performs in a time-critical environment that is at the same time very harsh because of dust and temperature.
These PLCs look like some parallel universe where a lot of programming is going on to get stuff done in factories and such. Totally detached from the the universe of normal programming and programmers.
Of course there are other parallel universes of programming. For example we hear there is a lot of COBOL in use and still being written in the financial world. After decades moving around various industries programming it's only recently I met a COBOL programmer for the first time. Wow, it was like making contact with an extra terrestrial intelligence! Despite working on process control systems for a long time I have never met anyone who programs a PLC.
This is a bit of a problem. Lessons learned in one programming universe don't make it over to the others so easily. For example security issues. Google "stuxnet" for a great example.
I remember one of my instructors in CS, who was the head of F-22 software development got a big laugh when I told him I programmed in Ladder Logic. He had never heard of it and didn't believe it existed.
Same with most of my classmates.
Most folks have no idea what exists outside of their own little world.
I used to work on a large sortation machine that was used to sort small packages, this was about 20 years ago.
The system had 300+ carts which had a belt that ran transverse to their axis of motion on a large loop, they made up in effect a continuous train.
Each end of the loop had 6 induction lanes that would load packages onto the carts as they moved by. There where rows of double stacked chutes on the sides of the loop where the carts would eject the packages. An air powered flap at the chute would determine if the ejected package went into the upper or lower chute. The system was controlled by Allen Bradley PLC's. There was one main controller and a separate smaller PLC for each of the induction lanes, a boat load of I/O modules to drive everything. Large number of photo-interrupt modules for detecting positioning. The printout of the ladder logic was two 4 inch thick binders of green bar paper. A PC drove the main PLC and received lane/package information from 4 PC's running Verbex voice recognition cards. It was very impressive to see the system in operation, we would typically sort around 12,000 packages per hour over a 3 to 4 hour shift.
My hobby is electronics, my job is industrial automation. When I first learned about PLC when I was still in the university, it did not make any sense to me at all to pay thousands of bucks for an automation controller to do something that we can do for a couple of bucks with microcontrollers. Now that I see what is happening in factories, I realize how I was wrong.
One hour downtime in the plants where I work translate in a loss of 5,000-15,000$. The cost of the controller is negligible. Replacing a faulty IO card or CPU with a spare is a matter of minutes and distributors can ship parts so we receive them the next day. The software to program these serve both purpose of programming and debugging at the same time. Text programming is a pain for electricians and technicians. Most IEC 61131-3 languages used to program those are visual. (we mostly use ladder logic and sequential function chart). As you look in the code (when working online with the controller), you can see the values of the variable change and analyze what is happening. Take a look at this example ladder rung : https://goo.gl/7qu3eE
Also, the most notable feature is online edits. That means that you can modify the program (e.g. changing a ladder rung) while the production is running, this saves you a lot of downtime. Most of the time, I'm adding new program features to the controller during shifts. You can be more than one at the same time online with the PLC, so the electricians debugging another problem in the plant on the same controller as me and changing some lines of code don't interfere with what I'm doing (unless we work on the exact same ladder routine).
In the world of industrial automation, compiling code and flashing a microcontroller memory or modifying a computer program forcing a shutdown of operations everytime does not work. Also, not everyone are geniuses like the people on this forum and can program like pros. Most electricians are only able to force/bypass some bits of logic allowing the production to continue when a particual photoeye or limit switch is broken. The core code often is not changed that much once the plant is running well.
Don't be mistaken and think that PLC and ladder logic is only good for dumb stuff (buttons, relays and valves). Where I work, we designed a machine that wraps a bundle of wood. The PLC used is an ControlLogix from Allen-Bradley. The machine is all servo-motors (not your typical hobby servo) and pneumatics. It's more than 12 motion axis that we have to synchronize together to grab the paper and staple it on the bundle. I'll take a video tonight and edit my post so you can see it in action.
But all of what I'm saying is for automating a production line. I think it is perfectly fine that someone that makes a device (let's say a metal detector before putting food in its package to prevent putting a fallen screw in it) uses the microcontroller of his choice. As long as spares are available if something breaks. Electrical cabinets housing PLC are often used for more than 20 years, replacement parts are still available.
Sorry for disrupting this thread with all of this PLC talk.
Also, the most notable feature is online edits. That means that you can modify the program (e.g. changing a ladder rung) while the production is running, this saves you a lot of downtime. Most of the time, I'm adding new program features to the controller during shifts. You can be more than one at the same time online with the PLC, so the electricians debugging another problem in the plant on the same controller as me and changing some lines of code don't interfere with what I'm doing (unless we work on the exact same ladder routine).
This must be 'on-line', but not quite 'live' in the true sense.
ie they must have some means to Edit and then apply/save when done, as you do not want live machinery running half-written code branches!
How exactly do they manage that Edit-then-replace, and is there any audit trail and undo ?
How exactly do they manage that Edit-then-replace, and is there any audit trail and undo ?
It's a very integrated IDE. The user doesn't see the PLC<->IDE interaction beyond the start-edit and commit-edit commands. The live monitoring stays active the whole time but yes, the changes to the rung being edited is not committed until it's valid and you tell it to.
Yes, you double click on a rung and you end up with two rung, the old one and the edited one. You have an apply button to replace the old one with the new one when you are done.
I dont think the online edit is implemented though
Nice examples, but I think that may have hit a dead end ?
Any live links, or something working on Prop ?
This would be a better fit on P2, and P2 could (eventually) use the likely C-output many such tools will generate ?
...air-pistons with micro switches at either end so you can read actual state.
Test was to make piston-1 move twice back and forth then piston-2 moves once.
Wow, tonyp12, you have just reminded me of one of my proudest moments.
On a training course back in 1980 we were given exactly that task. Two pneumatic rams, about a meter long each, a bunch of spool valves and tubes. Make one ram oscillate back and forth, make the other do one stroke for every two strokes of the first. Basically a binary counter in "air logic".
After scratching my head a bit I drew out a digital counter using two flip-flops made of NAND gates. Then translated that logic circuit into a system of spool valves and pneumatic RAMS.
Me and my two mates were the only team to complete that task.
That programming system you describe sounds similar to the Luco language used by Lucas Aerospace for controllers of jet engines and flight controls. All inputs get read every 10 or 100ms. Some processing happens. All outputs get written out. That processing step did not support loops. It could only change it's state according the inputs and write the outputs.
The beauty of Lucol was that the compiler could always tell you exactly how long things took to run. You could never overrun your 10/100 ms time quota on any iteration.
I totally appreciate why PLCs exist. Hardware and software wise.
Twenty years ago I was amazed to find that all the traffic light controllers in Scandinavia supported a very rude and crude scripting language that allowed traffic engineers to tweak the logic of a running intersection controller.
That was put in place in 1978 or so when the first micro-controller based traffic lights were created. When I arrived on the scene we had to modernize all the hardware and rewrite the software in C. We had to support that scripting system though.
When a competitor arrived on the scene they had to clone that scripting system to have any chance of getting in to the market.
We had a lecturer who was fascinated by fluidics - using jets of fluid to control other jets with no moving parts.
My dad worked in aerospace and he said that microfluidic computers had been developed for space applications where a fine pattern was etched into a thin stainless steel plate whose face was bonded to another plate. The etched pattern formed the logic. It could run off a sphere of compressed gas for some long period of time.
Wow, another long forgotten blast from the past. We also learned of fluidic logic back in that school. They even had a bunch of fluidic gates. Made of plastic. Never did anything practical with them though.
My hobby is electronics, my job is industrial automation. When I first learned about PLC when I was still in the university, it did not make any sense to me at all to pay thousands of bucks for an automation controller to do something that we can do for a couple of bucks with microcontrollers. Now that I see what is happening in factories, I realize how I was wrong.
One hour downtime in the plants where I work translate in a loss of 5,000-15,000$. The cost of the controller is negligible. Replacing a faulty IO card or CPU with a spare is a matter of minutes and distributors can ship parts so we receive them the next day. The software to program these serve both purpose of programming and debugging at the same time. Text programming is a pain for electricians and technicians. Most IEC 61131-3 languages used to program those are visual. (we mostly use ladder logic and sequential function chart). As you look in the code (when working online with the controller), you can see the values of the variable change and analyze what is happening. Take a look at this example ladder rung : https://goo.gl/7qu3eE
Also, the most notable feature is online edits. That means that you can modify the program (e.g. changing a ladder rung) while the production is running, this saves you a lot of downtime. Most of the time, I'm adding new program features to the controller during shifts. You can be more than one at the same time online with the PLC, so the electricians debugging another problem in the plant on the same controller as me and changing some lines of code don't interfere with what I'm doing (unless we work on the exact same ladder routine).
In the world of industrial automation, compiling code and flashing a microcontroller memory or modifying a computer program forcing a shutdown of operations everytime does not work. Also, not everyone are geniuses like the people on this forum and can program like pros. Most electricians are only able to force/bypass some bits of logic allowing the production to continue when a particual photoeye or limit switch is broken. The core code often is not changed that much once the plant is running well.
Don't be mistaken and think that PLC and ladder logic is only good for dumb stuff (buttons, relays and valves). Where I work, we designed a machine that wraps a bundle of wood. The PLC used is an ControlLogix from Allen-Bradley. The machine is all servo-motors (not your typical hobby servo) and pneumatics. It's more than 12 motion axis that we have to synchronize together to grab the paper and staple it on the bundle. I'll take a video tonight and edit my post so you can see it in action.
But all of what I'm saying is for automating a production line. I think it is perfectly fine that someone that makes a device (let's say a metal detector before putting food in its package to prevent putting a fallen screw in it) uses the microcontroller of his choice. As long as spares are available if something breaks. Electrical cabinets housing PLC are often used for more than 20 years, replacement parts are still available.
Sorry for disrupting this thread with all of this PLC talk.
Yes, the cost is negligible many times. In the plants I work for, because of the production chain, 1 hour of downtime on a machine translates to a loss of nearly 100K$. Because if there is no buffers in the production chain the stop of broken machine is only delayed for the next one because even if working it miss the parts to process. And this can happen along all the production line.
But I do not agree for ladder logic as I consider it limited. You need to consider that with ladder you are many times interacting with function blocks (function card drivers for example) and these function blocks are all written in instruction list or sometimes in structured text.
An instruction list (structured text) chunk of code with the addition of a couple of instructions can be used in ladder logic.
It is true that maintenance people (electricians or automation technicians) in the factory have many times troubles understanding instruction list. For this reason we receive many times specifications form customers that states that they want the program in ladder. In this case all the code interacting with in/out (emergency circuit, inhibits, interloocks, safety switches, overload protections ...) is made in ladder but the core functions are always written in instruction list and those people rappresenting the program in ladder see a rectangular box with all the inputs and outputs to it. But internally this box is not written in ladder. Thus we can say that the process control is written in higher level languages while the IO interfacing is written in ladder.
Also, the most notable feature is online edits. That means that you can modify the program (e.g. changing a ladder rung) while the production is running, this saves you a lot of downtime. Most of the time, I'm adding new program features to the controller during shifts. You can be more than one at the same time online with the PLC, so the electricians debugging another problem in the plant on the same controller as me and changing some lines of code don't interfere with what I'm doing (unless we work on the exact same ladder routine).
This must be 'on-line', but not quite 'live' in the true sense.
ie they must have some means to Edit and then apply/save when done, as you do not want live machinery running half-written code branches!
How exactly do they manage that Edit-then-replace, and is there any audit trail and undo ?
There is some misunderstanding here or FredBlais was not clear enough. When I said in the previous post that the PLC have its own OS, that any language is basically interpreted (more or less like spin on propeller) there is many other things happening behind the scenes.
The code in the PLC is divided in blocks. You have many type of blocks (autostarting blocks, function blocks, data blocks ....). The autostarting blocks are like the main in many languages. This is triggered by the OS after/before IO shadowing in ram. This is your main program. You can write everything here but like in any language it is good to logically/functionally divide the code, using function blocks in this case. Other kind of autostarting (automatically called by OS) blocks can be interrupts, diag events, .....
You normally work on an offline copy that is more comprehensive than the online. Eg offline you have comments, you have a symbolic table for the IOs, you chose the labels name (jump targets). In the online generally all this is missing. When you debug through the offline project, in the realtime states screen you see all the offline information. But having in the online copy all the configurations and code (more or less) means that you can debug the program even without the project, only the ide is enough. The ide shows you (ladder or code lines) in the same way but some info is missing (coments, symbols, labels: instead of having your logic names they are numbered numerically from the top to the bottom, ...). Of course you can do everything only with the "online copy" if there is no copy protection (know-how) in place, but the ide and the offline project allows you to document everything.
Where is the magic. All the IEC 61131-3 standard languages shares a calling standard. There is a block interface version and unless the block interface remain the same (there isn't any change in the exchanged parameters/arguments) you can replace the block of code without any pain and without the need to upload/update the parent block that is calling the modified one. Moreover you can change the programming language so if a block before was in ladder you can rewrite il in instruction list and replace "live" (when the machine is working). Sometimes is enough to change the representation: you can always view a ladder block in instruction list format, the opposite is not always true because there is instructions that can't be translated in ladder.
When FredBlais said online editing is because he feels like that. Really the IDE downloads the online block, enable you to edit it, and then uploads again the modified version. How the uploads work: the block get copied in a new memory area and then the pointer to its beginning is changed and the old block's memory area becomes free.
If you change the interface also the parent block must be updated because the calling structure may be different (this can involve calling stack and other things). Also here, the IDE usually allows you to select which blocks to upload. If you select multiple blocks (can be program blocks or data blocks for example) they get uploaded in the order you have chosen them but all the pointers are then modified synchronously at the end of the upload. This, by carefully choosing the upload order, gives you the opportunity to change the code while the machine is in production. Skilled and confident (in his skills) programmers/developers do this many time.
Fluid logic is pretty common in my opinion. Nearly every hydraulic valves block have some logic built-in. Eg two one direction valves with shorted outputs forms an or. Also for a regenerative circuit for a cilinder we can claim that it have a sort of fluid logic. Even variable flow pumps on hydraulic powerstations have fluid logic.
You have also many logic blocks in pneumatics but here are not used/seen so often.
dMajo,
What little experience I have with PLC function blocks, and I'll extrapolate that to all block types, they don't actually call each other. In that the execution does not flow serially through the linkages. They are effectively separate tasks that can signal each other.
getting back on topic, I would like to share my point of view on the state of microcontrollers.
My first experience with mcu (in 2007) was with assembly on a PIC18. This was painful. I learned a lot from the process though.
Later, I saw an ad with the Propeller chip in the Elektor magazine if I recall correctly. I decided to buy the Hydra gaming system from Andre LaMothe and joined the forum in 2008. I was amazed at how easy the chip was to use. Easy to set-up on a breadboard, you basically just need caps, xtal, prop and eeprom. I also like the Propeller Tool software a lot, learning how to use it is a matter of minutes. I think Spin is pretty intuitive too, clean syntax that makes the code easy to read.
I was introduced to the Arduino around the same time that I learned about the Propeller. I did not like the Arduino as much as I liked the Propeller. The community is much more fun here too. Who would want a 8bit 16MHz mcu when you can have 8 80MHz 32bit mcu in the same chip? IMHO
The game changer now is the Raspberry Pi and all the Linux boards. A lot of people use them as media centers or retro game console. I'm not interested in that. What I like to do is to work headless on the Linux box and program it with high level languages like Python and use web framework such as Flask and Django. It is perfect for applications like home automation and remote control/monitoring. The real feature for me is the internet connectivity and SSH access to the board to program it.
What the Pi lacks is fast IO and determinism. Something easily achieved with the Prop.
I bought an Intel Edison as soon as I could get my hands on one. What appealed to me was the fact that it was a Dual Core Atom + Quark MCU. It took several months before they unlocked the MCU. I tried it and it is Smile. It does not even run bare metal and is not fast enough to drive a strip of WS2812 LEDs. In the end, I need to add a dedicated microcontroller for that task!
It is true that the forum seems less active since 1 or 2 years. The P1 chip is still capable, but I think that the when the P2 will come out, it will generate a lot of interested and the new stuff will attract newcomers in the forum. Maybe some people that left the forum will come back.
Just give me a P2 that can host a web pages and can do Ajax with a web browser and I will be happy to put back all my Linux boards in the drawer. It would be a big plus if we can find a way to remote flash the Prop eeprom too.
I know this has been done before with the P1, but I think it now has to be an out of the box experience (cheap and easy to get going). A bit like how easy it was to hook-up a keyboard, mouse and TV to P1.
I bought an Intel Edison as soon as I could get my hands on one. What appealed to me was the fact that it was a Dual Core Atom + Quark MCU. It took several months before they unlocked the MCU. I tried it and it is Smile. It does not even run bare metal and is not fast enough to drive a strip of WS2812 LEDs. In the end, I need to add a dedicated microcontroller for that task!
The newest Edison variants claim to have a 100MHz 32b Microcontroller - as well as the Dual Core quark.
Were you able to drill down far enough to get at that microcontroller ?
Info on that sub-section seems sparse, but I guess it is similar to their recent 32MHz D2000 ?
It is true that the forum seems less active since 1 or 2 years. The P1 chip is still capable, but I think that the when the P2 will come out, it will generate a lot of interested and the new stuff will attract newcomers in the forum. Maybe some people that left the forum will come back.
Just give me a P2 that can host a web pages and can do Ajax with a web browser and I will be happy to put back all my Linux boards in the drawer. It would be a big plus if we can find a way to remote flash the Prop eeprom too.
I know this has been done before with the P1, but I think it now has to be an out of the box experience (cheap and easy to get going). A bit like how easy it was to hook-up a keyboard, mouse and TV to P1.
The P2 has to be ready for IoT.
With a lot of USB ports, the P2 can easily become a smart-hub.
Just give me a P2 that can host a web pages and can do Ajax with a web browser and I will be happy to put back all my Linux boards in the drawer. It would be a big plus if we can find a way to remote flash the Prop eeprom too.
I know this has been done before with the P1, but I think it now has to be an out of the box experience (cheap and easy to get going). A bit like how easy it was to hook-up a keyboard, mouse and TV to P1.
Comments
When I first glanced through that, I thought I read, "Javascript is predicated on the idea of tweets." I suppose anything is possible.
Ahh, another design.
This one handles the multi-direction connectors better, but only fits some Pi's.
Wonder why they did not continue this approach, for their cases for newer Pi's ?
Maybe that's a better way to explain it to the young'ns now a days.
Nearly every brand supports ladder because when the PLC's born their main aim was to replace the relay logic in industrial machinery control boxes. Thus to make it smoother, you can take the same wire diagram of the relay logic and draw into the PLC obtaining the same function. Easy for electricians (that are not programmers).
@jmg: the picture you've showed are toys, not PLC. This are PLC's (ok, there is also your toys here, but you should look at multicard compositions):
https://www.google.it/search?q=siemens+plc+pictures&tbm=isch
https://www.google.it/search?q=schneider+electric+plc+pictures&tbm=isch (ex telemecanique https://www.google.it/search?q=telemecanique+plc+pictures&tbm=isch)
https://www.google.it/search?q=ge+fanuc+plc+pictures&tbm=isch
https://www.google.it/search?q=omron+plc+pictures&tbm=isch
https://www.google.it/search?q=allen+bradley+plc+pictures&tbm=isch
The instruction list is more similar to assembler than forth I think. In any case there are cases where you are forced to use it (or structured text) because there are things that with ladder logic are simply impossible.
All of the IEC 61131-3 standard languages are generally interpreted by the PLC that have its own operating system that is acting behind the schemes.
Basically in all the PLC you have3 phases: inputs acquisition, program execution, outputs driving. Some PLC reverse the phase order but the functioning doesn't change.
During the inputs acquisition a picture of all the inputs is taken and stored in internal "shadow" ram. During your program execution you read input state from the ram and drive outputs into the ram (another shadow copy of phisical outputs). After the program execution the ram copy is transferred to the outputs.
So eg in microcontrollers if you:
S Out1
R Out1
S Out1
you will see the output toggling based on mcu sysclock (clocks/instruction) rate.
With PLC only the last state is transferred to the physical output, what toggles is output image in ram. Same happens for inputs. All the program will see the same state. In MCU between an input test at the beginning and the same test at the middle-end of the program can give you two different states if the input is physically switching. That means that you can't drive inputs/outputs faster that the whole program scan cycle.
Also you can't wait in loops for a given condition because the whole program execution time must be less than the watchdog period (which for siemens defaults to 650ms, but you can change it).
All supports realtime state debugging, many single stepping (if not forbidden due to hw config, where there is time critical programs).
This is some aspects from the sw side. The hw of a PLC is based on 1 (or more) CPU cards and input/output/function cards as expansion, all with industrial grade temperature ranges, optoisolated inputs/outputs, many times with galvanic isolation. A PLC warranty you at least 10 years after EOL of spare parts.
In more complex systems you have high availability with double set of cpu/input/output cards running the same program. Now a days also the emergency system runs over a bus safely from a security point of view. Over the bus you control inverters and you drive motors with virtual shafts .....
From a PLC point of view the max complexity is in paper mills and iron mills industry and usually PLC manufacturers are fighting to sell their PLC brands in these industries and often time develop and/or support the machinery directly with their employed engineers. Because this shows how powerful are their PLCs and how well they performs in a time-critical environment that is at the same time very harsh because of dust and temperature.
Of course there are other parallel universes of programming. For example we hear there is a lot of COBOL in use and still being written in the financial world. After decades moving around various industries programming it's only recently I met a COBOL programmer for the first time. Wow, it was like making contact with an extra terrestrial intelligence! Despite working on process control systems for a long time I have never met anyone who programs a PLC.
This is a bit of a problem. Lessons learned in one programming universe don't make it over to the others so easily. For example security issues. Google "stuxnet" for a great example.
Same with most of my classmates.
Most folks have no idea what exists outside of their own little world.
Test was to make piston-1 move twice back and forth then piston-2 moves once.
As a BASIC programmer at the time could not grasp its state-machine reads all instructions all the time,
there is no sequence, while or local loops.
As it has 8 internal memory, I know now decades later I should used one of those and toggle it,
so I could make pistion1 go twice.
The system had 300+ carts which had a belt that ran transverse to their axis of motion on a large loop, they made up in effect a continuous train.
Each end of the loop had 6 induction lanes that would load packages onto the carts as they moved by. There where rows of double stacked chutes on the sides of the loop where the carts would eject the packages. An air powered flap at the chute would determine if the ejected package went into the upper or lower chute. The system was controlled by Allen Bradley PLC's. There was one main controller and a separate smaller PLC for each of the induction lanes, a boat load of I/O modules to drive everything. Large number of photo-interrupt modules for detecting positioning. The printout of the ladder logic was two 4 inch thick binders of green bar paper. A PC drove the main PLC and received lane/package information from 4 PC's running Verbex voice recognition cards. It was very impressive to see the system in operation, we would typically sort around 12,000 packages per hour over a 3 to 4 hour shift.
C.W.
My hobby is electronics, my job is industrial automation. When I first learned about PLC when I was still in the university, it did not make any sense to me at all to pay thousands of bucks for an automation controller to do something that we can do for a couple of bucks with microcontrollers. Now that I see what is happening in factories, I realize how I was wrong.
One hour downtime in the plants where I work translate in a loss of 5,000-15,000$. The cost of the controller is negligible. Replacing a faulty IO card or CPU with a spare is a matter of minutes and distributors can ship parts so we receive them the next day. The software to program these serve both purpose of programming and debugging at the same time. Text programming is a pain for electricians and technicians. Most IEC 61131-3 languages used to program those are visual. (we mostly use ladder logic and sequential function chart). As you look in the code (when working online with the controller), you can see the values of the variable change and analyze what is happening. Take a look at this example ladder rung : https://goo.gl/7qu3eE
Also, the most notable feature is online edits. That means that you can modify the program (e.g. changing a ladder rung) while the production is running, this saves you a lot of downtime. Most of the time, I'm adding new program features to the controller during shifts. You can be more than one at the same time online with the PLC, so the electricians debugging another problem in the plant on the same controller as me and changing some lines of code don't interfere with what I'm doing (unless we work on the exact same ladder routine).
In the world of industrial automation, compiling code and flashing a microcontroller memory or modifying a computer program forcing a shutdown of operations everytime does not work. Also, not everyone are geniuses like the people on this forum and can program like pros. Most electricians are only able to force/bypass some bits of logic allowing the production to continue when a particual photoeye or limit switch is broken. The core code often is not changed that much once the plant is running well.
Don't be mistaken and think that PLC and ladder logic is only good for dumb stuff (buttons, relays and valves). Where I work, we designed a machine that wraps a bundle of wood. The PLC used is an ControlLogix from Allen-Bradley. The machine is all servo-motors (not your typical hobby servo) and pneumatics. It's more than 12 motion axis that we have to synchronize together to grab the paper and staple it on the bundle. I'll take a video tonight and edit my post so you can see it in action.
But all of what I'm saying is for automating a production line. I think it is perfectly fine that someone that makes a device (let's say a metal detector before putting food in its package to prevent putting a fallen screw in it) uses the microcontroller of his choice. As long as spares are available if something breaks. Electrical cabinets housing PLC are often used for more than 20 years, replacement parts are still available.
Sorry for disrupting this thread with all of this PLC talk.
This must be 'on-line', but not quite 'live' in the true sense.
ie they must have some means to Edit and then apply/save when done, as you do not want live machinery running half-written code branches!
How exactly do they manage that Edit-then-replace, and is there any audit trail and undo ?
It's a very integrated IDE. The user doesn't see the PLC<->IDE interaction beyond the start-edit and commit-edit commands. The live monitoring stays active the whole time but yes, the changes to the rung being edited is not committed until it's valid and you tell it to.
Yes, you double click on a rung and you end up with two rung, the old one and the edited one. You have an apply button to replace the old one with the new one when you are done.
I dont think the online edit is implemented though
Nice examples, but I think that may have hit a dead end ?
Any live links, or something working on Prop ?
This would be a better fit on P2, and P2 could (eventually) use the likely C-output many such tools will generate ?
YES!!!!
On a training course back in 1980 we were given exactly that task. Two pneumatic rams, about a meter long each, a bunch of spool valves and tubes. Make one ram oscillate back and forth, make the other do one stroke for every two strokes of the first. Basically a binary counter in "air logic".
https://en.wikipedia.org/wiki/Directional_control_valve
No micro-controller or electronics.
After scratching my head a bit I drew out a digital counter using two flip-flops made of NAND gates. Then translated that logic circuit into a system of spool valves and pneumatic RAMS.
Me and my two mates were the only team to complete that task.
That programming system you describe sounds similar to the Luco language used by Lucas Aerospace for controllers of jet engines and flight controls. All inputs get read every 10 or 100ms. Some processing happens. All outputs get written out. That processing step did not support loops. It could only change it's state according the inputs and write the outputs.
The beauty of Lucol was that the compiler could always tell you exactly how long things took to run. You could never overrun your 10/100 ms time quota on any iteration.
I totally appreciate why PLCs exist. Hardware and software wise.
Twenty years ago I was amazed to find that all the traffic light controllers in Scandinavia supported a very rude and crude scripting language that allowed traffic engineers to tweak the logic of a running intersection controller.
That was put in place in 1978 or so when the first micro-controller based traffic lights were created. When I arrived on the scene we had to modernize all the hardware and rewrite the software in C. We had to support that scripting system though.
When a competitor arrived on the scene they had to clone that scripting system to have any chance of getting in to the market.
It's still in use today.
My dad worked in aerospace and he said that microfluidic computers had been developed for space applications where a fine pattern was etched into a thin stainless steel plate whose face was bonded to another plate. The etched pattern formed the logic. It could run off a sphere of compressed gas for some long period of time.
But I do not agree for ladder logic as I consider it limited. You need to consider that with ladder you are many times interacting with function blocks (function card drivers for example) and these function blocks are all written in instruction list or sometimes in structured text.
An instruction list (structured text) chunk of code with the addition of a couple of instructions can be used in ladder logic.
It is true that maintenance people (electricians or automation technicians) in the factory have many times troubles understanding instruction list. For this reason we receive many times specifications form customers that states that they want the program in ladder. In this case all the code interacting with in/out (emergency circuit, inhibits, interloocks, safety switches, overload protections ...) is made in ladder but the core functions are always written in instruction list and those people rappresenting the program in ladder see a rectangular box with all the inputs and outputs to it. But internally this box is not written in ladder. Thus we can say that the process control is written in higher level languages while the IO interfacing is written in ladder.
There is some misunderstanding here or FredBlais was not clear enough. When I said in the previous post that the PLC have its own OS, that any language is basically interpreted (more or less like spin on propeller) there is many other things happening behind the scenes.
The code in the PLC is divided in blocks. You have many type of blocks (autostarting blocks, function blocks, data blocks ....). The autostarting blocks are like the main in many languages. This is triggered by the OS after/before IO shadowing in ram. This is your main program. You can write everything here but like in any language it is good to logically/functionally divide the code, using function blocks in this case. Other kind of autostarting (automatically called by OS) blocks can be interrupts, diag events, .....
You normally work on an offline copy that is more comprehensive than the online. Eg offline you have comments, you have a symbolic table for the IOs, you chose the labels name (jump targets). In the online generally all this is missing. When you debug through the offline project, in the realtime states screen you see all the offline information. But having in the online copy all the configurations and code (more or less) means that you can debug the program even without the project, only the ide is enough. The ide shows you (ladder or code lines) in the same way but some info is missing (coments, symbols, labels: instead of having your logic names they are numbered numerically from the top to the bottom, ...). Of course you can do everything only with the "online copy" if there is no copy protection (know-how) in place, but the ide and the offline project allows you to document everything.
Where is the magic. All the IEC 61131-3 standard languages shares a calling standard. There is a block interface version and unless the block interface remain the same (there isn't any change in the exchanged parameters/arguments) you can replace the block of code without any pain and without the need to upload/update the parent block that is calling the modified one. Moreover you can change the programming language so if a block before was in ladder you can rewrite il in instruction list and replace "live" (when the machine is working). Sometimes is enough to change the representation: you can always view a ladder block in instruction list format, the opposite is not always true because there is instructions that can't be translated in ladder.
When FredBlais said online editing is because he feels like that. Really the IDE downloads the online block, enable you to edit it, and then uploads again the modified version. How the uploads work: the block get copied in a new memory area and then the pointer to its beginning is changed and the old block's memory area becomes free.
If you change the interface also the parent block must be updated because the calling structure may be different (this can involve calling stack and other things). Also here, the IDE usually allows you to select which blocks to upload. If you select multiple blocks (can be program blocks or data blocks for example) they get uploaded in the order you have chosen them but all the pointers are then modified synchronously at the end of the upload. This, by carefully choosing the upload order, gives you the opportunity to change the code while the machine is in production. Skilled and confident (in his skills) programmers/developers do this many time.
You have also many logic blocks in pneumatics but here are not used/seen so often.
What little experience I have with PLC function blocks, and I'll extrapolate that to all block types, they don't actually call each other. In that the execution does not flow serially through the linkages. They are effectively separate tasks that can signal each other.
My first experience with mcu (in 2007) was with assembly on a PIC18. This was painful. I learned a lot from the process though.
Later, I saw an ad with the Propeller chip in the Elektor magazine if I recall correctly. I decided to buy the Hydra gaming system from Andre LaMothe and joined the forum in 2008. I was amazed at how easy the chip was to use. Easy to set-up on a breadboard, you basically just need caps, xtal, prop and eeprom. I also like the Propeller Tool software a lot, learning how to use it is a matter of minutes. I think Spin is pretty intuitive too, clean syntax that makes the code easy to read.
I was introduced to the Arduino around the same time that I learned about the Propeller. I did not like the Arduino as much as I liked the Propeller. The community is much more fun here too. Who would want a 8bit 16MHz mcu when you can have 8 80MHz 32bit mcu in the same chip? IMHO
The game changer now is the Raspberry Pi and all the Linux boards. A lot of people use them as media centers or retro game console. I'm not interested in that. What I like to do is to work headless on the Linux box and program it with high level languages like Python and use web framework such as Flask and Django. It is perfect for applications like home automation and remote control/monitoring. The real feature for me is the internet connectivity and SSH access to the board to program it.
What the Pi lacks is fast IO and determinism. Something easily achieved with the Prop.
I bought an Intel Edison as soon as I could get my hands on one. What appealed to me was the fact that it was a Dual Core Atom + Quark MCU. It took several months before they unlocked the MCU. I tried it and it is Smile. It does not even run bare metal and is not fast enough to drive a strip of WS2812 LEDs. In the end, I need to add a dedicated microcontroller for that task!
It is true that the forum seems less active since 1 or 2 years. The P1 chip is still capable, but I think that the when the P2 will come out, it will generate a lot of interested and the new stuff will attract newcomers in the forum. Maybe some people that left the forum will come back.
Just give me a P2 that can host a web pages and can do Ajax with a web browser and I will be happy to put back all my Linux boards in the drawer. It would be a big plus if we can find a way to remote flash the Prop eeprom too.
I know this has been done before with the P1, but I think it now has to be an out of the box experience (cheap and easy to get going). A bit like how easy it was to hook-up a keyboard, mouse and TV to P1.
The P2 has to be ready for IoT.
The newest Edison variants claim to have a 100MHz 32b Microcontroller - as well as the Dual Core quark.
Were you able to drill down far enough to get at that microcontroller ?
Info on that sub-section seems sparse, but I guess it is similar to their recent 32MHz D2000 ?
With a lot of USB ports, the P2 can easily become a smart-hub.
I also like what EXAR did with their 'Compound Devices'
https://www.exar.com/product/interface/bridges/usb-ethernet-bridges/xr22804
These 'look' to the host like a Hub, with 6 connected peripherals.
yes it has been done on the Prop1 e.g. with Peter's IoT5500 modules and Tachyon forums.parallax.com/profile/47248/Peter%20Jakacki, but also was running on Spinneret.