Getting -1950679023 for one shared variable but not others

[jmorris]

Hello again all you helpful forum-goers!

I have a project which has two executables, one which runs on Windows and one which runs on a real-time target.  They communicate with each other using network-published shared variables.  The real-time side is always running, and the Windows side is optional.  All shared variables are hosted on the real-time side.  In order to have good default values in the variables which normally come from the Windows side, the real-time side writes good default values into those shared variables once upon startup.

The problem is, one of those shared variables is returning error code -1950679023 ("The connection to the server was disconnected") and default type values (it is a cluster), while others that are stored in the same shared variable library are working fine.  This problem is persisting regardless of whether I have started the Windows side of my project to write a new value to that shared variable or not.  The variable in question is network-published with a real-time FIFO of 1 element.  It has worked in the past, but no, I'm not sure what I've done since then to break the system; if only it were that easy!  😉  I know I have not changed the properties of the shared variable.  The initial writing of the default values into the problem variable is not returning an error (although I don't know if it is returning a warning).  I do not read the variable anywhere else in the real-time side of my code.  A trivial new VI thrown together to run on the Windows side which just reads the variable a couple times seems to work fine (and have the good default values returned).

Unfortunately, as always my code is work-related and therefore proprietary, and cannot be posted.

I do not understand how the connection to the server could be lost for one variable and not others.  All other communication via other shared variables back and forth between Windows and RT seems to be working just fine.  Does anyone know why this might be happening, or have ideas to try to fix it?

Thank you very much in advance for any help you can give!

-Joe

[Arham-H]

Hi Joe,

It is quite peculiar that only one shared variable is throwing an error, especially a communication error. Try to re-deploy your variable library and see if makes a difference.

Sometimes the reference to a variable can become corrupt, you can try deleting the variable from the block diagram and then dragging it back in from the projects window.

Hope this helps.

Regards

[jmorris]

Arham - I completely agree about the peculiarity!  😉

Unfortunately I have tried both undeploying and then redeploying the shared variable library which contains the problem variable, as well as deleting the variable from the library entirely, deleting the variable off of the block diagram, re-creating the variable, and then adding it back onto the block diagram.  Neither fixed the issue.

Thank you for the suggestions, though!

-Joe

[Arham-H]

Hi Joe,

Since you have also created an SR for this issue I will work with Daniel on this however he will be your point of contact.

Regards

[jmorris · Accepted solution]

FYI, I tried putting a wait off of the real-time pallet in front of my RT initialization code (using a flat sequence structure) in order to try to give the shared variables engine more time to startup before my code started using it, and it resulted in my real-time code never executing, as far as I could tell.  I cannot explain why.  😛

I was able to find a work around that fixed the problem.  I moved the reading of that problem shared variable into a VI that executed immediately before the one that uses that variable’s value, and passed the value between VIs via new local output and input terminals.  Now it works.  I have to imagine that something in the code of the VI it was originally in was corrupted, even though it was not fixed by removing and reinstating the variable, nor even by creating two new shared variables that between them contained all of the same values and putting them in the same place in the VI.  That makes me think that something in the background code compilation of that VI is not friendly to shared variables (there aren’t any others in that particular VI, although there are in its subVIs).

As always, thank you for your time and suggestions, even if the solution ended up being not as satisfying as I could hope.  At least my program is working now, and that is the important part.

-Joe