Subroutine bug across POUs

[Saxony Thermal]

Hello, I have a subroutine error that I cannot figure out.
I had about a 45k step ladder project with about 50 subroutines running great. I decided to add another subroutine and I get this error (attached.)

• Error H33E7 which means there is some structural ordering issue. I have had this before and it was always that I forgot my RET or I deleted a RET on accident after a subroutine definition. No prob, easy fix.
• However, that is not the case with this issue I am having. After cutting code out of my project until the error went away, it came down to specifically this: (see simple code attached)

This is a test project separate from my main project to replicate the issue. Notice in the Navigation panel that I have two POU's under main program. POU2 shown in the picture is M0 controlling a call for P1. FEND, then P1 is defined as a simple INC Z0 and then RET. This is the exact 'structure' in my working subroutine ladders but with much more complex operations; where, I define 50 or so subs P1-100 thereabouts, and call them throughout my other POU's, and each sub is 25-100 rungs.

This code you see does not error until I added POU1. Meaning, building and simulating POU2 by itself will work. Adding POU1 is a simple SM401 (always off) controlling INC Z1. Its just a dead line to make POU1 a thing when compiled. Then I get the error. No matter what is in POU1, the error will exist. This basically means I cant have any other POU's without a structural error when using subroutines.

In diagnostics while simulating (and on the FX5UC PLC unit I have, I tested if it wasnt just simulation), I can jump to the error line. It will always point to the first line of POU1. This is important to note: in my full program with the 50 subs, when the error occurs, it will pick one of my 7 POUs and say error at the first line of it. If I unregistered that POU that is marked, the error will simply jump to another POU, and so on until it was reduced to basically the sample code I showed in the attached. The error went away when it was 1 POU.

 

But in my working project (before implementing this sub that caused all this issue) all these subs work and there are several POUs.

I spent a 2days on this so I am just g oing to copy paste this code I intended to sub many times just to move forward, but I want o understand what is the hangup. The test project was me just trying to write a sub again and apparently I cannot anymore.

Thoughts? I appreciate it, thanks.

 

 

 

 

[Gambit]

Did you check what the on which pointer nr the global pointer is set ?

By Default on an iQ-R it's, the FX5 2048

[Saxony Thermal]

I think I found what you are referring to (attached). I am in IQ-F which also is 2048 points as you said. But what do I do with that? Would my 50 subs consume all those points? I cant imagine more than a point per sub, right?

 

So that I can finish my project, I found a work around where I didn't do the additional sub routine and instead copied the routine code the several times it needed to be ran.

Or I had to merge 3 POU's into one. So I had 7 Pous, and 3, 4, and 5 had to merge to make the sub work which was not something I wanted to do for organization purposes.

I don't know what merging POU's solving the issue mean. The order of the ladder did not change. I simply copied the code all into one POU (because I was trying to see what the problem was) and the error went away. My code is running on a PLC fine now, no functional issues and passed bench tests.

 

I still want to understand this issue because its preventing me from doing more subs (big issue) or ruining my organizational structure (also an issue). Maybe its not just a pointer issue but a large abstract structural problem, and the subroutine pointer just brought it to light?

 

[Saxony Thermal]

I am on the trail to discovering the issue. I have gone a while without the error and successfully made new subroutines but didn't know why I have been fine.

The issue reappeared the moment I unregistered a POU (so I can test something without the influence of a POU within a program) and then I re-registered that POU. Now, when I re-register, the registration creates a new program to house the POU under 'even' or 'scan' or 'initial' etc. I then drag the POU out of the program into the 'mainProgram' program tree where I intend it to be in and delete the program made from registration. I get structural error, even though its identical code to before I did any re-registration.

I jump to the error event and it is the start of the POU just re-registered.

I will continue to investigate. but does anyone have an idea on that? This issue did strictly re-appear after I re-registered a POU and inserted it into my program.

[Saxony Thermal]

So i Unregistred the POU again. Simulated, and the structure error is gone.

I made a new data (POU) for my program. Thats it, leaving it blank. No error.
But I remembered that it will error if there is at least one line of code in it. so I shall add an SM401 INC Z15 (just something useless)

Boom, structure error. Project is bugged.

I remember the way I fixed the project before, I had a miscellanea POU for random small operations and I had to shove all my PID temp control code in there so it became PID and miscellanea.

This will happen again out of necessity; I have to now merge my analogInputs POU into some other, perhaps digitalOutputs to make a combined POU and call it 'AI and DO'.

what in the world? xD

Its night and day now, so this 'is' I guess literally what they were saying, "structure error". There is something that bugged in the POU structure / file structure and my patch is to combine POU's.

[Saxony Thermal]

Just confirming I have no error now with all my code present but with 1 less POU. Now I have 4 POU's. Eventually it will be one mass.. undesirable

I'll have to make a new project when I have time and play with re-registration and see if I can narrow in on the bug. I have done registration play quite a lot without this issue so maybe I maxed something out for this project.