07-11-2011 04:09 PM
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.
07-12-2011 07:15 PM - edited 07-12-2011 07:15 PM
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.
07-13-2011 09:48 AM
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.
07-15-2011 10:48 AM
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
07-15-2011 09:21 PM
Hey Caleb,
Yep, got a successfuly compile with the new CLIP file :D.
Regards,
Alex
07-18-2011 03:55 PM
Awesome, thanks for letting me know!
Good luck!