infinitenothing

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=a₁x+a₂y+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.

Something like this?: http://zone.ni.com/reference/en-XX/help/370281P-01/imaqvision/imaq_fit_circle_2/

Thanks everyone, for the insightful discussion. I agree that it's most sensible to perform cleanups even if an error occurred, and the Network Stream example sounds like a design flaw.

 

Aside from cleanups though, I can't think of any other good cases which should run regardless of error -- do you guys do this in non-cleanup code?

 

As for accessors, I agree that read VIs for a simple number shouldn't have error I/O terminals. I still put them in write VIs though -- I avoid modifying my object's state if an error occurred beforehand. Does anyone feel strongly against this?

Any sort of inter-module communication will have certain messages that you want to get across regardless of the error.

I don't think you attached code as you had intended but have you considered putting a case structure in your <0.6 case that would trigger in a range. You could use the "In Range and Coerce" function and wire the "In Range?" output to the inner case selector.

Relevant idea

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Visual-indication-that-VI-will-run-even-on-error/idi-p/1587044

At the very least it should be in the context help when I hover over that terminal.

Yeah, I've seen it mutate even without changing platforms. They are delicate.

I tried this in 8.6 and I got the same behavior. Not sure what's up with 2009.

Over by 5. I'm still impressed.

I'm not sure where this is documented but it's pretty consistent. Here's a simplified diagram showing this behavior with a numeric. If you wire the indicators to the connector pane, they get defaulted at the end of the run.

The distinction was where they were implemented. If the memory is implemented higher up, its easier to unit test the lower level VIs.

No. Something happens after the false case runs. The VI returns default data for all its unwritten indicators. The moral of the story is to not use controls or indicators as memory storage. The preferred memory storage unit is a shift register in the test vi. A feedback node in the subVIs is the next best thing.

Maybe explain how you fixed it for future visitors. https://xkcd.com/979/

You might phrase it differently. It's hard for us to think from the perspective of someone that's lost.

I have sent out a "xmodem" in a string with carriage return.

Why?

I am sniffing the transmit out of my UART. The UART transmit line then continuously sends a negative acknowledgement (NAK).

Am I on the right track?

Doubtful. Did you try what I suggested above?

And since you don't have type safety, if you have multiple state machine threads, you have to be careful to keep your queues straight and not send your message down the wrong pipe.

Wait for a "C" from the receiver and then run "Xmodem Send.vi"