12-19-2015 10:03 AM
Hi NI community
I am a labview novice, but have a computer that was running a big set of VIs whose HD failed and with a new computer and a backup I have to get it running again.
My issue is that despite back ups of the VIs, the NIDAQ-Mx 'tasks' (details of each input from my hardware) are no longer there or configured... All my programming is just drawing from nonexistant tasks....
Again, as a novice I have looked around, there are no project files with task info, there are no .nce, .ini or .txt task files either I think....
.... So my question is where are 'tasks' stored and in what sort of file format? There must exist somewhere in a non-project based VI.....
Perhaps that is a dumb question and I'll have to reconfigure everything....
Thanks,
Tom
12-19-2015 11:34 AM
12-19-2015 01:24 PM
.... So my question is where are 'tasks' stored and in what sort of file format? There must exist somewhere in a non-project based VI.....
Tasks are defined in MAX, and in the LabVIEW Project. MAX Tasks can be "exported" in a variety of formats (not all of which I've been able to "re-use", but it may be something I'm doing wrong). MAX also saves files in Windows' Program Data folder, but I'm uncertain how to "extract" their data (or even which files to investigate).
I'm not sure quite where Task information is stored in a Project file. I know I've created Tasks in the Project, and they are subtly different from Tasks that I create in MAX. However, I have a nagging suspicion that they are really MAX tasks "in disguise", so might be saved alongside Tasks that MAX creates. I'm not at work, with access to my LabVIEW devices, so I can't play around and test, but I'll try some experiments on Monday if noone gives a Definitive Answer sooner.
Bob Schor
12-19-2015 03:25 PM
12-19-2015 09:02 PM
My advice would be to proceed as follows:
Bob Schor
P.S. -- I did some searches and binary "exploring" into the files that MAX makes, including those that I suspect contain its internal settings. Unfortunately, most of the files I looked at were binary files -- I didn't really find much that appeared to be helpful in "reverse-engineering" a lost MAX. I suppose I could try making a new system and save "before-and-after" MAX folders to see what gets added when I create some new tasks, but right now I have too much on my plate ...
12-19-2015 09:31 PM
@Bob_Schor wrote:
P.S. -- I did some searches and binary "exploring" into the files that MAX makes, including those that I suspect contain its internal settings. Unfortunately, most of the files I looked at were binary files -- I didn't really find much that appeared to be helpful in "reverse-engineering" a lost MAX. I suppose I could try making a new system and save "before-and-after" MAX folders to see what gets added when I create some new tasks, but right now I have too much on my plate ...
I don't work too closely with this stuff but I actually called into NI support with this exact question a couple years back and was told I wouldn't be able to get the task information back.
I basically did what Bob mentioned above. Also make sure you remake any scales if you need to.
12-19-2015 10:51 PM
12-21-2015 10:00 AM
OK, so I've experimented and have the usual Good News/Bad News.
I started with a rather "clean" VM that had LabVIEW 2015 (32-bit), MAX 15.0, DAQmx drivers (a basic set), running on Windows 7 Pro x64. I saved the entire C:\ProgramData\National Instruments\MAX folder three times -- before I did anything, after I plugged in an NI USB-6009, and after I configured 4 Tasks for this device in MAX. I then compared the files and folders, and can say "what changed".
I created 4 tasks -- AI-0_1KHz, AO-1, DI-P0-L0, and DO-P0-L1.
The more interesting case is what changes between plugging in the USB-6009 (which causes it to appear in the "Hardware List" in MAX) and after the Tasks have been defined. Only 5 files show changes: config3.mx5, config3.mxd, config3.mxs, msxjar.ini, and mxsjar.mx5. Of these, only config3.mxd increased in size. but by only 34 bytes. Here are some more observations:
config3.mx5 is a 16-byte binary file that has no recognizable data. Perhaps it is a checksum.
config3.mxd is a text file that has the form of a .ini file. Section Names appear to be (meaningless-to-me) GUIDs. This is the file that "grew", with most (I didn't check every entry) of the growth being a change similar to the following:
neo66 = "{09D6A476-DE90-4503-A500-58F1B673AAFD},64,0" to
neo66 = "{09D6A476-DE90-4503-A500-58F1B673AAFD},64,2685".
Most of the entries in this file were "neo??????" entries of this form. There were a total of 10 entries with differences.
config.mxs appears to be a "mostly-binary" file, though one can find traces of Text embedded in it. In particular, if I examine this file with a Binary Editor, I can find my Task Names (e.g. "AI-0_1KHz") in this file, but the surrounding content is binary of unknown meaning. I'm pretty sure that this file is the MAX Configuration file (Windows also identifies it this way).
msxjar.ini is, no surprise, a .INI file, with a single change -- LastServerCookie = 229 (changed from 225 before the Tasks were defined).
msxjar.mx5 is another 16-byte binary file, also perhaps a checksum (no obvious pattern to the differences).
My conclusion from this Experiment is that it is pretty hopeless to reverse-engineer the MAX settings if you haven't exported them. However, if (after the disk crash) you can recover the MAX Data folder saved inside ProgramData, I'd bet it would recreate the MAX settings ...
Bob Schor
12-21-2015 10:14 AM
Wow, great investigating, and yes good and bad news!
Thanks for all your replies, I'll consider getting the HDD recovered if I cant define the tasks myself....
Perhaps this is something NI should move from being saved in these MAX files to the VI itself.
As an aside, when an executable is created from a VI, do tasks/channels saved then?
12-21-2015 10:35 AM
An Executable is yet another Binary File. If your LabVIEW code used a Task defined in MAX as a "Task Constant" or a "Channel Constant" (I use both of these), then those "Constants" will be compiled and be saved in whatever internal form NI uses inside the binary of the Executable. You still won't have easy access to them, however ...
Bob Schor
P.S. -- this gets me thinking -- I'm not planning to do this, but one could conceive of writing a Utility that would take a DAQmx Task/Channel line, run it through some Property and Invoke Nodes, and attempt to deduce all of the Configuration Information in that Wire, which it could then "export" to a Configuration File. Similarly, such a Configuration File could be used to construct the DAQmx Task/Channel Wire ...