Rolf Kalbermatter

On 11/5/2023 at 4:15 PM, Neon_Light said:

This might be a little bit of-topic but I think you also use Matlab code in  Labview? I see a lot of files with the name Mathscript is this the software needed to use Matlab ? or is it something completely different ?

MathScript was the mathematic node that used to be NI's attempt to make a Matlab clone. It sort of worked similar to Matlab and could execute Matlab scripts to some extend. But it was of course never a full replacement for Matlab and NI eventually stopped pursuing MathScript any further. Since LabVIEW 2023 MathScript has been removed from LabVIEW. NI recommends to use Matlab now to implement those scripts https://www.ni.com/docs/en-US/bundle/daqexpress/page/migrate-to-interface-for-matlab.html

The 5 and 10 volume license give you some discount. But it still adds up. And the real volume licenses for large sites are indeed relatively cheap for what you get but I doubt your company is willing to shelf out 50k or more even if it allows them to have 500 licenses to be used. 😀

10 minutes ago, Neon_Light said:

Can you even get a maintenance support contract on old versions? Or can you only get it on the new versions where you need to pay every year?

No you can't anymore. NI added subscription licenses in November or December of 2021 to the order system, and discontinued perpetual development licenses on January 1, 2022.

After that date they did officially not sell any non-subscription licenses anymore. For a little while you could try to appease a sales representative and if you were good and did it long enough, they could still put an order for a perpetual license into the system, but I'm pretty sure that possibility has long been removed since.

You could buy a subscription for one year. It gives you the right to download older versions too. If you use the old serial number, it will allow to use the old installation up to the point your maintenance contract expired. If you use the new serial number that comes with the subscription purchase, you can run old versions for as long as your subscription is valid.

49 minutes ago, Ronin7 said:

As far as accusing someone of not doing all of their job if they did not predict that NI would totally shift paradigms as far as LabVIEW licensing and marketing, well then 99% of their user base is guilty of the same...

You won't like it but you could never officially download software from the NI site other than the latest version to use as evaluation download without a maintenance support contract. If you were not logged in with an account that had a current maintenance support contract associated, selection of previous versions were blocked from the Download website ever since that Download page got active.

And NI never ever guaranteed anywhere that you could keep downloading software as far back as you liked. Not even with a maintenance support contract or nowadays a subscription. Even if you pay for it, it is a service that is delivered as is, without any guarantees that you can continue to download older version (for instance LabVIEW 7.1, just to name one very old version) which you indeed can't and never will be able to download anywhere officially.

So if you build a system that requires a specific version for whatever reason and don't archive all and every piece of that system somewhere, the problem is definitely up your sleeve and always has been.

As for charging a 100 dollar fee to download software, that may sound an interesting option. But unfortunately companies of the size of NI nowadays will not even lift a telephone of the hook for that amount. Why? Until the order is booked, payment processed, accounting had its pee over the transaction, shipment (or access to the file organized), the whole thing has cost many times more than those 100 bucks.

So you expect Microsoft to let you download Visual Studio 2005 (or 2008, 2010, 2013, 2015) for free because you have somewhere a Windows XP machine running that runs a very expensive experiment where the hardware drivers don't support anything newer?

Bad luck for you but that is not an option (unless you want to resort to bogus download sites where you have to search for the right download button among a few dozen others trying to get scareware or worse onto your system, and/or the download itself is bogus or even malware invested).

You can buy a Microsoft Visual Studio Professional subscription however for ~1500 bucks a year and then you can actually download (most) of them.

Or you can of course download these packages when you have the license to access them and then safely archive the installer somewhere.

If you build such a specialist system and don't plan for having to sometimes in the future reinstall the whole stuff again (on new hardware or after a fatal crash) you only did part of the job for that project!

That works for LabVIEW (and many other software) the same, if there is even a possibility to download older versions!

1 hour ago, MikaelH said:

Also try running the DLL in any thread.
That will probably speed up the execution >100 times, but if the DLL is not thread safe you might get crashes.

That is a tricky recommendation, as you explain too. Unless it is documented that the DLL or particular function is thread safe, I would normally refrain from calling the function in any thread.

Also your claimed speed improvement is very off, especially in this case. The main time loss is when the LabVIEW program has to wait for the UI thread to be available for calling the CLN. This is at worst in the order of a few ms, typically even significantly below 1 ms. Compared to the runtime of these functions, which for the capture does a GDI bitmap copy and some extra shuffling to only get out the actual pixel data and for the MoveBlock(), which does a memory copy of a significant size, this delay of arbitrating for the UI thread is pretty small. It's likely measurable with the high resolution timer, but do you really care if this VI takes 25 ms to execute or 26 ms?

