LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

"task location"

 

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

0 Kudos
Message 1 of 14
(5,909 Views)
The task definitions are stored internally in MAX. Unless someone thought to export and backup the task definitions, they are gone.

Is the old HD completely toast?

Mike...

Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion

"... after all, He's not a tame lion..."

For help with grief and grieving.
0 Kudos
Message 2 of 14
(5,888 Views)

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

 

 

0 Kudos
Message 3 of 14
(5,869 Views)
Unfortunately yes the HD had a head crash. I could try and get a head swap done but doubt how much useful would come put of it....

So if the tasks are in Max, where/how is it stored?
0 Kudos
Message 4 of 14
(5,848 Views)

My advice would be to proceed as follows:

  1. On your re-built LabVIEW PC, create a LabVIEW Project for your "project".
  2. Put all of the VIs "rescued" from your hard disk or backup into this project.  You should (now) just be missing the DAQmx Task information.
  3. Open MAX.  To the best of your ability, try to recreate the Tasks that your program needs.  You know what inputs and outputs you need, you know the channel names and configurations, you know the sampling rates, etc. already, I presume.  This is a little tedious, but you only need to do it once.
  4. Test your system until you think you have it configured correctly.
  5. Once you've done this, save the MAX configuration as a .txt file and include it in your Project.
  6. Save the entire Project (and all of its files and folders) in a Version Constrol System (such as Tortoise Subversion).

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

0 Kudos
Message 5 of 14
(5,816 Views)

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

Matt J | National Instruments | CLA
0 Kudos
Message 6 of 14
(5,805 Views)
This is one of the reasons I seldom use MAX to setup data acquisition. Having everything in the VI puts it in one place as well as protecting the task from being changed.
Message 7 of 14
(5,793 Views)

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

 

 

 

 

0 Kudos
Message 8 of 14
(5,740 Views)

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?

0 Kudos
Message 9 of 14
(5,731 Views)

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

0 Kudos
Message 10 of 14
(5,710 Views)