ensegre

Shoot one image at a given exposure time. Get a meaningful measure of its intensity (e.g. the maximal pixel value, the average of the pixel values in a region around the maximum or in a ROI). If too large halve exposure, if too small double exposure. Repeat in a loop till this measure is in the middle of the acceptable range.

If the camera is Genicam, i.e. driven by IMAQdx, check if it has a settable attribute for auto exposure. Auto exposure normally means a canned algorithm inside the camera which shoots images at increasing exposure times, till the average intensity is middle of the way, and then keeps that for good. If it hasent, just program it in your code.

Oh that's not all. There is also this idea, where AQ said that he will try to rattle the cages, and this thread. On linux it is worse, but run_scaled may be viable.

Parallelizable for loops were 2009 or 2010?

I see. For your specific real world example though, couldn't this be a workaround? E.g. registering statically for a mouse_move event of a generic (blank) reference, turning it to the relevant reference on mouse_down, and reverting to blank on mouse_up? evnt3.vi

I confirm the behavior in 2017 which is the only version I have at hand now, but am not sure about your intent. Certainly you're more sophisticate than me in programming and your snippet is a minimal cutdown of something really meaningful. I only observe: if I register once the event before the while loop, which is what I'd normally do, the increment is fired. maybe the new behavior is not about registration, but about the generic event refnum constant?

Can we see some code? How moving around the controls is handled? Is it some sort of drag and drop? Is it handled by LV or by Windows API? Also, is the VI in the supbanel running? I wouldn't know if it is possible at all to add a control to a running VI with LV scripting.

Right click -> Visible Items -> Radix Left click on d -> Hex

I NI-updated today to 17.0.1 and VIPM didn't disappear. Maybe they solved the issue?

For instance. There is even an Example in the Example Finder for that, Histogram.vi

Some discussion about performance of various path computations is at pages 1-2 of this thread. The dll needs to be called at every evaluation, by its known path, not just at construction. Maybe it would be conceivable to carry the path to the dll on the muparser reference wire, but I'm not sure it would be too logical.

Did you add libmuparser-xxx-lv.dll to the project, and specified it in the Source Files/Always Included section of the build spec? Since the dll is called dynamically (see previous discussions), it is not automatically detected as dependency.

Crosspost on the dark side. (and on the track of "where do I connect the cable so that it is integrated with Labview"). Forget.

Certainly not. You see, it is not that the difference with these anemometers and yours consists in the length of the cable and in the firmware version. The general principle of the instrument may be similar, but the protocols they may have chosen to deliver the data will certainly differ. You have to look up your documentation and understand which kind of commands and data your instrument talks. And you have to get familiar enough with labview to be able to write a program for doing what you want. Based on my previous experience I would guess that your instrument may accept some commands sent on the serial port, and deliver, continuously or on demand, still on the serial line, velocity datapoints. Your program will have to receive this data, parse it and interpret it. The format chosen might be ASCII or binary, this I don't know. The basic building blocks of your program may include VISA read, VISA write and scan from string. Beyond that the business logic is all yours. A further issue you might have, is how to synchronize the anemometer with the readout of the other instruments. As I don't know details, I can't recommend. Basically, every device would run on its own clock, and replies to the computer with its own delays and latency, unless there is a way to ensure the sync - a trigger, for instance.

I have no experience with this one, but I do with Gill sonic anemometers, and I don't think the story must be very different. These are probes which provide a continuous stream of 3d velocity data, usually on a serial port, using some simple communication protocol of their own but documented. Normally all that is required is setting the work range and sampling frequency, and then just log the incoming data, for archival/online processing/whatever (which is application dependent). https://www.nortekgroup.com/products/vectrino?p=en/products/velocimeters/vectrino (click on Technical Specification/Data Communication) gives some hint about being a) serial b) supported by some software or SDK. Beyond this, homework. You know, handling serial communication, sending command words, parsing incoming strings, logging data.

Control:Is typedef? is read only, that is the problem.

PS: you may have to cast number arrays to U32 to avoid wraparound of the sum, if you have more than 32767 pixels, sorry I didn't pay attention to that.

How about or ?

In general I am however interested in hearing about experiences and opinions about LV vs. X for building SCADAs. A quite broad question I understand, and much dependent on plant size and boundary requirements, but still. In my case some of the arguments which drove me once more to LV were: heterogeneity of the hardware to be controlled, need to interface with other systems, perception of a higher freedom and power in concocting the HMI, academic rather than industrial work culture, presumption of insurmountable learning curves and additional license costs.

I'm throwing in my all the way incomplete point of view, because my current project is a SCADA too, and I decided to go the labview way. However, I'm still asking myself about the rationale of my decision, and about the option of integrating PLCs at a later stage. At the design phase I looked at some docs of a few PLC vendors and their control software, and was scared off by their license tems (LV we have academic), by the learning curve and by the apparent (to me) clunkiness. Add to that that I presume that the bonanza I can get from the LV community largely surpasses the support, even paid, which I could get from a solid SCADA vendor. It seems you are still deciding whether you need PLCs or not. If you're excluding NI (realtime standalone?) hardware, does it mean that you can afford the increased instability risk of running your business logic on a desktop computer? Is safety among your requirements? (No connection with the particular vendor), I ended up purchasing a number of these Advantech ADAM-5000 modules, which seems a decent compromise for my needs. On one side, they are ruggetized and modular remote IOs, which I can easily read as modbus registers. On another, they seem to have a minimal capacity for an embedded logic (e.g. you can define logic functions of three inputs which are routed to another register of the same or of another module), thus potentially overlapping with minimal PLC capabilities. I'm currently testing them. Has anyone else used them and would share opinions?

Getting no answer, I crossposted the dark side and got a solution there.

No idea about the above. If it marginally helps, I have this snippet which descends a directory tree and does all .vi, .ctl, .lvclass and .lvlib. The code is a basic elaboration of what proposed earlier in the thread. SeparateCompiledCodeTree.vi

I wonder if someone ran into this and has a good suggestion about. I have a DSC project, in which it looks just right to organize hierarchically my shared variables. Like, e.g. Now this is easy to do programmatically, see the attached project. The problem arises when building an application. It would look as if the plain way to do it, would be to create a build specification which includes the additional libraries, and select their deployment in the "Shared Variable Deployment" tab. However, this doesn't seem to work for nested libraries as in my example. The only possibility seems to add in "Always included" each of the contained libraries. But by doing like this the hierarchy is flattened. If I include like this, then the variables within the container library are not deployed at runtime. In my example project: open the project in the IDE, run DeployAllSharedVariables.vi, then CheckDeployed, and see the result (all four variables found with their nested paths) build and run DeployFlatLibraries and see the result: four variables, but flattened paths build and run DeployHierarchicalLibraries: only the two variables in the unnested SimpleVariableLibrary are there. I've searched a bit, and only came up with this document, which (for >2009) says "just check the checkbox". Nor the help page says much either. I wonder if I can do what I'd like only compiling separately the libraries, and loading them programmatically afterwards, both in the IDE and in the exe. Which probably is sane, but inconvenient for the first attempts. TestDeploy.zip