Are PXI-8183 RT and LabView 2012 incompatible?

[peabody_bass]

I recently upgraded the software on an older PXI-RT system (from 8.2.1 to the August 2012 versions).  The controller is the PXI-8183 RT.  No changes were made to the source code (other than re-compiling a FPGA bit-file for the current version).

The RT source code seems to run fine.  But when compiled to an executable or a source distribution, strange things start to happen (weird reference errors, unresponsiveness, possible memory leaks, etc).  When I enable debugging on the RT-executable, as soon as I insert a probe the entire RT system reboots.  So I plugged in a monitor to the RT system and looked at the console output (I needed to record it to video since it was only on the screen for a split second):

[Error: LabVIEW: VI is not loadable.

In a build application, this might occur because the VI being loaded was last compiled for a different OS, in which case you must save the VI on the current platform.  This error also might occur if the VI is a polymorphic VI, which cannot be loaded in the LabVIEW Run-Time Engine.  You must load an instance of the polymorphic VI instead of the polymorphic VI itself.]

[Load error 57 occurred while loading [4] Error Out]

Rebooting system due to exception

[SYSTEM MESSAGE] System is Shutting Down...

The problem seems similar to this, but SSE2 was disabled for the build.  The Host-PC that built the RT-executable was a Intel Core2 Quad (if relevant).

Any ideas?

[Brandon-L]

Here are a few things that you might try since you mentioned that you already disabled SSE2, but to not avail.

1)Be sure to recompile all of the subVIs in LabVIEW 2012

2)Reformate the PXI-8183

3)See if you are able to recreate this error with a simple VI

I would also be helpful to know:

-How many probes you were using before the system crashed

-What operating system you had on the Host-PC

-If you have any polymeric VIs in the program

[peabody_bass]

I will try the 3 things you mentioned.  Do you mean performing a re-compile of the subVIs in use (<Ctrl> + <Shift> + Run Button)?  Or a mass compile of everything (Tools-->Advanced-->Mass Compile).

-How many probes you were using before the system crashed

It would always crash on the first probe inserted, regardless of probe-type.

-What operating system you had on the Host-PC

Windows XP/SP3.  I'm currently configuring it for a dual-boot with Windows 7.

-If you have any polymeric VIs in the program

I believe there are a few.  I think I did try to leave all polymorphic VIs referenced in one of the builds.

[Brandon-L]

It would not hurt to do both a forced recompile (<Ctrl> + <Shift> + Run Button) and a mass compile of everything (Tools-->Advanced-->Mass Compile) along with reformatting the PXI.

Please respond back with the results of these steps. Also, if you are still seeing the same behavior with a simplified VI it might help if you post that code here.

[peabody_bass]

I reformatted the PXI-RT.  I still got an automatic restart when using a probe.

I tried a simple VI compiled to an EXE, and had the same result.

Since the simple VI still cause the error, I'm jumping right to a mass compile of everything (which I'm doing right now).

(This is on a fresh install of Win7, with only the LV packages from August 2012).

Thanks.

[Brandon-L]

Just to be clear, does the crash happen when you use a probe when you remotely debug the application, or when you are interactively debug the application. It might also help if you posted the simple VI that still recreates the issue and I can see if I am able to recreate this behavior. 

[peabody_bass]

It crashes only when I remotely debug the RT-executable.  When I interactively debug the RT-source code, everything is fine (including proper execution of the program).  Attached is the simple VI I used.  Thanks.

[Brandon-L]

I am still looking to recreate this issue. It might also help if you could post your MAX Technical report that gives the information regarding you Hardware and Software setup.

[peabody_bass]

Hi Brandon,

Thanks for the help.  Sorry for not getting the Technical Report sooner; I was out of the lab all of last week.  It is attached.

-Joe

[Kilometers]

Hi Joe,

Brandon has gone out of office and I'm going to be looking into this while he's gone. Before he left he let me know he was not able to produce this on any of our newer hardware. I'm going to look into finding some other controllers to try and recreate this issue. I'll get back to you when I have more information.