coersion do: one more type def thing

[OPCler]

Dear all,

althoug there are already some threads about this i did not find an answer tot he followeing:

why does the coersion dot appear in the middle branch?

This VI takes Data from a measurement and from a simulation and based on user settings it forwards one or the other to output 1. I just added outputs 2 and 3 because they dont produce the coersion dot.

thanks  for suggestions on how to fix this!

[billko]

I don't have LV on this computer so I can't see the code, but I'm guessing it's because you typedef'd the array when really it should've been the element that was typedef'd.

[Bob_Schor]

You don't provide all of the VIs and Controls to answer your question, but I suspect it may be due to the following, shown in the Snippet -- if you have an Array saved as a TypeDef (as is Real Array and Real Array 2, here), then taking the elements (here, of Real Array) and building another Array from it just creates an array, but not an array that matches the TypeDef.  You can check this by holding your mouse over the wire while Help is active -- it will show you the "type" of data in the Wire.  Note that the Type on the wire into the For Loop is Real Array, TypeDef of 1-D Array of Numeric, while the type on the output wire is simply 1-D Array of Numeric.  They are different (in name, only), hence the Coercion Dot.

Bob Schor

[OPCler]

I think you both pointed it out such that i understand why it shows the dot.

but if so, i cant imagine to manipulate the data and then feed it back to something of the original typedef. or am I wrong with this? What error could be introduced if i dont change the current VI?

Thanks!

[Gregory]

You can get rid of the dot by using a shift register. Use the "Replace Array Subset" with index "i" (the loop counter). The indexed tunnels are more intuitive though, so I think it's easier to just let it coerce into the typedef.