Passing values to XNet Controls (Bug?)

[EdDickens]

I've run into something that may be a bug.

I'm trying to pass some values from a custom Step Type to XNet controls on a VI. The Step Type has parameters added for each type of XNet control, so in the sequence, they are passed as "Step.Xnet_Interface", "Step.Xnet_Database" and "Step.Xnet_Signal". These are all of type "LabVIEWIOControl".

When the first step runs, it seems to correctly pass all the values to all the controls. When the second step runs with different values, the XNet controls do not get updated with the new values. They instead stay at the value from the first step. 

The VI also has a string control for each of 3 XNet control types that gets populated with the "DeviceName" portion of the IO Control from the Step Parameters. These do get updated correctly.

The attached contains a sequence, the VI, a Degub.ini which is the Types configuration and a couple small XNet database files just to have a couple to work with.

The first two steps in the sequence are run from the custom step type. The last two are just LabVIEW Actions running the same VI. The last two steps from the Action do correctly update all the controls while the first two from the custom step type only correctly update the String controls.

Am I missing something simple here or is this not working correctly?

[~jiggawax~]

I was able to reproduce this.  It looks like a bug to me as well.

I even tried changing the VI settings to Preallocated clone reentrant execution and it had not impact on the bahvior.

I also changed the step to load dynamically and unload when step executes.  I don't think this is happening because it is a substep.  It still exhibits the same behavior.

I even changed your substep to pass just the device name on the LabVIEW IO Controls and not the entire container.  Same behavior.

Also, I tried changing it to a Pre-Step instead of a Post-Step.  Same behavior.

Truly odd behavior in my opinion.

[EdDickens]

It's good to know it's not just me.

For now I've worked around this issue by changing the XNet controls to Strings and casting them to the proper XNet controls type in the VI's.

Seems to work so that's what I'm going with.

Thanks

Ed