LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Compile Error in FlexRIO FPGA when using derived clock

Hi Caleb,


It appears I sent you a bad version. I was actually making that change for all the variant clocks I tried. I.e. Every time I tried a clock, I would update the single cycle timed loop where the DRAM is read out from. Your solution doesn't take into account the fact that VI's with no DRAM in them, and no derived clocks being used, still refuse to compile if there is a derived clock defined in the project. Subsequently these same VI's (completely unchanged) compiled sucessfully when the derived clock was removed from the project definition. I have also been keeping in touch with Australian tech support and one of their engineers took my code and compiled it successfully on his machine with a derived clock. When he sent me his project it refused to compile citing the same error as in the original post. It appears that one of my dependencies is corrupt, but I don't even know how to figure out what it is? When I attempted to compile the australian engineers version of my code, it stated I needed to rescan my CLIP file for the NI-1483, I've asked him to send me his version of the CLIP file as that's the only thing I can think of testing.

 

As an aside, can you confirm whether it is possible to read from and write to the DRAM at different clock speeds? The options seem to imply that this is the case.

 

0 Kudos
Message 11 of 16
(838 Views)

Alex:

 

Yes, it is possible to read and write DRAM at different clock speeds.

 

As for the compilation issue, that's defnintely not the correct behavior you're seeing. If there's an issue with a compiler dependency, I'd start with the vision driver; the CLIP seemed to be off when you got the project back, so that's a little bit of a trouble sign. If that doesn't work, then you'll probably want to move on and reinstall the FPGA module and your RIO driver (in that order).

 

Let me know if that helps. It does sound like a compiler/dependency issue at this point, so I think a software reinstallation is our likeliest option for sorting things out.

 

Caleb Harris

National Instruments | Mechanical Engineer | http://www.ni.com/support
0 Kudos
Message 12 of 16
(818 Views)

Alex:

 

A few addendums:

 

Before you go reinstalling, I got a copy of the CLIP that you can just use to replace the existing stuff (see attached).

 

I probably wasn't terribly explicit about the testing. The R&D engineer I worked with ran several iterations on our farm (around 9 compiles) to narrow down the behavior. He made sure that the derived clock wasn't an issue in any of the cases, and that the VIs compiled with or without the derived clock in the project. I've attached the testing report on that, as well (it's the PDF).

 

One thing that's suddenly occurring to me: the compiles were done in 2010, not 2009. I'll run another one on the project in 2009 to make sure I can't replicate it there.

 

 

Caleb Harris

National Instruments | Mechanical Engineer | http://www.ni.com/support
Download All
0 Kudos
Message 13 of 16
(803 Views)

Alex:

 

I've discovered that the code you uploaded is too new to open in 2009, but you listed the 1483 CLIP from the 2009 LabVIEW directory. Are you running 2009 or 2010?

 

Also, have you had any luck replacing the CLIP? Does the behavior change at all?

 

-Caleb

Caleb Harris

National Instruments | Mechanical Engineer | http://www.ni.com/support
0 Kudos
Message 14 of 16
(781 Views)

Hey Caleb,

 

Yep, got a successfuly compile with the new CLIP file :D.

 

Regards,

Alex

0 Kudos
Message 15 of 16
(769 Views)

Awesome, thanks for letting me know!

 

Good luck!

Caleb Harris

National Instruments | Mechanical Engineer | http://www.ni.com/support
0 Kudos
Message 16 of 16
(757 Views)