04-29-2011 07:06 AM
Hey all,
I'm designing a system where two valves are controlled by the input from two flowmeters (counters). Reading and writing to the channels works fine, but from there I would like to synchronize the in- and outputs.
After trying a lot of suggestions from the forums or the Labview examples, none seem to fit my problem.
The setup consists of a CompactDAQ 9188 chassis, an NI 9263 AO module, and an NI 9411 CI module. What I'm trying to achieve is to implement shared sample clock and start trigger for all channels. Ultimately this should lead to a TDMS log file with a certain timestep.
Edge counting instead of frequency measurement is used so zero flow can be detected.
The code got kind of messy so I'm starting from square one with this message, please see the attached code. Any help on synchronization is more than welcome.
Regards,
Bram
04-29-2011 12:09 PM
I haven't done this myself, but my understanding is that this is the way to share clocks. You export the sample clock from your AO task to a PFI line, then use that line as the sample clock for your counter tasks. Do the same for the triggers. Start the exporting task before the others. The DAQmx Export Signal vi is found in DAQmx Data Acquisition pallette-> Advanced Task Options -> DAQmx Export Signal. In some cases you can directly export the signal to the desired destination without needing the call to Sample Clock and the use of the PFI line as the intermediary.
04-29-2011 02:46 PM - edited 04-29-2011 02:48 PM
Richard is correct that you can share timing and triggering signals between the tasks. I would do something like this:
I started with Richard's example and added the following modifications:
1. Assuming you don't want to use an unnecessary PFI line, you can just route the clock internally.
2. You must start the master task AFTER the others. This ensures both counter tasks have started before the first sample clock edge is generated.
3. Adding the Arm Start Trigger ensures the counters start counting together at the same time that the AO task begins.
Best Regards,
05-02-2011 04:20 AM
Hey,
A few steps further and I'm encountering different problems. I configured the sample clocks and triggers as suggested.
When writing data to the Analog Out tasks before starting them, error 200609 pops up when I write two single samples on the Analog 1D DBL NChan 1Samp DAQmx Write VI:
In John's VI he writes data on Analog 1D Wfm NChan NSamp. Is that intentional? For my application I'm looking to adjust the voltage values in the while loop depending on the counter output.
When I follow John's example and configure a waveform for the AO channels, the above error does not occur but I encounter another error:
This seems like a straigtforward error, but I cant seem to fix it. Is it related to the number of samples that are written to the analog output channels? Disabling regeneration does not help. The updated VI is attached to this message.
I've got some more questions, but we'll get to those in due time.
Any help is greatly appreciated.
Regards,
Bram
05-03-2011 04:19 AM
Dear Bram,
Waveform is just another data type containing your y array, t0 and dt. You can select this or just an array. Within the task you have to select n chanel n samples or n channels 1 sample. You want to be able to change the analog output on the fly. It is best to keep one DAQmx write function within the loop. When we enter the while loop write the control values to DAQmx write, start the task (using a case structure and the 'first call?' function). Then write an array size of the number of analog outputs to the DAQmx write.vi.
Best regards,
05-03-2011 09:26 AM
Hey all,
Thanks for the help so far, I tried Martijns suggestion by adding the start task inside the while loop in a case structure. A cleaner look, but unfortunately this does not alter the functionality of the application. I still get the same errors described earlier. Since yesterday I looked into the problem some more and I will try to clarify what happens.
Ignoring the counters for now. The application should write different samples to two different AO channels. For control of the analog channels, I want to be able to adjust those values in a while loop. All is well when no sample clock is involved. I use a simpler VI that does just that:
When I add a sample clock below, an error occurs when I hit the stop button (actually the error is already present, but pops up after the while loop has been terminated):
Specifically Error 200609 when I specify a write 1D DBL NChan 1Samp:
:
Now I figured out that this error goes away when I change the write VI to 1D WFM NChan NSamp, so apparently this changes the buffer size in some way.
The problem is that I can't figure out how to wire two 1D Waveforms to the write VI without running into new errors, see attached VI... Note that the goal is to adjust the AO values in the while loop for control purposes later (that is also why the wait until next ms VI is there).
Why isn't it possible to just stick with the one sample per channel when a sample clock is added?
Regards,
Bram
05-03-2011 10:21 AM
Hi Bram,
If the control is coming from the software loop anyway, what is the purpose of the sample clock?
To explain the errors you are receiving:
Anyway, I don't think that simply fixing the errors is going to give you what you want. Rather, I think what you're really looking for is a software-timed generation based off of the voltage computed by your control loop.
Best Regards,
05-04-2011 07:21 AM - edited 05-04-2011 07:25 AM
Hey all,
To answer John (If the control is coming from the software loop anyway, what is the purpose of the sample clock?):
I was under the impression that a sample clock is needed to log to a TDMS file. Also, I corrected the sample clock in my previously attached example from finite to continous samples, which I forgot to do. My mistake.
What I want to do and why I supposedly need the sample clock and while loop with software timing:
For me this seems like a straightforward problem, combining the examples shipped with Labview should get me there. Unfortunately, as John already stated, I'm unable to use hardware-timed single point operations because of the chassis I am using (cDAQ 9188).
When I set the sample clock to continuous samples I run into the trouble described earlier in this thread.
If anything is unclear I'll gladly explain some more or post my current VI. Solving this has almost become an obsession 😉
Thanks all for the help so far.
Regards,
Bram
05-10-2011 07:13 AM
Hey,
Shameless bump.
Still haven't figured this one out. If there is anyone who has a clue, please shine your light.
Regards,
Bram
07-06-2011 01:33 AM
Hi AE,
Can someone help out here?