LogMAN

Mine are between 1-3 levels

43 minutes ago, Francois Aujard said:

Last night before shutting down the machine I looked at the resource monitor and surprise, all my files are in memory (see picture)

Did you try disabling buffering as mentioned in my last post (2)?

15 hours ago, LogMAN said:

30 minutes ago, Francois Aujard said:

I changed my call from Vi to dynamic

What do you mean by that?

31 minutes ago, Francois Aujard said:

I have seen that there is a memory management vi, do you think it will help me?

I don't think it makes a difference.

If you dynamically call VIs using 'Call and collect' or 'Call and forget', then the 'Request Deallocation' function could free up memory earlier.

That said, it is mostly useful when you work with large amounts of data.

3 hours ago, Francois Aujard said:

One interesting thing, I have another parameter file that uses the config data Vi. This one I run by dynamic call and close it at the end and the call reference and I have no problem with this file. The vi that crashes and that I sent is inserted in my code, at the beginning, but it is not called dynamically. Is it a coincidence that this one crashes and not the other one called dynamically?

Are both files accessed at the same rate?

I'd assume that the one you call more often is more likely to fail.

---

Edit: It appears that the configuration file VIs clear the file size before they write new content. If your computer crashes at this moment, it will result in an empty file:

Here is what could happen:

To prevent this issue, try this:

1 - Use 'replace or create' instead of 'open'

2 - Disable buffering (this will directly write to disk without caching)

3 - Remove 'Set File Size' function

Warning: This VI is installed with LabVIEW, so changing it will affect any project on your computer!

Alternatively, it is also possible to just write the string to disk without opening the file explicitly. However, in this case caching will be used.

2 hours ago, Francois Aujard said:

I will read the link you past in your last message https://learn.microsoft.com/en-us/windows/win32/fileio/file-caching and try to understand the text. I am not very good at english...

Mise en cache des fichiers - Win32 apps | Microsoft Learn

In that case, perhaps you can improve your error message with functions from the General Error Handler VI. It should allow you to achieve what you want.

Another idea is to add images for well-known errors (file not found, error 1172, etc.). It helps users recognize issues they encountered before (and perhaps learned to fix on their own). Here is a complete example I just put together (it uses a picture ring for the image):

Error Dialog.vi

It depends on the kind of error.

If the error can be fixed by the user, we typically guide them through the process. In this case the error is handled as part of the regular operation cycle that we designed with the customer.

If the error cannot (or should not) be fixed the user, then we typically block the process and wait for authorization by a supervisor. These are errors that we anticipated in the design, but whose root cause is not clear (i.e., failure to connect to hardware).

Finally, if the error does not fall into the first two categories, we dump them in a log file and fail the operation with a simple error message like "An unhandled error occurred. Report this issue to your supervisor.". These errors often indicate a bug or a flaw in the original design.

Does the issue also occur during normal operation or only during a power failure?

If the files get cleared during normal operation, then there is probably a bug in your software. Otherwise, fix the power failure.

1 hour ago, Francois Aujard said:

I use the write condition only when I do a calibration of my sensors, and I was not in this case. And I never write 20 files in the same times... It's very strange...

Even if you do not intend to write data to disk, the configuration file VIs use an internal "dirty" flag to determine when data should be written to disk. This "dirty" flag is set to true during write operations. You can prevent it from writing any data using the optional input, but that input is not wired in your VI. This flag may get corrupted during power failure, causing it to write garbage data to disk.

Then there is also file caching from the operating system which could play a role in this: https://learn.microsoft.com/en-us/windows/win32/fileio/file-caching

Quote

By default, Windows caches file data that is read from disks and written to disks. This implies that read operations read file data from an area in system memory known as the system file cache, rather than from the physical disk. Correspondingly, write operations write file data to the system file cache rather than to the disk, and this type of cache is referred to as a write-back cache.

This can happen when the computer turns off while it writes data to disk.

I've had the same issue recently, which was caused by broken power supplies. Fortunately, we do automatic backups of all configurations, so it was an easy fix.

Other than that, I don't think there is much you can do about it. A UPS might be a good idea.

Done 🙂

7 minutes ago, Connor.Prior said:

does anything about the code change when you copy it to a new location?

It depends. Sources files link to each other using relative paths, except for items in well-known locations (vi.lib, user.lib, instr.lib, etc.), which are referenced relative to their well-known location. As long as you don't change the relative location of files, nothing changes.

12 minutes ago, Connor.Prior said:

I copied my directory to a new location to run some tests, but when I opened the project, I noticed several typedefs showing up as missing in the dependencies. They were all typedefs that I had recently deleted, but they weren't showing up as missing in the main project. In addition, when I clicked "why is this item in dependencies?" and found the offending VIs & typedefs, the dependencies were cleared as soon as I opened them, before I even resaved them to clear the changes. However, I found if I closed and re-opened the copied project the dependencies would reappear if I didn't re-save the VI the first time.

This is a side-effect of how the dependency tree is generated. Instead of re-computing linkage information, LabVIEW relies on linkage information that is stored in a VI. So, if you change a typedef and don't apply (and save) all its callers, then the callers will have outdated type information, which can result in "ghost" dependencies. Clearing the compiled object cache and mass-compiling your project should generally fix these issues.

