ensegre

I have LV12, 13, 14, 15 on my desktop (probably ubuntu 12 release upgraded to 14) and 14, 15, 16 on my laptop (ubuntu 14 upgraded to 16). So possible it is possible. How do I do, I forget year after year, immediately after I succeed. IIRC it usually involves an "Oh, ./INSTALL.sh gives an obscure ]] not expected syntax error", and an "ok, let's copy all the *.rpm to /tmp and alien -i them". On those two systems I can confirm the installations survive to distribution upgrades, the files just sit in /usr/local/natinst/. I usually never bother to get VISA really working, I only use the installations for code-checking and algo developement, GUI without being too picky about font look (which however somewhat improved with 2016). If I'd be to bother about VISA, I think I always stumbled in noncompilable kernel modules. Maybe the last time I somehow succeeded in having VISA working on a nonsupported distro was in 2008.

You are the master of your code, you can do what you want. Perhaps you're asking - if I get a full image from my camera, can I extract a ROI with IMAQ - short answer, yes, http://zone.ni.com/reference/en-XX/help/370281P-01/imaqvision/region_of_interest_pal/. But you may also want to look into getting only a ROI from the camera, to reduce the payload. To do that, you send settings to the camera, and get only that part of the image; you can't expect to draw something on a LV widget and magically have the camera know about it. Unless you code for that. I think you are confusing the IMAQ image buffer size with the actual content acquired by the camera and transferred to the computer. IIRC the IMAQ images auto-adapt themselves in size if they are wired to receive image data different than the sizes they are set to. Of course you can also get your images at high resolution and resample them, but that adds processing time. You may have to grasp how IMAQ images are handled btw - normally transformation are never in place, they require the preallocation of a source and of a destination buffer.

The application has to render a larger number of scaled pixels onscreen. The performance drop may be particularly noticeable on computers with weaker graphic cards (e.g. motherboards with integrated graphic chipsets) which defer part of the rendering computations to cpu. If you process smaller images, your processing time may also be proportionally smaller. Additionally, image transfer and memcopy times will be smaller. But images at lower resolution contain less information. You are the one who has to decide how small the resolution can be, in order to still derive meaningful results from the analysis. If the bottleneck is rendering, you could constrain the GUI so that the display never gets too wide, or the zoom factor never too high. Another popular approach is to process every image from the camera, but to display only one image every so many. Depends on the camera. Look for image size, ROI (AOI), binning. If you can with MAX, you can with LV (GigE, almost surely Genicam -> IMAQdx properties). [with the advantage that in MAX you can save the default setting]. If you can't with MAX/LV, it might be that a camera SDK allows control of additional features, check your camera documentation.

Could you trim that down to some code without hardware dependence, which we can look at? Oh, and you mentioned dynamic events. Are they involved here, so that you have reasons to blame them?

Doh, completely right. That would be the first of the alternatives given in https://en.wikipedia.org/wiki/Shoelace_formula, plus argument checks. It occurred me to think that among the various alternatives, both the one I thought and this one are the most efficient needing only two array allocations and one multiplication. The determinant form in http://mathworld.wolfram.com/PolygonArea.html needs two.

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.