bmouring

From what it sounds like, I bet that James' notion was spot-on: the last closing of the session was resetting the FPGA, which is fine but will not result in the FPGA restarting (and, as he noted, opening a session to a non-running FPGA VI is perfectly valid, it's just not running). Ensure (at least) one of the following: ensure that all closing sessions are not configured to reset the FPGA (and ensure that you do not abort the RT VI(s) that open the session(s)) configure the Open Sessions to force a download (if you do not need to maintain state in the FPGA from one opening of the sessions to the next) On opening a session, force that the VI be running (and possibly filter the warning that occurs if the VI is already running)

The example that I keep tucked in the ol' noodle is the exceedingly bizarre situation of a FXP number with a WL of 1 and an IWL of -1024, meaning you have 1 bit to represent the value (so only two numbers in the range) and that they are the exceedingly small numbers around 0, so ±2^-1024

I would recommend getting a VNC server setup on the machine that you will be remoting onto (it allows you to show what you are doing and basically act like a multi-player computer). Then, when you run into an issue/want to review something with a coworker they can see what you can see. I've used UltraVNC on my old Windows machine with a fair amount of success (was out of the office for a few months, was able to do VI code reviews this way)

I should really check these boards more often: yes, NI releases support for our internal Digital Electronics FPGA board (which can dock to an ELVIS II or be used separately) as well as the Spartan 3E XUP (500K version) board, however support for that board, as James noted, is limited to academic use only.

If you look further down in the results (search for "Starting program map") you will see that you are well within the capabilities of the part, LabVIEW FPGA simply isn't reporting it correctly at the top (I'll look into this one for sure). I do notice however that it looks like you're using a large memory that doesn't seem to properly be mapped to a Block RAM, when I have a bit of time I'll look into why it's not being inferred properly. Out of curiousity, do you still have this project?

bluesky96 The latest release of the Spartan 3E Starter board support has been released for LabVIEW 2010. It can be downloaded here

Hi bluesky96, Mellroth is indeed correct: the interface code behind the scenes is using LV semaphores to try to make things safe. It was determined that this code was problematic (as you're seeing now) and was redesigned in the upcoming release of the package to be much more robust. As such, unfortunately there is precious little you can do to solve this particular problem other than trying to reconfigure your design a bit to try to avoid the issue you're running into or wait for the impending release