Reentrant execution of a CLN gets really interesting performance wise when you have a short running function which is called over and over again in a loop. Here the overhead of arbitrating each time for the UI thread will be significant and can get even the single most dominating factor in the execution speed.

There is one other aspect about not wanting to run a CLN in the UI thread. While LabVIEW is busy executing the CLN in the UI thread, this thread is not available to do anything else, including drawing anything on the screen and processing Windows events such as mouse and keyboard events. If the CLN takes a long time to execute (many 100 ms to seconds) the LabVIEW application will appear to be frozen during the call to this CLN (and in the worst case Windows will notice after several seconds that the event loop isn't polled for a long time and provide the user with a dialog suggesting that the application is unresponsive and should probably be shut down).

20 hours ago, mooner said:

Thank you very much for your reply. After your guidance, I re-learned the use of "MoveBlock" and found that this function is indeed a very powerful thing, and I have solved my problem by using it so far. Attached is a screenshot of my code, thanks again!

 

What does the documentation say about the pointer returned by the function? Is it allocated by the function? Is it a static buffer that is always the same (very unlikely)?

If it is allocated by the function, you will need to deallocate it after use (after the MoveBlock() function), and the documentation should state what memory manager function was used to allocate the buffer and what memory manager function you should use to deallocate it, otherwise you create a memory leak every time you call this function.

Ideally the DLL exports a function that will deallocate the buffer, still a usable solution is if they use the Windows GlobalAlloc() function to create the buffer in which case you would need to call GlobalFree(). Pretty bad would be if they use malloc(). This is because the malloc() call that the DLL does might be linking to a different version of the C runtime library than the according free() you will try to call in LabVIEW, and that is a sure way to create trouble.

1 hour ago, Lucky--Luka said:

Could you explain to me what have you done please?

Right click on a string control (or constant) and select "Visible Items->Display Style". The control gets an extra glyph which is marked with the red rectangle in the image of Mikael. This indicates what display mode the control uses.

Note that this changes ABSOLUTELY nothing about the actual bytes used in the string. It only changes how the control displays them!

1 hour ago, codcoder said:

I've always found it contradictory that LabVIEW itself, which relies so heavily on GUI, has such a limited selection of provided icons and buttons.

Especially those useful for electronic testing and similar purposes: remixicon.com contains over 2000 icons, but the word 'electronic' yields no results. Additionally, the word 'test' yields only one result, an icon for A/B testing primarily used in software testing.

NI: why you do this?

Icons are the resource sink of many development teams. 😀

Everybody has their own ideas what a good icon should be, their preferred style, color, flavor, emotional ring and what else. And LabVIEW actually has a fairly extensive icon library in the icon editor since many moons.

You can't find your preferred icon in there? Of course not, even if it had a few 10000 you would be bound to not find it, because:

1) Nothing in there suits your current mood

2) You can't find it among the whole forest of trees

Well, I have done a few minor updates to the library to fix a few minor problems with newer Windows systems. It's still active and used by some customers. What do you want to know about it?

52 minutes ago, Mads said:

The link only points to Jordan's profile, but he might have been involved back then yes...

Oops, sorry! 😀 But you found it already. 👍

8 minutes ago, Mads said:

I had noted a simple recipe earlier from here somewhere for manually installing lvzlib.so (OpenGZip 4.2beta) on Linux RT 2020 and newer now that the "Custom Install" option no longer exists / works in NI Max, but I seem to have lost it and cannot find it again. 

Do anyone know where that discussion was, or has the recipe? 

Where you refering to this?

https://lavag.org/profile/19157-jordan-kuehn/

5 hours ago, Porter said:

Unfortunately as soon as I build vipm package, the *s get replaced with 32 and dll. So when I open the vis on x64 labview, they are pointing to the wrong dll.

My solution is link the CLFNs to libmuparser-lv.dll and have a post-install vi copy the appropriate version of the shared library to that filename. I know it looks weird to see a dll in linux, but it doesn't seem to break anything. 

I would consider that a bug in VIPM. It should not rename the DLL and linkage name in the VI in this case or at least offer an option to disable-that. But your solution with the Post Install works and is what I always do. VIPM always lacked a few features to properly handle 32-bit and 64-bit binaries. I haven’t checked in the latest version but there was no way to distinguish files to be only installed for 32-bit or 64-bit only and even if the latest version would support that I’m hesitant to use it as VIPM tends to create packages that won’t be installable by older versions of it.

