Shared Variable bug when unflattening class from string

[cirrusio]

Hello all,

I have an odd problem that I have never seen on an existing application.  This problem seemed to crop up after bumping from 2017 to 2018.  Basically, I have a real-time application that is sending an object to a client on a windows machine by first flattening the object to string and then writing that string to the shared variable.  On the client side, when I now attempt to unflatten, I get a 1403 error stating that the data is corrupt (not 1400 saying that the data is of the incorrect type).  This happens when I am running the RT target and client as executables and when running in the debug (LV) environment.  Does anyone have any thoughts on this?  Could this be a class version mismatch (although I am not sure how this would happen as the origin of the class in the project is from the same disc for both the client and the real-time machine)?

And, as a side note but related (more funniness) - errors are only thrown when the output is wired to something (such as a flat sequence structure).  Why would the error output be dependent on whether the output of the Unflatten from String function is wired?  Never noticed this behavior before.

Thanks, m

[wiebe@CARYA]

---

@cirrusio wrote:

And, as a side note but related (more funniness) - errors are only thrown when the output is wired to something (such as a flat sequence structure).  Why would the error output be dependent on whether the output of the Unflatten from String function is wired?  Never noticed this behavior before.

Thanks, m

---

IIRC, some Property nodes, Format Into String and Flatten\Unflatten and probably other functions do that. It's an optimization thing. No outputs means code can and will be skipped. That saves CPU, but is a bit weird in corner cases. 

[cirrusio]

> That saves CPU, but is a bit weird in corner cases. 

Thanks - forgot that LV will optimize to this extent.  And to be honest, I have only seen something like this on the FPGA.  Do they have an optimization setting on the compilation of VIs so that things are not optimized out?  In C you might add volatile to the declaration...

[wiebe@CARYA]

---

@cirrusio wrote:

> That saves CPU, but is a bit weird in corner cases. 

Thanks - forgot that LV will optimize to this extent.  And to be honest, I have only seen something like this on the FPGA.  Do they have an optimization setting on the compilation of VIs so that things are not optimized out?  In C you might add volatile to the declaration...

---

No, regular LV does it as well. It isn't a problem that often in the wild though. When it does, it can be quite a puzzle.

It happens to me often while scripting. For instance (IIRC) getting a terminal's connected wire reference doesn't give an error if the terminal isn't wired, even if there's no wire connected. It does give an error when the reference is used. So to test if there is a wire connected, the reference needs a stub, or there won't be an error.

[cirrusio]

So, I was able to run a simple test and closer examine this behavior.  In this test, I simply flattened the class to string every second on the server side and passed that string to the shared variable.  I then had a VI on the client (Windows) side read it several different ways.  What I am finding is odd:

• If the VI reading the shared variable is set to just run once (not in a loop) and the timeout is too short, I get the 1403 error regardless of how many times I hit run.
• If the timeout is set to a longer period, and the VI is set to run once (not in a loop) then I will not get the error 1403.
• When I get 1403, I get it for all variables regardless of the complexity of the data.  This includes just passing a simple string.

The code for testing is shown below.  The server code is shown on the left hand side while the client side code is on the right.  I have tried this with both the stop control on the client side wired and unwired (as pictured).  I have set the timeout on the client side (right hand) to 0, 10, 100 and 100 ms.  The error is not thrown at 1000 or 100 but definitely at the other set points.  Does anyone have any thoughts?  This problem has cropped up recently with an existing application that has been running since at least 2013 using shared variables.  I am currently running LV 2018, v18.01f.  This may have started with the application of .01f, but I can't be certain.  I also can't be certain that it didn't begin with the upgrade to 2018 period.

[cirrusio]

> No, regular LV does it as well. It isn't a problem that often in the wild though. When it does, it can be quite a puzzle.

So, you are saying that they don't have a way to change the optimization level?

[Mark_Yedinak]

I'm not sure about the specific issue you are seeing with the error being generated with LV 2018 and not in earlier versions. I can only guess that they may have changed the error handling to be less forgiving or that shared variables have lost some performance.

With that said, I would recommend using a timeout of at least 25 ms on shared variables. I generally don't use them but I do tons of networking and know that network traffic can easily add latency of 10 to 20 ms to traffic. Of course this depends a lot on where and how the devices are connected (how many switches between the devices) and the general load on the network itself.

[Mark_Yedinak]

You can in the LabVIEW options. The setting is under the environment options near the bottom of the page. You would have to experiment to see if the level would affect this behavior or not.

[cirrusio]

Thanks Mark.  So, the timeout in the application was 100 ms and the 1403 error was being thrown.  So, we are 4x higher than the recommended 25 ms.  And, in the application, I have tried to up the timeout to 1 s to no avail (and the reality is that I can't have my app sit around for a second waiting for data as this causes degradation of the UI performance).

[Mark_Yedinak]

---

@cirrusio wrote:

Thanks Mark.  So, the timeout in the application was 100 ms and the 1403 error was being thrown.  So, we are 4x higher than the recommended 25 ms.  And, in the application, I have tried to up the timeout to 1 s to no avail (and the reality is that I can't have my app sit around for a second waiting for data as this causes degradation of the UI performance).

---

I completely understand that. PErhaps this is a bug that was introduced. I would suggest you contact support with a simple example that demonstrates this issue.

WIth respect to your application, could you have a separate task that effectively monitors the shared variable. It can use a short timeout and ignore the timeout error. It would have he most recent value available and use that when it gets an error. If no error, update the value. By nature a shared variable is an asynchronous update and you should just use the most recent value if there was no update.