Hi, yes, I agree it is likely impossible to solve remotely like this. I wish I was able to upload the whole project for someone else to be able to look at, but it doesn't seem like I can do that. But I am able to answer the questions you asked:
- LabView 2015 32 bit.
- The same version. (We have in the past tried to use this program in LabVIEW 2020 and the FPGA code within it would not compile so we are sticking to LabVIEW 2015 32 bit.)
- As a LabVIEW project.
- This program is perhaps 9-10 years old with major developments from ~5 people over the years (including one new addition by me a few years ago). None of those other 5 are particularly responsive any time I have asked for help in the past.
- I have the most LabVIEW expertise in my group currently.
The only other idea I have had since yesterday is that perhaps, because the space is running low on the computer (~6 GB remaining), that something funky is going on with saving the data (even though the data files are max ~1 MB). I've had experiences where things stop working properly like that when disk space gets low.
Copying here also the message I sent to NI technical support that has a lot more detail:
The main problem we are having: a VI is not saving/storing measured data as it should.
The VI is called: NET_Scan_Accel_41s.vi
The Project is called: FPGA computer connection_BDAs_modified_FPGA.lvproj
NOTE: We are running LabView 2015 (32 bit). We have found that the FPGA code involved in this VI does not compile in more recent versions, so updating is not an option.
Windows 10 Pro OS.
How this problem has evolved:
- As of Jan 9 2024: Program ran with zero errors or warnings and stored data properly. This is the last known time of running this VI without error.
- The next time we tried to run this program, Mar 14 2024:
- Upon opening, the VI had a Resolve Load Conflict window regarding a control (.ctl) file called "Bindary_data_save_typedef.ctl." I chose the path where the Project and control file are actually stored. The VI opens and I get a Load and Save Warning List, warning me again that "Dependency loaded from new path (1 warning affecting 25 callers)." All of these callers are subVIs called things along the lines of "Binary_data_save_subvi_blahblahblah." Which I’m guessing is important because the problem we’re seeing is about the data being saved.
- However, I was able to copy a back-up of the project we had saved on an external hard drive into a new directory, and the VI opened without the warnings, ran, and successfully stored the data! So it seemed like a good temporary fix.
- Now, the next time to run this program since March, it is now April 5 2024:
- Both the original and the back-up projects are not storing data properly.
- What I have tried today:
- Copied the back-up to a new directory again. Problem persists.
- Found the ctl file in the Project Explorer, right clicked and selected Resolve Conflict, which seemed to update the affected callers to look in the new dependency path. So now when I open the VI, I don't get the Resolve Load Conflict or Load and Save Warning List, but the VI still does not successfully save the data. Problem persists.
- Tried running another VI in the project called “NET_Scan_Accel_20s.vi”, which is the predecessor to the one we want to run. This VI has the same problem.
- Tried recompiling the FPGA code. Problem persists.
- Tried shutting down the computer and restarting. Problem persists. Additionally, upon restart, we get some additional errors:
- “Unable to locate the LabVIEW Run-Time Engine. VIPM Service requires a version 2019 (or compatible) LabVIEW Run-Time Engine.”
- According to NI MAX we already have Run-Time 2012 SP1 f9, 2014 SP1 f11, 2015 f3, 2015 f3 (64-bit), and 2019 f2 (64-bit) installed. I don’t even think the LabView 2015 (32-bit) version we are using is compatible with these newer Runtimes…
- I went ahead and installed JKI VIPM (2024 Q1) which came with Runtime 2023 Q3 (64-bit).
- Now that error no longer occurs upon computer boot up.
- The first time the VI is run after reboot, it loads for a while and then gives the error: “Error 1 occurred at Wait on Notification in NET_Scan_Accel_41s.vi. Possible reason(s): (1) LabVIEW: An input parameter is invalid. (2) NI-488: Command requires GPIB Controller to be Controller-In-Charge.”
- I have yet to troubleshoot this error, the reason being that when this error occurs and I select “Stop” and then press Run on the VI again, it runs.
I am at a loss for which of these errors is the true source of the issue with storing the data, nevermind why these errors have suddenly appeared between Jan 9 and Mar 14. Between Jan 9 and Mar 14, nothing was done that would seemingly disturb this program. Other Vis in the project were used without error during this time. The only other thing happening with this computer was a full metal back-up was made, involving uninstalling and reinstalling some security software.
Some more detail about what I mean by “not storing data properly”:
When the VI is working, it creates a new folder in a directory according to today’s date and creates binary files called “phd#.bin” named with incrementing numbers. These binary files are then imported into MatLab with a custom script and the output is 50 fields of data. For example, the VI calculates the velocity of a particle through a detector, so one of these fields is an array containing the velocity of every particle measured.
What is currently happening: the new folder is created successfully, as is the binary file “phd#.bin.” But when we import the data into MatLab, the output is (almost) empty. We know it is not the import function because the function still works on data collected on Jan 9 and earlier. So for some reason, the data is not being written to the binary file. I said “almost” because the file isn’t entirely empty:
- The first field in a “phd” file is called “Start_time.” Normally this is a small array (say, containing less than 20 values). In the error scenario, the field “Start_time” exists but it contains thousands of values.
- The second field in a phd file is called “Start_timestamp.” Normally this is a single value. In the error scenario, the field “Start_timestamp” exists but it is empty.
- No other fields were written to the binary phd file.
I understand that this aspect of the problem is difficult to troubleshoot without access to the project.
