SharedVariableNode didn't get properly patched to DS

[Richard1000]

I'm receiving very occasional errors as follows:

####
#Date: THU, JAN 01, 1970 12:00:13 AM
#OSName: VxWorks
#OSVers: 6.3
#OSBuild: Jun 14 2012, 08:43:39
#AppName: /c/ni-rt/system/lvrt.out
#Version: 12.0rc7
#AppKind: AppLib



<DEBUG_OUTPUT>
01/01/70 12:04:48.865 AM
DWarn 0xE3E2BC8B: SharedVariableNode didn't get properly patched to DS
source/variable/SharedVariableCallbacks.cpp(99) : DWarn 0xE3E2BC8B: SharedVariableNode didn't get properly patched to DS

I am using Shared Variables ... they are Single Process SVs with RT Enabled (these are not Network Published).  This will occur in perhaps 1 in 100 runs, so difficult to isolate. I am using SVs to maintain current values only for communication across deterministic processes.

Do SVs need to be initialized? 

Can anyone decode the error message ...?

[Arham-H]

Hi Richard,

When do you receive this message? Is it during deploying the code or while the program is running? SInce the message starts with a DWarn it means that it is a warning and not a hard error.

Are you seeing any anomalies during program execution?

It is good practice to initialize shared variables so that program execution always starts from a known state. I would recommend initializing the shared variable to see if it fixes the issue.

Regards 

[Richard1000]

Thank you Arham.  The message is received once the code begins running, and is accompanied by severe slowing of execution.  I did read in NI documentation that it was important to initialize Network Published SVs, but that Single Process SVs were basically implemented like standard Global Variables, and apparently did not require initialization (although this was not explicit).

I could see initializing SVs to ensure known state on starting, but that shouldn't throw an SV error.  Not sure what "... didn't get properly patched ..." means, either.

This is for code running in a FIRST Robotics Competiton (FRC), so maybe "DS" refers to 'Driver Station'?

I'll try initialization but the issue is so intermittent that I won't really be sure that it was fixed.

[Arham-H]

Richard,

It does seem like DS is for Driver Station. I would recommend posting your question on this discussion forum as it is specific to FRC. This forum community has a lot of experience with FRC and will be in a better position to answer your question. 

Regards 

[Richard1000]

I'll try that, thank you.

[jdr_ni]

FYI, While it's true that a DWarn is just a warning and not a failure, it's an internal warning put in by developers and it usually indicates that something has gone badly wrong inside of LabVIEW. In this context, "DS" stands for "data space". The data space is where the VI stores runtime data (values and the like). In this case, it appears that the variable node has not been properly compiled and is missing it's runtime data. I'm not sure what would cause that, or why it would be intermittent. If you can contact support and provide reproducing code, someone may be able to track this down.

[df86]

If this system is critical refrain from using Shared Variable Engine. I have a project in which I used the shared variable engine and every few weeks the shared variable engine goes down, I looked into it for a few weeks, but the behavior of the shared variable engine is exteremly erratic when it comes to error handling. If you research NIs white papers enough, they warn you about the reliability and throughput of the shared variable engine. Try using the Network Stream VI's. they are still fairly simple to implement but as far as performance go, they far exceed shared vairables. they are the closest thing to using TCP/IP directly, but much simpler to implement.

Good luck,

Dan,

[jdr_ni]

Single process shared variables do not use the shared variable engine. The configuration described here is more or less exactly equivalent to using the RT FIFO palette.

[df86]

jdr,

Thanks. As I was about to quote "I'm having issues with my network published Shared Variable" from the original message, I realized I had responded to the incorrect posting after looking through the person's VI.

Thanks,