ShaunR

The toolkit will lock the libraries and produce a licence file which you can browse to and select in VIPM. NI have a SoftwareKey Server that they use for Tools Network offerings but you can buy and install your own from SoftwareKey.

Is it reentrant?

I've only seen those sort of frequencies of corruption if the files are on a network drive.

Ditto what Rolf said. If you want a class that handles arrays of objects then take a look at List.

I don't really use classes for the intended purposes. I mainly use them as a variable cluster local to the instance when I need to keep track of state (sessions, stateful protocols et. al.). On the rare occasions I have used them for the intended purposes it has never gone beyond 2-3 and it's always been more hassle than it's worth, less elegant and incomprehensible build times.

That's because you have only dumped LV error messages into the DB. LabVIEW error messages are for LabVIEW programmers. Pull the error number out to a field so you can look up your own, different messages. I think what you are struggling with is the difference between application error messages and system error messages. So I would expect an application message something like "Server XXXX is not responding. Unable to connect to server". That is fairly easy as you just override the default LabVIEW message for 63 with a more verbose one. However. They may have left the IP address blank, in which case the application error would be something like "You must enter an IP address". If you let that through to LabVIEW then it will report error 54 "The network address is ill-formed." That may be ok since a blank IP address is, indeed, ill-formed but the former is more explicit. Note that just overriding error 54 with "You must enter an IP address" will have them yelling at you "I did enter it" as It is a context sensitive error. So adding a custom error code for blank fields that should be filled in is advisable and check the field before actioning. That way you can be sure error 54 was an illegal address. That's a rather contrived example but the sort of error guessing and reporting that I try to do (caveat: non programmers) In summary, there are application specific errors. A production line operator should only be expected to resolve two types of errors - they didn't enter something they should have or they entered an illegal value. Outside of that it depends on training and remit. If there is training then you should also add the training manual page and section to which the error refers. This will cut down a lot of the "didn't read it" responses as they are expected to refer to the manual to resolve the issue and the manual will contain far more information than an error dialogue and what to do about it. If they can't give you the page number and section then they have not followed procedure and you can chew them out. If they have referred to the manual then you know the common resolutions have already been tried.

You are not using SQLite for this? Not only can you have multiple messages based on required verbosity but you can have fine grained segregation based on type (information, debug, Critical, Warning etc) and user (Operator, Technician, Maintenance etc). Additionally you can have language translations.

Considering COBOL is over 60 years old, I think most experts have long since retired and most of the US government runs on COBOL. Just a quick and dirty example from one site...

Too obtuse for my smooth brain. You link to a COBOL forum and imply something but I have no idea what you are implying or it's relevance. Is it a spam post?

The intensity graph is usually an order of magnitude faster for this sort of thing as it has in-built interpolation. Not sure it would particularly easy with the mouse-over circle, though, since you wouldn't be able to draw on it and it would be very difficult to implement non-rectangle colour maps.

I disagree. There are other native solutions that won't crash LabVIEW, are cross platform and you could probably make it look much better than the LabVIEW native control.

I haven't finished yet Agreed. Bug. I too couldn't preproduce it in 32 bit. However. You need both strides for the 2D array (offset= x*Stride_1 + y*stride_2). Granted LabVIEW uses a contiguous allocation but that also assumes packed and aligned. Not sure we can guarantee that on all platforms (Rolf will know). You can obviate the array allocation for this particular example by auto-initialising it on the first run (or when the length changes). You can remove the calculation of the length too since that is returned as one of the size parms. You can calculate the length as in the other examples but not calculating it improves jitter immensely. I also did your little trick with the wrapper which makes a nice difference here. too. The following was on LV 2021 x32. Compared to... Raster 2021_SR_1.zip

A warning about the ArrayMemInfo function. Be aware of whether it is returning a sub array or not. It can change even by changing VI properties and a plethora of other reasons.

I like that.

You used to be able to modify the GSW but in later versions they put it in a packed lib. The probe window is still my #1 focus of hate. The fact you can't resize string controls in it makes it dead to me

I'm nothing if not consistent. I have a first in, first out memory with limited buffer. I guess the buffer has reduced to less than 2 years in my old age. Not long now before I'm yelling at clouds, I guess.

Ok. Sweet. I get the same now. I tried it on some other functions that I thought might benefit but it turned out that the majority of the overheads were elsewhere. Is that feature sticky in that if it is set during design time it stays with the VI when loaded on a LabVIEW install without the ini settings?

Interesting. I only see a difference when Error checking is Max. Default and None produce no changes. I assume that's what you mean by "without the wrapper function"?

Well. just to be argumentative.... It is <almost> entirely equivalent. A type cast is used in AQ's original to convert between formats initially and assumes a particular memory format such that when the reverse is operated, it produces the expected result (consistent memory topology). Memcopy, of course, won't work with the LabVIEW type cast since the expected memory formats are different (and would be different on different endian machines and not portable). There are also a lot more checks and an allocation with the type cast, naturally. I suspect the performance boost that AQ sees by converting to a string first is to do with bypassing byte swapping-perhaps he can tell us in intricate detail why it is faster converting to a string first. The memcopy is doing a lot less work because the array initialisation is outside of the timing and a fixed size. You can move the array initialisation into the timing area to create the buffer on-the-fly at the cost of performance in order to generalise but it is still slightly faster. If then you check the length and allocate that amount on-the-fly, then you end up with a similar performance to the tostring trick, sans protection. Most of the differences will be to do with compiler optimisations. The take-away is that the type cast (rather than memcopy) won't crash labVIEW if you get it wrong, is portable and poke-yoke. Use it.

Doh. that's what happens when there are several different VI's with the same name. Should be fine now (and neater).

Done.

I modified AQ's test to include moveblock so we can see. array-typecast-benchmark.vi

Indeed....but! We are looking at a 0.1% case so it's things like this we have to bear in mind. Error messages not being reported. My money is on it being used. You are probably in the 0.00001% of LabVIEW programmers that don't use it.

Without knowing what the problem (error) is with the underlying socket, you are on a hiding to nothing. The fact it is rare and affects other software points to a hardware or OS issue, not your code (except that your code doesn't report an error). That doesn't mean to say other software or the OS isn't responsible for crowbarring the socket underneath you but you need errors to figure out what is happening and what the state of the socket is when it fails. Another technical detail. The LabVIEW Listener uses SO_EXCLUSIVEADDRUSE and assumes it has sole ownership of the socket. It then uses the "Internecine Avoider" to choose ports. If no net address is defined it binds to all network adapters. Does the device have multiple network interfaces? What is the OS?

What's the error?