01-06-2017 12:31 PM
The error codes are in the ErrorSelector.ctl enum. The VI that has generates them is in CustomErrors.vi.
I didn't test with any particular waveform. I just saw that I was getting random noise that looked about right for my system.
Error 537955 implies that your RT code is trying to handshake the interupts but your FPGA code is off in the acquisition loop so it isn't available to do the handshake. If you want, you could drop somethingl like this in your acquisition loop to verify that.
Check your SAR Acq Main front panel to see if any of the error lights are activated there. You'll probably want to hit the abort button to get out of that loop. Then try again.
01-10-2017 09:21 PM
Also can you upload a screenshot of your graph what it show's when you're actually acquiring noise.
01-10-2017 10:10 PM
So we added the Acquire feedback loop to the FPGA SAR file and it worked the very first time we ran it. We picked up adequate noise and played around with it. Then after that it wouldn't work anymore. If we stopped the program and tried to run it again we would get the same ConfigTiming.VI Error 537955 again. So I'm sure everytime you've downloaded our file and ran the loop im sure it worked. Try to stop and run yours a second time and see if you get the same error we do. It doesn't matter if we close the VI and re-open it or re-set the RIO even it still does the same thing. The one way we get it to work is to OPEN the FPGA SAR file and run for a second and then abort that file. Then Re-open our main acquisition VI with the graph and then it will work. It's like after it's done the handshaking one time you need to re-run and abort the FPGA SAR file separately to get the main file to re-handshake again. How do we solve this problem.
01-11-2017 07:34 AM
NI has a workshop based on the sbRIO evaluation kit that provides a rich material on how to build from scratch an application.
You can access the material at:
01-11-2017 03:48 PM - edited 01-11-2017 03:54 PM
Yes, I saw error 537955. When the Cont Acq.vi stops, it leaves FPGA_SAR.vi acquiring so it can't go back and acknowledge your interupts. You can see that's the case because the Acquiring LED is blinking. Sometimes, that's acceptable because, RT applications are normally headless and don't have a stop button. I did notice a difference between your example an the shipping example that might solve the issue for you. You are missing the close at the end which should reset the FPGA back into a non-running state
You can add in a reset node for good measure too.
01-12-2017 10:34 AM
Thank you for all your help. Everything you suggested to do has worked. We tested the VI with a function generator this morning and everything worked. We were succesfully able to close the VI and then re-start it and begin re-acquiring the waveform again. The next step is to get the generation portion of the code. We re-wrote the fpga code a little bit and added in a portion for Sine-Wave generation. We wanted to be able to generate Sine-Waves on the FPGA. Our code works. But the output the receive portion is receiving is digital. Are we going about generation the wrong way or is this simply the only way to do it. I've uploaded the graphs and what they look like when we generated and received using a local loopback. I also attached the new code VI as well. The cont acq is the one you want to run.
01-12-2017 01:18 PM - edited 01-12-2017 01:19 PM
The AO0 and AO1 terminals take in a voltage. That is if you wire a 1 to them, you should get out ~1 volt. Your output into AO0 appears to be ±32,768. I'm sure your intention isn't to output kilovolts.
One way you could scale the data is to use Reinterprete Number.
One thing that's greate about LVFPGA is the simulate feature. You should be able to switch your FPGA target to simulate mode and then you'll be able to probe wires and figure out why things aren't working as you expect. The data coming out of reinterperate should be scaled by 2^-11 so if 32,765 comes in, ~16 should go out which I'm guessing is closer to your intended output range
01-12-2017 02:46 PM
@nanocyte wrote:
The AO0 and AO1 terminals take in a voltage. That is if you wire a 1 to them, you should get out ~1 volt. Your output into AO0 appears to be ±32,768. I'm sure your intention isn't to output kilovolts.
One way you could scale the data is to use Reinterprete Number.
One thing that's greate about LVFPGA is the simulate feature. You should be able to switch your FPGA target to simulate mode and then you'll be able to probe wires and figure out why things aren't working as you expect. The data coming out of reinterperate should be scaled by 2^-11 so if 32,765 comes in, ~16 should go out which I'm guessing is closer to your intended output range
So by adding a re-interpret number It will allow me to scale down the voltages? Is the signal output actually analog or is it digital? The scale I'm looking for is just -10V to 10V since that's the maximum input the RIO can actually read.
01-12-2017 03:10 PM - edited 01-12-2017 03:13 PM
The signal output is a created by a digital to analog converter so a digital signal goes in and a voltage goes out. Because of the digital input and the nature of DACs, if you are able to generate voltage x, you probably can't generate voltage 0.0000001+x.
I wouldn't say "reinterpret" lets you scale down voltages, reinterpret lets you scale down digital values so that they are in the range more inline with the voltages you want to generate. In my example I scale ±32768 to ±16. If you wanted to output 1V, you would want to make sure that the number going into reinterpret was 2048 if you wanted to generate 10V you would want 20,480 going into the reinterpret function.
01-16-2017 07:08 PM
Hi Thanks for replying. I believe it is similar issue but I am using the original the deliver and I do have the close FPGA reference at the end. I also added reset node to make sure but it still doesn't work!