3 hours ago, Porter said:

I tried the .\libmuparser-x*-lv.* trick for the CLFN path but when I build a VIPM package, it converts it to libmuparser-x32-lv.dll because I am building on LV 32-bit, Windows. So then the VIs are broken on 64 bit and Linux. If I can preserve the wildcards in the CLFN path it would be ideal.

Here is my latest attempt. Statically linking to libmuparser-lv.dll but located in the vi.lib next to mupLib.lvlib: lv_muparser-2.2.0.6.vip

A star before the file ending is translated to 32 resp 64, a star for the file ending is translated to the respective platform specific shared library file ending.

Is your shared library name different between bitnesses? Otherwise you do not need a star at all before the file ending.

2 hours ago, Porter said:

Give this a try: lv_muparser-2.2.0.4.vip

It worked with LV2020 x32 and x64, Windows.

In Linux I had to manually copy the .so file to libmuparser-lv.dll. Permission issues with the installer of course. I think that Labview needs to be run as root during the install but my community edition was activated under my user account. After doing that manual copy it worked fine though.

All CLFNs are statically linked to "<resource>\libmuparser-lv.dll"

If you make that libmuparser-lv.* you can leave the default file ending for the shared libraries. .dll for Windows, .so for Linux and .framework or .dylib for Mac OS.

And you don’t rename the default name of libraries under Linux but typically create a symlink with whatever non-versioned name you need.

3 hours ago, Andy75 said:

OK, thank you for the hint. I'll try it on Monday. Since my experiance it is unusual to place a DLL beside to the exe file and not within the support folder of the application. Is there a special reason why you did it this way?

It’s actually how Microsoft wants DLLs distributed with an application unless it is installed directly into the system (or GAC for .Net assemblies). For DLLs that get directly referenced by LabVIEW VIs it is not important as the application builder adjusts the path to whatever relative directory you told it to move the DLL but for other DLLs that LabVIEW and/or the application builder doesn’t know about it is important to place the DLL in a standard Windows searched location.

On 8/18/2023 at 9:55 PM, Reds said:

The NI P&L statement has a revenue line item called "Software Maintenance" at about $37mm per quarter. It's trending downward. Does any know if LabVIEW revenue is included in this P&L line item? What other things might be in this bucket besides LabVIEW?

NI System Link, NI TestStand, NI Measurement Link, NI MultiSim/Ultiboard (barely) , NI LabWindows/CVI (pretty much not anymore), MATRIXx (not sure they still sell that other than to legacy customers), Diadem (not actively sold anymore), and a few others that they have stopped working on.

Other than LabVIEW, TestStand and System Link, NI has pretty much stopped any other software development, so part of the down turn is likely that sales from those other software is dwindling as existing customers jump the boat and no new customers are boarding for them.

There is no simple fix to that. In order to draw anything on a Windows GUI you do need GDI objects. Every Window is one, every subwindow, every icon or bimap is one, every line or arc could be one, every text can be even two or three. You can open them, draw them to the device context and close them afterwards but opening/creating them costs time so if you foresee to use them again it’s a pretty smart idea to keep them around instead of spending most of your program execution time in creating and destroying them continuously.

The only thing LabVIEW programmers can do is to try to combine more operations into a single object and/or finding the objects that are rarely needed and pay the runtime performance penalty to recreate them each time instead of keeping them around. Also I’m pretty sure that 3D controls with alpha shading may look cool to some people but tend to increase the GDI object count substantially. Classic and Dialog controls are a lot easier to draw!

9 hours ago, ShaunR said:

I'm surprised it works at all tbh.

The Intialise is in side the while loop but the close is outside. Either move the initialise to outside the loop or the close to the inside.

You start to read when there are greater than 0 bytes (1 or more), but you want 23 bytes. Either accumulate bytes as they come in until you have 23 and then decode into the numerics and strings or wait until there are 23 bytes at the serial port (rather than greater than zero) then decode.

See how far those changes get you.

And the Scan From String does a greedy pattern match, this means the first %s will eat the entire string as any character matches %s and then there is nothing left for the other 7 %s to process => error 85 as the Scan from String can't satisfy the second %s.

If you have a space as separation character as it seems you have from the format you show you should rather use following Scan From String format string

%[^\s]\s%[^\s]\s%[^\s]\s%[^\s]\s%[^\s]\s%[^\s]\s%[^\s]\s%[^\s]

