max copy configuration locks up RT

[Yevoc42]

There is about a 33% chance of my RT locking up when I attempt to export a .ini file using Max Copy Configuration.vi on my host computer.  The RT's status screen in pharlap always shows a permanent CPU load of 80% and 20% on its two threads once it's locked up.  If it doesn't lock up, the export takes 3 to 5 seconds to complete.

I am using LabVIEW 8.6 and DAQMX 8.8.0f2.  There are about 60 tasks on the RT. The RT is an Intel Core 2 Duo on an ASUS P5K motherboard.

Here is how I call the VI hostside:

Any suggestions on preventing the RT lock-up are most welcome.

Thanks.

[Yevoc42]

While this isn't always the case, I seem to have this problem the most after soft or hard RT reboots.

The RT contains a PCIe-6259 M series board (which contains all of the tasks being exported) and a PCI-6071E and PCI-6509 (both of which do not have tasks as of now).

[Yevoc42]

A colleague suggested that I first perform a manual export from MAX every time the RT starts up.  However, the RT still managed to lock up two times in a row this morning despite that tactic, so something else is clearly going on.

I hesitate to ask all of my customers to pull up MAX every time they cycle power to their entire control system anyway, as that would be a slightly embarrasing kludge of a solution.

It does seem that the only RTs I've setup which don't have the problem are the ones who never get turned off and never have their tasks modified.  Unfortunately, that's a select few of the RTs, so hopefully this issue is addressed by National Instruments at some point.  Otherwise, our product demonstrations would embarrasingly involve multiple RT reboots during "normal" operation.

[Justin_P]

Hi Yevoc

I am trying to understand exactly what you are doing.  My understanding of the MaxCopyConfig.vi is that it is used to copy configurations to MAX, which is not on RT systems. 

Regards,

Justin P

National Instruments

[Yevoc42]

Justin,

Thanks for responding.

"Max Copy Configuration.vi" is a programatic equivalent of importing/exporting MAX configuration files between systems and/or files as can be done directly in MAX.

I am using a Windows XP computer with LabVIEW 8.6 connected via cross-over cable to an RT desktop running Pharlap UNIX with LabVIEW Real-time 8.6. (It is the 192.168.1.56 system you see in my VI call)  In this configuration, the RT shows up in MAX on the Windows computer under "Remote System."  Ever since DAQMx came out, you are able to import/export configuration files to/from the Remote System through MAX on the Windows computer.

Doing this directly in MAX works perfectly every time without problems, but exporting the RT configuration to the Windows computer programatically with Max Copy Configuration sometimes crashes the RT as described in my first post.

[Justin_P]

Yevoc,

In your first post you show the source as "system://192.168.1.56" and the destination as "c:\data\max.ini" (the format of this should be the same as the source i.e. an IP).  What this means to me is that you are copying the MAX configuration file from the RT to your host computers hard drive.  What confuses me is that RTF systems do not have MAX.  I am curious what you are copying.  Could you post one of your in files from a successful attempt?

Also, what are you using this information for?

Regards,

Justine P

National Instruments  

[Yevoc42]

Gladly:  max.ini

Your interpretation of what I'm doing is correct.  However, this is what the Max Copy Configuration.vi help file says about specifying source/destination:

"To specify a configuration file, set source to a file path. To specify a MAX configuration, set source to "system://<host>", where <host> is a system hostname or IP address. The format for destination is the same as for source."

Since I want to specify a configuration file (and not another system) as a destination, I set it to a file path instead of using the "system://" syntax.

I am importing this data because the user has a text file that contains all of our software settings.  This text file needs to be compared against the actual DAQMx task settings on the RT so the software knows what has changed, as the user can make changes to either the text file or the DAQMx task while running our software in LabVIEW.  Running our software without this comparison would create very dangerous physical situations, so from our perspective we have no choice in making this MAX export.

[Justin_P]

Hey Yevoc

I'm going to ask you to take a step back.  Are you trying to get this information to help you replicate an RT system or are you just trying to get the system information to confirm the setup? 

The CopyMAXConfig is designed to copy the configuration files between Windows machines.  The mxs database on RT systems is different from the database on Windows systems.

If you are trying to replicate a customers RT system, the System Replication Toolkit is the way to go.  And if you are trying to get system information, the MAX Report would give you even more information.

I am thinking that you are getting this unexpected behavior because you are using the VI in an unintended way.

Have a great day,

Justin P

[Yevoc42]

Justin,

Thanks for the clarification about what is causing the problem.  I am not trying to perform system replication.  I am specifically trying to get the current task and channel information off of the RT, and MAX Report.vi does not give me this information:

test.htm    test.xml

Does this mean I'm stuck using the Max Copy Configuration.vi in an unsupported fashion to get what I need, or is there another method without doing it manually?

Thanks.

[Justin_P]

Yevoc,

I did a little more research on this and it looks like what you are doing is a supported function.  I was able to get the max.ini file off of an RT PC, but then I ran into an issue different than yours.

I am still trying to replicate your issue at this point.

Jusitn P