Are PXI-8183 RT and LabView 2012 incompatible?

[Kilometers]

Hey Joe,

I have a couple of questions for you. Are you still getting those errors you mentioned in your original post after upgrading to Windows 7 (you mentioned reference errors, unresponsiveness, and possible memory leaks)? Is it possible for you to use indicators instead of probes to accomplish what you want to? Just so you can continue working on things.

Sorry for the delay in my posts. PXI-8183 RTs are apparently hard to come by round here and I'm still hunting one down. It is one of our older systems, so it is difficult to know when or if a fix will be available. It's probably best we try and find a workaround for you while I'm working on reproducing the issue. 

[peabody_bass]

Hi Miles,

Yes, the same errors exist in Windows 7.  I suppose I can use indicators for debugging.

Thanks for the effort.  I figured the same with concern to a fix; I'm just hoping that I have something misconfigured (or similar).  Thanks.

-Joe

[Kilometers]

Hi Joe,

Were you able to get any useful information from your indicators?

[peabody_bass]

I haven't had the chance yet, but I probably will tomorrow.

TBH, I'm not looking forward to it.  It's quite a large application, so there are many things to check.  Every new indicator I use will require me to compile the executable, deploy it, reboot the RT, connect to the debugging, and open up all the front panels I want to examine.

[peabody_bass]

Depending on how you look at it, I either did or did not find out something by adding indicators and debugging the RT executable.

I added a bunch of error indicators to the front panel of the top-level VI, and the executable worked fine while debugging, but still halted when debugging is closed.  I slowly removed the indicators, recompiled, and the same outcome occured.  Finally, nothing was left on the front panel (even the text indicator that is always there, and only gets written to during an 'error' state), and it still worked fine with debugging open and halted with it closed.

So it seems that just the action of opening the one front panel (the top-level RT VI) with debugging allows normal operation.  Does this make any sense?  How much does opening a blank front-panel slow down or otherwise alter execution?

I was able to change some wiring on the RT-side and capture a 1055 error (Object reference is invalid) during the 'Run Trial' state.  It will take a little time to dig further as this state accesses ~10 reference with 6 difference VIs.  But I bet that debugging the individual VI's, that the problem will go away.

Any ideas?  Thanks.

-Joe

[Kilometers]

Hi Joe,

Are there any property nodes, invoke nodes, shared variables, or anything else referencing a front panel object in your Real-Time VI? These cause errors when running a Real-Time application or VI because the VI does not typically load the front panel when running. In debugging mode the front panel is loaded so these errors wouldn't occur. Is there any chance that's what's occurring here?

[peabody_bass]

Hi Miles,

I figure this has to be the issue.  Was this not the case for LV 8.2.1?

I believe the only references being used are 9 'TCP Network Connection' references and 1 'FPGA Interface' reference.  But none of them reference a front-panel object.  I will check the rest of the application for any front-panel references and let you know.

Thanks.

-Joe

[Kilometers]

There have been some changes in functionality and how different calls are made in LabVIEW since the older versions of LabVIEW. However, in general, references to a front panel on a Real-Time device have never been supported. I'm not aware of any specific functions of this sort that previously worked and now don't, but if you have questions about a specific call I can try to look into it.