ensegre

Onboard. Observations: Brian's last version must have a bug, the resulting html is almost static (I can type inside numerics and strings, I can pull down Averaging, but non data is sent from or to the VI). I wouldn't be surprised if it is a trivial mistake in JSON escaping. See my image, the double backslashes in the path are suspicious.[EDIT - no] The thing still depends on wsapi (dragging in the whole library for good), thus working only on windows. This is because Escape HTTP URL.vi, Unescape HTTP URL.vi and LV Image to PNG Data.vi.

I see, thanks Rolf and smithd for the pointers. Setting aside the stability and future support of private stuff, about which I agree with Rolf's first comment. Let's suppose that I "guessed" the calling sequence of one core function, one which is for example (linux) inside /usr/local/natinst/LabVIEW-2017/cintools/liblv.so along with those of the old list, but not one of them. If I release code based upon this guess, would I place myself on the bad side?

Off the head, I think that it may be common knowledge on this site that some functions are realized via CLNs which call certain procedures, with "LabVIEW" as library. I don't have a particular link to prove this, but somehow it is my off-the-head, long lurker impression. Certainly "LabVIEW" is not a smart search term here. The intriguing fact about the "LabVIEW" dynamical library is that the application resolves it opaquely, perhaps (from minimal explorations I did on Linux and windows versions) even pointing at differently located dynamic libraries on different platforms. Now, is there some semiofficial resource about this? The reason I'm asking is actually the following: I think I could offer a nice addition to a nice project here on the site, using native LV calls, by providing a couple of VIs which implement such calls. The concern is: would I be breaching the LV licence if I did? [apart of "it's private stuff, don't cry if"]. The alternative would be to locate a really suitable external library, interface it, maintain it; a much larger hassle.

I was thinking, an useful addition to the cool Modbus Comm Tester would be a section for Read Device Identification. Probably fitting nicely the 7th rectangle on the FP is the difficult part of it; the extension of the code, which is elegantly written, seems trivial. What do you think about?

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.