Actor Method Call Not Being Made?

[thutch79]

I'm puzzled and I don't know how to troubleshoot this. I have a message class that updates a parameter in an actor (Pump Control) that's called Liquid Selection. When that method is called, it does not update the actor. I can probe the value of the data going into the call in Do.vi. It is correct. I can probe the actor data before the method call and after to see that it did not change the actor. I've set the method to show the front panel upon execution, and it never opens. However, I can probe the error wire after the call and that does execute. It seems Labview is just skipping this node. Can anyone help me with a path towards troubleshooting this? This is not the only parameter I cannot update so it doesn't seem to be limited to this one method.

Attached is a few screen shots of the offending code and the resulting probes.

[auspex]

I would put a breakpoint just before the case structure in Write Liquid Selection.vi. Then you can either probe it when it executes, or you can confirm that it didn't execute.

[thutch79]

The VI doesn't allow a breakpoint. Debugging is disabled and if I enable it, it breaks the VI.

[auspex]

That's curious. Did you disable inlining?

[thutch79]

The method in question is for data member access. I didn't specifically disable the debugging myself. Apparently it is setup for inlining, but I'm not sure how. Maybe default settings for actor framework or LVOOP?

[auspex]

I do believe it is the default. You can just toggle inlining off and debugging on in the properties. I would restore the default once the problem is solved.

[thutch79]

So, turning off in-lining seems to have solved the issue. Is there a bug with in-lining going on here?

[elset191]

I have seen this behavior several times, where the bundle inside an accessor does not seem to ever execute.  Toggling the execution properties always seems to make it fix itself.  It seems to happen randomly to different VIs every few months.  Hopefully now that it's documented here we (NI) can find a solution.

[thutch79]

Thanks for your help! What you said makes sense. This code worked previously. I then created a new concrete implementation of an abstraction layer. I didn't touch this area of the code in the abstraction layer, yet it broke. I was pulling my hair out trying to figure out how I could have broken something. I just went back and turned on in-lining again and it works fine now. Must be something going on in the background that's causing incorrect behavior.

BTW...I'd be happy to supply any of this code to NI if it helps track down the issue.