infinitenothing

Try this

Your class type has the queue in it. Your accessors have to dequeue-modify-enqueue with a timeout as an input. You have to have a Create-Run-Destroy architecture.

I don't run into this issue much but back before we had DVRs, many people were using single element queues for the same purpose.

Let me poke a hole in that theory. Async wires aren't necessary for anything. The functionality already exists as shown in the Getting Started guide.

It's one of those implicit features. You'd expect 2015 to open block diagrams from 2015.

The important one is that you'll be able to open block diagrams from other people who are writing in 2015 without going back and asking for a down conversion

Zer0, where do you initialize (write zeros to) the array? I'm guessing you have a race condition. Using a shift register will fix that race condition

There have been some attempts: https://lavag.org/topic/5047-prototype-replacement-for-errorllb-second-attempt/ https://lavag.org/topic/10741-updating-the-labview-error-handling-core/

Every time you start the outer while loop, you're going to start with the same initialized array coming into the wire. If you want labview to remember something from one iteration to the next, you need to put a shift register on that loop. The inner while loop does nothing as far as I can tell and probably should be removed.

Also, you have no wait in your loop. Check your processor use—It's probably at 100% (not a great idea) for one of your processors. Try ~100 ms. If you still want to give the array event a try, here's an example of an event that is triggered by the array value change.

I'm not totally clear on what you are having trouble with. After you bring in a CSV, you have an array. You need do some sort of array manipulation and comparison operations to trigger actions. I've attached a trivial example of what you can do with a 2D string array If you want that data to affect something physical you need help with DAQmx Here's a test CSV: Status,Number Normal,5 Broken,8

Your VI is going to read the stop button (False) then invert that (True) make an array from that Sit at the edge of the event structure for a bit Lets say you press stop 2 ms into the event structure wait—you have an array of true waiting at the incoming edge of the event structure. That true is going to go into your "data array". The next iteration starts, the "true" at the stop control is read at the begging of the loop, you wait and execute the timeout event You can verify the above sequence if you are patient and set a really long timeout (~30 seconds) and turn on highlight execution In the picture, the shift register is just a way to make the first iteration different from all the others. On the first iteration, the timeout is 0. All other iterations have a timeout of -1. Most of us like trigger our actions based on events rather than letting the timeout lazily pick up changes as needed. To that end, you can create an event that will start executing as soon as your "data" array changes. Also, your DAQmx clear and stop are being performed in the wrong order. Follow the examples.

No, that example writes to many lines at the same time. Look at the channel input: Dev1/port0/line0:7. That means that the "channel" is 8 lines. The input being an array goes along with this. Writing all the lines at the same time should be more efficient that writing them individually.

Look at the example here: {LabVIEW Programs Folder}\examples\DAQmx\Digital Output\Digital - SW-Timed Output.vi One of the best things about DAQmx is there's so many good examples.

Primarily, $1555

"critical sections around shared resources" sounds a little like how non-reentrant VIs are used to arbitrate functional globals If I recall correctly, there's also some deadlock proofing in the DVRs where if you try and nest DVRs in a bad way you get an error. Just remember, you can't have it all https://en.wikipedia.org/wiki/CAP_theorem

Maybe you can accumulate the X and Y values in a shift register and use an XY graph

It's probably not determined at compile time because I think reentrant clones will each have a unique number. It's probably determined when the VI is opened.

The advantage there is you can open occurrences at will without worrying about closing, deleting, destroying, or releasing, your references

Someone should make a internet drop box type app for conversion. Until then, there's always http://forums.ni.com/t5/Version-Conversion/bd-p/VersionConversion. I've taken it back to 2009.

Since you are storing the data uncompressed, maybe you can just write 2D arrays to disk using Write to Binary File

What kind of throughput do you need? You could consider some sort of custom serial or parallel interface.

That makes sense. Let me throw out an idea: So you're trying to find the coefficients in this formula: Z=a1x+a2y+C. You might be able to use this: http://zone.ni.com/reference/en-XX/help/371361H-01/gmath/general_ls_linear_fit/ Where Y is an array of all the pixel intensities and H is {x1,y1,c}, ... You might want to use real world coordinates instead of pixel coordinates.

A tilted circle projects to an ellipse right? http://zone.ni.com/reference/en-XX/help/370281M-01/imaqvision/imaq_fit_ellipse_2/ Not sure about the general solution but maybe something involving this solver http://zone.ni.com/reference/en-XX/help/371361J-01/gmath/find_all_minima_nd/

You might have to show us some pictures. It sounded like you had some edge detection which should give you points that make a circle on the edge of the cylinder. You can use a circle fit to get the radius which will give you an area. If you need, you can take an average inside the circle to get the height of the cylinder.