Function Block Instance error

[Tess 0]

I'm nearing the end of a project in which a an Omron PLC, CJ1M series, communicates over a ModBus network using a SCU41 card to read/write various data accross the network. However, I've recently come up with a problem that's making all my work seem useless. I have been creating a function block for each kind type of component across the network, be it power regulator or circuit breaker, that way its easy to take a block and move it across a program plus it serves as a black box, you don't need to see what its doing, just the results. However, due to many, many comparison lines I've inserted to map the different data types in each of the network components (aka the program automatically knows wether its looking for UDInt, Floating Point, UInt and gathers the necessary date), I had too many steps and ran out of UM. I therefor changed from a CPU11 to a CPU22, and all should be good. However, I now get an error message "Internal error. Failed to generate Function Block Instance code" which is preventing me from sending my program to the new CPU. Only 1 of my FBs seems immune to this error. Any help? Edited 2 May 2006 by Tess

[Tess 0]

I seem to have fixed my problem by loading a a slightly older (but not enough for me to lose anything) version of my project. Good thing I had a backup... I still don't have a clue why it wouldn't let me use them instances though.

[Nibroc 4]

Tess, Not sure if this will help ... I had a program which I developed in the office and test ran on a spare CPU 12, this program had many FB instances. On site I converted the program to suit a CPU 13. The program would download into the CPU 13, however the PLC kept reporting a fatal error, related to invalid code !! I tried everything from initiating the PLC, checking the program etc but could not get the CPU13 to run the program. I tried starting with the original CPU 12 version which worked on the office CPU12, however every time I converted to CPU 13 (or back again) the code would no longer execute in the CPU13 PLC !! To solve this, I created a new blank CPU 13 project, and cut and paste the FB's and program from the CPU12 project to the CPU13 project. After this all worked fine !! Something was corrupting my original project when I tried to convert it from one CPU to another ? Give it a try .... not sure it will help ... Nibroc Edited 2 May 2006 by Nibroc

[Tess 0]

Thank you Nibroc. Although the problem had fixed itself temporarily when I switched to a slightly older backup, the corruption must have still been there for it came back haunting me today. I then decided to follow your advice and voilà! My problem is fixed... Hopefully forever. Conversions are annoying, I've decided!

[Nibroc 4]

... Glad I could help. Interesting to hear that this is not a one off case, it seems the CPU conversion causes 'issues' with FB instances! It took me a couple of hours and much head scratching to find a solution! Nibroc

[MuttsNutts 0]

I have seen a number of occasions where editing of FBs in CX Programmer will lead to strange errors. I use ladder FBs and structured text FBs, some nested, some not. I also reuse instances of FBs and merely load an IR with the start address of a block of data (and use +n,IRy to offset into the data) before moving onto the next similar block of data. This reduces the amount of memory used dramatically. However, when I change one aspect of the FB - for example, add a new Input to the FB, all references to the FB in my ladder programmes appear in red. Sure, I can just go and edit each instance to "plug in" a value/address to the new FB input but this doesn't always work. Cutting and pasting the lot to a new section within a programme always cures the problem. Therefore, I suspect it has to do with CX Programmer ver 6.11 moreso than the actual mechanism of the FB. My findings anyhows.

[Guest anonymous]

If you add an Input or Output to a Function Block that has already been used in the Ladder program, then any invocations will need to be updated. Simply right click on the FB that is displayed in red, and select 'Update Invocation'. If the addition was an Input, then you will need to add an Input parameter. You don't need to do this for an Output. Hope this helps Regards anonymous. Hello Tess, What version of CX-Programmer are you using? Regards anonymous

[MuttsNutts 0]

uuuuuhhhhhh. Good stuff. Hadn't thought of that (or known about it). Thanks, this will help lots.

[Tess 0]

I'm using CX-Prog 6.00. I'm actually doing an internship at my school (Last semester of a 3 year career program), so I don't believe there'd be any easy way for me to update to the lastest version, either.

[Guest anonymous]

Hello Tess, In v6.0, there was a minor problem with the number of FB instances that CX-P 'generated' for the CJ1M range. I can't remember the exact details, but depending on how many instances of FBs there were, and under certain circumstances (in particular during CJ1M conversions), CX-P would generate an erroneous number for the FB instances. I believe that this is now fixed (probably not a lot of use to you right now - but at least you can take solace in the fact that you are not alone ). As nibroc correctly pointed out (and as you have found), the copy and paste is a workaround. Sorry I can't be of more help. Regards anonymous

[VAU_RMA 3]

Problem: Error message: "Failed to generate Function Block Instance code" Why: This may be due to a bug in CX-P that have deleted the "initial value" on some of the variables in the function block. Solution: 1. Open the edit window for the variable, and activate "retain", then press "OK". 2. Open the edit window for the variable again, and disable "retain", then press "OK".

[Alberto 1]

Thanks to VAU_RMA we could easily address the problem. The file probably got corrupted after an international settings change in windows control panel. Changing the initial value of all the REAL parameters inside the function blocks from 0,0 to 0.0 solved the problem

[pfort 20]

7 hours ago, Alberto said:

Thanks to VAU_RMA we could easily address the problem. The file probably got corrupted after an international settings change in windows control panel. Changing the initial value of all the REAL parameters inside the function blocks from 0,0 to 0.0 solved the problem

Yes very important: You must have the same decimal symbol (point or comma) in your Windows Parameter/Regionnal Setting, than you have in your FB if in structured text.