Module Template Code from NI Week 2011

[Amiri 0]

Hello Justin,

 

I am using the Module Template (along with the JKI State Machine) that you demoed at NI Week 2011 (Beyond State

Machines); good job on the presentation and thank you for providing the code.

 

I added my desired top-level vi to the module template library so that I

could generate public events and it works, but I am having a strange problem.

The generate public events vi is giving me an error 1 (very generic and hard

to track down), however, if I open the generate public events vi front panel

and run it directly (instead of as a sub vi) I do not get any errors... Any

suggestions?

 

It is inconsistent (sometimes no errors, but once they start I get them a

lot), and I have seen strange errors like this before with Active-X; where I

had to delete portions of the code and replace it to get it to work properly.

 

Also, do you guys still actively monitor the blogs below? I posted a few

related questions there as well:

http://blog.jki.net/events/niweek-2011-beyond-state-machines-slides-and-code-now-available/

https://decibel.ni.com/content/blogs/jim.kring/2011/08/09/niweek-2011-beyond-state-machines-slides-and-code-now-available

 

Regards,

Amiri

[Justin Goeres 1]

I added my desired top-level vi to the module template library so that I

could generate public events and it works, but I am having a strange problem.

The generate public events vi is giving me an error 1 (very generic and hard

to track down), however, if I open the generate public events vi front panel

and run it directly (instead of as a sub vi) I do not get any errors... Any

suggestions?

 

Hi Amiri,

 

The reason for Error 1 in a situation like this is almost always that your Event Refnums are getting destroyed somewhere.

 

Here's how things generally work. I'll try to explain it clearly, but feel free to ask for clarification if I screw something up:

1. Your code calls Get Public Events.vi somewhere (probably when a loop registers for the events). Because this is the first call to Get Public Events.vi the event refnums are created and stored in a shift register (functional global-style). On every subsequent call, Get Public Events.vi just returns these already-created refnums.
   
