labview error 200963 at daqmx write (analog 2D DBL Nchan nsamp)

[Arcus]

Hi all,

I have this problem with error 200963 appearing after the DAQmx Write (Analog 2D DBL NChan NSamp).vi. My vi  generates a voltage through PCI-6722 and measures voltage from PCI-6220. This a program made by somebody from long ago and I haven't changed anything yet except upgrade labview to 2015 from 2012. there are a few bugs appearing that seemed to come from version7.1 bugs but for now this error 200963 is keeping me busy. Please see attached picture. thanks! live long and prosper!

[GerdW]

Hi Arcus,

did you read the explanation for that error number? It's quite explicite pin-pointing the error source!

- Is there anything running in parallel using the very same DAQ device?

- Did the device naming in MAX change when you installed LV2015 with new DAQmx drivers and MAX? (Your VI uses the "Dev1" as start trigger, but PCI6722 is Dev2 apparently.)

[Arcus]

Hi GerdW,

Thank you for sharing your thought. The program prepares the measurement setup first (AI) then sets the control (AO) then the output (AO)  does it job first then the input (AI) - acquire. What I am trying to say is that the Dev 2 start trigger is dependent on the prior stage which Dev1 sample clock to get the control-acquire process. I am getting error 89136 when I change the start trigger to Dev2/ai/sampleclock which means no routing available. Let me know if I am making sense. cheers!

[aflojo]

Arcus,

I have looked at your screen shot. You aren’t going to be able to use Dev1’s Sample clock for your start trigger unless you export that signal and give Dev2 access to it. I looked at the routing table for your PCI-6722 in MAX and it looks like it has a direct route to your PFI lines and your RTSI0-6 lines. It also has indirect routes to your 20MHzTimebase, your MasterTimebase, your 100 kHzTimebase, Your Ctr1InternalOutput, and your ctr0. So using any of these should work for setting your trigger depending on what you want to want to do. If there is a reason you want to use Dev 1s sample clock and don’t know how to export that signal let me know and I can explain how you would do that in more detail.

[Arcus]

Hi Aflojo,

I seemed to have fixed the problem following GerdW's instruction to check other vis using the same DAQ device. I removed the "DAQmx is task done.vi" prior to DAQmx write or read vi. also the "DAQmx stop.vi" and "DAQmx control task.vi" from those subvis.not sure why but it worked. So the vi screenshot that i posted seemed to get affected by this but did not cause the error.

However, with GerdW and your comments about the start trigger, I am puzzled this vi worked. This is from an old program that may have been taken from one of the examples and tweaked to work for our need. My next question would be, how do we export the signal from Dev1's sample clock to dev 2 so it has access? I can't find something like that in the program. the program actually controls the voltage to a raster scanner and a sensor detects this ions from the other side. Timing is important for this code (control and acquire) but it seems the program, having this issue doesn't seem to care and it worked. I'de want to correct it and want to do what you said, but I want t understand it. I am still new to labview and the timing setups. I would appreciate your help. cheers!

[aflojo]

The way you would use the Dev1's sample clock for Dev2's trigger is by exporting Dev1's sample clock to one of the devices PFI lines using "DAQmx Export Signal.vi". You wound then need to wire the PFI line on Dev 1 to a PFI line on Dev2. Then, set this PFI line on Dev 2 to be the start trigger. Hope this helps!

[Arcus]

Hi Aflojo,

I was trying to do what you've told and I want to clarify how to connect the PF1 of Dev1 to PF1 of Dev2? It seems to make sense to me now and I did a little reading and I found this link: https://www.ni.com/en/support/documentation/supplemental/06/timing-and-synchronization-features-of-n... 

item 9 seems to talk about implicit connection when the RTSI cable is already connected and setup at MAX? Just wondering if this is the reason why the program still works even without exporting the signal trigger? Let me know. Cheers!

[aflojo · Accepted solution]

Hi Arcus,

Yes that is correct. I didn't realize you already had the two cards connected. If this is the case, as talked about in point 9, you wouldnt need to export the signal.