Appear to lose connection with the Shared Variable Engine

[Will_S.]

Flushing the variable buffer is already to set automatically in LabVIEW. You should only need to do it manually if you want to flush it earlier than within 10 ms or before it is full.

Could you describe a little more about what your function does and how it uses the variables? I am curious why it could cause this issue.

[thisisnotadream]

I think I can do you one better.  I was able to spend some time today scrubbing enough of my code of proprietary information to send to you.  I tried the scrubbed code and got the same results as before.  I tend to have better luck after I lose the connection (not as many drop-outs, etc.) but I still have the occassional issue even while disconnected.  If you have questions, please let me know.  I hope the code makes enough sense.  The target application is a bunch of code to monitor the PXI hardware in generic terms and interface with the host who is primarily concerned with going from generic to specific (this software is intended for use with multiple units under test). 

Thanks,

Dan M.

PS--Sorry for being so lame about sending code earlier, but it would have been my butt on the line if a crazy spy stole defense information off the posting.  Sorry to all you hostile spies out there...no offense intended.

[thisisnotadream]

Sorry.  You'll probably need this too, to get it to load  (it's not actually used with this unit under test, though). 

DRM

[Will_S.]

Dan,

I've been looking at it, but this is still pretty huge. Would you be able to shrink it down to the bare essentials that cause the issue? That would be a big help.

Thanks,

[thisisnotadream]

That's part of the problem.  This IS stripped down.  Much of the time I am doing much MORE than what this build does (processing DAQ, receiving and responding to CAN data, RS-485 data, etc.).  The issue does not appear to follow anything consistently.  I cannot reproduce the issue at will.  Sometimes the software will only run for 5 seconds without a loss...the very next run I have seen sometimes run for a half hour before causing an issue.  Sometimes restarting appears to help.  Other times, not.  It USUALLY appears to run better if I perform little in the way of user interface, but letting the software sit does not solve the issue.  I have stripped major portions of the code out to no avail.  (note the myriad of disables)

Have you been able to at least reproduce the issue?

Dan

[rex1030]

You mentioned that the cpu stays around 15%, what about the memory usage?

[thisisnotadream]

Memory useage appears pretty stable.  (If you knew me at all, that would be a bit of a surprise.  It's taken me some time, but I think I have curbed my habit of writing memory-hungry RT applications.)  I have included a profile that I pulled from LabVIEW.  The only thing that appears to jump in memory is the CAN read multi VI, but that doesn't seem to be a show-stopper.  This profile was running during two communication drop-outs.

Dan M.

[Will_S.]

Hi Dan,

I'm checking in to see if you have made any progress with the issue of losing connection with ithe shared variables? Have you been able to isolate the cause to a more central part of your VI?

[thisisnotadream]

Nope.  No such luck.  I have been able to mitigate the issue somewhat by tweaking different things, but nothing eliminates the problem entirely.  Problem appears to be on the host side.  I notice that the communications issues are often associated with front panel events, but I cannot trace why.

**SHRUG**

Dan

[Will_S.]

Earlier you said you had isolated the issue to a particular function. Which function is that within the VI you posted?