ShaunR

2 hours ago, Youssef Menjour said:

1 - Get started with NI 
Advantage --> Your package will be on ni.com, NI helps you directly and they manage your licensing policy.

Disadvantage: you have to pay a fee to NI (30%). I feel it exessive for long term, they are too greedy and i dont want to sell my package to expensive i will lose customers.

Interesting. This is could be due to their new subscription method. It might be worth finding out whether that is the case as there will be other caveats like you need to maintain a subscription

2 hours ago, Youssef Menjour said:

2 - Do it yourself

Advantage: you are free to do what you want. 
Disadvantage --> more complicated to do, not well documented.

Indeed.

I vaguely remember a third party that was offering an alternative solution that was implicitly geared towards LabVIEW and used the TPLAT. But I can't remember who it was or how it worked.

48 minutes ago, Youssef Menjour said:

I could not find where to start the Third Party Licensing and Activation Toolkit

The toolkit will lock the libraries and produce a licence file which you can browse to and select in VIPM.

49 minutes ago, Youssef Menjour said:

As i understood i have to use it to format my project then i'll will need to link to softwarekey solution to manage the generation and sell part of key.

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?

1 hour ago, Francois Aujard said:

Not always happen, sometimes... perhaps once in 20 or 30...

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.

2 hours ago, drjdpowell said:

I have an SQLite logger, yes, and the more expert Users do use it.  But even there hard to read error messages are a burden.  Especially the poor first line, as teh first line is what appears in the list of log entries, as in the "Error 63" shown here, which was a failure to find a TCP Service (because the service was not running). 

 

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.

2 hours ago, drjdpowell said:

I should say my particular use case involves a large set of third-party code that can throw errors (often without error codes!), plus a variety of different categories of "Users", including not just "Operators", but subject-matter experts in the hardware and some of the third-party packages, who need to be able to use error information to debug problems in their areas.  I need to be able to present arbitrary errors in a way that is most helpful to them.

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.

9 hours ago, hooovahh said:

I'm with you.  I just assumed it was a suggestion that LabVIEW will soon be seen, the same way COBAL is today.  Very little activity, and developers asking the void if there is any work for a thing they were an expert at not long ago.

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.

3 hours ago, Neil Pate said:

this sounds like the perfect use case for some low level OS API trickery

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.

4 hours ago, Neil Pate said:

Thanks everyone, I really appreciate the help. I will take a look over the weekend at the suggestions.

I haven't finished yet 

6 hours ago, dadreamer said:

@Neil Pate

As I can see, your pointer maths are okay, as long as you provide valid coordinates in Point 1 and Point 2 parameters. Thanks to @ShaunR it appears, that ArrayMemInfo has a bug, that's reproduced in 64-bit LabVIEW. I couldn't reproduce it in 32-bit LabVIEW though. The stride should not be zero, unless the array is empty, no matter if subarray or not. But even when the stride is 0, it shouldn't lead to crash, because in this case we're just writing into row 0 instead of intended one. To eliminate the bug influence (if any), you might not use the stride of ArrayMemInfo node, but use (Array Width x 4) instead as it's a constant in your case.

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.

Quote

for advanced LabVIEW developers and Architects (certified or self-proclaimed) 

 I like that.

4 hours ago, dadreamer said:

I got used to almost everything in modern LabVIEW, but these two are driving me nuts.

- "new styled" bright white splash screen and GSW (Getting Started Window) (since LV 2021 and up);

- online help in LabVIEW 2022 Q3 (and probably up?).

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

2 hours ago, dadreamer said:

Yes.

Also stays (and works) in RTE, when the VI is compiled. Also works if saved for previous down to LV 8.0. In fact LV 8.0 didn't have that token in its exe code, but the call remained inlined. LV 8.6 had that token, so confirmed it there as well.

 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. 

10 hours ago, dadreamer said:

I meant these ini tokens.

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? 

1 hour ago, dadreamer said:

You can squeeze some more time out of the MoveBlock without wrapper generation.

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"?

2 minutes ago, Rolf Kalbermatter said:

The comparison is however not entirely fair. MoveBlock does simply a memory move, Typecast does a Byte and Word Swap for every value in the array, so is doing considerably more work. That is also why Shaun had to add the extra block in the initialization to use another MoveBlock for the generation of the byte array to use in the MoveBlock call. If it would use the same initialized buffer the resulting values would look very weird (basuically all +- Inf).

But you can't simulate the Typecast by adding Swap Bytes and Swap Words to the double array. Those Swap primitives only work on integer values and for single precision and doubles it simply is a NOP. I would consider it almost a bug that Typecast does swapping for single and double precision values but the Swap Bytes and Swap Words do not. It doesn't seem entirely logical.

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.

1 hour ago, Neil Pate said:

@ShaunR you are missing a bit

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

48 minutes ago, Antoine Chalons said:

could you save back the VI to LV 2018 please?

Done.

17 hours ago, jacobson said:

I've seen a few RT applications that use move blocks over type casting as well. Obviously not very safe but it is fast.

I modified AQ's test to include moveblock so we can see.

array-typecast-benchmark.vi

24 minutes ago, Rolf Kalbermatter said:

The SO_EXCLUSIVEADDRUSE is in principle a good thing, you do not usually want someone else to be able to capture your port number.

Indeed....but!

Quote

 

A socket with SO_EXCLUSIVEADDRUSE set cannot always be reused immediately after socket closure. ...

Even after the socket is closed, the system must send all of the buffered data, transmit a graceful disconnect to the peer, and wait for a graceful disconnect from the peer. It is therefore possible that the underlying transport may never release the connection,

 

We are looking at a 0.1% case so it's things like this we have to bear in mind.

24 minutes ago, Rolf Kalbermatter said:

That about the Internecine Avoider is only true if you use the high level TCP Listener.vi.

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. 

2 hours ago, Rolf Kalbermatter said:

Technical details: the Wait on Listener basically does a select() (or possibly poll()) on the underlaying listener socket and this is the function that can fail if the socket library gets into a hiccup.

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?