ensegre

Zombie resurrecting. I'm in the same situation, downloaded the deprecated, and see that the interesting VIs are password protected. With due time I can perhaps work my way out, but otherwise can someone suggest me a quick wrapper just for sending command strings and receiving replies? TIA, Enrico

This is a DSC module question: has anybody here experience with building standalone executables which include shared variables bound to DSC modbus i/o servers? I have an issue with deployment, possibly related to licensing. I posted on the dark side, but haven't got feedback yet. https://forums.ni.com/t5/LabVIEW/shared-variable-bound-to-Modbus-i-o-not-working-in-deployed/td-p/3809801 TIA, Enrico

My speculation would be that NI implemented in IMAQdx only the support for the most common events, and that this is static. The fact that one particular camera has additional capabilities, and perhaps even advertises them when connected (like it does with its attributes) may simply not be taken into account. But I'm curious to know about too.

Well, my idea for multiplatform is in fact trivial: replace the three wsapi VIs with independent ones, fiddle a little to get rid of the broken library dependencies, and go. For the two % escape vis it is just a matter of copying the code which is open, modulo some correction. Talking about the third VI is a bit hairy because the original is password protected, but, I found out a posteriori, you have been there too. As you said there, the code appears as conceived for working on the three platforms. So I did that and played a bit with it, with inconsistent results. I tested three machines, one windows and two linuces, and concentrated just in getting the two examples read as file:// in chrome and firefox. The one windows was most of the time updating correctly (but not sometimes, not on second run of the same vi, sometimes only refreshing the browser, etc.) The first linux updated itself erratically when it should have, mostly updated correctly only refreshing the page, but still transmitted correctly to the VI the controls operated in the browser. The third linux produced a static and messed page in the browers. Alas, that one happens to be a system with comma decimal separator, so perhaps there is this in the way. All together nothing yet stable enough to post here. I'd need to grasp the mechanics of what goes on, and look for races or bugs, not sure if I'll manage soon. For one, I have a vague suspect that the final anonymous call to Cleanup.vi cripples the synchronization if the Example vi is run the second time.

Ok, 1 depends apparently on a double NIC. I should have read this before, perhaps. In fact "Here we can use the external IP address..." in Example.vi is wired in Brian's latest version, and not in Thomas' one on github. Sorry for the noise. For 2 I'm testing a solution which could make it work on linux and possibly even on mac.

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