Is MAX a run-time engine for labview executables? Questions about MAX and LabVIEW

[LLB2012]

Hi,

I am trying to figure out how MAX interacts with LabVIEW...

If I build a LabVIEW executable file and run it on a computer that does not have LabVIEW, with associated DAQs, do I need MAX to configure the hardware? Or can I do it all through the LabVIEW file?

Do I need to have MAX installed when using LabVIEW with DAQ hardware or can I configure everthing in LabVIEW?

Thanks

[mikeporter]

You do not have to install MAX on the target computer, you can configure everything in LV.

Mike...

[crossrulz]

But I think MAX is installed with DAQmx, which you will need to talk to the NI devices.

[Dennis_Knutson]

But when creating an installer, the DAQmx core can be selected which will not include MAX. The op is asking about a deployment.

That being said, installing MAX makes for debugging any problems much easier. I would recommend including it.

[JÞB]

---

@Dennis_Knutson wrote:
But when creating an installer, the DAQmx core can be selected which will not include MAX. The op is asking about a deployment.

That being said, installing MAX makes for debugging any problems much easier. I would recommend including it.

---

Ditto the above.  but remember the smarter additional installers portion of the app builder that ships with LabVIEW 2013 does not optomize for integration ease so MAX and  DAQmx MAX Config support must me manually added to the spec when building an installer.

[LLB2012]

Thank you for the input! This helps. I am starting a 'computerized system qualification' and need to figure out if I should include MAX or not. Knowing that it is not required for LabVIEW to run helps. Additional question: what is a good practice when programming devices with LabVIEW- Config hardware in LabVIEW vs MAX or the opposite? I am (obviously) a newbie but I have done it both ways. However, I have not had experience compiling .exe files and am wondering if its better to have it all in LabVIEW for those. That way I wouldn't have to reconfig the hardware in MAX on the target machine???

[JÞB]

The obsolute best way (IMHO-well maybe not exactly "Humble")  Would be to store all the hardwawe configuration within the LabVIEW Project then select export configuration to "MyProject.nce" and use the installer to load that *.NCE into MAX in a project specific location so the maintainer and integrators can use the config file to test and troubleshoot the test system.   However these IDEAS have not been implemented by NI

http://forums.ni.com/t5/Additional-NI-Software-Idea/Project-and-Workspace-Context-in-MAX/idi-p/18511...

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Simulated-Devices-in-LabVIEW-projects/idc-p/1851177#M1...

http://forums.ni.com/t5/NI-TestStand-Idea-Exchange/Simulated-Devices-in-TestStand-Workspaces/idc-p/1...

So, for the most part I create my hardware configuration in MAX, export the hardware configuration to MyProject.nce and add it to my LabVIEW project (OR TS Workspace) and make sure that the installer imports the config file.  When Hardware errors occur (and they will because someone will muck with MAX) I get human in the loop to re-import that golden .nce configuration that deployed with the application.  The System API "Could" import the config automatically but a trained tech in the loop will be able to use better judgment if the reason is that there is a bad device.

[Dennis_Knutson]

On the other hand, if you don't have anything in MAX, there is nothing for anyone to muck around with.

[JÞB]

---

@Dennis_Knutson wrote:
On the other hand, if you don't have anything in MAX, there is nothing for anyone to muck around with.

---

Very true.  It is a trade-off between ease of integration and test system maintanence and security.  A factor that must be considered within the enviornment of the intended use.  A Highly regulated enviornment often requires having no means of changeing the test operation external to the application and the technique and method I discribed would be a place where an "installation qualification" is not easilly traceable.  -Thanks Dennis for reminding me, I meant to point that out but had to go to a meeting and rushed though the other point. - Of Course, that makes fixing broken systems fair to middlin' painful.  In those cases I do try to create an additional engineering console leveraging the project configuration that is not qualified for production purposes.  It adds the the project cost and requires additional resources to code and train the users.  Make sure the boss knows up front and budgets appropriately  That maint console scope creep is fairly dangerous because the client allways wants more features added (at no cost to them, mind you) 

[LLB2012]

The operators having access to muck up the hardware config is definetely a concern which is a reason why I am trying to understand how LabVIEW, MAX and DAQmx work/interact together. Still struggling.

So, I can config my hardware in a DAQ Assistant in LV. I can also get to the same config screen in MAX and do it there. How do they talk to each other? If I update LV, does MAX update?

I have pretty much zero experience with the LV excutable files. If I use a DAQ assistant and config hardware through that, then build an *.exe, is all the hardward config included in the file? Are there assosicated files with the *.exe file that contain the info that need to be installed with the .exe? Can the hardward config still be modified by MAX? Is the *.exe calling MAX for this info?

I think a lot of my questions are coming from not understanding how LV. MAX and DAQmx interact. Does DAQmx just handle the drivers? Or is that MAX? Is LV looking at MAX for hardware config info and drivers?

Sorry for the million questions.