Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

synchronized digital output and delay triggered analog input

robo1,


Can you post your latest code?  I'll see if I can spot the problem.

 

Thanks,

Dustin D

0 Kudos
Message 11 of 15
(1,128 Views)

Hi Dustin,

I was able to fix the errors I was having with the delay and samples by rewiring some elements and inserting a "Configure Input Buffer" VI. The code now runs as desired, but it returns all null's when obtaining data on the analog input channel. I tried running my original program about which I first posted, which previously obtained analog voltage data correctly, but it too returned a set of nulls. This suggests to me that there is a problem with the hardware, rather than the program I wrote.

I have attached my latest code and also a text file with the set of null characters I collect (to explain better what I mean). If you know what the issue is and how to solve it, that would be great.

Thanks for the help.

Download All
0 Kudos
Message 12 of 15
(1,116 Views)

Hi robo1,

 

This is the first thing I've noticed about your code that could be causing unexpected behavoir.  It's certainly worth talking about.

 

 

SS-2010-04-15_10.28.03.png

 

 

This specific piece of code drew my attention.  Through the laws of data flow VI's or property nodes can only run when data is avaiable at all of their required terminals.  So you would expect your data flow to go in numerical order.  The problem is that you have the CO.CtrTimebaseRate indicator downstream from the variable.  The CO.CtrTimebaseRate indicator does not have the correct value in it until after the variable pointing to it has already been read.  This is one of the dangers with local variables their use should not be taken lightly since dataflow laws do not apply.  The other danger is even if your variables are used downstream from the indicators or controls they are referenced to you can still have race conditions, again because dataflow laws do not apply.

 

I would also reccomend taking a look at the picture that myself or SethB posted on starting your tasks with a sequence structure.  It would greatly simplify your code.  Keep us updated on your progress!

 

Regards,

Dustin D

Message 13 of 15
(1,102 Views)

Hi Dustin,

My code works fine now. The problem I was having with my data acquisition was, ironically, a Notepad error rather than a LabView one.

Regarding the sequence structure for starting, that actually led to a timeout error on obtaining the data, whereas the program works fine without it. I'm not exactly sure why this is, but I thought you might like to know that.

Also, regarding the sequence you pointed out, where I read from a local variable before writing to it, on the first execution, the value in that CO.CtrTimebase is 0, so the counter uses a delay of zero. Subsequently, CO.CtrTimebase is updated to 80 MHz, and the counter executes with the desired delay. It seems that the local variable simply uses the previous value stored in it, so this did not cause any execution problems. 

Thanks for all the help. It was very useful in getting my program to run.

0 Kudos
Message 14 of 15
(1,075 Views)

robo1,

 

I would be cautious using the local variables like that. It may have more serious implications down the road.  I am glad, however, that everything is working. Good luck in the future!

 

Regards,

Dustin D

0 Kudos
Message 15 of 15
(1,060 Views)