Incorrect data type when writing Typedef to FPGA Read/Write Control

[svpug]

I run into a problem described in one of the topics from 2013. I still found no soultion yet neither myself nor on the forum and I would like to raise the topic again. May be some of you know the way.

The problem is wiring Typedef to FPGA Read/Write Control connected to the same Typedef. I can't get rid of a coercion dot. Terminal data type is shown as an Error cluster. But I'm sure that it is not. Here are few screenshots to illustrate.

The constant  is connected to the CycleTypes.ctl

FPGA Read/Write Control with the Cycle Type FPGA control selected as input terminal.

and  we can see that the type of the constant is non-strict typedef CycleTypes.ctl

On the next screenshot we can see that the type of the FPGA control is the same enum. It is not indicated as Typedef however

But if I go to FPGA VI I can verify that this control is connected to the same Typedef.

When I connect two, I get this coercion dot and the type of the FPGA Read/Write terminal changes to Error cluster:

Similar behaviour is observed when reading from Typedef FPGA inicator to Network Published Shared Variable that is connected to the same Typedef.

I am programming a cRIO-9035 running in FPGA mode with LabVIEW 2014.  I am using the FPGA Read/Write Control function to pass data from the RT Host to the FPGA Target.  The data the RT Host is sending comes from a Windows UI and is received by the RT Host through Network Stream.

[Christoph_D]

Hi,

the behaviour is already known as CAR 373416, which has not been fixed.

As far as I know it is 'only' a cosmetic error. Or do you have problems with executing the code?

Regards,

Christoph

[svpug]

Software wasn't exhaustively tested yet, but it seems to work.

[JJMontante]

I have had the exact same problem.  The FPGA VI appears to lose its ability to propagate a front-panel control as a type-def when viewed by the read/write method of a host VI.  

• LabVIEW 2017 (32-bit) with FPGA module. 
• FPGA Top Level uses a non-strict type-def.  This type-def consist of a cluster containing mixed numeric types and one boolean.
• In simulation (using 3rd-party simulator Questa 10.2), the code functions correctly despite the coercion dot and the strangness in the help window.  

However, it obviously is concerning, especially if/when my team starts running nightly scripts of VI Analyzer.

I'd appreciate if we could work out that CAR.

-Jim

[GRE_]

I can see the same behavior in LabVIEW 2019 (19.0 32-bit Japanese). 
It is a concern since making changes to the typedef will break the code in the application interfacing with the FPGA VI.