I am using SVN to control its sequence file versions.
All steps in the sequence files are steptypes. And they all are settable via edit steps.
One problem is that, when you set your step via edit steps, TS UI isn't refreshed so the programmer might think that the edit step failed programming the step.
See this NI TestStand Idea Exchange thread : http://forums.ni.com...p/idi-p/1753456 (please Kudo if you think the idea is great... ).
So NI advices to generate an IncChangeCount to force TS to refresh its interface. This method makes the sequence file to be seen as 'changed' (star next to its name in the TS tabs).
When launching an edit step, it loads the current programmed values of the step to display them on the edit step interface. If the user doesn't change them and the IncChangeCount is generated, then the file is seen modified ( ) and the 'Change counter' is incremented.
In these conditions, SVN doesn't detect any change to the file !!
This would mean that the 'change counter' is not stored in the file... Do you have any idea on where it could be stored ?
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.
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.
I need some help.
I have a motor that moves a tray.
During the movement of the tray, 2 switches will change value.
I want to read out the counter value / motor position when the signal of the switches changes. (rising and falling edges)
At this moment the only thing I can think off is a loop vi that reads the value of the swicthes and motorposition and evaluate the swicth states... But i'd rather have the position reading triggered by the digital lines.
I'm running LV2010SP1, DAQmx 9.4
cDAQ chassis: 9178
NI 9401 module => encoder signals are connected to this one.
NI 9403 module=> 2 digital inputs(so the switches) are connected here.
Thanks in advance for your help.
By Neville D
working on my first reconfigurable IO project using a PXI 7811R with LabVIEW RT. I am building a quadrature encoder counter using a couple of the NI examples, and was wondering if there were any caveats to changing it to use an I-64 as the counter output? The NI example uses a 32 bit integer for the count.
In my version, I changed it to an I64 count output and added a speed (counting ticks between pulses) output as well.
It seems to work fine, but would appreciate any cautions that experienced FPGA users might have.
PS. Cross posted to info-LabVIEW as well.
I wrote the following program trying to output a series of 100 samples of pulses whose frequency is ramping up from 10 to 100. Device: PCI-6229.
I got error: -201291: Pulse specifications cannot be written to a finite counter output task on this device.
I do not know what was wrong.
Basically I have no idea how to use the vi, DAQmx Write: Counter Freq NSamp 1Chan or NChan
I do know how to use property node to change frequency and duty cycle on the fly. However, In this particular post I would like to know how to use this NSamp VI.