Max is Overwriting cDaq Module Names on first "Reserve Chassis"

[jpeabod6]

I have a cDaq 9188 backplane that I have named "QCCartCDaq" in MAX. It has the following modules in its slots, which I have also renamed:

Slot     NI Module     Name

1)           9205     QCCart9205

2)           9264     QCCart9264

3)           9217     QCCart9217

4)           9213     QCCart9213

5)           Blank

6)           Blank

7)           Blank

😎           9472     QCCart9472

I have a project that uses these devices, and that has all my scales, channels and tasks defined in it. Everything works fine in the project, but when I build an application and installer for it and install it on a "clean" machine, it has not been working. So I installed MAX on the clean machine so I could see the hardware configuration and play around with it.

It seems that what is happening is that when "Reserve Chassis" is used for the first time, the names of the modules are changed in MAX from, say, "QCCart9205" to "QCCartCDaqMod1". My application uses the "reserve chassis" VI when it runs, so this is probably what was happening all along.

After this happens, in MAX, I can change the names back to what my application is expecting, and they will stay that way no matter if I reserve/unreserve the chassis or restart MAX. The installed build will also run fine. It seems to only be the first "Reserve Chassis" that causes it. If I then delete the chassis from MAX and re-import it from the .nce file that I exported off the development machine, it will import with all the correct module names, but they will then be changed when I reserve the chassis for the first time.

Yes, I know that the simple solution would be to simply keep the modules named as "QCCartCDaqModX" in the original MAX configuration. I suppose I should also just keep the name of the cDaq chassis as the serial number instead of QCCartCDaq. But I want to know why this is happening. Why is it possible to individually name the modules if this functionality is not intended to be used?

[Tom_W_[DE]]

Hi japeabody-

I want to make sure I understand what you are describing.

How are the module names stored in the first place?  Have you imported a MAX configuration from another machine?  Or are they referenced by those names in your application or in the DAQ Assistant?

The default module name behavior is <chassis name>Mod<slot number>.  The names that the system is assigning seem to follow that convention, but if you have previously added module names (via an import for example) and those are being overwritten, you may be encountering a bug.  Do the modules and/or chassis on the system match in model number, serial number, etc, from the original system?

[jpeabod6]

Hi Tom-

The chassis/module names are stored on my development machine in MAX (I'm not aware of any way to include chassis/module configuration data in a project, but if there is a way then I would be interested to hear about it). The project is on my development machine. All of the scales, channels and tasks that the project uses are defined within it. They are defined in terms of the modules as named in MAX.

The application would not run correctly after I installed it on my target machine. The hardware was the same actual chassis and modules.

I noticed that in MAX, on the target machine, the modules were named incorrectly, as <Chassis>Mod<Module#>. So I saved the MAX configuration from my development machine as a .nce file, deleted the 9188 from MAX on my target machine and imported the configuration file from the development machine. It imported with correct module names. When I clicked "Reserve Chassis" it changed all the module names. When I manually changed them back, it would not change them any more, and my application would run fine. I repeated the process of deleting the 9188 from MAX on my target and importing it from MAX on my development machine. Again it imported correctly. I then ran my application, and all module names changed.

Thanks for your response! I hope you can help.

-Jason

[Tom_W_[DE]]

Hey Jason-

Would you mind sharing your MAX export file in .ini format and in .nce?  If you'd rather not post them here let me know and I'll find a way to get in touch with you by email.

I have spoken to a representative from the R&D group that develops the import/export experience around these chassis and modules, and I have some indication that this may be expected behavior.  If that is true, I think it could definitely be improved, but before I make any definitive statements to that effect, I want to make sure I can get a good picture of exactly what you're running into.

Thanks again-

[jpeabod6]

Here they are. I changed the .nce extension to .xls because the forum did not recognize .nce as a valid extension and would not let me upload it.

[Tom_W_[DE]]

Hey Jason-

I delayed in responding because I was hoping we could find time during development of the current DAQmx release to definitively identify the code change that led to the advice I'm about to give.  We didn't get to that, unfortunately, but I observed some things anecdotally that may be helpful and not terribly time-consuming to try on your end.

Some background from my interaction and testing may help tell the story.  I tested with the current version of DAQmx (actually, an in-development version, but I expect that the most recent released version of DAQmx would have the same behavior, specifically DAQmx 9.7).  Since your configuration showed that you are using a slightly older version (DAQmx 9.3), I think it is worth your time to try DAQmx 9.7 (or later) based on my testing experience.

Here's some background on the behavior we had when we originally released support for ethernet and wireless cDAQ chassis:

---

When we import a configuration for an unreserved ethernet cdaq chassis, we do not know whether the modules are actually there or not.  So instead we import them as Not-Present and then on Reserve we will make them present.  The problem is that [Not-Present modules are not strongly linked to any other devices in the system], so we consider [a different module plugged in later to be a new one]. 

---

Under the hood, this basically means that a new module is created, with a new, default name.  The default name is <chassis name>Mod<slot number>, which matches the names you're seeing.

Here are my testing notes, which describe that I saw a different behavior (and, I think, the behavior you're hoping for) by using a newer version of DAQmx:

---

I have a cDAQ-9181 chassis with a module installed.  I configured them both in MAX, then exported my MAX configuration to .ini.  I deleted the chassis from MAX.  In the .ini I changed the name of the module to something nonstandard.

The .ini had TCPIP.DevIsReserved = 1, and I imported it, the chassis was reserved, and the module showed up as present with the name from the .ini file.

I deleted the setup again, modified DevIsReserved to 0, and then imported.  The module showed up as not present and with the funky name, I Reserved the chassis, and it showed up as present with the same name.  I thought maybe there might be something residual on the system from the previous association, so I deleted it again, gave the module a different funky name, and tested this part again and got the same result.

---

So, I think you could consider two things:

1. Export your MAX configuration with the cDAQ chassis still marked as Reserved.  This *might* make things work as expected with your current version of DAQmx, since the chassis isn't un-Reserved at import.  I haven't confirmed this recommendation, but it seems like it would be very quick for you to try it.

2. Upgrade to a newer version of DAQmx.  For example, you could consider DAQmx 9.7, or the next version that we will release for NIWeek in a couple of months.  I tested with that bleeding edge version and saw the behavior that I described above.

I hope that one or both of these would be quick for you to test.  I would like to have a more definitive answer for you without spending much more of your time with confirming these on your side, so if these don't check out please post again and I will redouble my efforts to finish out the investigation.

Hopefully this helps-