Should I Use Function Blocks?

[poovs 0]

I am trying to evaluate whether or not to utilize the FB capabilities of our Omron CS/CJ PLCs for future projects. Our typical projects involve controlling a few hundred devices (doors, intercoms, cameras, card readers, etc). There will generally be sections of PLC logic that are exactly the same except that they refer to different IO addresses. I can see that if I were to utilize the FB method I would not have to deal with creating/managing all of the 'pseudo' symbols that would essentially become 'internal' FB symbols. I can currently crank out the ladder pretty efficiently by copying out the mnemonic of a sample ladder and then find/replace the symbol names to match my desired few hundred devices... Can I do the same with the FBs? As I've never used them before, when I copy a functioning FB in ladder and then paste it; it seems to still be an instance of the originally 'copied' FB... can't seem to find/replace or change the FB instance unless I manually create another instance... Regards, JP

[PdL 70]

Hi poovs, The logic you desrcibe to use for your projects is perfect for FB processing. If you copy and paste a FB instance, it will be assigned the same instance name like you describe. You can create a new instance by right clicking the FB, and changing the instance name. However, it is perfectly possible to reuse the same FB instance in multiple FB copies. But beware that you can only do this if the FB code can be processed in a single scan, so it cannot contain timers, counters and data control instructions like PID that require multiple scans to complete. So if your FB only contains simple ladder functions you can reuse the same FB instance and save memory. If your FB does require separate instances to be used, you can still modify all instances at once by editing the FB internals and updating the FB invocations. You will find the FB instances in the symbol table under data type "FB". For more information on FB, see the manual "CX-Programmer Operation Manual Function Blocks Structured Text" which you can find in the CX-Programmer programs folder in the start menu. Hope this helps.

[BobLfoot 272]

Let me preface my response with the following: 1. I am no Omron Guru and have no experience with omron FB my last omron plcs were the C200H and C1000HF. FB may make a lot of sense for you in coding, but don't forget your target audience, the maintenance tech who has to troubleshoot and repair the system when it hiccups. With Lader Logic he can probably follow it himself. Is Omron FB that clear and widely accepted as to not give him issues? Consider this I would suggest.

[poovs 0]

PDL, Many of these FBs will in fact contain timers (length of time to pulse the associated output), and in fact the timer value will likely need to become an input variable... I realize that I can manually create a new instance of these FBs to accomplish truly independent instances of the timers/values assoc. but is there a way to do this quickly... the manual method is not that appealing to me :)

[poovs 0]

Bob, that is a good point: Most of the control systems projects we deal with are spec driven requiring us to be involved for 2-3 years post-substantial-completion. We will likely be dealing with the initial hiccups of the system... What I am running into as of late, is that in retrofit applications we are adding and removing devices on a regular basis in phases to reach the final completion on the project... Using regular ladder and "pseudo" points, I have to constantly maintain what symbols are being added, where to add them, and the same with what is being removed/deleted (if that makes sense)... Using FBs would allow me to only deal with the ACTUAL io points in most cases. Sure I would still deal with the Timers, alarms, etc on a onesie twosie basis but from where I am looking it would allow me to curtails some major obstacles... With all of that said, I still want to be able to generate the PLC code efficiently (and of course be able to understand and explain it to maintenance personnel).

[Sleepy Wombat 27]

Bob wrote I will now be referring to you as Master Yoda in future posts... BTW i would be using the function blocks in this case.. yes you can drill down into the ladder logic of the function block for monitoring online if required

[Sergei Troizky 26]

Function block downsides from my experience with CP1H: - Significantly increased scantime. - FB cannot be created/modified by online editing. - A new "invocation" for existing FB also cannot be created by online editing. - Devices status monitoring, manual value writing and forcing in each FB instance is at least questionable. - FB function and I/O variables must be very well described at the point of invocation in order to maintain readability of the program. Based on the above, I would probably use FB for relatively long piece of code which repeats not so many times during scan, but not vise versa. Edited 13 Jan 2009 by Sergei Troizky

[BobB 56]

I just do not bother with function blocks. I could only use them for alarm routines and it ain't worth it because I have anything up to 15-20 different alarm routines in a job. I like online programming and do it all the time - even with equipment running. IT AIN'T WORTH IT

[PMCR 65]

poovs This sounds like security / detention industry. Function Blocks are one way to make your job easier. Another way to do this that I use is to take a function like a door unlock, and create a single instance of ladder code using indirect addressing (using IR pointers). Then wrap a for / next loop around the code and step through many instances of the code in 1 scan. This cuts down troubleshooting, as you are changing 1 instance of your code. Here is an example. Door release buttons for 400 doors at 50.00 - 74.15 Individual timers for each door T100 - T499 Door outputs at 100.00 - 124.15 Press and hold a button for 1/2 second before opening a door. This takes some work up front to line up the data in contiguious blocks, but makes for some very efficient code. Simple_For_Next_Loop_Example.cxp

[ParaffinPower 12]

Sweet!

[Donovanr 0]

