We've got three devices we want to synchronize:
- "pressure" gives us an analog input
- "valve" needs a square wave pulse via counter channel 0
- "cam trigger" needs a series of square wave pulses via counter channel 1
It works as long as either the expansion valve OR the cam trigger is attached to the pressure. But when we attach both, we get Error 50103: resource is reserved. Does that mean I can't use both counter channels at the same time? At least that was what I guessed reading some other posts in this forum... Or does the synchronization not work properly?
Anybody got an idea how to solve this, or which alternatives there are for using the counter channel?
Thank you for your help.
Solved! Go to Solution.
The program setup is alright. It might be an issue with the Hardware and counter clock.
Please let me know which DAQ card (model number) you are using exactly.
Applications Engineer, NIG
Thank you for your reply.
I'm not exactly sure what you mean my "model number", as I considered 6036E as the model number. So I attached a photo of the card.
You said that it might be an issue with the Hardware and counter clock. I've been testing a bit and it might be that the ai/Start Trigger isn't compartible with ctr1. What could I do instead?
thanks for the pics.
I did some research about synchronizing two counter outputs. Unfortunately the DAQCard-6036E doesn't support to synchronize 2 counter outputs,
therefore you got the error.
The reason is the NI-TIO technology, which isn't supported for E-Series Cards.
Check the following link:
There would be an option if you have a M or X-Series cards with an ARM-Trigger
Don't give up just yet. It sounds to me like you may not need the missing features that are typically meant when people talk about synchronizing tasks. Your description sounds like you may only need to operate the counters simultaneously and independently, without need for sub-microsecond timing sync.
One bit of info that isn't obvious on the surface is that if you choose Finite Sampling mode for a counter pulse train, an E-series board like yours will use up both counters to generate the finite pulse train. Then when you try to make a task for the other counter, you get an error because it's already being used behind the scenes.
If you used Continuous Sampling mode, the task wouldn't use the other counter behind the scenes, leaving it available to be used in a different task. This would also be true if you generated a single pulse (configure the task without ever calling "DAQmx Timing.vi").
Another sneaky trick that might work is to create a useless dummy AO task which generates 0 volts and isn't wired anywhere. *BUT*, you may be able to route its sample clock out to a PFI pin, thus generating a finite pulse train without using *any* counters. Just note that the pulse train will be a very low duty cycle rather than truly square. But if your devices are primarily sensitive to pulse train edges rather than time spent in a given digital state, it won't matter.
So... does the valve need a single pulse? How crucial is the timing? There's a chance you could do that with a software-controlled digital output instead of a counter.
Does the "cam trigger" need a precise # of pulses? Or could you generate a continuous pulse train for an approximate # of pulses by using software timing to decide when to stop the task?
Thanks for your reply.
Indeed I just need the two counters operating simultaneously and independently. I tried without synchronising first and got the error you described below.
"If you used Continuous Sampling mode, the task wouldn't use the other counter behind the scenes, leaving it available to be used in a different task. This would also be true if you generated a single pulse (configure the task without ever calling "DAQmx Timing.vi")"
Sounds great! For the valve, I only need a single pulse. But if I don't use the Timing.vi, how do I attach the clock? Or would a clock not be needed in this case?
The cam trigger needs a finite series of pulses, but maybe it is possible to use the Continuous Sampling Mode and just stop it at some point. Or to use a loop for sending a series of single pulses. The number of does not need to be controlled precisely, but should be approximately 3-5. I'm not quite sure how to do that.
Hardwaretiming would be prefered, but a few microseconds won't matter. The valve needs a propper square, but for the camera trigger the pulseshape doesn't matter, it just needs to be above a certatin level.