Incoming Channels do not use their Default Value

[agomez08]

Describe the bug
Channels belonging to incoming transfer (Rx) do not seem to follow their configured default value.

To Reproduce
Steps to reproduce the behavior:

1. You can find a VS project that reproduces the issue here: https://github.com/agomez08/DSF_DefaultVal_Issue
2. Download and open this project (created with VS 2020 R3 and last DSF release).
3. Change IP addresses as needed.
4. Notice how the incoming transfer channel "ChA" has a default value of 3.0. The same for the outgoing "ChA" with also default value of 3.0.
5. Deploy the project.
6. Look at the UI: incoming ChA has a value of 0.0, even though no values have been received on this transfer yet. The outgoing ChA does show the configured default of 3.0.

Expected behavior
Incoming channels should hold their default value until a valid transfer is received with a new value.

Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

• OS: LinuxRT_x64.
• VeriStand 2020 R3.
• DSF Release 20.3
• Windows 10.

Additional context
Add any other context about the problem here.

[agomez08]

In case it is relevant, using the UDP Plugin.

[rtzoeller]

DSF is a bit unique in how it handles data copies to VeriStand - rather than allocate a buffer internally and then invoke Get/Set Channel Value by Data Reference.vi or Get/Set Channel Value by Block Data Reference.vi on that buffer like other custom devices, it builds a pointer into the buffer used by VeriStand itself, and does low-level data accesses to that buffer.

VeriStand DSF.lvclass:Create Group Buffer.vi is responsible for the first part of building the pointer into the VeriStand buffer. Specifically, it computes an offset into the buffer, but is not yet aware of the actual buffer address. VeriStand doesn't allocate this buffer until just before the first call to the custom device's Read Data from HW. Create Group Buffer.vi also allocates a dedicated buffer which is used for asynchronous operation.

The second part of building the pointer into the VeriStand buffer occurs in VeriStand DSF.lvclass:Initialize Data Ref.vi. This is responsible for setting the address of the buffer, which the previously stored offset is then applied to.

I have not tested this, but it seems like we will need to write the default values to the asynchronous buffer in Create Group Buffer.vi, and then defer the initial update of the inline/VeriStand buffer to Initialize Data Ref.vi (or just after it). I'm not familiar enough with the implementation to say for certain if this mitigates any possible data races - deferring updating the asynchronous buffer until we update the inline buffer seems like it would certainly be too late, since those async loops will have already started - but it seems solid upon first glance.

@Karl-G1 @agomez08 I'm hesitant to pull this change into 20.4, since the timing of those memory accesses isn't clear to me and I'd expect any bugs to be intermittent and hard to track down given their asynchronous nature. Can you clarify the urgency for a fix?

FYI @dbendele.

[agomez08]

@rtzoeller @Karl-G1
We are exploring work-arounds.

If the fix is relatively complex and we are concerned adding it for the next release may affect stability, then it makes sense pushing it for the next one so it can be reviewed with more detail.

[rtzoeller]

@agomez08 FYI the 20.4 custom device packages have gone final, so this won't be in that release. Please continue to update this bug with its urgency as you explore workarounds.