ensegre

No experience with the Moxa beyond reading the product page, which reminds me much of the Vlinx and Advantech serial servers I'm using. These do have TCP and UDP modes, and are thus cross platform. You have to configure them first using either the windows configurator or their webby. Here is an example for TCP. Note the .vim which provide alternate code for either TCP or VISA. VLINXqueryTCP.vi VISA_TCP_query.vim CloseConnection.vim

So it is.

Possibly you're missing that Porter's library (pretty as much as any other modbus library) is made in order to save you from the technicality of how to build the proper header and CRC. To reproduce the table you copied, which is call function 3, read holding registers, for a device at address 6 (hence serial modbus it is) you do like this:

I meant to write: another one of the hidden gems, one which I didn't notice. Thanks nevertheless Darren.

Hidden gems I didn't know. Thx!

.net is windows only, G runs wherever LV runs. From the READNE.txt

Mostly a curiosity, it would be the cherry on the cake for a build specification which generates a distributable .llb (build Source Distribution, Destinations/Destination type: llb): is someone aware of a way of making some file appear as top-level in the built llb? Either as build spec option or postbuild scripting? I found none. LV2014 presently, but I'd suppose it isn't there in later LV either.

cross-platform, say? [never used that particular library, anyway]

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.