Route trigger from PXI-6602 to PXI-6534 AND PXI-4070?

[Tom_from_the_Lab]

I am trying to use a counter on my 6602 to start a second counter, a buffered digital input on the 6534, and a waveform capture on the 4070. I have no problem with the first two but the 4070 will not trigger at all. If I set the trigger to immediate it runs so I think my configuration is OK. I have tried routing with both the routing VI and the Channel Property Node and I can get the DMM to trigger on its own, the problem seems to be when I include the other hardware. I found several answers to routing and counters but nothing I have been able to translate into a solution.

 

Here is what I have, PXI-1033 chassis, slot 2 - PXI-6602, slot 3 – PXI-2529, slot 4 – PXI-6534, slot 5 – PXI-4070,  LabView 8.50, Vista.

 

Thanks in advance!   

[ManLongAtNI]

Hi Tom,

What will be triggering the 4070? Do you have code that you are working on that isn't exactly working?

Regards,

Glenn

[Tom_from_the_Lab]

Hi Glenn,

Here is a screen shot of where I am now. As it stands the 4070 triggers and captures data but the digital input (slot4 Port2) returns no data. The Digital out works fine and produces the correct data but the digital in does not return any data at all. I don't get it, they are on the same card and use the same clock.  I seem to be stuck at 2 out of 3 things working at a time.  

[ManLongAtNI]

Hi Tom,

Judging from the image, I noticed you didn't have a DAQmx Read for your Digital Input. I was curious to see that you configured the channel, sample clock and start task for each iteration of the while loop. Am I right in assuming you don't use these tasks in other cases in your application?

Glenn. 

[Tom_from_the_Lab]

Hi Glenn,

You are correct, I have a state that reads the data later. I included a copy of the VI I use to read the digital in port and it does something I think is odd. The Available Samples Per Channel Property returns the correct value the first time the VI is called but every time after that it returns some number in the 3200 range. If I stop, clear, and restart the tasks it will read correctly the first time again and then return the incorrect value. The samples are there and get read, it reports the incorrect number available. Everything else works correctly as far as I can tell, the digital out that I monitor runs and produces the correct data and the master clock produces the right number of cycles at the correct frequency.

I moved all the task start VIs to the read state and start them in the order of Digital Input, Digital Output, DMM, and them the counter that produces the trigger for the master clock ("Route Test" task on the VI).  I added a state that stops and closes all the tasks and then goes back to the state that reconfigures all the tasks. This works and since I am sending 60 seconds of data the hit I take clearing and restarting all the tasks doesn't really hurt. The program runs and reads all ~ 18e6 samples correctly. The problem is I need to run this in a tighter loop in other parts of the program and I would like it to run every time I trigger it.

I know its something I am doing and its right in front of me but I don't see it.

[ManLongAtNI]

Hi Tom,

Can you calrify where this vi is placed in imaged code you provided? I'm curious to see what state is initiatiing the DAQmx Read vi.

Glenn

[Tom_from_the_Lab]

Hi Glenn,

I included copies of the 2 states that I think you need to see. One configures the hardware and the other starts the counter and reads the information. I wanted to restart the counter task that starts the retriggerable counter when I want to start collecting data. It works except after the first time I run the "Send Data" state the Available samples Per Channel property returns a fixed number and does not change. The data is there and can be read but the while loop does not work like I expect. As it is now I have to stop and close all the tasks and restart them in order to make the digital in loop work, that is why the stop task for the DMM and digital in are in this state. The other tasks are stopped and all tasks cleared in a later state.

Here is another thing that may help. Every time I try to print LabView prints 1 to 3 pages and crashes. Could it be a corrupt install?  

[ManLongAtNI]

Hi Tom,

Judging from your post, it appears that the DMM is acquiring appropriately. If that  is the case, due to the complexity of your vi I recommend creating another vi with just the counter and DIO tasks since that is where the issue is isolated. I'm curious to see the second state of the DI loop and what occurs if the Counter/Timing task is complete. First glance at the error routing implies that the task is already stopped, resulting in a fixed number of samples available. I suspect you're using that property node as a check to when you are receiving samples. If that is the case, you can wire a -1 to the timeout of the DAQmx Read so that vi waits indefinitely.

Regards,

Glenn

[Tom_from_the_Lab]

Hi Glenn,

Sorry for the delay getting back to this thread. I took the minimal code and created my VIs from scratch and they still had the same problems in 8.5, the number of samples available to read was incorrect for instance. I recreated all my code in 8.21 and everything works fine, no surprises or problems. I also found if I loaded and closed 8.5 and then tried to open a TDMS file for writing in 8.21 I would get an error from the open VI. The only solution was to reboot if I launched 8.5 before using TDMS in 8.21. I also found loading 8.5 to copy VIs into 8.21 required a reboot before the VIs would run correctly in 8.21.

Bottom line is I ported all my code to 8.21 and it runs perfectly. I read all the bug fixes between 8.5 and 8.51 and some of them are also problems I am having with 8.5. Since 8.51 is not included as a free update I will roll back to 8.21 for future development.