ensegre

just to exclude the obvious: how do you know? Are you inspecting the right instance of the clone?

No. https://en.wikipedia.org/wiki/Shoelace_formula, http://mathworld.wolfram.com/PolygonArea.html. Just with an alternative arrangement of the terms. You could if you want to rasterize your image. Do you need that?

Why arguing? If you have the coordinates you have the analytical solution. You may decompose it in summation of areas of oriented triangles with a common vertex (any point of the plane), or in trapezes based on the y axis, you will get to the same result.

See http://forums.ni.com/t5/Example-Program-Drafts/Create-Configuration-Files-INI-for-Your-LabVIEW-VIs/ta-p/3536260

You have to code it yourself in a way or the other. For example having your VI save the important values in some kind of config file on exit, and read them in (if the file is present) first thing on start. Your choice whether to dump plainly the control values in a binary file (inflexible and obfuscated), to use a standard format like xml or json, or a plain format of your design for human readability, and how to treat file errors and make room for future changes. OpenG should have something in this direction, never used. Another way may be invoking "Make current values default" and then saving the VI, programmatically. I find the first solution preferable in general.

There are properties like VI server/Application/Display/Primary Workspace, VI server/VI/VI/Front Panel window/window bounds which you can use as a base for your computed placements.

If you already have the coordinates {x_i,y_i}, i=1...N, simple integration by trapezes gives A=sum_{i=1}^N (x_{i+1}-x_i)*(y_{i+1)+y_i)/2, identifying N+1 with 1. You can implement that in pure G as well as with mathscript, as you like.

LV metrics is in pixels, not in inches anyway. Your best bet is to develop from start for the exact number of pixels you have on the deployed screen. You could also try VI properties/Window size/Mantain proportions of window and VI properties/Window size/Scale all objects, or Scale object with pane on single controls, but the result may not be impressing, and this is a notorious flaw of LV. For finer control, you could specify programmatically the positions and sizes of all your objects with property nodes, which is certainly tedious.

Oh, apropos FP things and "LabVIEW falling short and us solving simple shortcomings with days of programming".... One idea in this direction.

BSD.

There is also the plasmionique, supposed to be better (not tried yet), coincidentally also at its rev 1.2.1.

An animated gif is of course a convenient compact container, I was thinking too, but a suitable custom format could be devised to the same extent, if one really decides to pursue this path. For instance, a zip containing the pngs and playlist information, or timing encoded into the png filenames. I also remarked that some animated gifs contain incremental (like e.g the one in Steen's), not full frames (like in bbean's above), but I guess that could be appropriately taken care of too, at worst converting them to full independent frames. A matter of effort for the purpose. What I wonder is if it is worth to concoct some kind of Xcontrol out of the idea, in order to get a configurable animated button, hiding the additional event loop.

Maybe I say an heresy, but what's wrong with a clickable picture box? This is a q&d attempt, just loads in memory all *.png found in a directory and animates them, it doesn't look to me as overcomplicate as an embedded activeX browser or the like. Maybe a portable Xcontrol out of it? RotatePNG.vi

If some of your "dimensions" are just A vs. B (e.g. 50 vs. 220, Al vs. Ti like in what you show), perhaps plotting each group in a different panel and juxtaposing them may convey better the information than a single plot with too many similar looking symbols. Indeed the symbol variety in LV plots is nothing impressing. Other plotting packages have many more options as for shapes (e.g clubs, diamonds, ducks, broccoli), hatchings, and whatnot. One additional style parameter which you could use to differentiate sets on the same plot in LV, could be symbol size (Line Width). Of course useful only where you have two or three possible classes, not for a continuous range.

