doubt on plc functional blocks

[JesperMP]

bad news if a power station is shut down and no one can understand the software and soirt it out.

Seriously ? A power station goes down because of a programming error, and someone who hasn't designed the software is supposed to be able to go online and find the error, fix it and be the hero of the day !

1st, if there is a seriously important utility, the entire system incl. software should be so well designed and tested that there should be absolutely no need for anyone (incl. the original programmer) to go online to find "errors".

2nd, for any system that is above a certain complexity, to let an untrained noob (*) go online and start rewiring the code gives me the shivers. If the people onsite really must be able to go online, they must be trained by the original programmer to fully understand and be competent enough to grasp the code, including reusable code such as function blocks. I have done this a couple of times for customers that want to maintain their code by themselves.

*: And your argument only makes sense if you intend to let "anyone" go online.

 

[wimpiesplc]

Just keep in mind that most of these PLC system are maintained by NON-Programmers. When they get online to find a problem if they track an IO point back to a function block their going to get into a dead-zone they cant do anything about and will likely be calling YOU. Even if it's 3am.

As a programmer I see this stuff come out and it looks cool, but in reality who is going to be trouble-shooting it at 3am?

For this reason I always stick to plain old ladder logic. It's boring yes, but I don't get any 3am phone calls.

Using FB's or not has nothing to do with doing ladder or not

 

[GlenGineer]

I can't say I've used function blocks before. However I recently had to fix a program that used recipes to change program values. With each piece of equipment the program checks this array of integers (with ABs Sequence and compare function). So the program checks it like 8 times. While fixing somebody else's mistakes I considered making a subroutine that each of these devices access. I did not do this because I foresaw problems caused by sharing the function that would need to be figured out.

I can echo earlier sentiments about keeping the program simple enough for a maintenance electrician. Heck today an electrician had a straight forward problem which could have been figured out by reading the electrical ladder, looking at the PLC, and reading the troubleshooting guide. However I got called down to the machine because the guy did not bother to understand the ladder drawing and told me I had mislabeled it. I don't know about the rest of the world but there are a lot of stupid maintenance electricians out there.

 

[JaxGTO]

Using FB's or not has nothing to do with doing ladder or not

My point is not to use function blocks, in AB anyways. They are very tough to trouble-shoot online. Especially if they have embedded structered text.

 

[wimpiesplc]

My point is not to use function blocks, in AB anyways. They are very tough to trouble-shoot online. Especially if they have embedded structered text.

Well I'm speaking from Siemens perspective. it doesn't matter much where you program, you can put STL anywhere you want but also program almost anything in ladder. but that is not always the best solution imho.

on the other hand, I think FB's should have been thoroughly tested and well documented about their workings so you don't need to bother with them when troubleshooting an working system.
but... we aren't living in a perfect world ;-)

 

[JesperMP]

Yeah.

I think that "function block" means something differently depending on which PLC.

Makes the pro-con discussion a little bit pointless.

And since trimurthulu hasnt bothered to elaborate, I shall
1. Put him on my ignore list.
2. Leave this thread.

 

[trimurthulu]

hi

 

[CapinWinky]

Seriously ? A power station goes down because of a programming error, and someone who hasn't designed the software is supposed to be able to go online and find the error, fix it and be the hero of the day !

1st, if there is a seriously important utility, the entire system incl. software should be so well designed and tested that there should be absolutely no need for anyone (incl. the original programmer) to go online to find "errors".

2nd, for any system that is above a certain complexity, to let an untrained noob (*) go online and start rewiring the code gives me the shivers. If the people onsite really must be able to go online, they must be trained by the original programmer to fully understand and be competent enough to grasp the code, including reusable code such as function blocks. I have done this a couple of times for customers that want to maintain their code by themselves.

*: And your argument only makes sense if you intend to let "anyone" go online.

I completely agree! What the hell applications are people putting out there that need constant debugging by untrained service guys in the middle of the night? That seems like the go to argument against any and everything non-ladder, but really the argument sounds like they are writing bad code without any diagnostics or error recovery. Probably because they have a massive program written entirely in copy/pasted ladder.

I also see things like "what if the input/output goes bad and they need to move to another one". Well maybe they should take 5 minutes and put in the spare input or output card they should have and maybe they should stop using a controls platform that has such a high frequency of IO failure or fire the electrician that keeps frying them.

 

[GlenGineer]

Even though we have had some maintenance technicians with PLC "training" working at my facility my boss only allows me to communicate with them or program them. This sometimes seems insane to maintenance technicians because some of these systems are extremely complex and just reading the IO will not suffice. Its hard to diagnose a black box. I try my best by writing manuals, troubleshooting guides, etc. Unfortunately when we design equipment we need to help the guy trying to fix it out. I have a continuous heat treat in my plant. The quench tank for this heat treat utilizes 4 proximity switches to control when parts are on it and when it is up or down. For some reason this is beyond most of our even maintenance electricians ability to diagnose. They ask me "Can you connect to it and tell me what is wrong" (often they try to imply there is a logic problem - yeah on hour 30000 suddenly the program stops working... I guess it has alzheimers) However adding a few routings to self check and an HMI to tell them what to check would help that problem (yet I cannot convince those that control the purse strings that it would save money)

On the alternative end of the spectrum we have a melting furnace. It has absolutely no need for a PLC. If fact all the actual control functions are controlled by physical relays and physical timers. However everything reports to the plc. When there is a problem the PLC sends a series of suggestions to an HMI. - Burner is off unexpectedly check this - check that - check here.

Me I can read a drawing and a meter also however many cannot (sadly). That is why maintenance techs might want to get on line with a PLC. Not to change it but to figure out were the problem is.

But yes I do wish we would fire a few of the lessor qualified...

 

[Plastic]

I agree wholeheartedly with JaxGTO - Raw, brute force ladder can be mans second best friend. (Dog is first).
Todays PLCs have no real memory constraints, so there is no reason to try to "name that tune" using fewer notes. There is no real reason to seek out "elegant", or "crafty" programming techniques to save a rung or two.

 

[jvdcande]

Raw, brute force ladder can be mans second best friend. (Dog is first).

I don't agree, but then that's probably because I'm allergic to dogs.

Todays PLCs have no real memory constraints, so there is no reason to try to "name that tune" using fewer notes. There is no real reason to seek out "elegant", or "crafty" programming techniques to save a rung or two.

I agree on the memory constraints, but I don't see why this should keep you from using functions or function blocks.

If you have to program N times the same ladder rungs because you have N same things to accomplish then you have N times the possibility to make typing errors and thus f**ing up your code. If you use function blocks you can only make mistakes in naming the parameters. So this is not about saving some lines of code, but a whole lot about making less errors in programs.

I agree with a lot of the colleagues here that it also makes a big difference depending on the brand and even model of PLC you're using. I've worked most of the times with Siemens S5 and S7, so it might be difficult for me to see why people rant about FBs. In those PLCs you can use ladder about anywhere, so even function blocks can be made understandable for just about anybody who has a basic training in PLCs.

And especially to trimurthulu: just saying 'hi' from time to time just to keep the thread on top of the list won't give you any credibility here. As a matter of fact, it's not only my friend JesperMP who is going to put you on his ignore list, there will be others as well. I just posted because of the others who made this an interesting thread, but don't try to get any help from me unless you add something worthwhile in yourself.