Unexplained delay in code

[PantsOnBackwards]

NI Gurus,

I'm experiencing unacceptable delays in my code and I really cannot figure out the reason.  As had been suggested, I switched everything over to a producer-consumer architecture, but I'm not sure I have it correct.  I would like to get my cycle time under 10ms, but it is typically running at 12-14 ms and then every ten or eleven loops there is a cycle time of around 40 ms.  Here are a few of my concerns:

1.)  DAQmx sampling rate - could this be a problem?  I don't specifically set a sampling rate, but it is in a timed loop whose rate I do set.  Also, I have tried to set up a proper DAQmx sampling rate, but when I follow a Labview example, it gives me an error.  Any suggestions on this?

2.)  Storing data for writing to a file - I don't want to write to a file until my program finishes.  I can't tell if I am accomplishing this or not.

3.)  Finally, I'm using RS-232 communication from a Windows based system.  I have set Labview on high priority for Windows and turned off file indexing and anti-virus.  I have put a flat-sequence around my RS-232 communication to my motor and I get a consistent 8-9 ms.  Also, this consumer loop I believe I have properly set to run off processor 2, so it shouldn't interfere with the delay faced in my DAQ producer loop.

Any suggestions are greatly appreciated!

Thank you,

Jason

[LV_Pro]

I am presuming that you are running on a non-RT system. Unfortunately, unless it is an RT system you will have no determinism, with random Windows interrupts/processes causing variable delays. I'm not able to download your code at this location, so I can't comment on it, but as far as the not writing to a file until the end, if the rest of the process is in a loop, putting the file write after the loop will make it execute after the data acquistion part, IF you have data flow dependencies, usually by wiring the error in/out chain.

It is also helpful, when attaching code, to mention what version it is in. Particularly now as LabVIEW 2010 was just released and undoubtedly we will start to have people posting in that version.

[nathand]

If you clean up that code and include all the subVIs it will be easier to provide helpful advice.  You have wires running all over the place, the VI takes up well more than a full screen (even on a large monitor), and it's very difficult to make any attempt to understand what your VI should be doing.

Can you disable the loops that aren't so critical and try to narrow down the source of your delay to a specific loop?

You should be able to use the DAQ hardware to maintain your sampling rate.  Which example are you following, and more importantly, what error are you seeing?

[PantsOnBackwards]

Nathand,

Is there a better way to introduce notifiers and queues from one section of code to another?  This was my first experience using them and I'd definitely like to clean up all the wires.  I have attached the relevant .vi's.  The other .vi's don't normally get called by the program.

-Jason

[nathand]

You've included only about half the missing VIs.

I generally wire queue references directly unless there's a specific reason to use a named queue.  It makes it clearer which loops use the queue, and ensures that the datatype is consistent.

By cleanup I'm suggesting that you avoid wires with excessive bends and wires that run behind other block diagram objects.  You might want to make some loops, or the loop contents, into subVIs to shrink the diagram to the point where it's manageable.