There are some exceptions where this doesn't work but let's just hope it doesn't apply here 🙂

It appears to be working when unchecking the "Remove unused polymorphic VI instances" option in the build specification. Not sure why because the library does not seem to include any polymorphic VIs 🤔

33 minutes ago, Connor.Prior said:

When you say it might exceed the max length during the build, do you mean the build is the only time that limit is checked, or do you mean the paths may get longer during the build?

The latter. Just like @hooovahh explained, the files are copied to a temporary location which can result in longer paths.

The output directory for your application determines the location of the temporary folder, which is actually just the name of the executable as a folder (i.e. "Application.exe" but it's a folder).

EDIT: Regarding vi.lib, these files also reside inside the "Application.exe" folder. Here is an example for JSONtext:
"C:\Code\Repository\builds\Untitled Project 1\My Application\Application.exe\1abvi3w\vi.lib\JDP Science\JSONtext\LVClass Serializer"

Here is an example of what it looks like during build.

16 hours ago, Connor.Prior said:

Error 1 occurred at An error occurred while saving the following file:

C:\Program Files (x86)\National Instruments\LabVIEW 2019\vi.lib\registry\registry.llb\Registry refnum.ctl

Click the link below to visit the Application Builder support page. Use the following information as a reference:

Error 42 occurred at AB_Source_VI.lvclass:Close_Reference.vi -> AB_Build.lvclass:Save.vi

Possible reason(s):

LabVIEW: (Hex 0x2A) Generic error.

Possible reason(s):

LabVIEW: (Hex 0x1) An input parameter is invalid. For example if the input is a path, the path might contain a character not allowed by the OS such as ? or @.

=======

Command requires GPIB Controller to be Controller-In-Charge.

This error happens when one of the files exceeds the maximum path length of 256 characters on Windows. While the file path can be short enough in your source repository, it might exceed the maximum path length during build.

Find attached a VI that extracts the longest path in a folder. Point it to the working directory of your project and see how long the longest path is.

Find Longest Path.vi

2 hours ago, Krishna16 said:

Can you please tell me Is there any legal problem for  use oglib_error v2.0-1  as it is LGPL License Type?

This is not the right place to ask for legal advice. You should read the license terms and check with your legal department.

Here is a link to the full license text for version 2.1 of the license: GNU Lesser General Public License v2.1 | Choose a License

4 hours ago, MartinP said:

I recomend all other LabVIEW programmers to do the same.

To what end?

NI will never go back to perpetual licenses, no matter how many offers we reject.

Mainstream support for LabVIEW 2021 ends in August 2025, which means no driver support, no updates, and no bug fixes.  By then you should have a long-term strategy and either pay for subscriptions or stop using LabVIEW.

As a side note, if you own a perpetual license you can get up to 3 years of subscription for the price of your current SSP. This should give you enough time to figure out your long-term strategy and convince management  

Quote

What will happen if I currently own a perpetual software license when my SSP renewal is up? 

We will quote you for a subscription license of your software at a one-time price that is the same as your SSP renewal quote would have been. You can pre-purchase up to a three-year subscription term at that per-year rate. This one-time price is available whenever your SSP renewal expires. For example, if you purchased software in 2021 with 3 years of SSP, the one-time price will be available to you in 2024.

-- https://www.ni.com/en-us/landing/subscription-software.html

Of course, if you let your SSP expire and are later forced to upgrade, than you have to pay the full price...

17 hours ago, Dpeter said:

It seems that you can not just insert a class into a library.

You cannot directly create PPLs from classes. Instead, put the class inside a project library to create a PPL.

20 hours ago, alvise said:

When I run the "Preview Demo" example built with C# that comes with the SDK, it seems to increase memory usage, is this normal?

22 hours ago, alvise said:

When running -VI, memory usage sometimes goes up and down. For example: 178.3MB to 182.3MB then be 178.3MB again.

In C#/.NET, memory usage can fluctuate because of garbage collection. Objects that aren't used anymore can stay in memory until the garbage collector releases them.

https://docs.microsoft.com/en-us/dotnet/standard/garbage-collection/

This could explain why your memory usage goes up and down.

There is a way to invoke the garbage collector explicitly by calling GC.Collect(). This will cause the garbage collector to release unused objects.

Don't tell him about Excel...

14 minutes ago, crossrulz said:

Yeah, but this is still a major support hole.

No subscription = no money = no support

I believe this is the case for most software products.

9 minutes ago, FixedWire said:

Now this is fun...anybody else tried to download a old version of LV that was used to develop  projects and noticed that you can't actually download it any longer?

You need an active subscription to download previous versions. This has been the case for many years.

Quote

Previous versions are available only to customers with an active standard service program (SSP) membership.

Welcome to LAVA @jorgecat 🏆

As a matter of fact, there can be two files depending when you installed NIPM for the first time.

• \%programdata%\National Instruments\NI Package Manager\Packages\nipkg.ini
• \%localappdata%\National Instruments\NI Package Manager\nipkg.ini

According to this article, the location changed from %programdata% to %localappdata% in later versions of NIPM but both locations are still supported.

Quote

The INI file for the feed has changed, but the software still references the old INI file. If you have an nipkg.ini file inside C:\Program Files\National Instruments\NI Package Manager\Settings, delete this file.