Timing inconsistency in producing a voltage/digital output

[deskpilot]

I have a program that I have broken down to a bare bones example in the following screenshot. I am monitoring an approximately 5ks/S analog input from an 1102C in an SCXI to decide when to output from a 6713 card in a PXI chassis. I have used analog and digital ouputs from the 6713 and see similar results. I do not want to use the built in trigger functions on the cards, I can explain further if you like. My main goal is to output 5 volts based on a logical decision from the analog input signal. I also have access to an 1161 card, but have not tried it.

This is currently taking about 100 - 300 milliseconds, 100 - 200 would be acceptable, although 100 ms where I would really like it. The real problem is the inconsistency. I would like the output to occur reliably within 50 ms. Is this possible running Windows with DaqMx? Is there at least a way I can improve the consistency. The example below is just the most basic representation of what I'm doing. Thank you.

[Dennis_Knutson]

If you are going to post just a picture, just post the picture and not embed it in a word doc.

There is a lot missing from your 'basic representation' that is important to know and makes it difficult to make any kind of recomendation. How are you handling the start and stop task? Is that inside or outside the loop. If it's inside, move it out. You should not be starting and stopping a task with each loop iteration. From what you have shown, there is also no reason to use two separate loops. Running a while loop without a Wait (ms) can also cause problems.

Message Edited by Dennis Knutson on 06-27-2008 02:14 PM

[deskpilot]

The ai task, and the output channel are started and stopped outside of the loop.  I should have shown that I do have a 100 ms wait in all of my loops. Other than this being left out, the loops shown are completely representative of what I'm having trouble with, minus the wires. I tried using one loop, but the inconsistency did not appear to improve. 

Is there some reason not to use two loops?  I prefer using multiple loops over one, mainly for organization, but also because there are some queues involved that I do not want to wait on in my real, larger program (which has 6 - 8 parrallel loops). None of that appears to be at the root of my problem, though, because when I break it down to this fundamental level, I still have the timing inconsistency.

I played around a little with timed loops, although I am not that familiar with them, but I seemed to still be getting the same result. Can anybody offer any help? 

I will post a better picture if necessary, I thought the cut and paste into word would be sufficient to demonstrate my intentions. I can bring my basic program from another building and upload it, but the basic idea is what I have shown.

[deskpilot]

Here is a an example of the test vi I have been playing with. There is also a screenshot of the section of the program that I have broken down. Sorry, I don't know how to post the screenshot without putting into a word document.

Message Edited by deskpilot on 06-30-2008 07:25 AM

[Dennis_Knutson]

I still don't see an explicit Start Task for either your analog or digital task. A Create Task is not the same thing at all. The DAQmx digital write is set for auto start but I don't know if that means that it auto stops as well. With your analog read, you are also not specifying how many samples to read.

You might also want to try it with a Wait (ms) instead of the Wait Unitl Next ms Multiple.

Message Edited by Dennis Knutson on 06-30-2008 08:22 PM

[deskpilot]

Just wanted to say thank you, your suggestions improved my code. I did not realize by allowing autostart it had to open and close the task each iteration. I had allowed this error to propogate through more than one of my codes, and so went back and fixed them all.

As for the timing, in the simple test vi with the wait until changed to wait and set to 10 ms, the timing is great. Unfortunately it takes up about 60% of the processor. If I back it up to 50 ms, the timing is acceptable and the processor is down to about 10%. It looks like this is the best compromise, although I have not gotten it to work in the main vi to know for sure. It is definetely headed in the right direction. Thank you.