distributing daqmx tasks with program exe

[mysticfree]

I was wondering about that, Bob.  Since the 6501 on the lab pc is only seen by Windows as USB device, I wondering how my DAQmx script convinces Windows that that is the device my program wants to control.

[Bob_Schor]

---

@mysticfree wrote:

I was wondering about that, Bob.  Since the 6501 on the lab pc is only seen by Windows as USB device, I wondering how my DAQmx script convinces Windows that that is the device my program wants to control.

---

It's not Windows that cares about the device, it is MAX (which should recognize, and classify, all DAQmx Devices when they are plugged in).

Here's a routine I wrote to Find DAQ Devices, returning an Enum that said it was a specific (by serial number) USB-6009, a-nother USB-6009, a USB-6002 (Case not shown), or "Unknown Device", with the latter choice allowing the user to opt for a Simulated Device.  Note that if it was a "real" (recognized) device, the Device ID is saved and can be used to start Task construction.

Bob Schor

[mysticfree]

Do you think it would be easier to just install NI MAX on the non - labview machine? I don't think there's any licensing involved with that program. Then I could use NI MAX to setup the task that match what was coded in the program. Would that be a better all-around solution?

[Bob_Schor]

---

@mysticfree wrote:

Do you think it would be easier to just install NI MAX on the non - labview machine? I don't think there's any licensing involved with that program. Then I could use NI MAX to setup the task that match what was coded in the program. Would that be a better all-around solution?

---

My opinion (not having all the facts) is that this would be the wrong option for the following reasons:

• You could use MAX to set up the task and try to match what is coded in the Program, but your Customer  --might not be able to do this once you left.  Let a few Reboots go by, some Windows Updates, changing the connection to the Device (such as changing the USB port, or plugging in other devices), and who knows how the Device will identify.
• Your assumption that installing MAX does not require a LabVIEW License is not one I would make -- you may be correct, but I'd be willing to place a bet (a whole quarter!) that you are wrong.
• If MAX is installed, and someone comes along and plugs something that MAX might recognize into your Target PC, MAX will give it a name and you may have created a Name Conflict that will make your code just fail (of course, you'll trap the Error and output an Error Message to your Customer saying "Oops, I can't find the USB Device, so give me a phone call on my Help Line ...").

You've been getting pretty consistent advice (and some helpful code, as well) saying "Build the Task programmatically for the Device you want to use".  Some of the responders really know what they are talking about (I'm learning from them, myself).  I suggest you Byte the Bullet and write robust code following their recommendations.

Bob Schor

[JÞB]

First at Bob.  Bet the farm not only a quarter.  MAX And DAQmx configuration support are as free as the LabVIEW RTE.

  Next at Ben.  That MAX config import should be covered by the Installer.  Better yet, in high mix testers, use the Configuration API to import the .nce, configuration file at  application startup. 

NOW I'm going to do something that it is seldom advisable to do,  disagree with Ben.

(Don't try this at home, I am a trained professional with years of experience)

  I'll compare the several methods. 

Building tasks and scales programaticaly and deploying as exe.

The installer needs DAQmx configuration support and MAX to set the device name.  Even if you import the MAX config.  PRO the device setup in in the exe and none can change it without rebuild.  CONS see pros and limited maintenance support.

Building in MAX.  You have the same installer bloat but, MAX can be used to edit and test the task, scales, channel names ...  Ideal if you have a tech user that needs to swap out devices for calibration or users swap USB Ports.

Building in the LabVIEW project.  The exe includes a NI DAQ folder with a human readable .ini file. No MAX NOR DAQmx stuff in the installer.  And yes, you can edit the ini to tweak scales (thing an automatic cal routine as a second. Exe to change scales, find devices..  .)   The user's don't know about the file so they can't mess up settings like they might if the DAQ stuff in in MAX but you can change. Settings easy without rebuilding when the client suddenly want to add another channel.

Pick your best fit for your user.

[Bob_Schor]

Thanks, Jeff.  Always learning -- I didn't know that including the Task in LabVIEW Project had the possibility of making a change to the parameters inside a built Application (.exe).  My only experience wanting to use Scaling (I was using a ROM Triaxial Accelerometer -- ROM means "Rough Order of Magnitude, i.e. the Offset and Gain values were specified ±10%),  I saved the post-calibration values in my own .ini file, not knowing that the Project maintained one I could utilize.  Time to explore ...

Bob Schor

[JÞB]

I see that a lot! "I put my DAQmx objects in a configuration file"  just to prove that they are DAQmx savvy.  Without realizing LabVIEW does that work for you and NI tests the bejeezus out of it! I just say, "if you write fewer bugs than NI R&D go sling all those wires over again." Usually while laughing. 

The only down side to project DAQmx objects has been reusing them in other projects.  There is a workaround but, it is scary. 

Use notepad to open the projects and copy paste the xml.

You'd think the LabVIEW IDE would support that natively.   

[mysticfree]

What is the "behind the scenes" interaction with NI-Max task and the device name in a program?  Does NI-Max act as a server?

[crossrulz]

---

@mysticfree wrote:

Where do you locate the "DAQmx System" property?

---

Measurement IO->DAQmx->DAQmx Advanced->DAQmx Constants & Property Nodes.  It is the one with a monitor image on it.

---

@mysticfree wrote:  For some reason, this VI snippet won't drag-n-drop as other snippets usually.

---

You are probably using an older version of LabVIEW than the snippet was made it.  The snippet was made in LabVIEW 2018, which is just a few months old at this point.

[mysticfree]

Thanks, crossrulz.  I'm still waiting on my DVDs updates.