2. When your code generates a Public Event, it uses a VI called Generate Status Changed.vi (or similar -- it's specific to your app and your event). This VI calls Get Public Events.vi, which is how it gets the refnum for the event that it wants to generate.
   
3. Later, when your application exits, it calls Destroy Public Events.vi (or similar, I forget exactly how the template is set up just now), which destroys the events.
   

Note that after Destroy Public Events.vi is called, Get Public Events.vi will still return the same old cached event refnums, but those refnums will now be invalid and will result in Error 1 if you try to use them.

 

Calling Destroy Public Events.vi out of sequence is almost always the reason for errors like this. It can sometimes happen due to slightly wonky error handling, where (for instance) an error in the module causes the "Macro: Exit" sequence to execute, which destroys the Public Event refnums, but then another error occurs during the Exit sequence which causes other dependent actions to happen.

 

My top-line advice is to trace the execution of the module where you see this happening. Consider setting a breakpoint in Destroy Public Events.vi and some probes/etc. in your state flow so you can see exactly what's causing things to happen in the order they're happening.

 

Your comment has gotten me thinking, though, that Get Public Events.vi should maybe do a better job of reporting errors. We know why Error 1 occurs -- somebody killed our refnums . It would be totally reasonable for Get Public Events.vi to throw an error when its refnums go bad, rather than just blindly passing them out and waiting for another part of the code to bonk.

 

It is inconsistent (sometimes no errors, but once they start I get them a

lot), and I have seen strange errors like this before with Active-X; where I

had to delete portions of the code and replace it to get it to work properly.

 

It's true that once you get one error, you'll get a lot of them -- the reason, of course, is that once those refnums are destroyed they're gone forever. On the bright side, though, this is definitely not a situation where you need to just delete and recreate code -- it's definitely a legit behavior that you can track down and fix, although actually tracking it down can be tricky.

 

Also, do you guys still actively monitor the blogs below? I posted a few

related questions there as well:

http://blog.jki.net/events/niweek-2011-beyond-state-machines-slides-and-code-now-available/

https://decibel.ni.com/content/blogs/jim.kring/2011/08/09/niweek-2011-beyond-state-machines-slides-and-code-now-available

I apologize for dropping the ball on these. I saw your comment on the JKI blog a few weeks ago but it just slid off my radar -- I'll take another look at it.

 

The comment on Jim's blog is one I just wasn't aware of. We need to do a better job of keeping an eye on these things, and I really, really appreciate you taking the time to run me down on this rather than just giving up!

 

I hope that helps, and please get in touch if you have more questions. These forums are a good place, or the JKI blog post is fine, too. Thanks, and I apologize again for being hard to reach.

 

Justin

[Amiri 0]

Hi Amiri,

 

The reason for Error 1 in a situation like this is almost always that your Event Refnums are getting destroyed somewhere.

 

Here's how things generally work. I'll try to explain it clearly, but feel free to ask for clarification if I screw something up:

1. Your code calls Get Public Events.vi somewhere (probably when a loop registers for the events). Because this is the first call to Get Public Events.vi the event refnums are created and stored in a shift register (functional global-style). On every subsequent call, Get Public Events.vi just returns these already-created refnums.
   
2. When your code generates a Public Event, it uses a VI called Generate Status Changed.vi (or similar -- it's specific to your app and your event). This VI calls Get Public Events.vi, which is how it gets the refnum for the event that it wants to generate.
   
3. Later, when your application exits, it calls Destroy Public Events.vi (or similar, I forget exactly how the template is set up just now), which destroys the events.
   

Note that after Destroy Public Events.vi is called, Get Public Events.vi will still return the same old cached event refnums, but those refnums will now be invalid and will result in Error 1 if you try to use them.

 

Calling Destroy Public Events.vi out of sequence is almost always the reason for errors like this. It can sometimes happen due to slightly wonky error handling, where (for instance) an error in the module causes the "Macro: Exit" sequence to execute, which destroys the Public Event refnums, but then another error occurs during the Exit sequence which causes other dependent actions to happen.

 

My top-line advice is to trace the execution of the module where you see this happening. Consider setting a breakpoint in Destroy Public Events.vi and some probes/etc. in your state flow so you can see exactly what's causing things to happen in the order they're happening.

 

Your comment has gotten me thinking, though, that Get Public Events.vi should maybe do a better job of reporting errors. We know why Error 1 occurs -- somebody killed our refnums . It would be totally reasonable for Get Public Events.vi to throw an error when its refnums go bad, rather than just blindly passing them out and waiting for another part of the code to bonk.

 

 

 

It's true that once you get one error, you'll get a lot of them -- the reason, of course, is that once those refnums are destroyed they're gone forever. On the bright side, though, this is definitely not a situation where you need to just delete and recreate code -- it's definitely a legit behavior that you can track down and fix, although actually tracking it down can be tricky.

 

 

I apologize for dropping the ball on these. I saw your comment on the JKI blog a few weeks ago but it just slid off my radar -- I'll take another look at it.

 

The comment on Jim's blog is one I just wasn't aware of. We need to do a better job of keeping an eye on these things, and I really, really appreciate you taking the time to run me down on this rather than just giving up!

 

I hope that helps, and please get in touch if you have more questions. These forums are a good place, or the JKI blog post is fine, too. Thanks, and I apologize again for being hard to reach.

 

Justin

 

Thanks for the help, I was able to track down the problem after reading your post. I have made a "fix" that is working well, however, I have still not proved out exactly what the problem was (scary, I know).

 

I am not destroying the reference on purpose, but here is what I found/think was going on... My top level VI calls other VI's dynamically using a plugin architecture by way of VI Server and Sub Panels. If i do not first run that Get Public Events FG in my top level vi (the one that creates the events), it instead gets ran for the first time when I initialize my VI's into the sub-panel; after initializing my plugin VI's into the sub panel, the user can then (again) recall any one of the plugin VI's by selecting it from a multi-column listbox. (I initialize my plugins this way because I need them to communicate to my top-level VI whether or not their hardware is available, or in simulation mode)

 

My theory - So then if the top level VI does not first call the Get Public Events, it gets ran first by a plugin VI during initialization, but after initialization, the sub panel VI basically goes out of existence, and so the refnum(s) is no longer valid, but is still in the FG. Does this sound correct??

 

Unlike queue event refnums, when I probe a user event refnum, it does not tell me whether the reference is still good or not (this makes debugging a pain).

 

I like your idea of throwing some sort of message when the references are no longer valid, but how would you know when they are no longer valid, other than the specific instance of when you destroy them (which is not the problem in my case).

 

Amiri