Setting a NaN duty cycle can cause subsequent counter updates to hang

[mje]

This one caused me a day of grief.

Turns out an error in the start up logic of one of my applications would request a duty cycle of NaN to a counter output I'm using for pulse width modulation. The problem is the NaN request goes through without returning an error. But the next request to update the duty cycle hangs the DAQmx write VI. After hanging, there's no way out, aborting the calling VI leaves LabVIEW in a sorry state.

Example:

WARNING: Running the snippet above can leave LabVIEW in an undefined state. Save your work before you do so!

Now obviously a NaN duty cycle makes no sense, but I'd expect DAQmx to be able to handle such requests gracefully, either by ignoring them, or preferably issuing an error.

I've observed this behavior on the USB-6343 device.

[asbo]

Did you get NI's take on this?

[mje]

Nope, just thought I'd post it here. Not exactly a critical bug since it can easily be worked around. I have a few other counter devices I wish to test it on, then might file a ticket with NI.

[asbo]

Also in LV2011 (DAQmx 9.3.5), I tried this on a simulated device (PCI-6230, though I doubt it matters). It repro'd, but I couldn't stop the VI. When I tried to close it, it asked me to save; I declined and it got stuck at the "Resetting VI" window.

[mje]

Yeah, that's the same behavior I get.