LogMAN

Something like that. The actual implementation takes several factors into account, for example, how frequently a file is accessed. Also, your disk has its own cache on top of that. If you have a virus scanner running, it might lock the file for processing. I believe the Set File Size function is to blame for that. By changing the file size to zero, the file is effectively cleared. The write function after that is cached and never gets flushed to disk because of power failure, which leaves the file empty after reboot. I'm not sure why it was implemented this way. The following will produce the same result without this issue:

Mine are between 1-3 levels

Did you try disabling buffering as mentioned in my last post (2)? What do you mean by that? 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.

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.

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. 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

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 🙂

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. 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 🤔

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.

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

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

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 Of course, if you let your SSP expire and are later forced to upgrade, than you have to pay the full price...

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

Powered by LabVIEW NXG 😋

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...

No subscription = no money = no support I believe this is the case for most software products.

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