Compiler error

[dbrigada]

When I try to compile my VI, it says:

Compiler error.  Report this problem to National Instruments Tech Support.

Decompose Unbundler bad element mode=0x2.

[RavensFan]

Exactly what do you mean by "compile"?  Are you trying to build an executable?

Do you get any other error code as part of the message?

What version of LV are you running?

[dbrigada]

This happens when I select the run VI button or try to save the VI.  I'm sorry that the post didn't include the version number.  The support form asked for it, so I assumed that it would appear here.  I'm using LabVIEW version 8.5 (32-bit) on Windows Vista (64-bit).  This is the only error that appears, and it seems as though the dialog box with the error appears about 5 times each time it occurs.

[RavensFan]

It think those questions about the LV version only affect what kinds of results might show up as part of a knowledge base search.  It doesn't tie into the discussion forums.

Is your Run Arrow broken when you click on it?  Do you have any unbundle functions in your code?

Can you post your VI for others to try and see if they can replicate?

[dbrigada]

The run arrow appears fine until clicked, at which point the compile error boxes appear, the error list window comes up with the error "VI failed to compile," and then the run arrow becomes broken.

I don't think that I can post the full VI due to IP considerations, but I can post the part that seems to be causing the problem.  The Update Image VI in the middle compiles successfully.  I have also tried deleting and replacing all the bundle and unbundle nodes here to no success.

I have created a VI "Test Error.vi" that is essentially a copy of the problematic part.  I simply added some constants at the left hand side of the case node to get it to the point to where it should compile.  The Update Image VI compiles fine if I run it on its own.  It's a bit messy, but that's to be expected right after you convert something to a sub-VI.

The in-place node was there before the error occurred.

Pretty much, I took the code inside that in-place node, and put the majority in a sub-VI.  The clusters are to reduce the number of variables entering and exiting the sub-VI.

Thanks!

[RavensFan]

I can confirm I see the same thing in LV 8.6.  It actually gave me the error while opening because it was trying to compile from your posted 8.5 version to my 8.6.  The run arrow was then broken and said it was because it failed to compile.

I tried deleting the master cluster constant.  The recreated it by right clicking on the tunnel and Create Constant.  Then the error changed because it did not have a connection to the Sound Task ID typedef.  So I disconnected it from the TypeDef, but it still "Failed to Compile".

If I remove the In Place Structure, the error goes away.  Try eliminating that.  Then adding it again.

Perhaps someone from NI will jump in and can inspect your VI's in a more detailed manner.

[dbrigada]

So it works for you in 8.6 when you remove and recreate the in-place node?  For me, it gives the same compiler error when I do that.  Thanks for all your help.  Hopefully someone from NI can investigate the cause of the error.

[RavensFan]

I just got done recreating the In place structure.  No, it doesn't work after recreating.

Do you need to use the inplace structure?  Where does that cluster go?  You have nothing wired to it once it leaves the tunnel on the end of the case strucure.

I'm wondering if you are running into some memory conflicts since you don't have a similar structure in the other case.  Perhaps you should try turning it inside out.  Put the case structure inside the In Place structure and wire things through intact in the other case.

[dbrigada]

That cluster represents the internal state of the program.  I use that to minimize the need for local variables and stacked sequences in the program without having 30+ wires having to go across my whole block diagram.  I use inplace structures to minimize data copies throughout the execution of the program.  It currently isn't perfect, but it's much faster than what I had before.  That happens to be the last inplace node in the main loop of my program.  After that, it goes into a shift register ready for the next loop of execution.  From there, it filters through several other inplace nodes, and returns to the problematic part.  I'm sorry that I can't show you the entire program, but that should give you a general overview of what it does.

[dbrigada]

Replacing the inplace node with a bundle/unbundle fixes the problem for me, but it causes an extra undesirable buffer allocation for a new copy of the cluster.  I'm guessing there's a problem somewhere with the inplace node.