I'm also onboard about not having to check and branch for an invalid default input, but an use case where that would really have been a hindrance never really occurred to me. Putting aside for a moment the considerations about use case ("would a polymorphic implementation be leaner?"), it seems to me the problem splits into two different parts. This is how I would envision using them, but I don't really know what is going on under the hood to understand if it they make compiler-wise sense. a) a scripting Property node like say VIserver/Generic/ConnectorPane/IsTerminalWired[], returning an array of booleans b) a new special Case/Conditional Disable hybrid, allowing a control terminal (unlike the Disable) connectable to these booleans, but imposing the elimination of dead code (unlike the Case). Now, a)'s results would be determined at compile time, looking up at the calling context, and perused by the programmed code. I suppose the wire could be as well probed for debugging, and if the VI is used multiple times, called by ref or whatnot, the result would reflect the called instance / clone being run and probed. It's b) that looks to me quite awkward. ("a new special frame, seriously? accepting only compile-time determined boolean inputs? Are boolean operations on compile-time booleans permitted?"). a) would just tell about terminals and b) would make explicit (?) the optimization, but?

Unless you are in a situation where you can happily mix commands and replies, because each instrument identifies itself in the reply, and the response to a query may take a variable time, or parallelization would be advantageous, and the bus has some arbitration feature that prevents instruments from talking simultaneousy. Then you should create a readout queue, identify and dispatch messages received there, etc. It never occurred to me so far to do it, but that makes sense.

I don't know. But for a similar case, in my ignorance and probably just crudely redoing what the lock is supposed to be for, I used semaphores named after the VISA resources. I acquire the semaphore immediately before every read or write, and release it then (forget the specific details of the readout): To deal with multiple serial ports I have a FGV containing the list of serial ports used and their associated semaphore references. ResourceSemaphoreContainer.vi

Might it be that some file in <LV>/resource/PropertyPages/ is screwed up/not readable? This was earlier in the forum, and explains to some extent: http://webspace.webring.com/people/og/gtoolbox/CustomizePropertyPages.html

Years ago I had a similar problem, and I think I temporarily resolved it by disabling/reenabling the device, which is not exactly the same as reinstalling as you ask, though. Here are some links I perused at the time (the last dead now), which involve a command called devcon, which worked for XP. Maybe it helps... http://en.kioskea.net/faq/1886-enable-disable-a-device-from-the-command-line http://www.rarst.net/script/devcon/ http://www.wlanbook.com/enable-disable-wireless-card-command-line/ http://www.osronline.com/ddkx/ddtools/devcon_86er.htm Otherwise I can just generically recommend to make your usb connection as robust as you can, to improve reliability. Watch out for flimsy cables, and EMI.

On linux, avconv is powerful, command line, and options rich. I have used it routinely to create .mov from .wmv, for instance. For automatic conversion, I imagine one could set up a script which checks for new files in a given folder and initiates conversion after they have stopped growing since longer than N seconds, or something the like. It never occurred to me to stream contents through some pipe for conversion on the fly, but that might be possible too. If windows is required, short of seeing if something can be run in MinGW/Cygwin, I see that libav provides windows builds, but I haven't looked into operation.

(probably echoes what also said in the other thread): If the reference can become invalid in the course of the iterations, and I want to check it specifically at each iteration, I'd put a shift register; if it is sufficient to know what was the initial ref, I'll go for 1. or 3. If reference going invalid in the course of the execution of the inner VI implies an error at output, I'd put a shift register on the error wire. But most importantly: if there is any chance that the loop executes 0 times, use 2., not 1.

https://en.wikipedia.org/wiki/Lakh

Thread starving might become an issue eventually, but only if there are some thread-locking calls, e.g. orange CLFN. But anyway, I would give some thought about whether the proposed architecture is really sound and couldn't be factored out differently. For example, would it scale gracefully if a fourth, a fifth instrument and so on will need to be added later on? In the middle level, why a cluster of queue references needs to live on the shift register? How does the producer loop address the right queue, and how easy would it be to add more commands/instruments? What would be the stop conditions of the inner and outer while? Is it ok that the each "measurement" command produced by the top level translates to independently executed instrument commands, or is there some sequentiality and interdependence to be accounted for?

86 means labview 8.6? At that time IIRC IMAQdx was provided as an unsupported addon rather than as a device driver component, so location and probably naming of vaguely equivalent VIs may have changed. "IMAQ USB Init.VI" may be roughly "IMAQdx Open Camera.VI", for one. It may be that you can still download the package from NI Support, but if you have LV2014, the sane thing would be to use IMAQdx coming with it.

Are you sure it is not diaphony of your sound card? Does it happen with other sound generators as well on the same system?