Incorrect data type when writing to FPGA Read/Write Control

[parmstrong42]

I have run in to a problem this morning that is causing me substantial headache.  I am programming a CompactRIO chassis running in FPGA mode (not using the scan engine) with LabVIEW 2012.  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 host machine (acting as the UI) and is received by the RT Host through a network published variable.

The network published shared variable (shared between the RT and Windows system) is a Type Def cluster containing several elements, one of which is a Type Def cluster of fixed point numerics.  The RT system reads this shared variable and breaks out the individual elements to pass along to various controls on the FPGA code's front panel.  The FPGA's front panel contains a type def cluster (the same type def cluster, actually) of fixed point numerics.

The problem comes in the RT code.  After I read the shared variable I unbundle the cluster by name, exposing the sub-cluster of fixed point numerics.  I then drop an FPGA Read/Write Control on the RT block diagram and wire up the FPGA reference.  I left click on the FPGA Read/Write Control and select the cluster of fixed point numerics.  I wire these together and get a coercion dot.  Being a coercion dot hater, I hover over it the dot and see that the wire data type is correct (type def cluster of fixed point numerics), but the terminal data type is listed as a cluster containing a Boolean, code integer and source string, also known as an error cluster.  I delete the wire and check the terminal data type on the Read/Write Control, which is now correctly listed as a type def cluster of fixed point numerics.  Rewiring it causes the terminal to revert back to the error cluster.  I delete the wire again and right click on the terminal to add a control.  Sure enough, a type def cluster of fixed point numerics appears.  Right clicking and adding an indicator to the unbundle attached to the network shared variable produces the proper result.  So, until they are attached to each other, everything works fine.  When I wire these two nodes together, one spontaneously changes to a error cluster.

Any thoughts would be appreciated.

[Zach J]

Hi parmstrong42,

Do you think you might be able to post some screenshots of this behavior? Aside from the coercion dot, does the code function?  Is this behavior seen when using a FXP cluster that was not part of a larger cluster previously (IE can you see this behavior on a smaller, test system)?  Additionally, is the FXP cluster built with the same TypeDef as the FPGA cluster?  Can you see if this behavior occurs when it is based on the same TypeDef?  Let us know!

[parmstrong42]

My apologies I never got back to responding on this.  I regret that now because I got it to work but never posted how.  I ran in to the exact same problem today and returned to this post to read the fix.  It wasn't there, so I had to go through it all over again.

The manifestation of the problem this time was that I was now reading from the Read/Write FPGA front panel control and writing to a network published shared variable.  Both of these (the published shared variable and the front panel control) were based on a strict type defined cluster, just like in the original post.  In this instance, it was a completely different cluster in a completely different project, so it was not a one-off thing.

In addition to getting the coercion dot (one instance becoming an error cluster, recall), LabVIEW would completely explode this time around.  If I saved the VI after changing type definition (I was adding to the cluster) I would get the following error:

Compile error.  Report this problem to N.I. Tech Support.  Copy cvt,csrc=0xFF

LabVIEW would then crash hard and shutdown without completing the save.  FYI, I'm running LabVIEW 12.0f3 32-bit.

If I would then reopen the RT code, the same crash would occur immediately, ad nauseam.  The only way to get the RT code to open was to change the type defined cluster back to the way it was (prior to adding the new element).

I didn't realize it last time around (what originally prompted this post), but I believe I was adding to a type def cluster when this occurred the first time.

So, how did I fix it this time around? By this point I tried many, many different things, so it is possible that something else fixed it.  However, I believe that all I had to do was to build the FPGA code that the RT code was referencing.  I didn't even have to deploy it or run it... I just had to build it.  My guess is that the problem was the FPGA Reference vi (needed to communicate with the FPGA) is configured (in my case) to reference a bit file.  When the development FPGA Main.vi ceases to match the bit file, I think that bad things happen.  LabVIEW seems to get confused because the FPGA Main.vi development code is up and shows the new changes (and hence has the updated type def), but when you ask the RT code to do something substantial (Open, Save, etc), it refers to the old bit file that has not yet been updated.  That is probably why the error getting thrown was a compile error.

I'm going to have to do an additional round of changes, so I will test this theory.  Hopefully I will remember to update this post with either a confirmation or a retraction.

[JAnthony]

I just encountered the same problem described in the first post. I have attached screenshots to show that this is still not fixed.

Notice that when the cluster is connected to the FPGA Read/Write control the cluster is coerced.

This image shows that it is being coerced to an error cluster.

This image shows that the type of the incoming cluster is indeed a cluster of 8 booleans.

This image shows that the type of the accepting FPGA Read/Write Control terminal is indeed a cluster of 8 booleans.

Please report back on when this is going to be fixed. In the meantime, I will have to manually divide my clusters into individual controls which is a signficant pain in my behind.

[crossrulz]

One of your problems is that you are passing around a strict type def cluster when the terminal just wants a cluster.  That is likely what is causing your coersion.

[Kapur]

I did not use a published shared variable but believe my solution might help. I ran into error -61205 with NI 6581 +PXIe-7966R. "LabVIEW FPGA: an item of the selected name is present but is a different data type than that configured in the Open FPGA VI Reference"

In the Host VI, the variable of interest "No. of Bits" was packed in a cluster "SPI Protocol Configure 0". I used the FPGA Read/ Write Control to update "SPI Protocol Configure 0". In the In the FPGA VI, "SPI Protocol Configure 0" cluster was duplicated and also made a Type Def. In addition, the variable was called "Number of Bits" (note different label). Here is what I did to fix this. First, changed label of variable of interest in Host VI to match the FPGA VI label. Second, disconnected the cluster in FPGA VI from Type Def.. "SPI Protocol Configure 0" is a cluster in both Host VI and FPGA VI (earlier Type Def). Hopefully, this helps someone.

Thanks,

Mohit Kapur

[svpug]

Never found any solution to this problem. Disconnecting FPGA control from typef gives much headache when changing the control. My code works though even with coercion dot.

I guess the problem is that when Read/Write control is still not wired, and I check in its node the data type of the FPGA control, it is not shown as typedef, and I try to wire typedef to it. As I see from your screenshots you have a similar issue. However, I don't understand why this happens. I double checked and see that my control in FPGA vi is connected to typedef.

[GiantDeathRobot]

Hi svpug,

This post is about two years old. You might get better visibility by posting to a new thread. If you could grab some screenshots like JAnthony posted, so we can get a visual on what you're seeing, and post that to a new thread, that would probably get you the fastest results!

[nanocyte]

I ran into that error code just now and I was able to identify the issue and workaround it. The FPGA had an array lets call it basket. Basket was an array of booleans labeled Apples. In my case, my FPGA reference control had Basket but its subtype was labeled oranges. That didn't trigger a type mismatch at edit time but it did throw that error at runtime. Fixing the label name on the FPGA reference control fixed the issue for me.