OK, I have Good News and Bad News. I opened one of the Multy_Scan_Script VIs, guessing these were at or near the Top Level. I noticed that you had a lot of .LLB files that looked like you might have thought you could pull in Driver and other Support Files (instead of loading them when installing a version of LabVIEW with its Drivers) -- my hope was that if your code was really in LabVIEW 8.5, that might be "close enough" to current versions of LabVIEW that I might be able to at least partly open it on my PC.
Instead, I got a series of messages saying that LabVIEW was searching for legacy DAQ routines in the LabVIEW 7.0 folder. Oops, NI DAQmx replaced Legacy DAQ in 2003!
I can see two possibilities for resurrecting this old code and re-establishing its functionality. One way would be to re-create the original Development Environment, which I will assume is LabVIEW 8.5 (which still can support Legacy DAQ, though NI, and I, strongly recommend migrating to DAQmx). To do this, I suggest the following steps:
- Obtain an older computer, manufactured no later than 2010, earlier if possible.
- Install Windows XP (32-bit).
- Install LabVIEW 8.5. Reboot.
- Install any additional Toolboxes or Modules you will need (the fewer, the better). Reboot.
- Install Legacy DAQ, MAX, and any Drivers you will need (the fewer, the better). Reboot.
Note that this machine should not be connected to a network, as it lacks security from attacks and updates are no longer possible.
With this replication of the original Development machine, but with a clean installation of LabVIEW, you should be able to open the code that you have and get most of the VIs to load. You will (probably) not need (and not want) the numerous mis-placed DLLs that are present in your ZIP file, which belong in the National Instruments "Program Files" Folder where the Driver files are stored.
A much better alternative, especially if you want to many any changes or improvements to this legacy code, is to build a "modern" LabVIEW Development System and "re-Develop" the application. This may seem like a much more difficult task, but having done this myself several times, the result was a huge improvement over the original code, running faster, with fewer errors, and being much easier to develop, debug, and maintain.
If you choose this route, here are the steps I'd suggest:
- Start with a modern (no older than 2 years) PC, running Windows 10 Pro, 64-bit.
- Install Full or Professional LabVIEW 2016 or 2018, 32-bit. Install the minimum set of Toolkits and Modules that you will need. Reboot and install the minimum set of Drivers that you will need. Of course, install DAQmx.
Now you need to design your Project. I definitely recommend putting your "project" inside a LabVIEW Project to help you keep track of the various pieces of code that your project requires. Here are some things that you should strive to attain:
- The Top Level VI should utilize a State Machine, Queued Message Handler, or some other Design Pattern suited to providing Control and Information to the Operator of the Task at hand.
- All VIs should adhere to the following principles:
- Every Sub-VI should "Do One Thing, Thoroughly and Well". A corollary of this is that every Block Diagram should fit on a single Laptop Screen (if this seems impossible, then you are doing "too much" inside the sub-VI -- hand sub-tasks off to sub-VIs inside the sub-VI, as a sub-VI takes only 32x32 pixel on the Block Diagram).
- Every Sub-VI should use the 4-2-2-4 Connector Pattern, with Error In and Error Out at the lower outside connectors.
- Every Sub-VI should have an Icon, if only a Square with 3 short lines of text, for identification.
- Every Sub-VI should have a Description, at least identifying its Inputs and Outputs.
- Coding works best with a team, even if its only one person doing the LabVIEW coding, and another person who understands the Task being accomplished. The team should write the Description of the Program (what it is supposed to do, what hardware it needs to use, what inputs and outputs are required, etc.) and as development continues, the Team should revise the document as needed. If only one person on the Team knows LabVIEW (or C++, or whatever you are using to write the code), then that person needs to at least "walk through" the code, explaining what is happening, and making sure the rest of the team sees the point. Note that if you have adhered to the "one-screen Block Diagram" by utilizing sub-VIs that do "one thing", you have effectively "buried the details" and can concentrate on the Big Picture.
- An advantage of having nested sub-VIs that "do one thing" is it becomes much easier to test that they actually work. Example: Write data to a binary file having a file name of <Year>-<Month>-<Day>-<Hour>-<Minute>-<Subject>.bin (an example would be 2018-07-28-14-03-Bob.bin). You definitely want a sub-VI, "Make File Name", that takes a string, "Subject", and returns a Filename, "Filename". Your sub-VI, of course, also has Error In and Error Out. Code it. Test it. It should be easy to tell if it works. Now use it wherever you need to make file names. [Note -- please do not use such awful file names -- I just included this pattern here as it is an easy example of "hiding the details"].
Bob Schor
