Delta X in spreadsheet in terms of seconds instead of samples

[PJS]

great...  Now that you are monitoring your AO on a seperate channel, this makes the next part easier.  Take your AO VIs and move them outside of the 'monitor' while loop and create a while loop around them.  You should put some kind of  delay or pause inside, even if you wire it with 0mS, just to make sure there is an interrupt for your CPU to switch loops... Although it may be frowned on by other uses, you can use a local variable to make sure your 'stop', ends both loops. 
I am not sure if you are a student doing this for a school project or someone learning labVIEW.  But you seem to be pretty intuitive at figuring this stuff out, so i will omit the picture for now.  This approach has some other minor issues concerning timing and sync of the start.  But one, it may not matter once your analyzing the results.  Two, if it does... you can look at occurances.  Three, if you truly want to switch your AO every 0.1 sec but not before, you will need to put some logic in your AO while loop to insure that this is happening.  If you get stuck, I and/or others here will be glad to help.
Oh, and your welcome 🙂

[JennaU]

Thanks Paul,

This strategy seems like it could work... but right now with two loops stopping at the same time it still yields a slow update for the AO.  I'm considering a buffer for the AO that could write all of the changes at once when the program is stopped (to save CPU).  But I'm not very familiar with that.

You mentionned something about occurances?

Jenna

[PJS]

Occurances are used to synchronize the start of multiple events.  Not sure that they will solve your problem.  As for a slow AO update, your second loop is outside the 'main' loop?  I assume, by slow, you mean that it is still updating only once per second?

[JennaU]

Yeah I mean only one second of updating.  And yes the AO second loop is outside of the main loop.  It is connected (by tunnel) to the local variable which stops both loops at the same time.

Puzzling...

Oh and yes I am a student working with LabView so your posts have really helped me!

Jenna

[PJS]

They should not be connected.  You should have a local in the AO loop.  See this thread on that topic.
http://forums.ni.com/ni/board/message?board.id=170&message.id=253938#M253938
I think that is why you are having that problem... without looking at your current code.

[JennaU]

So I fixed that part, but it doesn't seem to change anything in the output.  It must have something to do with the large amount of processing that the changing AOut needs.  Without the input channels the output updates every 0.01 s.  Would you know, from what my VI looks like now, how to implement some way of storing the information for the AOut while the program is running and writing it to a file at the end?

Jenna  

[PJS]

Glancing at your code again.  On the surface (and the fact I can not execute it) it looks ok.  A couple of things.  you do not need the express vi for DC, you can wire your slide control directly to the 'to eng' vi.  also, try removing the the while loop embedded in the AO while loop.  And I do not think you need the 'stop BG' either or 'err msg'.  You will know that you are outputting based on your monitoring of the ao channel with the AI while loop.  Replace the AOBG vi with the A out vi in the das16 palette.  And I think you will be OK.  I will not be in the rest of the day... But good luck... I think that will get it for you.  I think the background operations are what is causing your issues on the AO... as the card (or driver) are queuing the operations. 

[JennaU]

Wow that completely fixed it... you're right!  It was the combination of all that you suggested.  I needed to change the AOut and simulated signals.  I even tried to see if two loops were necessary and they most definitely are.

I really appreciate all of your help Paul.  I'm sure this will be satisfying for you to hear as well!

Jenna 

[PJS]

glad to help, thanks for the feedback... Best of luck with school