Ah yes, evanh, that is an oft told story throughout industry.
It underlines one of the problems of closed source custom solutions.
This is true but at the same time, an obsolete big-name-PLC/CNC failure can present a similar problem. Bean counters don't like having spare parts on the shelf.
Personally, I have never been asked for source but have provided it anyway for hardware, software, BOM, etc.
Any company that's smart keeps spares. I worked for a cement plant and our PLC's were ancient and tied into several Gould SEL's minicomputers.
We had spares for all of it. When a plant operates 7x24 350 days a year. You can't afford not to keep spares.
Software wasn't a issue, since it was all written in-house by plant electricians and the single programmer on staff over the years. The applications on the Gould mini-computers was written by corporate and bullet proof.
It would be exceptional if PLC's from the same manufacturer didn't have a simple upgrade path. Usually no software changes needed. Can even use the binary ladder and convert it on the spot.
Also, with the sources for a PLC, or even just the binary ladder, it's a straightforward job to port over to another PLC brand.
EDIT: I recently had a conversation with a sales rep - due to the previously mentioned controller failure - and he mentioned the increased level of competition occurring between brands due to the networking standards being well established now. It seems one can now mix'n'match makes of I/O modules on the one high performance backbone.
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.
Most designs run a fast interpreter that scans user code, at some fast rate, to give a virtually parallel system.
The P1 is reasonably well suited to small PLC, and many are used that way, maybe just not called a PLC.
The P2 is probably better suited, and it would not be too difficult to do a Structured_text release for P2.
In many ways, the hard real time engine of P2, is wasted spinning Java Script, and better suited to hard real time problems.
It would be exceptional if PLC's from the same manufacturer didn't have a simple upgrade path. Usually no software changes needed.
Yup, here is one example of a simple upgrade path, to a new model engine :
["The Jazz® 2 units are also 30X Faster than their standard Jazz® counterpart with 1.5 µSec for bit operations (typical). The HMI application enables you to design up to 60 text screens, using up to 64 HMI variables for the display of time, date, and real-time system data. Programming is as easy as it gets— with a built in mini USB port, you are able to build Ladder Logic control applications using click-and-drop elements and create your HMI application in the same simple environment.
Upgrading your current Jazz® system is easy! The Jazz® 2 offers the same look, dimensions, wiring and functional behavior as it’s Jazz® series counterpart. Users are able to update their existing projects in 3 easy steps: 1. Open the application 2. Select the new model in Hardware Configuration 3. Save the application. It’s as simple as that! "]
... 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.
Yes, yes and yes.
I strongly feel Ladder Logic should be taught at secondary schools. Not only because of it's wide use in the trades but it also teaches basic logic that can easy be translated to actual chippery and the start of more extensive formal tertiary training.
There's one site I came across recently where ladder logic was banned. Haven't yet found out the background reasons. Given many tools let you swap back and forth between the iec61131 languages its not a big deal.
My experience of the major PLC vendors is they *do* have different software packages for their different series of PLCs. The AB Micro's are interesting, have high speed counters/pulse train outputs available as well as ethernet, DH+, modbus and other serial options. Quite powerful for a few hundred $ http://ab.rockwellautomation.com/Programmable-Controllers/Micro850
It's interesting hearing all the PLC talk in a microcontroller thread, but in my experience PLC's are becoming so feature-rich they end up needing regular 32-bit microprocessors (like an ARM) that have an external memory bus. This is because they need to have megabytes of RAM, communicate over ethernet with a full TCP/IP stack, serve webpages, and have enough flash memory to store the source code files with comments, many megabyte log files, and recipes databases among other things.
Inside *sensors*, though, is where you'll find the microcontrollers. Pretty much every photoeye (photoelectric sensor) has a programming mode where you hold down the button to program, tap again to teach a point or two, and then one final press to save the setting to eeprom. I've also seen an air pressure sensor that has a 4-digit 7-segment LED display. Two buttons and the display helps to program a digital output setpoint and to display the current value, in the selected unit (like psi, bar, mm-hg, etc), and configure other things like delay time or hysteresis. These micro-controller infused sensors are getting really tiny, so their circuit boards use the fine pitch surface mount components, and usually but not always a linear regulator (so they get a bit warm dropping 24V DC down to 3.3V or lower).
Furthermore, there is a sensor communication protocol now called IO-Link which is pretty much like RS232 serial but with a 0 to 24V DC voltage swing and half-duplex. It replaces overpriced analog inputs in situations where update intervals needed are less than 500 times a second (or so). It has automatic downgrade of baudrate (230.4K, 38.4K, 4.8K). Imagine something like a laser distance sensor that can shine out 20 meters and give back a 16-bit value representing the distance between the reflection and the sensor lens. You get back a precise digital number instead of a noisy analog value that is subject to drift.
Actually, "focused will" and "NO professional skill" is precisely the problem here.
No professional skill:
The over-zealous maintenance electrician who has learned enough to be dangerous has the ability to change machine control logic, willy-nilly, on the spot, to "make it better".
Focused will:
I was responsible for controlling the first ever CNC (PC-based) tube forming machine for vehicle seats. This was the only source of seat frames, at the time, for GM's mini-vans. My 5-axis tube-former would bend the the 3-D shapes which were then transferred to a press-type operation which would flatten, pierce and trim the ends of the tubes. Because this was a new development, I had to camp for months on end in Athens TN (dry county, ugh!) to watch over this thing. I was constantly being called to the machine at all hours because of a stoppage. I couldn't understand why the stoppage seemed to be always due to the PLC-controlled press that I had nothing to do with. Long story short, their in-house maintenance electrician had access to the PLC's ladder-logic and he had modified it to include a cycle-counter that would stop the machine after X cycles. Sometimes he would jumper 24v to a "spare" input and other times he would "get in to the program" to set the count to a different value. Of course, to his boss, he was the company's "computer wizard" because he always "fixed" the machine.
I needed these guys on my side therefore I couldn't expose him so I just insisted that I take control of the press logic with my PC-based controller for the subsequent machines to "provide better diagnostics".
We only hear about the many pro's of PLC's but I have to believe that what I experienced happens elsewhere.
I needed these guys on my side therefore I couldn't expose him so I just insisted that I take control of the press logic with my PC-based controller for the subsequent machines to "provide better diagnostics".
You could have worked with him instead.
We only hear about the many pro's of PLC's but I have to believe that what I experienced happens elsewhere.
For sure, everyone makes mistakes. Machines are operated for their entire existence with obvious bugs, operators work around them as best they can and can have quite detailed procedures to avoid triggering the various bugs. Sometimes those bugs are so bad that management buy another brand for the next machine, which they usually prefer not to do.
I guess this "custom tweak" by the local guru problem is endemic.
What I found in the traffic light industry is that if you ask the traffic engineers of any city how their intersection controllers are configured they cannot tell you. Sure there were timing plans drawn up by traffic consultants when a controller was installed 20 years ago, if you can find the paper work, but those parameters and programming will have been tweaked over the years. If you are lucky there is a folder of yellowing paper work inside the controller cabinet by the road with changes noted on it.
I recently got a live feed of controller data from 1200 odd intersections in and around San Jose. Great I can see, in real time, the lamp phases in all directions from every intersection, I can see vehicle and pedestrian requests coming in from the various detectors. There is no way to tell which direction is which or which detector is which! Another company spent the best part of a year figuring all that out from the old documentation and trial and error.
When I have visited factories in the past it was always fascinating to see all the little tweaks and bodges they had in place to keep everything going.
I needed these guys on my side therefore I couldn't expose him so I just insisted that I take control of the press logic with my PC-based controller for the subsequent machines to "provide better diagnostics".
You could have worked with him instead.
Oh, he resented me right from the get-go. I was a baby-faced 26 year-old Englishman and pretty much every young female in the plant wanted to take me home. Furthermore, I was getting all the "attaboys" from the GM guys for developing the CNC. I'm sure you get the picture....
their in-house maintenance electrician had access to the PLC's ladder-logic and he had modified it to include a cycle-counter that would stop the machine after X cycles. Sometimes he would jumper 24v to a "spare" input and other times he would "get in to the program" to set the count to a different value. Of course, to his boss, he was the company's "computer wizard" because he always "fixed" the machine.
Oh yeah, a similar though different story although I am sure I can dig up the "same" story too. Many years ago I designed and sold Forth controller modules that had all the smarts that could be plugged into a new product to speed development etc. Anyway one day I was relaxing at home and I got a knock on the door from two strange gentlemen asking me if I was company so and so and did I make such and such a product? Rather cautiously at first I asked some probing questions until I was satisfied I could answer more directly and confirm this information. Anyway it turned out that their company's business was dependent upon a consultant whose product had at the heart of it my modules. But they kept having problems and losing both money and having to pay the consultant big money to go and rectify the problem each time which he did. Do you see where this is leading?
Eventually I came on board and had a look at the binary image of his code and wrote a disassembler that not only disassembled but made multiple passes to recreate the original source code albeit of course without the comments. Interesting thing turned up, a little counter that kept track of restarts would lock up on the fourth (Forth ) restart necessitating a callout. Since so much money was at stake this all ended up in court where I had to travel down to appear as an expert witness but the whole case was dismissed for "lack of evidence". So the consultant may have wormed his way out of paying damages and compensation but he certainly didn't get anymore business from that company at least. I however was now stuck with helping them develop new controllers which might have been a good thing except they didn't really know what they needed and if you gave them what they really needed they always seemed to try to do their own thing with it to mess it up.....grrhhhh.
There are plenty of other stories of sabotage and incompetence etc and of course the whole vast arena of backstabbing "politics" that come about with various stages of success.
We only hear about the many pro's of PLC's but I have to believe that what I experienced happens elsewhere.
That wasn't a PLC problem, it was a sabotage. It's not a uncommon problem where certain employees cause problems in order to fix them, so they look good to management. Seen it with maintenance personnel of all stripes and even programmers.
Unfortunately it seems there are less and less people wanting to make an honest living. Even some of out our banks are up to completely dishonest trickery to gouge more money.
Structured_text is a procedural language, along the lines of Modula-2, Pascal, (structured) Basics, C et al, & even Spin.
Most designs run a fast interpreter that scans user code, at some fast rate, to give a virtually parallel system.
The P1 is reasonably well suited to small PLC, and many are used that way, maybe just not called a PLC.
The P2 is probably better suited, and it would not be too difficult to do a Structured_text release for P2.
In many ways, the hard real time engine of P2, is wasted spinning Java Script, and better suited to hard real time problems.
Nice looking case, but they do not show one actually connected and powered.
Rather demonstrates the form-factor failings in the original Pi PCB design with 'connectors facing in all directions', and no thought given to how anyone could case the thing.
Apart from Occam, and Go and XC I don't know of any languages that have multi-threading built in as a concept in the language. Perhaps Ada with its "rendezvous".
Javascript is predicated on the idea of events. Which was cool in the browser environment. A users clicks on a button, some function attached to that event does something.
Turns out this "event driven" model is also cool outside of the browser, get a network packet, do something. Get a serial port input, do something. Get a pin change on a GPIO, do something.
This event driven model saves all the time wasting of context switching threads. It saves all the chaos of memory shared between threads. It makes programming multi-tasking things really simple.
So what about JS on a 16 core Propeller 2?
I imagine one COG running a JS engine which is running the user program. Other cogs are running device drivers that produce events for that top level JS program.
Kind of like a typical P1 program is written in Spin but uses a lot of sub objects with code running in other cogs.
Nice looking case, but they do not show one actually connected and powered.
Rather demonstrates the form-factor failings in the original Pi PCB design with 'connectors facing in all directions', and no thought given to how anyone could case the thing.
Comments
It underlines one of the problems of closed source custom solutions.
This is true but at the same time, an obsolete big-name-PLC/CNC failure can present a similar problem. Bean counters don't like having spare parts on the shelf.
Personally, I have never been asked for source but have provided it anyway for hardware, software, BOM, etc.
We had spares for all of it. When a plant operates 7x24 350 days a year. You can't afford not to keep spares.
Software wasn't a issue, since it was all written in-house by plant electricians and the single programmer on staff over the years. The applications on the Gould mini-computers was written by corporate and bullet proof.
We get them from our customer, so they must have bought a lifetime supply many years ago to support their product.
Also, with the sources for a PLC, or even just the binary ladder, it's a straightforward job to port over to another PLC brand.
EDIT: I recently had a conversation with a sales rep - due to the previously mentioned controller failure - and he mentioned the increased level of competition occurring between brands due to the networking standards being well established now. It seems one can now mix'n'match makes of I/O modules on the one high performance backbone.
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.
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.
Surely you have heard of them ?
https://en.wikipedia.org/wiki/PLCopen
https://en.wikipedia.org/wiki/IEC_61131-3
https://en.wikipedia.org/wiki/Structured_text
https://en.wikipedia.org/wiki/Instruction_list
https://en.wikipedia.org/wiki/Function_block_diagram
https://en.wikipedia.org/wiki/Ladder_logic
https://en.wikipedia.org/wiki/Sequential_function_chart
Ladder Logic you should already know about ?
Instruction_list is roughly similar to Forth. (Stack based, and a little cryptic.)
Structured_text is a procedural language, along the lines of Modula-2, Pascal, (structured) Basics, C et al, & even Spin.
The simplest PLCs are 24v IO, (no analog) commonly open collector, with maybe 6 in 4 out.
Look something like
more here :
http://annelectric.com/productslist.aspx?typeid=20
Most designs run a fast interpreter that scans user code, at some fast rate, to give a virtually parallel system.
The P1 is reasonably well suited to small PLC, and many are used that way, maybe just not called a PLC.
The P2 is probably better suited, and it would not be too difficult to do a Structured_text release for P2.
In many ways, the hard real time engine of P2, is wasted spinning Java Script, and better suited to hard real time problems.
Yup, here is one example of a simple upgrade path, to a new model engine :
["The Jazz® 2 units are also 30X Faster than their standard Jazz® counterpart with 1.5 µSec for bit operations (typical). The HMI application enables you to design up to 60 text screens, using up to 64 HMI variables for the display of time, date, and real-time system data. Programming is as easy as it gets— with a built in mini USB port, you are able to build Ladder Logic control applications using click-and-drop elements and create your HMI application in the same simple environment.
Upgrading your current Jazz® system is easy! The Jazz® 2 offers the same look, dimensions, wiring and functional behavior as it’s Jazz® series counterpart. Users are able to update their existing projects in 3 easy steps: 1. Open the application 2. Select the new model in Hardware Configuration 3. Save the application. It’s as simple as that! "]
"No focused will"
"No professional skill"
?
Maybe it was along these lines ?
"No1 focused will"
"No1 professional skill"
Yes, yes and yes.
I strongly feel Ladder Logic should be taught at secondary schools. Not only because of it's wide use in the trades but it also teaches basic logic that can easy be translated to actual chippery and the start of more extensive formal tertiary training.
My experience of the major PLC vendors is they *do* have different software packages for their different series of PLCs. The AB Micro's are interesting, have high speed counters/pulse train outputs available as well as ethernet, DH+, modbus and other serial options. Quite powerful for a few hundred $
http://ab.rockwellautomation.com/Programmable-Controllers/Micro850
But a different tool to the usual RSlogix
Inside *sensors*, though, is where you'll find the microcontrollers. Pretty much every photoeye (photoelectric sensor) has a programming mode where you hold down the button to program, tap again to teach a point or two, and then one final press to save the setting to eeprom. I've also seen an air pressure sensor that has a 4-digit 7-segment LED display. Two buttons and the display helps to program a digital output setpoint and to display the current value, in the selected unit (like psi, bar, mm-hg, etc), and configure other things like delay time or hysteresis. These micro-controller infused sensors are getting really tiny, so their circuit boards use the fine pitch surface mount components, and usually but not always a linear regulator (so they get a bit warm dropping 24V DC down to 3.3V or lower).
Furthermore, there is a sensor communication protocol now called IO-Link which is pretty much like RS232 serial but with a 0 to 24V DC voltage swing and half-duplex. It replaces overpriced analog inputs in situations where update intervals needed are less than 500 times a second (or so). It has automatic downgrade of baudrate (230.4K, 38.4K, 4.8K). Imagine something like a laser distance sensor that can shine out 20 meters and give back a 16-bit value representing the distance between the reflection and the sensor lens. You get back a precise digital number instead of a noisy analog value that is subject to drift.
Actually, "focused will" and "NO professional skill" is precisely the problem here.
No professional skill:
The over-zealous maintenance electrician who has learned enough to be dangerous has the ability to change machine control logic, willy-nilly, on the spot, to "make it better".
Focused will:
I was responsible for controlling the first ever CNC (PC-based) tube forming machine for vehicle seats. This was the only source of seat frames, at the time, for GM's mini-vans. My 5-axis tube-former would bend the the 3-D shapes which were then transferred to a press-type operation which would flatten, pierce and trim the ends of the tubes. Because this was a new development, I had to camp for months on end in Athens TN (dry county, ugh!) to watch over this thing. I was constantly being called to the machine at all hours because of a stoppage. I couldn't understand why the stoppage seemed to be always due to the PLC-controlled press that I had nothing to do with. Long story short, their in-house maintenance electrician had access to the PLC's ladder-logic and he had modified it to include a cycle-counter that would stop the machine after X cycles. Sometimes he would jumper 24v to a "spare" input and other times he would "get in to the program" to set the count to a different value. Of course, to his boss, he was the company's "computer wizard" because he always "fixed" the machine.
I needed these guys on my side therefore I couldn't expose him so I just insisted that I take control of the press logic with my PC-based controller for the subsequent machines to "provide better diagnostics".
We only hear about the many pro's of PLC's but I have to believe that what I experienced happens elsewhere.
For sure, everyone makes mistakes. Machines are operated for their entire existence with obvious bugs, operators work around them as best they can and can have quite detailed procedures to avoid triggering the various bugs. Sometimes those bugs are so bad that management buy another brand for the next machine, which they usually prefer not to do.
What I found in the traffic light industry is that if you ask the traffic engineers of any city how their intersection controllers are configured they cannot tell you. Sure there were timing plans drawn up by traffic consultants when a controller was installed 20 years ago, if you can find the paper work, but those parameters and programming will have been tweaked over the years. If you are lucky there is a folder of yellowing paper work inside the controller cabinet by the road with changes noted on it.
I recently got a live feed of controller data from 1200 odd intersections in and around San Jose. Great I can see, in real time, the lamp phases in all directions from every intersection, I can see vehicle and pedestrian requests coming in from the various detectors. There is no way to tell which direction is which or which detector is which! Another company spent the best part of a year figuring all that out from the old documentation and trial and error.
When I have visited factories in the past it was always fascinating to see all the little tweaks and bodges they had in place to keep everything going.
Oh, he resented me right from the get-go. I was a baby-faced 26 year-old Englishman and pretty much every young female in the plant wanted to take me home. Furthermore, I was getting all the "attaboys" from the GM guys for developing the CNC. I'm sure you get the picture....
I've submitted Ladder changes back to the OEM when the option exists. I suspect they don't bother to read it though.
Oh yeah, a similar though different story although I am sure I can dig up the "same" story too. Many years ago I designed and sold Forth controller modules that had all the smarts that could be plugged into a new product to speed development etc. Anyway one day I was relaxing at home and I got a knock on the door from two strange gentlemen asking me if I was company so and so and did I make such and such a product? Rather cautiously at first I asked some probing questions until I was satisfied I could answer more directly and confirm this information. Anyway it turned out that their company's business was dependent upon a consultant whose product had at the heart of it my modules. But they kept having problems and losing both money and having to pay the consultant big money to go and rectify the problem each time which he did. Do you see where this is leading?
Eventually I came on board and had a look at the binary image of his code and wrote a disassembler that not only disassembled but made multiple passes to recreate the original source code albeit of course without the comments. Interesting thing turned up, a little counter that kept track of restarts would lock up on the fourth (Forth
There are plenty of other stories of sabotage and incompetence etc and of course the whole vast arena of backstabbing "politics" that come about with various stages of success.
It certainly does, and with all types of equipment, not just PLC's.
Heck yeah, I can see a Prop and a range of interface modules, maybe in a DIN-rail enclosure like they have for the Pi
Is Node.js multi-threaded? I know browsers aren't... but I can't remember if that's a rule of JavaScript or a rule of the JS engines in all browsers.
Not a DIN-rail enclosure, but an interface modul soon will come in QS-format . 16 High side switch outputs, 24 inputs
Nice looking case, but they do not show one actually connected and powered.
Rather demonstrates the form-factor failings in the original Pi PCB design with 'connectors facing in all directions', and no thought given to how anyone could case the thing.
node.js runs Javascript.
Apart from Occam, and Go and XC I don't know of any languages that have multi-threading built in as a concept in the language. Perhaps Ada with its "rendezvous".
Javascript is predicated on the idea of events. Which was cool in the browser environment. A users clicks on a button, some function attached to that event does something.
Turns out this "event driven" model is also cool outside of the browser, get a network packet, do something. Get a serial port input, do something. Get a pin change on a GPIO, do something.
This event driven model saves all the time wasting of context switching threads. It saves all the chaos of memory shared between threads. It makes programming multi-tasking things really simple.
So what about JS on a 16 core Propeller 2?
I imagine one COG running a JS engine which is running the user program. Other cogs are running device drivers that produce events for that top level JS program.
Kind of like a typical P1 program is written in Spin but uses a lot of sub objects with code running in other cogs.
Found a brochure......