Error: Master Copy for Type Definition Could Not Be Found

[GregFreeman]

See screenshot below please. The typedef is there (I navigated to it via windows explorer and it's not greyed out in the code), and my FPGA VI is not broken, which uses the exact same control. I also created these constants by right clicking and choosing create constant, so it's not as if I'm loading the wrong enum. Has anyone seen this before?

[Ben]

No I have not seen it but I'll guess a bit...

The FPGA code is intended for use on FPGAs and some of the functions can only be used for an FPGA. Which environment the code is opened in is determined by the project, is it under an FPGA target.

So if you navigated to the type def from the diagram that was opened from the project, LV maybe able to recognize the type def was for the FPGA context.

opening from the Windows explorer may have opened it i a diferent project.

Done guessing,

Ben

[GregFreeman]

Well, the typedef is in an autopopulating folder underneath the FPGA target. But I haven't changed this and it worked last week...only thing I changed is a reinstall of LabVIEW because I got a new hard drive. I'll try moving the control around within the project and see if it makes a difference.

[GregFreeman · Accepted solution]

Because I am a bad scientist, I do not know exactly what fixed my problem because I changed more than one variable at once.

Here's what I did:

Removed auto-populating folder from project (doubt this mattered, still broken after this)

Changed my open FPGA VI reference from using a bitfile to using a VI, selected my FPGA VI, NO MORE BROKEN RUN ARROW! YAY.

The above finding led me to go look at my FPGA bitfiles on disk -- I had two of them (weird). Usually a compilation just overwrites the older file.

Just in case the names give any insight, they are:

Older:  NASATTRControlCo_FPGATarget_FPGAMain_25B3817B.lvbitx

Newer: NASATTRControlCo_FPGATarget_FPGAMain_25AF817B.lvbitx

I went back to my open FPGA VI reference, and selected the most recent bitfile that I compile this morning -- No more broken run arrow.

I have a feeling this may be due to selecting an old bitfile, but usually if the bitfile doesn't include the control, it won't show up in the read/write control node. If anyone from NI would like to comment on this I'd appreciate the insight on what may have happened.

I am wondering if it's because I installed 2010 SP 1? Who knows but it's fixed now.

[MatthiasF]

Hi,

I have just experienced the same behaviour with LV 2010 SP 1.

What happened:

1. Development of the application (LV RT using a 7851 LV RIO board) in the lab, tested to work

2. Commit via SVN and checkout at test stand where it shall be deployed

3. Read/Write VI calls that access a cluster in the FPGA interface broken with the error message given in this threads title

4. Deleted bitstream, rebuilt it

5. No more broken VIs

Is there a way to avoid this? I don't want to rebuild my application each time at the test stand if I do updates in my lab and I'm very much into testing thoroughly and then just deploying it.

Best regards,

Matthias

[MatthiasF]

Hmm, nobody has an answer? It's really bugging me because I first lose time when I have to rebuild the bitstream and then reopen the Open FPGA VI Reference and compile my application and I lose the good feeling of having a tested bitstream that I can put into the production environment. Luckily my FPGA design is not (yet) at the limits so it builds without problems.

I suppose the information about this type definition is somewhere in the project and when I get the project on a different machine from SVN this information is lost and gets back into the project with the synthesizing process, so maybe there is a simpler way to do this.

Cheers,

Matthias

[stoneadam]

This is still an issue in 2015 SP1, I have a single variable that triggers the error.  If I change to openning the VI instead I don't have issue-- unfortunately one of the solutions to error 61017 (which says to recompile your VI) is to use VI as your source for the FPGA VI reference-- it seems to be a circular set of issues.