MAX Configuration Server Corrupt

[Niatross]

In the last two weeks I have had two separate projects at different customers give me warnings saying that the MAX configuration server has stopped working. (One system is a PXI and the other an ethernet cDAQ, this error stopped the DAQmx tasks from initialising and running)

I have carried out the instructions on this link https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000P8bkSAC&l=en-GB which reset the MAX configuration and I managed to get both systems working again.

I don't want this to happen again, so I have three questions:

- Does anyone have any insight into what causes MAX configuration server to become corrupted

- Is it possible/recommended to bypass the MAX config server when setting up DAQmx tasks in LabVIEW by somehow programatically identifying and configuring all of your hardware instead of setting up configuration in MAX and just referencing the hardware aliases in your code (I have seen online that it is possible to identify hardware by its serial number which may be a way forward)

- Has anyone had any success programatically resetting the MAX server, I am thinking something along the lines of storing a backup of the server in the installation directory, and if I receive errors saying the DAQmx task can't be started I could replace the config file and prompt the user to restart.

Any thoughts would be appreciated 

[Bob_Schor]

I've never heard of the MAX Configuration Server, but I can answer the second question, to programatically identify your hardware.  Here's a little VI I wrote called "Find DAQ Device" (I actually have several different VIs with this name, depending on how I'm using them).  In the Snippet shown here, I'm looking for an NI USB-6009, and am further distinguishing them by Serial Number, and if I fail to find them, informing the User and asking if they want to use a "Simulated" device (which I need to build into the code, of course ...).

Bob Schor

[Niatross]

Thanks Bob

I have just check, configuration server is incorrect, it is actually called MAX Database Service.

That is the sort of thing I am considering doing in the future, a nuisance if you swap a card out in the future for some reason though; config file or rebuild i suppose.

Do you tend to do all of your card configuration in your code rather than MAX as well. For example one of the systems which went down last week was a SCXI chassis and we lost the configuration which took me a while to work out what it was meant to be. I haven't looked to see if this is even configurable yet but I am guessing it is.

(edit - by configuration I am talking about the settings available for individual cards sometimes, this affected an SCXI-1102 which has some configurable gain settings)

It feels sensible to me to have ALL configuration set by the code rather than externally in MAX. Makes it more robust to people messing in MAX, might make it more robust to MAX database corruption, and also makes it more portable (Run it on a different PC without having to worry about setting MAX up)

Am I missing anything. Is there a reason you should use MAX instead of doing everything programatically?

[Bob_Schor]

You should always use MAX to "get acquainted" with your device, to "play" with it and run some Test Panels, to use it to learn about tricky things like "scaling".  The next step is to leverage this by building some MAX Tasks that duplicate some of the Test Panels you just developed (but give them more sensible names than "MyAnalogInputTask").  Now you can kiss the Dreaded DAQ Asssistant goodby and develop a 3-4 DAQmx Function routine that will do your Task in LabVIEW, like this:

To get this, I started with the DAQmx Create Task VI, put a constant on the Task In, clicked the little Selector button, and found the Task I'd created in MAX.  Wired it to the other three (obvious) DAQmx functions, and it ran!

Next, to free yourself from MAX on a particular PC and "lock" it it to your LabVIEW Project, you can also create a Task in the Project, so now all of the specifications stay with your Software (which, of course, is on a VCS Server, somewhere).

Finally, the last step (if you are so inclined) is to use MAX tools to search the PC, look at the Devices LabVIEW can find, and choose the right one.  I've gone through all of the above "evolutionary" steps, and now usually to this last method, especially since I can copy my "code I wrote two years ago" and make trivial changes to go from a PCI card to a USB device to a Camera.

Bob Schor

[JÞB]

---

@Niatross wrote:

In the last two weeks I have had two separate projects at different customers give me warnings saying that the MAX configuration server has stopped working. (One system is a PXI and the other an ethernet cDAQ, this error stopped the DAQmx tasks from initialising and running)

I have carried out the instructions on this link https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000P8bkSAC&l=en-GB which reset the MAX configuration and I managed to get both systems working again.

I don't want this to happen again, so I have three questions:

- Does anyone have any insight into what causes MAX configuration server to become corrupted

- Is it possible/recommended to bypass the MAX config server when setting up DAQmx tasks in LabVIEW by somehow programatically identifying and configuring all of your hardware instead of setting up configuration in MAX and just referencing the hardware aliases in your code (I have seen online that it is possible to identify hardware by its serial number which may be a way forward)

- Has anyone had any success programatically resetting the MAX server, I am thinking something along the lines of storing a backup of the server in the installation directory, and if I receive errors saying the DAQmx task can't be started I could replace the config file and prompt the user to restart.

Any thoughts would be appreciated 

---

I'll swing at all 3.

1, MAX Corruption.... the only reason for this is an update to XML files that MAX uses while something else is holding the same file data.  Every time I see this someone ignored the advice on every NI installer and keeps some NI software product running while an update is installed. <HINT: DON'T DO THAT >

2. DAQmx stuff.  Is defaultedly stored in 3 places.  The MAX configuration file as .XML.  the LabVIEW. Lvproj file as .XML..the LabVIEW build output support path/NI DAQ as an .ini file.    As an aside,  the system hardware API has several features that can be used to do most things MAX does programmatically....hire a Certified LabVIEW Consultant < yes, I AM one. No, I am not cheap.  Yes, I am a lot cheaper than getting it wrong >

3. Nce files.   These are used to export and import many different NI products.     See 2

[JÞB]

---

@Bob_Schor wrote:

I've never heard of the MAX Configuration Server, but I can answer the second question, to programatically identify your hardware.  Here's a little VI I wrote called "Find DAQ Device" (I actually have several different VIs with this name, depending on how I'm using them).  In the Snippet shown here, I'm looking for an NI USB-6009, and am further distinguishing them by Serial Number, and if I fail to find them, informing the User and asking if they want to use a "Simulated" device (which I need to build into the code, of course ...).

Bob Schor

---

@BS,  look into my older posts about NI Device Manager.  It is possible to automatically detect a new device and then associate it with everything DAQmx-ish with a simple executable and some adroit HKEY NInja like moves in the same installer.    <Don't do this at home!  We are professionals >

[Mancho00]

---

@JÞB wrote:

---

---

1, MAX Corruption.... the only reason for this is an update to XML files that MAX uses while something else is holding the same file data.  Every time I see this someone ignored the advice on every NI installer and keeps some NI software product running while an update is installed. <HINT: DON'T DO THAT >

---

We have ~20 computers using DAQ devices, and I get one with a MAX database corruption every 3-6 months.  It's definitely not due to software installation/update, either.  There is a reason NI put a menu item in MAX to fix it...

[JÞB]

---

@Mancho00 wrote:

---

@JÞB wrote:

---

---

1, MAX Corruption.... the only reason for this is an update to XML files that MAX uses while something else is holding the same file data.  Every time I see this someone ignored the advice on every NI installer and keeps some NI software product running while an update is installed. <HINT: DON'T DO THAT >

---

We have ~20 computers using DAQ devices, and I get one with a MAX database corruption every 3-6 months.  It's definitely not due to software installation/update, either.  There is a reason NI put a menu item in MAX to fix it...

---

Re read that post.   Then call me out.

I said "every time I see this..:" then explain what is being done to the configuration on your systems...in a separate thread!

.I am well aware of the fact that you cannot troubleshoot the general process.

[Mancho00]

---

@JÞB wrote:

---

---

Re read that post.   Then call me out.

I said "every time I see this..:" then explain what is being done to the configuration on your systems...in a separate thread!

.I am well aware of the fact that you cannot troubleshoot the general process.

---

Apologies. It wasn't intended as a callout.  Just noting it may be something else. I'm actually not doing anything with system configuration.  In fact, your snippet is essentially what we're doing to identify devices, but I don't want to hijack the thread.

[Niatross]

Just to re-clarify my question. I am after the best way of making code resilient to MAX database corruption issues. A lot of our code goes to customers who aren't knowledgeable with NI software/hardware and as far as they are concerned just want a magic black box. Everyones comments has confirmed that I am thinking along the right lines so I am going to have an experiment today.

---

@Mancho00 wrote:

---

---

We have ~20 computers using DAQ devices, and I get one with a MAX database corruption every 3-6 months.  It's definitely not due to software installation/update, either.  There is a reason NI put a menu item in MAX to fix it...

---

Mancho, I am guessing you are referring to the 'Reset Configuration Database' button?

@JÞB wrote:

---

---

---

@BS,  look into my older posts about NI Device Manager.  It is possible to automatically detect a new device and then associate it with everything DAQmx-ish with a simple executable and some adroit HKEY NInja like moves in the same installer.    <Don't do this at home!  We are professionals >

---

What posts are you refering to here JpB? I can't find them on your profile.

---