TCLK Synchronisation error requires computer restart

[jcswright]

Hello

I am using a PXI chassis with an MXI card, and synchronising a PXI-5122 digitiser with a PXI-5412 FGEN using NI-TClk.

I configure the TClk session in the conventional way (I think!) as so:(Apologies for the broken wires - I tried to take a snippet of a bit of my VI rather than the whole lot, which I unfortunately can't release.  However, it works fine so no need to worry too much about it!)

Then the program runs, and works fine, and then at the end I release the devices as follows:

And this also works fine.

The bit that doesn't work is if a user sets a combination of settings that aren't allowed, for example capturing more samples than is possible with the onboard memory.  Then, despite the fact the snippet above still runs on exit, I am unable to use the cards again without shutting down the computer and re-booting it.

The error I get then comes from the "niTClk Sychronise.vi" and says:

I can, of course, check for all possible permutations of options for the cards and prevent incompatible options.  These are strictly in-house applications, though, and I would like to give my users as much flexibility as possible, so that would be quite a task.  I'm not complaining though - I know it's the right thing to do but I don't write perfect code first time every time so there will still be some testing and the occasional time when something slips through.

It seems wrong that even during my testing there will be times when I have to shut down the whole rig just to get up and running again, and quite a waste of time - so my question is:

Is there something I can add to the 'standard' combination of niFgen Abort Generation.vi, niFgen Close.vi and niScope Close.vi, which will force the cards and TClk session to be released regardless of their state (i.e. if they have hung)?

Thank you!

P.S. This is for a built application - running the code from LabVIEW itself I don't have the same problem.

[Riley_Ilieva]

 Hi, 

We have a knowledge base article on what could be causing this issue - http://digital.ni.com/public.nsf/allkb/C087AC5A9C4536ED862579960063C85B?OpenDocument . There are a few suggestions for a workaround on the bottom. 

Let us know if this helps. 

Kind Regards, 

Riley Ilieva

Applications Engineer

National Instruments

[jcswright]

Thank you Riley.  I am fairly sure that is not the problem, but I appreciate the link!

On further investigation I believe that the incorrect parameters cause errors, but then my program actually hangs at niScope Fetch.

I also have the problem of how to cancel a hardware trigger (with a long wait-time, i.e. without a timeout) if the program needs to be reset before it has been triggered, and I believe I can solve both problems with the same solution.

I have found some links dealing with similar problems, and I will work my way through those suggestions and see if anything works for this situation:

https://forums.ni.com/t5/LabVIEW/waiting-on-scope-to-trigger-or-aborting-before-trigger/m-p/41345

https://forums.ni.com/t5/Example-Programs/niScope-Configured-Acquisition-with-Polling/ta-p/3524090

and

https://forums.ni.com/t5/High-Speed-Digitizers/How-do-you-abort-the-Scope-Fetch-before-a-trigger-occ...

The NI example is: "ni SCOPE Allow User to Stop VI on Long Trigger Wait" at http://www.ni.com/example/25427/en/

but with that approach I am concerned that a trigger might be missed if it occurs outside the timeout period - what do you think?

Thank you again,

Jonathan

[Riley_Ilieva]

Hi Jonathan, 

Thank you for the info. 

When you open a task for an instrument and set up a trigger, the trigger still work for measurements that you take within a loop as you pass a reference to it. There are some examples here (they are for DAQmx but the principle is the same) .

Many Thanks, 

Riley Ilieva

Applications Engineer

National Instruments