PLC Talk
FredBlais
Posts: 370
To continue the PLC discussion that started on the P2 forum and was getting out of topic.
http://forums.parallax.com/discussion/164055/what-s-the-state-of-micrcontrollers-these-days/p10
http://forums.parallax.com/discussion/164055/what-s-the-state-of-micrcontrollers-these-days/p10
Comments
@dMajo
What PLC are you using the most?
Older AB PLC (prior to Logix family) like the PLC5 and SLC500 had data files where accessing data was kind of more direct memory access, e.g. B3:0/0 for a BOOL and N7:0 for a DINT. You could give a symbol name to a memory address if you wanted. Everything was saved in the project file (comments and symbols) so when uploading a project from the PLC directly, you end up with a mess of not unintelligible code.
The greatest feature of the ControlLogix for me is the introduction of tags. You just choose your tag name and type and the PLC/IDE take care of where it will reside in memory. The tag names are saved in the PLC, so when you upload, they are not lost. However, the rung comments and tag comments are saved in the project file. This is true for RSLogix version V20 and below.
The new logix processors, (L7 series) when using RSLogix V21 and up come with a separate SD card and now, all the comments are saved in the PLC and the project file.
I like that because I can upload a program and get the latest comments that the others added. Without that, a lot of comments are lost because some make the error of using different offline project files for the same controller.
Yes, it is true that behing the scenes it's all instruction list (and end up in machine code!). I think it's a little bit similar as OOP, using a library of code or a Propeller object from the Obex : you don't really need to know what is in there, as long as it works and you have an interface to communicate with the piece of code.
I don't really see the need to do all in instruction list though. In some plant I work, there is high speed sorting done on a lug chain coupled to an encoder. All the logic is done in ladder, except some parts in structured text where a lot of loops were needed. However, this could have been done with a simple JMP and LBL ladder instruction.
It would be nice to see more "industrially ruggedized" I/O interface projects as well.
I've met the PLC's for the first time in '94. It was Siemens S5 103 and 115 series. I was lucky because I was born as a programmer from the age of 12 first on C64 and then growing up on Amiga, 286/386/486... win systems, and the company where I work had all the programs in instruction list. Even today it is much easier for me to read instruction list/structured text rather than ladder.
I started as a field assistance technician but was moved after 6 month in the r&d department developing the electrical and sw part of high vacuum metallizing plants (using different technologies as magnetron sputtering and evaporation through heating elements and electronic beams) for automotive (aluminium/silicon/polymerization of front/rear lamps; silver/copper on mercedes triangular reflectors), toys (everything has a metallic color, aluminium/silicon), food/tobacco/electronic capacitors (aluminium metallized paper or plastic film), aerospace (cadmium deposition on landing system and wings parts), sun glasses (chrome/silicon deposition on lenses), optical systems (multilayer dieletric coatings on hot and cold mirrors), cosmetics (various housings of nail varnish, lipstick, face powder) and generally (car/boat/street/furnishings) every kind of glass and plastic mirrors. And many other materials. This are examples of batch and roll2roll coaters.
Most of the machine was sold with our process know-how. During the commissioning all the process parameters was found out for a given product. Other times eg. for hot/cold mirrors the proccess knowledge was customer's and we only supply a system able to accomplish the requested tasks/jobs, in this case the deposition in single cycle of up to 40 layers of different materials controlling their optical thickness layer by layer. We developed our measuring instrument because this kind of measure was not possible through the PLC. I think this measuring system was the harder task I ever done.
My most used PLC (because of the worldwide availability of spare parts) was Siemens S5 and then S7. But when I worked in the vacuum field all the systems sold in France and their partnerships around the world was Telemecanique (Shcneider electric). Some of the plants sold to the states was made with GE Fanuc upon their request. On roll2roll systems there was a combination of Siemens and Allen Bradley but because at that time they was used to bought all the rolls control system from a third company that makes this kind of controls for the newspaper industry. As soon as I become the responsible of r&d we start building this controls inside using Siemens. The data acquisition/scada for the batch coaters was internally developed (mainly vb for the program with vc libraries for graph rendering because at that time vb3 was too slow. On the roll2roll we used iFix. This was 94-01 era.
Now I work in the metallurgic field (ductile cast iron pipes) for an multinational enterprise as the r&d and ict manager for their european plans so I use almost only Siemens S7 (300/400/1200) and sometimes Omron for some minor tasks (outside my first job) and always because forced. Here I've developed all the casting machines, zinc/alluminium coaters, inline water pressure test equipment and varnishing plants. All the HMI is Siemens, scada WinCC with a few Cimplicity. It still happens that sometimes I am called for some revampings of old coaters so I put my hands on the other brands again.
Considering my experience 94-today my first choice is Siemens and second Schneider electric but I haven't programmed the latest models of other brands in the last 5/10 years.
Regarding the choice of language I think it is up to the programmer until you face the language limit when you simply can't do a thing with ladder. For an electrician approaching the PLC the ladder is certainly simplier. In my case, coming from PC programming, instruction list or structured text is easier.
If you have to make a neural networks, nearly any controller, a mediane filter, you have to deal with matrices, you need to use pointers and pointers to pointer you simply can't achieve this with ladder.If you are using only ladder it means you are using manufacturer's libraries/building blocks. I will never be able to control a 15ton casting machine moved by a hydraulic cilinder driven by a proportional valve with regenerative circuit with speeds up to 1m/sec, 0 to max speed and opposite in 30cm with positioning error of less than mm with the built-in pid controller. I needed to develop my controller that beside controlling the movement because of the feed-forward is very quick (aggresive) without oscillations, can filter out system resonances, is bumpless in swithing between auto/manu and can internally compensate for PV errors (eg encoder damage) without overrunning. There was also a need here to drastically simplify the mathematics because of the available PLC operands so it ended out with product sum and division of matrices of which some are of parameters. I need mathlab to find out its values but the controller is robust, very quick and can function also as normal pid (in this case not needing mathlab). During my carrier I have rewritten also half of the siemens original libraries, keeping the same interface, but extending its functions and in many cases producing a shorter code.
So now that I am developing "for internal use" and that my maintenance people are all able to read instruction list I have no needs to write in ladder. Anyway all my "standard blocks", my library is written so that you can use it from ladder, it costs only two instructions more.
Regarding the SD cards I immagine that nowadays they can store the complete project nearly for every brand as is for Siemens. Siemens have only one sd/mmc you only need to buy it larger to store the complete project. But this is only storage, unless you do not download it to your programming device you can't use its info while debugging. I mean that if you do not have the project in the ide you cant see the comments online only because the project is in the SD.
@evanh
I think this is your feeling when you see ladder because you see many branches (lines) starting from left going to right. If you convert to instruction list you will see sequential instructions one below the other for the same line, repeating below for subsequent lines. And all this instructions are executed sequentially.
The same is if one block calls another, like in C calling a function. You can nest them down to a certain level depending on the cpu specifications and stack availability.
But in some cases you can have parallel tasks each following the same criteria. And they can signal each other because the memory is shared among them. One example can be a pid block running in an time scheduled task, while in the main program task you run the process. The pid needs scheduled run because of its id component but if you pass eg the auto/manu command to the block through a variable (from the main prg task) also the pid output (switching from auto to manu driving value) will be affected on time schedule basis. But you can recognize from which "task" a block is called so in my controllers I call it twice, once in the scheduled task and once in the main program task (which affect IO). The controller block recognize the calling task and executes different portion of code. In this way for example the feed-forward have immediate effect on the process and the controller corrects the error on time scheduled base.
Anyway, in normal situations, it is not important because until all the program is executed nothing change in the outputs and all the program will see the same input states if you do not use tricks. Eg if you have a broken sensor you do not need to hw bridge/bypass it. It is enough that you set the input in the first line. The plc copy the physical inputs in ram and every time you query an input state (in the same program cycle/scan) you are querying ram location, so setting an input makes the next program lines think it is 1 while physically it is 0. The next refresh will again copy field 0 to ram but the first line of code will set it again on 1 thereby misleading the program. Same apply for outputs.
So a synchronized picture of inputs is taken, then all the program is executed driving outputs (in memory) according to inputs (in memory) and at the and all the outputs are synchronously switched according to memory states. That mean that if during program execution an output is toggled several times only its latest state will be transferred to physical output.
The only think you must take care is structures similar to "do/loop/until" are not to be used because it can hang the program waiting for a given condition that could not happen. In this case you loose control over inputs and you are not driving outputs. The watchdog will trigger = CPU in stop.
While you can jump backward you must pay attention that a condition like the above can't happen.
But some programming knowledge with PLC i think can also help to program better MCU. I feel that I have learned from PLC programming and I am usually applying the same criteria also on MCU, I mean avoiding loops, doing part of the job at every program cycle and thus having a more frequent picture of the IOs.
I also think that the new P2 have a great potential in becoming the core cpu of a PLC system. It have the speed, determinism, multitasking, digital and analog IO and with 512K also the ram is sufficient in many cases.
With some rules eg calling conventions, now that P2 executes from hub nearly the same speed, you can immagine a P2 where each "global" function, can contain local functions, but is a separate block/chunks of code and can be written each one in its language c/spin/pasm/even ladder and then assembled and linked together.
By developing the ide/tools in this way it leaves the door open to any future language to be integrated in second time and leave the opportunity for mixed language programs.
http://forums.parallax.com/discussion/121404/picoplc-free-diy-plc-with-propeller
I have been an electrician on the floor, a controls engineer, and have designed microcontroller based machines as well. I've been successful at all of the above and have a few observations.
There are those who sabotage, but most of the time they are few and far between. Usually their peers will be able to get rid of them, Electricians usually aren't shy, and can be absolutely BRUTAL with a sabotaging so and so. (Or a dud engineer...)
When confronted with any new engineer, an electrician will be cautious. As much as some rare electricians will sabotage, some rare engineers will screw up and lay it on the electrician. it happens.
Ideally, they can earn each other's trust. Many electricians are WICKED smart, and can truly contribute to the project. Nothing works better than a machine that is understood and embraced by maintenance.
I would love to sell this stuff if anyone is interested.
IEC-61131-Instruction List as Byte code engine - by Rob Casey
Google finds this :
https://iec61131.wordpress.com/2014/10/01/whats-in-a-bytecode/
( 'byte code' here is actually 16 bits, and it shows a good list of 1,8,16,32,64b types )
and this
https://iec61131.wordpress.com/author/iec61131/
and some postings from about 1 year ago
https://bitbucket.org/rob_au/61131
the original software is hosted on GitHub : https://github.com/LDmicro/LDmicro
it seems some people are still interested in the software, commits have been made last week.
@dMajo
thanks for providing info on your background. It has been really interesting to read.
http://www.ezautomation.net
The company I work for has used the modular I/O PLCs inside a couple of our products. They've worked well for our needs (valve control and feedback, temperature monitoring, failsafe watchdogs, etc). And their software should be easily usable by anyone familiar with ladder logic.
I don't know the answer to that, as we never used their touch controllers.
OK thanks. This is an example of the kind of "GUI" that he would need to replace.
You have it correct, Keith. The objects on the touch screen will get mapped to internal memory addresses, the physical buttons to physical I/O. Generally, I'll try to put buttons most often used as physical switches (start, stop, reset, for example). Pushbuttons are usually cheaper to replace than a screen.
Also, unless you're really cramped for space, go for the separate PLC and screen instead of the all-in-one. Once a screen has had the stuffing knocked out it, you would only need to replace the screen and not your entire set of controls.
Just my 2 cents.
Hmm, trying to co-opt the PLC panel for user GUI is likely to push you from the simple units, to the Panel-PC level, plus bring in a lot of GUI management.
Maybe for that level, they should look at something like the FTDI EVE Modules ?
http://www.ftdichip.com/EVE.htm
or this, with more brain power...
http://www.ftdichip.com/Products/Modules/CleO.htm
https://www.indiegogo.com/projects/cleo-the-smart-tft-display-for-arduino#/
where you use the shield-stack as the PLC backplane.
This is really for an acquaintance, so I'll have to see his reaction to these types of products. e.g. why didn't they go with a PLC years ago? He's currently using some really old electronics and they are turning into unobtanium. And perhaps unmaintainium (e.g. STD bus boards using NEC's D70108C-8 V20 CPU) The ezautomation seems quite reasonably priced compared to some of the things he has to source - it doesn't seem that price is an issue with those products for this type of machine.
http://www.unitronics.com/plc-hmi/product-overview
http://www.profaceamerica.com/en-US/content/hmis-plus-control
http://www.heapg.com/135-all-in-one-controllers
If you are used to siemens/simatic you can consider also VIPA
http://www.vipa.com/en/products/hmi/ (http://www.vipaitalia.it/)
They are cheaper than siemens and many times the CPU are faster with more features. They can be programmed with both the siemens simatic IDE and their own software which can program also the siemens PLCs
Siemens has soft-controllers (PLC) that can run on PCs and/or LCD operator panels. It is a sort of virtualization. The PLC part is isolated from the HMI/PC and each one cant hangup the other.
https://mall.industry.siemens.com/mall/en/it/Catalog/Products/10252974?tree=CatalogTree
But I also suggest you a compact CPU (the ones that comes with integrated IOs) and a separate HMI.
Many of the hmi+plc(cpu) have modest built-in IOs and some of them then allows co connect external (remote) IO through some sort of bus. On the other side a compact CPU many times have much more built-in IOs, some times also technological IOs (weighting devices, counters, pwm) beside the traditional digital/analog. Here a compact plc/cpu) with separate HMI panel can give you more for nearly the same money.
As someone noted frequently used functions are better on hw pushbutton because the maintenance is cheaper. Or at least choose a panel with some soft-buttons more so that you can move the function to another one when the button dies.
One example of frequently used function is alarm ack or some manual movements that are done many times in a shift/day. The "enter" and "0" and "5" keys are also abused; people tend to round the parameters when inputting them. Here the workaround is to project some soft-keys with predefined values (5/10/100) or addition function (+/-1, +/-5, +/-10, +/-25, +/-50, +/-100) to increase/decrease the value under cursor.
Pure touch panel in this condition are better unless the operator in his usual working conditions do not have the hands dirt of grease, paint, solvent .... many times even if they use clothes gloves the do not undress them before touching the panel.
PS: Separate panels are many time OS based. That means that you can easily integrate your functions to the original software (through your components/scripts). For example on siemens win embedded panels you can write you own ActiveX/dll and use them from the HMI IDE.
For this reason, I no longer used dedicated displays/touchscreens but instead use a "ruggedised" Android tablet. In four years I have had zero failures. Should a tablet fail, my customer can simply transfer the software to another device by logging on to the machine's dedicated email address where the APK will show up in the Inbox.
IMO, dedicated HMIs are obsolete.
This thread was very interesting to see, as I too have wide experience with PLC systems.
The Propeller is interesting to me as a sort of "micro PLC".
My interest in the Propeller for real-world control is for some non-industrial applications I hope to pursue.
Many significant points have been discussed here already..
The sphere where modern PLC systems are selected and purchased most typically happens first as a business choice within the business of manufacturing, not as an engineering decision.
As many have pointed out, the support provided by the PLC vendors, employee training and the continuity of that training are paramount from a business perspective.
And increasingly, the incredible range of automation-specific network communications protocols and hardware are integral to such decisions from the engineering perspective.
Online editing, cited here already, is of course a primary aspect of the PLC that separates it from almost all other methods of programmable control. But more than that is the need to help the user avoid costly mistakes while working online with a running automation/manufacturing system. Rockwell/Allen-Bradley and Siemens have invested much to provide this as an essential tool.
The capability of functional redundancy can be critical to some uses, as is the ever-increasing integration with safety systems (Pilz, Siemens).
Nor is manufacturing the only use for PLCs where these same attributes of online edit capability, network comms, and vendor field support are critical... shipboard machinery control for Naval craft, commercial cargo ships, and cruise ships are among them.
And those suppliers of two or more processes or machines may be working cooperatively together, or they may have competing and contrary interests, or they may never meet or work in the same enterprise envelope..
Much of the question posed at the top of this discussion could be answered by searching for Profinet.. an amazingly-smart network protocol.
Having said all that, I have seen and done PLC applications that I'm confident could have been done with a Propeller or three (assuming so, as I'm just learning the prop).
http://hackaday.com/2016/06/07/openplc-is-ready-for-hacking/
http://www.openplcproject.com/
They already support multiple hosts from Linux to Windows and a bunch of microcontrollers.
and the C compiler
http://www.beremiz.org/doc
Looks like it might be a good fit for the P-2 once the instruction set is frozen and the compilers can go to work.
Imagine a combination of Rasp Pi 3 and P2 IO cards...
Any mix of Quadrature, USB Host, Timing, PWM, with very real time separation.
If it compiles via C, I wonder if there is enough original Source Debug info preserved, to Source-Code debug ?