I have a function to perform where I use a DIFF UP from a pushbutton to open a motorised circuit breaker with a trip coil if it is closed. Then close it if it is open. The trip coil is easy but the motorised closure signal has to be held on for some time using a pair of timers and retries that are counted in a counter to allow the motor time to close the breaker. If the brekaer does not close after 3 tries, stop trying.
There is a fair bit of interlocking etc as you can imagine. I fiddled around for quite a while with an FB and finally got it right after about 20 minutes. Wrote the same thing in ladder (only 1 rung) in 3 minutes.
I can see it would be excellent for repetative tasks but I rarely have repetative tasks. Nearly all my code is individual stuff. Every job is quite different.
I do a lot of generator work and even the alarm routines are different. However, there are a number of alarms each time that are the same so I could use it there.
By the way, a lot depends on the PLC one uses. With Siemens for example, you have to basically have a separate rung for each output. I use Omron and there is practically no limit on a rung. I can have 20 outputs in the one rung if I wish with individual conditions in each output line, plus a load of timers, counters, compares etc etc. Some of my rungs would need between 10 and 20 rungs in a Siemens PLC.
I guess I will perservere for some tasks but I cannot see any benefit for most of my software as so much of it is individually written for each job.
I can certainly see a benifit for YD starter control for example. However, a decision has been taken to use soft start/stop in future so there will be no more YD starters in my jobs.
I guess the other thing is the re-usable code situation. I have been able to have re-usable code files in ladder with Omron PLCs for some years now so it has not been an issue. Just insert the file and change the I/O numbers, as with FB.
The other thing I find with a lot of European software is that ladder is the poor cousin. The ladder tools are pretty poor in Siemens, Modicon Unity etc. They appear to be an after thought rather than serious programming tools. Omron and AB have serious ladder tools due to their background.
I challenged a Schneider rep, who works for their systems integration division in Ozz, to get out his laptop and I would give him a race to program 20 different alarm routines. The routines were already hand written on sheets of paper and only had to be punched in to the software. I used Omron CX-Programmer and he used Unity. I beat the heck out of him by quite some time. Have not seen him since.
Will keep trying but without many repetative tasks and very little software that I can transfer from job to job, I think it will not be of much use to me really. The biggest benefit I see for me at this stage is that the FB takes up a lot less room on the screen than a large ladder rung.
but I find FB to be one of the most tidy and neat ways of programming repetitive tasks , once tested , no need to check again
We make machines with a lot of the same components at each station, so FB's are really useful. The big problem with cut and past is that if you have a typo or want to change the logic, you have to do each repetition. With FB's you only have to make one change.
Fully agree with both of you but not much use to me.
Sometimes people substitute dislike for a failure to understand
Do not have that problem at all. Quite happy writing code in ST - write Cicode in Citect all the time.
Function blocks have their place, especially with instructions that require multiple inputs. Its much easier to set up an enhanced PID, or a LEAD/LAG, for example in FB rather than a couple of dozen MOV rungs just to get the data in place before you can ever execute the function.
Fully agree there also. Hardly ever use PID control for example. Lead/lag for pumps etc I have re-usable ladder code anyway. Re-usable code files are one of the strengths of Omron CX-Programmer ladder editor. For the number of times I use lead/lag pump control (once per job) re-usable ladder files are fine but I will probably migrate them to FB in the near future as that is one place I can use it.
One of the other things I find a bit painful is that most of the software today is symbol based and defaults to symbol. One of the things I wish Omron would do with their software is to put in a switch to default to I/O number based so that one can turn symbol based off. I guess that is what I use all the time due to my evolution path as a programmer/systems integrator. Omron PLC software does not and never has required the insertion of %I, %Q etc, just a number. I find this so much easier and quicker that it is not funny. For example, input 2001.03 is just typed into the input instruction as 200103 - no % or I or X or anything else. I am quite used to working with just numbers and find having to type in anything else slows me down considerably quite frankly.
You can teach an old dog new tricks. I am always looking for quicker and easier ways to write code as my time is to precious to waste. I am sure if I had a lot of re-usable code situations I would very quickly become a convert but it is only useful if it saves time and makes life easier, as it has for very many of you. Wish it could for me.
