TDMS with Action Engine (Functional Global)

[NIquist]

I can't seem to use my standard Action Engine paradigm with the TDMS functions.  I want to have actions like, open TDMS, Write Data, then close TDMS.  Even the simplest attempts to write return an error -2501 (Invalid TDMS File).  

[NIquist]

OOP!  Don't know what I pressed but it submitted my post twice before I was finished...

I'm using a shift register to store the reference.  I've done similar things before but the TDMS VIs don't seem to like it. Probing the reference always show it as the number 1.

Strangely, open TDMS and close TDMS seem to work fine (no error).  It's only the read and write functions that can't find the file.

I can dump the action engine idea and just string the functions together but I'm wondering if anyone else has seen this and whether or not there's a solution.

[Herbert Engels]

I wouldn't know of any issues with doing that. Storing the reference to a shift register is a perfectly valid thing to do. I'd be happy to help out, but I would need a code example that illustrates what exactly is going wrong.

Thanks,
Herbert

[Ben]

Yes as Herbert indicated an example would help.

Wild guess flows.

Is the AE going idle before ther read?

LV cleans up resources of VI's that go idle so make sure the AE is is in a VI that remanis running.

Done guessing.

Ben

[NIquist]

Thanks for the replies,

Here is a stripped down example.  I don't think the VI is going idle since I'm not closing it.  However, I am just running it by itself, selecting an action and then hitting the run arrow (i.e. it's not a subVI within a main VI that is constantly executing).  I thought that would maintain a valid reference and it seems to since I get no error closing the TDMS file, just when I try to read or write data or properties.

[Herbert Engels]

Not sure I'm getting this right. How do you call the action engine? If I just use it as a subVI, it seems to work fine for me ...
Herbert

[Jarrod_S.]

I think what you should investigate is an auto-initializing Action Engine. This is a tried-and-true technique that will work when used as a subVI or when called by itself. The idea is to use the First Call function to determine if you need to initialize your data structures, such as the TDMS file reference, rather than having a specific Initialize case in the Action Engine. That way, the first call to your Action Engine opens the file, regardless of which operation you're doing (Read, Write, etc). So you know you're always working with valid, initialized data.

This works for the case when you just press the run arrow everytime, since everytime you do that is the first call. When used as a subVI, there's only one first call, but you don't need to reinitialize your TDMS reference since LabVIEW won't clean it up unless the Action Engine VI goes idle.

I've attached a dummy example to help out. It doesn't do anything interesting, but should get you started.




Message Edited by Jarrod S. on 03-26-2008 11:21 PM

[Kevin_Price]

---

...I am just running it by itself, selecting an action and then hitting the run arrow (i.e. it's not a subVI within a main VI that is constantly executing).  I thought that would maintain a valid reference...

---

Nope, sorry, LV will clean that up that reference for you when the vi stops running.  You won't be able to test Action Engines as stand-alones.

I almost always make a very simple test vi for my Action Engines that let me exercise them.  Basically, I call the "Init" case, then I go into a while loop with an event structure.  I have an event for my "Do Action" button which lets me manually exercise the Action Engine.   Only takes about 5-10 minutes to code up a crude test vi.

The technique of initializing on first call can also be useful.  I myself usually logically OR the "First Call?" primitive with a boolean input -- this allows me to support a forced initialization option.

Final note: I've built apps that stored a TDMS file ref inside an Action Engine and it worked just fine.  The problem is simply that you can't test the AE as a stand alone.

-Kevin P.

[NIquist]

Thanks Guys!

I figured that LV must be tossing the refnum.  I use Action Engines for DAQ tasks all the time and the tasks remain in the shift register just fine as I test them stand-alone.  I thought I'd done it before with refnums but I guess I was mistaken.  LV and Learn!

K

[Kevin_Price]

FYI: that trick only works with DAQ tasks based on the legacy driver, aka "Traditional NI-DAQ."   The newer DAQmx driver does the same kind of cleanup on its tasks that you saw with the file refnums.  Forewarned is forearmed.

I also used to test my DAQ Action Engines in stand-alone mode with the legacy driver.  That was how I first started the habit of making a separate action-engine-tester vi.

-Kevin P.