Shift registers and non DBL waveforms

[xl600]

I ran into this when trying to create a complex waveform conversion tool.  Here's a simplified re-creation of the issue (Yes, I know.  This is a dumb example, but it demonstrates the issue).

Both the input and output are U32 based waveforms.  The top FGV shows a coercion dot and a DBL Y value.  The bottom shows the expected Y type and no coercion.  The only difference is whether I use the waveform in input of the build waveform VI.  This is an issue for any use of an unitialized waveform shift register of a non DBL variety.

Can anyone explain why this is happening?  And is the bottom workaround the right way to deal with it?

Thanks,

XL600

[altenbach]

Can you attach your example VI? (Sounds lik a possible bug).

I prefer using feedback nodes for FGVs, eliminating the vestigial while loop.

You can globally intitialize them with a constant of the correct datatype.

Maybe it solved the problem?

[xl600]

I tried that as well but it didn't seem to help.  The initializer terminal just gets a coercion dot as well.

Here's the VI...

[altenbach]

---

@xl600 wrote:

Can anyone explain why this is happening?

---

Looks like a bug to me. (I reported it here for further investigation)

---

@xl600 wrote:

And is the bottom workaround the right way to deal with it?

---

 No. The bottom code is equivalent to just wiring the waveform across unchanged. If you do that, you also don't get a coercion.

This is the corerect workaround for this specific scenario. 😄

 

[xl600]

The workaround I'm using does something interesting to the U32 Y data rather than copying it straight across... That was just an example to demo the bug.  My VI actually appends data to the Y array as it comes in from a network transmitter.  But it's in U32 format so when I tried to append using the waveform in, I noticed the bug (Since it kep forcing my input to DBL causing an incorrect coersion of my U32 data).

Thanks for reporting the bug!

[Jacobson-ni]

I filed CAR 560087, "Compiler Changes Waveform Y Array Data Type Unnecessarily" to describe this behavior. I wasn't sure exactly how to express this CAR so I will show how I explained it in the report. Please reply if this is incorrect so I can fix it on our end.

1. Delete U32 WFM In and clear broken wires. Notice how the Y Array representation has changed to DBL and there is a coercion dot on the U32 WFM Out

2. Undo all actions.

3. Delete the input to the Build Waveform function.

4. Delete U32 WFM In and clear all broken wires. Now notice how there are no coercion dots and the Y Array representation is still U32.

If there is information I left out of if I am missing the point please correct me.

[xl600]

That demonstrates the issue, yes.  Thanks.

[Alexander_Sobolev]

It describes the issue, but there is a possible confusion:

Input type specifying control and shift register initializing constant have the same name "U32 WFM in". It is not completely clear what to delete.

I would either

edit constant name, or

remove constant, connect control to initialize shift register and say "remove initialization of shift register" instead of "delete U32 Wfm In"

PS. confirming bug in LV 2011. Though similar clusters work fine.