Shared Variable Crashing LabVIEW

[deskpilot]

This is just one of those projects that has a brick wall at every turn so far. Two computers running LV2009. Computer A hosts Data Write Shared Variable. Computer B hosts Data Read Shared Variable. Data Read is bound to Data Write. Everything was working fine, and then late yesterday afternoon, I don't think I had changed anything on the shared variable, I start up my VI on Computer B, and LV crashes. The VI starts to run until the first execution of Data Read, and then poof, everything open in LV dissapears. The problem is one hundred percent repeatable since then.

Here is what I know:

1. An error indicator hooked to Data Read shows -1950679034 (Shared Variable has no value) for about a second before the crash. Everything stops executing as soon as the warning appears.

2. The Data Write is single writer, but it is also occasionally read in the VI that it is written in. It is not being read when the crash happens. I can however perform the read on Computer A without incident.

3. Not sure if this is related, but if I open the VI on Computer B, and then open the project, I am not able to drag Data Read from the project onto the block diagram. I also cannot perfrom any operations on the Shared Variable (like right click, ignore timestamp). I have to close the VI and reopen it from the project. Thinking back, this problem may have started when I opened the VI without opening the project.

I am torn between abandoning Shared Variables and trying to figure this out. I would definetely prefer to use the Shared Variable, especially because I need some buffering. I'm guessing I can buffer things some other way. Not sure if I can remotely access a queue, or ... ?

[Norbert_B]

Hm, never seen an issue like this before.... but one thing you can check out: use the DSM (Distributed System Manager) to kick the Data Read variable. Remove the process hosting this variable.

After this, deploy it again and check out if it changed anything.....

hope this helps,

Norbert

[deskpilot]

Norbert, I tried what you suggested, no change.

Totally perplexed by this, but if I change the Data Read from (Array of double waveform) to (Array of double), it runs without problem. Change it back to (Array of double waveform) crashes again. The Data Write is (Array of double waveform) with 1000 points buffered. The Data Read is unbuffered. When I look at Distributed system manager, everything always looks fine, but there are no values listed.

I really need the waveform information because I will be using the Data Read to backup data, while also performing calculations and displaying information. I do remember that when displaying the waveform info from Data Read before it started crashing, the NI attributes were not present, but they are present in Data Write.

Message Edited by deskpilot on 02-24-2010 01:10 PM

[kc64]

I abandoned the use of shared variables in favor of the STM (http://zone.ni.com/devzone/cda/epd/p/id/2739) because of reliability problems with the shared variables.  I would recommend the same to anyone (sorry, NI).

Do you have two NICs on either target?  If so, you may have the same problem I had where the shared variables are bound to a single network interface.  If there are any problems with that interface, the shared variables are rebound to the other interface.  If your problem is similar, you might want to try out the logos.ini file to help.

[deskpilot]

I looked at STM, but I think the Data Socket VI's may be a better fit for me. It seems like Data Socket and shared variables are sort of intertwined, but I'm hoping DS doesn't suck as much as the SV seems to so far.

I think NIC means network interface card? Anyway, I don't really know how many I have. The Data Writer is on a PXI8108 with Windows, the reader is an old crappy Dell that I inherited with the desk.

I'm also not sure about the logos.ini file you referred to.

My intention is to transmit an array of double waveform that is about 15 - 20 channels acquired at 100 - 1000 Hz. I think the Data Socket looks like the simplest way to do this, and I could live with 100 Hz if speed is a problem, but I sort of don't think it will be. I'll try tomorrow unless somebody has a better suggestion.

By the way, I saw in another post a similar problem with Shared Variables that is supposedly fixed with the new patch for 2009, but I'm not sure I trust SV's because this will, for about thirty seconds of its lifetime, be one of the most critcal applications I've written, so I want confidence that it will work for those thirty seconds.

[deskpilot]

SO maybe I owe Shared Variabels an apology. I got rid of every trace of them and their libraries, built a set of VI's around Data Socket, configured the server, ran a small test VI, and everything works great.

Plugged that into my main client and BAM, crash. You have to be &*%^&*% kidding me.

So, I've narrowed it down to the most ridiculuous thing, and figured out why the shared variables worked when I changed the reader to array of double instead of waveform (which is basically a two dimensional array).

I am taking the data out of the data socket (originally the shared variable) and comparing each channel to two values. I am using the standard greater than operator in aggregate mode. If I change these to compare elements and put an OR ARRAY operator after it (making it the exact same thing as compare aggregates), everything runs.  

[jareds]

Hi deskpilot,

Could you post the code that is producing this crash?  Also, there's a chance that the VI has become corrupted somehow.  To test this, copy the contents of it into a new VI and see if the new one has the same behavior. 

[deskpilot]

I was going to continue here: http://forums.ni.com/ni/board/message?board.id=170&thread.id=478120, since the title of this one seems to be incorrect.

I copied and pasted the code with compare aggregates into a new VI, and it also crashes.

Not sure if what this means, but it seems interesting: I open my VI with the data socket read, change it back to compare aggregates so that it will crash. I copy the block diagram before running it, then hit run, it crashes and dissapears as expected. I reopen Labview, paste into a new blank VI, and it pastes as a PICTURE? If I copy and paste before running, it pastes as expected and either one will crash upon hitting run.

Message Edited by Support on 03-01-2010 08:36 AM

[jareds · Accepted solution]

I was able to reproduce the crash that you're seeing with an extremely simple VI in LabVIEW 2009.  This looks like a bug in LabVIEW, so I'm going to check if there are any reports of this behavior already.

[deskpilot]

Just read the list of things fixed in Service Pack 1, and this appears to be included, along with about four other problems I encountered while trying to build the communication for this project. Suppose I should have read the list when it came out.