For this you should also right click on the string constant and enable '\' Codes Display

The format string basically says, take every character until you see a space and put this in the first output parameter, then take the space and repeat this for the remaining 7 output strings.

Possibly 23 character could also mean that each substring consists of exactly 2 characters plus the 7 separation characters. If so you could also use:

%2s\s%2s\s%2s\s%2s\s%2s\s%2s\s%2s\s%2s

You’re saying that an event registration terminal should behave like a tunnel?

They are not the same thing as the name already says (and the symbol shows)! It’s also more like a shift register although the right side of a shift register can’t be unwired.

And the behavior makes sense. For tunnels it can be a pitta to have to wire each output but it’s also desirable that it can be easily “reset”. And that behaviour was defined ca. 1986! For event registrations it is almost never needed to connect the right side terminal (I did that maybe once or twice in my entire LabVIEW programming). Alternative would have been to make only a terminal on the left side but then you couldn’t dynamically register an event.

Inconsistent? Maybe if you take a puritan look, ,useful? Definitely!

And I can assure you the LabVIEW team debated over this probably several weeks if not months before deciding on the current solution. 

The only improvement I could think of nowadays is to allow to hide the right side terminals!

59 minutes ago, ShaunR said:

It is indeed. But it doesn't have to be They could have decided it should behave like Queue's and an Event Reg merely creates a reference to the internal queue. IMO, Darren's nugget is a side effect of an implementation peculiarity (which you have explained in exquisite detail) rather than a philosophical design - a peculiarity I hope never changes  .

That would be a management nightmare. There would be no possibility to handle more than one event registration to subscribe to the same even generator without very involved buffer management. By placing the event queue into the event registration object it is fairly simple.

1) Hey here is my event queue, post any event you get to it.

2) I only have to check that queue to see if there is any event to handle. Not some other queue that might or not might have events present that I already processed but need to remain in it because not all event registrations have yet gotten to read that event.

There is a relatively cheap check needed in the event generator to see if the event registration queue is still valid before trying to post a new event to it but that’s much easier than turning the single.queue into a pseudo random access buffer for use with multiple registrations.

Similarly the event registration needs to check that the event generator is still valid when trying to deregister itself from it on its own destruction but that’s again a fairly simple Is Not an Object/Refnum check.

2 hours ago, ShaunR said:

Oh I don't know. They could delete the registration queues of any registration that referenced the event that was destroyed - they have to delete the registration queue at some point, right?. Luckily, that hierarchy isn't implemented and hopefully it would be too tiresome to implement.

That would make little sense. That event queue is owned by the registration refnum, and the registration refnum registers simply a callback in the event object. The event is able to have multiple callbacks registered as it "queues" them up internally. That's what makes it possible to have multiple registration refnums connected to the same event object.

That makes resource management fairly easy, avoids polling and objects owning other objects. Once the event goes away it simply will stop posting any events to the registered callback (it forgets about the callback since it is non-existent). The event queue in the event registration object still exists until that event registration object itself is destroyed. And if you close the event registration refnum earlier it simply deregisters itself from the event.

It's not a bug and there is nothing that could be fixed here.

The user event is not the same as the event registration!

The user event is an event object that manages events in an internal FIFO queue to pass the event over to the event wait node AND/OR to any number of attached event registration handlers.

When it is registered with the register node, a new independent object is created that contains its own event queue and that event registration is then connected to the event with an event registration handler that simply passes the event to this queue in addition to the internal event queue. Once the event is gone, all the events that are stored in the internal queue of the event are of course gone, but the events also were passed to the queue of every attached event registration queue. That queue remains valid until the event registration refnum is closed itself.

The event registration is special as it can attach to any object that can expose an event interface, such as ActiveX objects, or .Net classes too (if they have defined events). Also LabVIEW front panel objects actually can provide an event interface and their refnum can be connected to a Register Event node.

crossrulz is very correct. VISA only supports TCP/IP and that in two flavors. The first with the ::INSTR postfix is according to the VXI-11 standard that provides a resource discovery service (ala Bonjour) on the device that allows NI Max to query for connected devices and query their specific settings. The second variant uses the ::SOCKET postfix and is raw TCP/IP communication. The resource specifier needs in that case also a port number in addition to the IPv4 device address.

UDP communication in LabVIEW is only possible with the UDP native nodes in LabVIEW. No NI-MAX will be getting harmed nor in any other way getting involved in this!