LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

AO output and control in Labview 7

Solved!
Go to solution

hi all,

  Sorry to bother if you are NOT working in labview 7. I am working with a code written in labview  7 to control analogy output. The code looks like as follows

 

[AO CONFIG] -> [AO WRITE] (write a waveform in array) -> wait 2ms-8ms -> [AO CONTROL] (pause) -> wait 180ms -> [AO CONTROL](resume)

 

I am wondering upon the complete of AO WRITE, will the waveform sent to the buffer or to the real terminal? and if AO CONTROL (pause) pause the data transmission to the buffer or pause it sending to the terminal? As my understanding, from AO CONFIG to AO CONTROL, they are controlling the data transmission to the buffer only, and we need to use AO START to notify the buffer actually sending out the data to the terminal, is that correct? But what's really bording me is throughout the whole code, there is not AO START, so I don't know when the data will actually be sent out to the terminal.

0 Kudos
Message 1 of 10
(2,975 Views)
Solution
Accepted by topic author dragondriver

Hi dragondriver,

 

Not only you use LabVIEW 7, but you also appear to be using the Traditional DAQ drivers (T-DAQ). I’m not really familiar with T-DAQ, so I don’t know what AO CONTROL does. If you look on the Help file for NI-DAQ, it should help you with the description. However, I can help you with what goes on with the DAQmx drivers.

 

ao.JPG

 

Now, what happens in DAQmx on a regular continuous generation is: When you call the DAQmx Write,  you are writing the waveform you built in software to the ADE memory (LabVIEW buffer). When you call DAQmx Start, you transfer the data from the ADE memory to the PC buffer. Then, the PC buffer will transfer the waveform to the DAQ card’s FIFO.

 

After that, a couple of things can happen: If you have regeneration activated, the FIFO keeps the samples it was transferred and just re-runs them. If regeneration is not activated, then the PC buffer is continuously sending information to the DAQ card’s FIFO.

 

If you want to learn more about this, here are some useful links:

 

Analog Output Regeneration in NI-DAQmx

 

Analog Output Regeneration Modes

 

Configuring the Data Transfer Request Condition Property in NI-DAQmx

 

As a note: I highly recommend you migrate to DAQmx because there are very few people (if any) that know T-DAQ as well as DAQmx.

Regards,
Daniel REDS
RF Systems Engineer

Help us grow.
If a post solves your question, mark it as The Solution.
If a post helps, give Kudos to it.
0 Kudos
Message 2 of 10
(2,940 Views)

@REDS wrote:

 

As a note: I highly recommend you migrate to DAQmx because there are very few people (if any) that know T-DAQ as well as DAQmx.


While you are at it Migrate to a version of LabVIEW that still has device driver support.  7.0 was dropped from officially supported years ago.


"Should be" isn't "Is" -Jay
0 Kudos
Message 3 of 10
(2,934 Views)

Good point. According to the readme file, DAQmx 7.0 should still work with LabVIEW 7. I agree with Jeff you should upgrade your LabVIEW version, as we have done lots of improvements in the past years. However, upgrading the drivers won't cost you any money, just time (well spent).

Regards,
Daniel REDS
RF Systems Engineer

Help us grow.
If a post solves your question, mark it as The Solution.
If a post helps, give Kudos to it.
0 Kudos
Message 4 of 10
(2,932 Views)

@REDS wrote:

Hi dragondriver,

 

Not only you use LabVIEW 7, but you also appear to be using the Traditional DAQ drivers (T-DAQ). I’m not really familiar with T-DAQ, so I don’t know what AO CONTROL does. If you look on the Help file for NI-DAQ, it should help you with the description. However, I can help you with what goes on with the DAQmx drivers.

 

ao.JPG

 

Now, what happens in DAQmx on a regular continuous generation is: When you call the DAQmx Write,  you are writing the waveform you built in software to the ADE memory (LabVIEW buffer). When you call DAQmx Start, you transfer the data from the ADE memory to the PC buffer. Then, the PC buffer will transfer the waveform to the DAQ card’s FIFO.

 

After that, a couple of things can happen: If you have regeneration activated, the FIFO keeps the samples it was transferred and just re-runs them. If regeneration is not activated, then the PC buffer is continuously sending information to the DAQ card’s FIFO.

 

If you want to learn more about this, here are some useful links:

 

Analog Output Regeneration in NI-DAQmx

 

Analog Output Regeneration Modes

 

Configuring the Data Transfer Request Condition Property in NI-DAQmx

 

As a note: I highly recommend you migrate to DAQmx because there are very few people (if any) that know T-DAQ as well as DAQmx.


Thanks. I learn something today 🙂

0 Kudos
Message 5 of 10
(2,921 Views)

Hi RED and Jeff,

  I read your comments and the related materials on the DAQmx and I am going to migrate one of my code to the new driver for testing. Before that, I want to double check two things:

 

1) I saw DAQmx driver in the installation disk of labview 7.1, does it mean LV71 already support DAQmx directly? So what I have to do is to replace and relink my old analogy/digital input/output modules, right?

 

2) The system working in my lab is so big and I can only migrate a very small part at a time. For testing, I would like to modify the simplest module first. But after modifying some code, all other code (not dependet on the one I modified) won't be affected, right?

0 Kudos
Message 6 of 10
(2,901 Views)
DAQmx was released with LabVIEW 7.0 so whoever did the original program should have used it. There are considerable differences between the old driver and DAQmx so it's not a simple direct replacement.

Since you can only use one driver at a time, you cannot run a DAQmx program at the same time as a traditional DAQ program. I'm not sure, but you may have to do a reset before switching between two.
0 Kudos
Message 7 of 10
(2,895 Views)

@Dennis_Knutson wrote:
DAQmx was released with LabVIEW 7.0 so whoever did the original program should have used it. There are considerable differences between the old driver and DAQmx so it's not a simple direct replacement.

Since you can only use one driver at a time, you cannot run a DAQmx program at the same time as a traditional DAQ program. I'm not sure, but you may have to do a reset before switching between two.

Thanks for your reply. The problem in our case is the code were written in the even older labview and laster transferred to the LV7.1, you know some engineer doesn't really care about coding, they only care if it is STILL working or not. So all the old code and drivers are being used again and again.

 

What do you really mean by only one driver can be used at a time? Do you mean I can only use either the traditional one or DAQmx in one code but not mixing them? Also, what do you mean by reset? I saw in labview 7, there are traditioanl DAQ and DAQmx found in the panel and I can create code with either one. So what happen if I run the traditional one to control some ports and after I run the new one to control the same ports (I mean I run either one at a time), will it conflict?

0 Kudos
Message 8 of 10
(2,889 Views)
What I mean by using only one driver at a time is exactly that. You can't use traditional DAQ and DAQmx simultaneously. And I think you have to do a reset after using one before you can use the other. The reset can be done in MAX.
0 Kudos
Message 9 of 10
(2,884 Views)

I don't just think.  I know a device reset is required after a traditional DAQ call before DAQmx will do anything but throw an error


"Should be" isn't "Is" -Jay
0 Kudos
Message 10 of 10
(2,862 Views)