Asynchronous AI/AO ... totally frustrated!

[Rudolf Potucek]

After spending two weeks on something that should (in
theory) work but doesn't, I am just about ready to take
all the NI stuff I have and make a bonfire ...

Before I do so, does anyone have a WORKING example
of a VI that will do *concurrent* analog input and output
with different unsynchronized output clocks and that will
run for more than about 50s (which is the best I have
managed so far)? I would be VERY interested to see HOW it
can be done ... and I don't mean just supportive
comments from people who have, just like me, gobbled up
all that positive hype from NI but never actually managed!

After all the testing I have done, I am now certain that

(a) The error happens when the Read and Write events
happen at
the same time
(b) It is not my VI calling the Read/Write at the
wrong time, that is causing the problem (used
semaphores to make sure that this cannot happen)
(c) It is not the amount of buffer space that is available
to the input and output buffers, there is enough
for about 10s, which should be plenty.

If anyone wants to have a look, the VI is available as
tar file (yes, WinZip will read that) at

http://antimony3.chem.ucalgary.ca/~potucek/cv-2/cv2.tar

or as individual files

http://antimony3.chem.ucalgary.ca/~potucek/cv-2/


I admit that there is quite a bit of work still needed, but
what's the point of beautfying something that doesn't even
work in principle ...

Rudolf

[Ben]

Hi Rudolf,

I have down loaded and quickly looked at your code.
I have one suggestion at this time (I have limited time avail to answer these questions because I have to do the same for my paying customers).

First, what is the error that you are recieving?

Not being sure what that answer is, I would like to suggest a slight modification in you AI read VI.

When you want to read data from the input buffer, First do a an AI read and pass a value of zero in the input for how many scans to read. Then, take the backlog output of that VI and wire it into a second AI Read. This will ensure you never have to wait because you will only be requesting what is waiting.


I will watch for further questions,

Ben

[Rudolf Potucek]

Ben wrote:
: First, what is the error that you are recieving?

As far as I remember it was 10027 and 10843.

: When you want to read data from the input buffer, First do a an AI
: read and pass a value of zero in the input for how many scans to read.
: Then, take the backlog output of that VI and wire it into a second AI
: Read. This will ensure you never have to wait because you will only be
: requesting what is waiting.

I tried that with just about the same results. The approch I am taking
now is that I set up a large enough buffer and keep the backlog value for
the FOLLOWING read, trying to lag behind the read pointer a little.

As I said, I get the impression that the issue does not arise in the AO
and AI calls clashing but rat
her in the cards AO and AI memory access
causing the problem.

Thanks for your time,

Rudolf

[markwysong]

Rudolf,

I see several things that are most likely causing problems for you. First, you MUST use DAQ occurrences to accomplish this task. While you are using the DAQ occurrence VI to create an occurrence, nowhere in your code are you waiting for that occurrence to happen. Therefore, you're tying up your DAQ thread by waiting for data to be ready in the buffer, which won't allow any other DAQ VIs to run (like your AO update) until the AI Read is finished.

Therefore, I propose that you use code which is similar to the code I'm including. This is a continuous analog input using DAQ occurrences, coupled with an buffered analog output. Your AO code looks good, although you don't need the DAQ occurrence VI for your AO, because the buffer is always
defined--you're not waiting for it. Also, I don't think you need semaphores at all.

Check it out.

Mark

[Labviewguru]

Rudolf,

I'm not exactly sure what you are trying to do here, but I have a theory, and one that I think should be verified by National Instruments:

I believe you want to do asynchronous AI and AO. I don't believe this is truly possible with a single DAQ device. DAQ Devices use a single internal clock, as far as I know (I don't know all models.) Therefore, true asynchronous behavior is not possible. I believe that the way to accomplish what you are trying to do is to use two different boards.

I could very well be wrong on this, but I believe you should have NI verify whether or not this can be done. If you go to http://ni.com/ask and select email or call NI engineers, they will help you out. It doesn't look like this is a common issue, and should
probably be handled by NI. They have been extremely helpful in solving a few issues I have had recently.

I would transfer the matter to the capable hands of the NI engineers before you go out and buy a second board. They may be able to help you.

I have in the past done simultaneous IO, but it was all synchronous, or pseudo-asynchronous at best.

I know its not much, but I hope it helps.

Good luck


Michael Du'Lyea
Advanced Test Engineering

[Rudolf Potucek]

I got it working, I think. I will not shout too loud until I am
certain that this works for really different I/O clocks, but it
seems to have been the concurrent calls to AIRaed/AOWrite after
all, despite the semaphores.

I believe what is happening is that the Read/Write functions return
too early, giving a waiting function the chance to poll the card
when the card is not ready. I have it set up now, so that I
just check the semaphore and if its busy, instead of waiting for
it to be freed I just wait for the next data occurrence (in
effect a collision checking algo) so far has been running stable
for more than an hour at 1kS out/2kS in on a P133 with an E6035 ...

Thanks for the support everyone!

Rudolf

Labviewguru wrote:
: Rudolf,

: I'm not exactly sure what you are trying to do here, but I have a
: theory, and one that I think should be verified by National
: Instruments:

: I believe you want to do asynchronous AI and AO. I don't believe this
: is truly possible with a single DAQ device. DAQ Devices use a single
: internal clock, as far as I know (I don't know all models.)
: Therefore, true asynchronous behavior is not possible. I believe that
: the way to accomplish what you are trying to do is to use two
: different boards.

: I could very well be wrong on this, but I believe you should have NI
: verify whether or not this can be done. If you go to
: http://ni.com/ask and select email or call NI engineers, they will
: help you out. It doesn't look like this is a common issue, and should
: probably be handled by NI. They have been extremely helpful in
: solving a few issues I have had recently.

: I would transfer the matter to the capable hands of the NI engineers
: before you go out and buy a second board. They may be able to help
: you.

: I have in the past done simultaneous IO, but it was all synchronous,
: or pseudo-asynchronous at best.

: I know its not much, but I hope it helps.

: Good luck


: Michael Du'Lyea
: Advanced Test Engineering

[markwysong]

I can only speak for the E-series devices, for this is all the MIO boards I have used, but their block diagram clearly shows two separate timing blocks for analog input and analog output.

I have had a buffered input and a buffered output at different rates before, so on E-series MIO DAQ boards, this is possible.

Mark

[Ben]

Wonderful news Rudolf,

Ben

[Kelly6]

Hi,

I have the same issue with PCI 6221 borad, LabVIEW7.1 and DAQ7.3.

I want to generate a signal(sounds) for stimulus to the project(animal), then acquire response data from  the animal. It is simultaneously AI/AO procedure. This is called Auditory Evoked Potential System. Actually we had a old AEP system using NB-A2100 which is a simultaneously-sampled card with Sim IO.vi included in DAQ.

i am not sure it is possible I could do the same thing on my new PCI 6221? This board was chosed via recommendation by NI.

Appraciate any helps

kelly

[Poormanphysics]

Hello I think I would like to share almost the same sentiments! Now how do we do that with DAQMx which is poorly rated for multithread? For example the code I attached should be doing two separate P-controller for two separate servos now I am in trouble? Any ideas?

Regards,

Berns B.