PCI 6534 : how to generate variable finite-length waveforms; possible solution

[qpido]

As briefly discussed in a previous post, I need to generate a variable, fixed length waveform using a PCI 6534.

Solutions suggested at http://forums.ni.com/ni/board/message?board.id=250&message.id=54042&query.id=1113206#M54042

and http://forums.ni.com/ni/board/message?board.id=250&message.id=38960&requireLogin=False did not work for me.

The following solution seems to do generate a variable, fixed length waveform but it's rather unorthodox (see diagram below). I shall explain:

- what makes it work is the use of the "DAQmx Control Task" vi.

- the "DAQmx Control Task" vi raises error -200479 "Measurements: Specified operation cannot be performed while the task is running."

- ignoring such error (hence error terminal is not connected) makes the program work.

Can any of the DAQmx gurus explain this?

Is there another, cleaner, method  to achieve what I need? There must be a way to generate a variable fixed-length waveform with the 6534!

Many thanks.

[Aaron_W.]

qpido,

Thanks for posting on the NI Forums. Sorry for the delay in response, but I have a couple of observations regarding your code. 

1) What was the purpose of the  DAQmx Control Task VI in the code where you reserve the task. I believe you should just be able to stop the task and then re-configure the task on the next iteration of the while loop. Where you getting some specific problem when you were not using the DAQmx Control Task VI? 

2) I am guessing you are getting the -200479 error because you call the DAQmx Control Task while you still have the task running, if you were to call the DAQmx Stop Task before you called the DAQmx Control Task I am guessing you will not see the error. 

3) If you are specifying the number of sample you want to want to generation in your finite generation you should not need to set the Regeration Mode to "Do not allow regeneration". Looking at your code, it appears that you are getting the size of the waveform that you are creating and then generate that waveform completely and then the task would stop. For instance if your waveform is 1000 samples and you set your finite generation session to generate 1000 samples, you will not see regeneration.

In general are you going to know all the waveforms you want to generate at the beginning of runtime? 

[qpido]

Hi Aaron,

thanks for taking the time to reply.

---

Aaron W. wrote:

qpido,

Thanks for posting on the NI Forums. Sorry for the delay in response, but I have a couple of observations regarding your code. 

1) What was the purpose of the  DAQmx Control Task VI in the code where you reserve the task. I believe you should just be able to stop the task and then re-configure the task on the next iteration of the while loop. Where you getting some specific problem when you were not using the DAQmx Control Task VI? 

2) I am guessing you are getting the -200479 error because you call the DAQmx Control Task while you still have the task running, if you were to call the DAQmx Stop Task before you called the DAQmx Control Task I am guessing you will not see the error. 

3) If you are specifying the number of sample you want to want to generation in your finite generation you should not need to set the Regeration Mode to "Do not allow regeneration". Looking at your code, it appears that you are getting the size of the waveform that you are creating and then generate that waveform completely and then the task would stop. For instance if your waveform is 1000 samples and you set your finite generation session to generate 1000 samples, you will not see regeneration.

In general are you going to know all the waveforms you want to generate at the beginning of runtime? 

---

My answers:

1) Using the  DAQmx Control Task VI *in that particular location* is the only way I have found that allows generating variable content. Any ther solution, included the one you suggested, will cause the vi to raise error 200288 "Attempted to write a sample beyond the final sample generated. The generation has stopped, therefore the sample specified by the combination of position and offset will never be available.
Specify a position and offset which selects a sample up to, but not beyond, the final sample generated. The final sample generated can be determined by querying the total samples generated after a generation has stopped."

It is as if DAQmx does not like having the buffer content changed without deleting and the re-initialising the whole task (which is far too slow)

I have also tried to move the buffer cursor back to the beginning of the buffer at each iteration; that too causes an error.

2) True, but then the trick would not work. The  DAQmx Control Task VI must be *in that particular location*.

3) I agree. The "Do not allow regeneration" is not necessary but it does not alter the behaviour of the vi, with or without the DAQmx Control Task V.

4) Yes, I know the length of all the wayforms I want to generate.

I know that the solution of using DAQmx Control Task VI should not work on paper but it does and, more strangely, it's the only solution that allows me change the content of the buffer at each iteration.

What is the official way of generation a variable finite length waveform? Or perhaps such possibility was not allowed by the DAQmx designer?