Yes this is a definite downside with using FB, Your processor needs to be very quick depending on the quantity of FB you attend to use. I have used 100x Ladder FB's before on project, only to revert back to Ladder because of scan time issues using a CP1H

[poovs 0]

This is very interesting... I have read about indirect addressing within a PLC but never attempted to implement. I use indirect addressing frequently within my HMI scripting to re-use a single screen/window for 100's of similar devices... perhaps the PLC should follow suit. thanks for the **ahem** simple example, it certainly pointed me in the right direction. I am going to abandon the FB method. Thanks for everyones' input.

[pfort 20]

Hello PMCR This is very interesting for me. I never used FOR/NEXT loop, but wanted to learn, and i think that with your example i got it. Just to make sure, i have a question or 2: The loop is repeated 400 times before the scan continue after the ''NEXT'' rung. Right? If yes, how much time does it add to the scan time, assuming it is a CJ1M CPU11 like in your example? I never used indirect adressing except indirect DM (*D) so with your simple example i got how to use IR ...very nice :)

[PMCR 65]

Your understanding of for / next is correct. The for/next loop will run however many times you specify (in the FOR statement) before continuing on in the ladder scan. The execution time would be just about the same as if you wrote the ladder out straight the number of times specified in the FOR instruction. So, if you have 10 rungs in between the FOR and NEXT, and the FOR specified 25 loops, then the execution time of the for / next loop would be the same as if you copied / pasted the 10 rungs 25 times. For / Next is not really a faster way to execute code, but it makes writing repetitive code much faster, much easier to change, and allows the use of smaller memory capacity processors.

[Sleepy Wombat 27]

I believe that the latest CX Programmer and the latest version 4 cpus allow this...... The indirect method of programming can be very powerful if you can get your head around it.. i have attected a simple example.

[PMCR 65]

CPU version 4 can online edit Function blocks, but they cannot be created (from scratch) online. CX Programmer 7.0 or higher is needed for this functionality.

[BobB 56]

Why bother? The FOR/NEXT loops look interesting though.

[pfort 20]

Because there are many applicacations other than FOR/NEXT loops. Example: Lately i needed to send and receive explicit messages for E5ZN controlers. This FB saved me lot of time, look the ladder inside of it you will understand what i mean: omronlib/temperatureController/E5ZN/Dnet/_E5xxDRT400_WriteVariable10.cxf

[scottmurphy 1]

I agree, with the right thought For Next Loops can be quite efficient, but we also need to think about who supports the code after we have gone, will the infamous 'bubba' be able to troubleshoot it. This is where a HMI and fault routine/status indication are really useful. PMCR, Just a note, I believe you can also use the + after the IR registers to auto-increment the pointer, negating the need for the increment rung you have. But I'm picking you put this in for the example purpose. :

[PMCR 65]

I understand your comments about the troubleshooting for the poor sap who works on the code later on. I usually try to document the snott out of the code, including rung comments and annotations. You are also correct about the auto incrementing, but this only works if neither a constant nor DR preceeds the IR (as in DR0,IR1 or 2,IR1). DR0,IR1+ and 2,IR1+ are not allowed. You can use a + after the IR to increment after using the IR. You can also use ++ to increment by 2 after using the IR. I usually don't do this, as I am often incrementing by 10, 16 , etc. where +L IR0 &10 IR0 works better.

[scottmurphy 1]

Hi Bob, The For/Next can be very useful when configured correctly, I quite often use it for analogue setpoints/alarms/scaling etc. If you need any help on it just let us know, it can also help to generate a large amount of repetitive code very quickly (takes a bit of time to setup, but after is no problem), and reduce the CPU size also. Scott

[suby 0]

Hi all! Just one small thing regarding FBs with OMRON PLCs: Look at the PLC Memory utilisation at "View/See Memory" (UM's). Sorry but I'm using Cx-P in Spanish! Sometimes when using big FBs (i.e. with floating point calculations) or just Omron's made FBs (like those for Mechatrolink or DeviceNet), the CJ1M's PLCs become small and you need bigger PLCs (CPU43 or higher). FBs are a good tool to avoid typical problems caused by "Copy & Paste" programming whenever you need to use several times the same routine, sequence or steps, but be aware of Memory (UMs)! OMRON PLCs were not block oriented like SIEMENS. Best Regards! SUBY

[PMCR 65]

Scott The MOVRW is used when you want to point to the PV (present value) of a timer or counter. If you simply want to run the timer, and then use the completion flag, you can simply use MOVR. PMCR

[NovalutionGSi 0]

Just to bring this back to the top and from the dead! I perosnally have an application that should be perfect for Function Blocks, but my question is as follows, could i use one FB to "retrive" data from verious DMs for it to use, yet use the same FB numerous times with different DMs? my appliction has grown since my 1st posts i've made on here over 3 sites, now its got to the stage where writing it "long hand" in Ladder is just silly so moving to FBs would be best as the Scan time isnt really that important as i would have a 5 minute scan cycle anyway.

[pfort 20]

As far as i understand of your needs, FB are perfect for that. You can change the DM's for each instance of your FB.