Parameters not passing to subVI correctly

[CoastalMaineBird]

LV 2013 SP1, LVRT 2013, Win7, PharLap 13

My project now and then (maybe once a weekn now) gets into a weird state.

The RT part (running on PXI 9186) comes up with an empty config.  It's supposed to read a config file on startup. When this weird state comes on, the config shows up as empty.

I've traced the problem down to a parameter that is just not being passed from the main VI to a subVI.

Here is a  JING  that shows it.

You can see that the constant is set to INIT (I have replaced this to no effect).  But when you step into the subVI, it comes across as "Nothing".

"Nothing" is the default value of the control on the subVI.  But you see the step.

The OUTPUT manager, just below this one, uses the same constant, and shows the same trouble.

It doesn't happen with th other VIs there.  But they use a different ENUM (even though it also has an INIT value).

There's nothing unusual about this subVI.  It's not reentrant or inline or anything.

This error comes on every now and then.  It goes away after some combination of restart / power-off of the PXI box and/or the host PC (haven't found a reliable fix yet).

Any ideas?

[CoastalMaineBird]

Well, this time it didn't correct because of a restart, but a recompile.

I turned debugging OFF for the subVI in question - no effect.

I turned it back ON, and now things are working.

Don't understand that.

Still would like to know why.

[GuenterMueller]

It might be a variety of LabVIEW changes enumeration constant values randomly.

Have you tried replacing the block diagram constant of the typedef'd enum by a simple numeric carrying the "Init" value?

[JÞB]

Absolutely odd!

Just to rule out a few possibles (I'm sure you may have done so but... lets go there anyway to be sure)

Double check that VI Hierarchy view with show controls turned on.  (And please, use non-default icons for the type defs OK?)

Clear the object cashe.  I KNOW! that sounds silly but try it anyway please.  That debug on-off switch would have forced some recompiling and that gets a small deflection on my "somethings-wrong-o-meter"   

And lastly (this will sound even sillier but, try it OK?) Try using 1 constant per enum per type def.  Yup, branch the wire where "Init" is of the same enum.  I told you it would sound strange!  A miss-optomized buffer (Over-reused? ) sounds totally insane but.... those bugs fixed with an Always Copy might have been too agressive.  Then again- I might be right with fix 1 or 2.

Now, All of that being said, Please tell me that "Init" of control1.ctl and "Init" of control2.ctl have the same interger representation and value.  One Pattern I adopted years ago was to have most of my AE Case enums (Methods) as [0-"Null" , 1-"Init"... n-"Close"]  Why did I do that?  "-1" closes everything and default[0-"Null"] is a no-op.  Also, strange stuff happened when casting text from file to enum.  Usually my fault for a bad cast! but often enough explained by divergent enum represetations and identical strings.

[Intaris]

I have made similar observations in the past which had me tearing my hair out.  My observations may or may not align with yours but I'll chime in just in case.

1) LabVIEW sometimes to get confused between which files are deployed on a RT target and which files it is using for debugging.  I've had files which were running on the RT but were NOT marked as reserved as well as the opposite (Files reserved which I had actually removed from the RT target).  While I have not specifically seen the case you are showing in your JING it's not too far-fetched to think the situations behind the scenes may be similar.  I don't use the "step into" function a lot, so that might be why.

2) Our experience is that it is made much worse by utilising inlined VIs (especially nested Inlined VIs) but this is just a feeling.  We also think it may be significantly linked to the "separate compiled code" option and the associated administration of said functionality.

3) Changes to compiled code of lower levels of the Inlined VIs are apparently not automatically reflected in the higher-up VIs.  This leads to LV thinking the current files are deployed but in fact they are not (many of the VIs don't actually exist in the final deployed code.

4) Try forcing a recompile (Ctrl-Run) on the offending VI and all Callers step by step up to your top-level VI.  This generally gets it working for us.

5) Learn to live with it, it's a major PITA.  We've learned to do step 4 out of habit now eacht ime we make a change.  It slows down our workflow considerably but at least we make progress.  There were a few weeks where this problem was making me seriously question my sanity and ability to understand basic debugging stuff.

There are a couple of INI entries which NI suggested we use, we didn't find that they helped, I've since removed them I believe.

[CoastalMaineBird]

OK, thanks everybody.  All of your suggestions point to some LabVIEW bug and the next time it occurs I will try them.

[GuenterMueller]

Intaris, your link in the first line is not accessable to ordinary mortals like me. Seems to be restricted to LabVIEW Champions.

Just to let you know.

[JÞB]

---

@GuenterMueller wrote:

Intaris, your link in the first line is not accessable to ordinary mortals like me. Seems to be restricted to LabVIEW Champions.

Just to let you know.

---

Steve,  PM me contact info.  Guenter is right that link is not for mere mortals. and I wouldn't even publically admit to having read it.  I'll see what strings I can pull with @T-REX$ to discuss what you are finding.  Your SSP is up-to-date right?

[CoastalMaineBird]

My info is publicly available, via my profile.

[Intaris]

Oops, sorry about that.

I had forgotten where the post was andhad to search for it to find it.

My bad, apologies.

Shane