Error -200284 from my DAQmx Read VI

[RezaTAMU]

Hello,

I tried different suggested solutions to fix this error but none worked so far. Any great idea how can I modify this section of the code to solve this. Thank you so much in advance for kind help. 

[Bob_Schor]

Thank you for including a piece of an actual VI.  I did a Diagram Cleanup on it, straightened out some wires, and am beginning to "see the Forest for the Trees".  I notice you have an I/O constant for /Dev1/PFI10 wired into DAQmx Timing and into a DAQmx Trigger Property Node -- it appears Greyed Out going into DAQmx Timing, but not into the Property Node.  Why?  You also seem to be generating a finite number of Trigger Pulses with Dev1/Ctr1 -- why not Continuous, as you clear the task right after taking the data.

Is this "wrapped" in a While loop?  If so, put BurstCounts on a Shift Register and don't use Local Variables.

Just in case someone else needs to maintain this code, a few sentences in a Free Label discussing the Timing/Triggering Logic would be helpful.

Bob Schor

[RezaTAMU]

Hello Bob,

Thank you for kind help and information. The "Burst Count" is being read from a different vi in this vi and being used. Not sure what would be the best way to do that. I did change the "trigger" to continues instead of "finite" but not much difference. I added the entire code just in case if it does help. It is written under LabVIEW 2015. 

[Bob_Schor]

Oh, my goodness!   Another Chance to Teach ...

• Never (and I mean never) use a Stacked Frame structure.  They obscure Data Flow, are ugly, and should have been eliminated from LabVIEW decades ago!
• You almost never need to use Frames (almost the only exception is when timing code).  Use Data Flow instead (the Error Wire is your Friend).
• Just because monitors have gotten larger and multi-monitor systems are more common does not mean it is OK to have huge Front Panels and even larger Block Diagrams.  If your Block Diagram won't fit on a single laptop screen, redesign it (the simplest way to do this is to have at least 100 sub-VIs, each of which does one thing).
• Sub-VIs should (almost always) use the 4-2-2-4 connector pattern, with the Error Line running through the lower left/lower right connectors.
• LabVIEW is a parallel language.  You should have the Error Structure in its own While loop, "feeding information" into a parallel While Loop that "does things" for you.  Take a look at the Producer/Consumer Design Pattern (Data), one of the New VI Templates.
• Write the Documentation First.  What this really means is plan what you want your code to do, and try to structure it in logical steps.  Try to identify those parts of the code that can be "buried" in sub-VIs.
• Learn about some common Design Patterns by studying some of the Templates and Projects that ship with LabVIEW.  In particular, learn about State Machines.  You might install the JKI State Machine (you can look it up, or if you have VIPM installed on your machine, you can find it on the LabVIEW Tools Network).  State Machines work especially well with Written Documentation.  If you say "First, we initialize the equipment, then we collect 20 seconds of data, then we analyze it to death, then write it to disk, then wait for a button push, then do it all over until someone pushes the Stop button", you can immediately see you need an Initialize, Collect, Analyze, Save to Disk, Wait to Repeat, and Exit states, each of which does "something" and all of which save common results in shift registers in the main State Machine While Loop.  

Bob Schor

[RezaTAMU]

Hello Bob,

Thank you so much for your kind reply and the great suggestions!