Thanks.

[Aaron_W.]

qpido,

I was able to get my hands on a 6534 and I tried some very similar code. 

This code gives me no errors at all, and I am able to specify the size of the waveform as I am writing data in the loop. You might try some similar code. I just started with the Write Dig Chan-Int Clk-Dig Start.VI and took out the Digital Start Trigger, and placed a while loop around the shown VIs, and made sure to put a Stop Task in before the end of the while loop. I would suggest trying something similar and seeing if it works for your applications. Thanks!

[Aaron_W.]

qpido,

Could you also clarify for me exactly what you want from the generation? If you can have these waveforms configured at the start of the generation would it be possible to load all these waveforms onto the memory and then generate them? How many waveforms do you need to generate, for how long? How big are the waveforms that you need to generate? 

[qpido]

Thanks Aaron,

I have modified my test VI as shown below, so that it's functionally identical to yours.

When I run it I get (as I got in all of my previous tests): Error -200288 "Measurements: Attempted to write a sample beyond the final sample generated. The generation has stopped, therefore the sample specified by the combination of position and offset will never be available.

Specify a position and offset which selects a sample up to, but not beyond, the final sample generated. The final sample generated can be determined by querying the total samples generated after a generation has stopped."

Something is afoot here. Which version of DAQmx are you using? mine is 8.5.0f5.

Could you post you VI (in LabView 8.2 format please) so that I can try it?

Many thanks.

 

[qpido]

---

Aaron W. wrote:

qpido,

Could you also clarify for me exactly what you want from the generation? If you can have these waveforms configured at the start of the generation would it be possible to load all these waveforms onto the memory and then generate them? How many waveforms do you need to generate, for how long? How big are the waveforms that you need to generate? 

---

Aaron,

My application is somewhat more comlex that the test VI I posted. I'm generating SPI waveforms to communicate with an ADC chip.

I have to make use of the PCI6534 trigger line to start the SPI waveform generation when the ADC's "data ready" line goes low. This means I can only generate 1 waveform at a time when the trigger event occurs. Different SPI waveforms correspond to different commands sent to the ADC (e.g set PGA, set MUx, etc.).

The tests are long in duration (hours/days).

(I know this is a suboptimal way of dealing with SPI devices but currently the 6534 is the only hardware I have that can deal with the problem. Once I have proven the concept I hope to move onto a CompactRIO!)

Regards.

[Aaron_W.]

qpido,

I have attached the VI saved for LabVIEW 8.2 that I was using. When I was running the tests I was running on one of our test machines that was using DAQmx 8.9.5. I have included a link for that driver below. I would try the existing code with your current driver and if you are still getting errors in it, you might try upgrading your driver to 8.9.5 or later (9.0.2 is our newest version and supports LabVIEW 8.2). 

Your doing SPI communication, that makes sense with what you are trying to do. This won't completely solve your problem but we do have some documentation on the SPI protocol and even created a Reference Library that might provide you some functionality that could help in your development. 

SPI DIgital Waveform Reference Library:

https://forums.ni.com/t5/Example-Code/SPI-Generation-and-Acquisition-using-HSDIO-Hardware-654x/ta-p/...

Let me know how the testing goes. Thanks!

DAQmx 8.9.5:

http://joule.ni.com/nidu/cds/view/p/id/1384/lang/en 

Message Edited by Aaron W. on 02-25-2010 08:36 AM

[qpido]

Thanks Aaron.

I have run your VI and it fails with error200288 "Measurements: Attempted to write a sample beyond the final sample generated. The generation has stopped, therefore the sample specified by the combination of position and offset will never be available. " as in my previous tests.

I'm really puzzled. I'll try to upgrade the drivers but I expect that to not solve the problem. It looks like this is one of those mysteries that will remain as such.

Regarding the "SPI DIgital Waveform Reference Library": I have used it extensively. I may post some comments/improvements on the relevant thread when I have the opportunity.

Regards. 

[Aaron_W.]

qpido,

I ran the example as I sent it to you, by chance did you change the clocking rate or  'Samples per Channel'? I would suggest upgrading your driver and see if that helps the situation at all. 

As far as suggestions for the SPI Digital Reference Library, I would suggest you to post to the thread as the developers monitor that thread and are always happy to hear feedback on the library.