11-04-2013 05:15 PM - edited 11-04-2013 05:32 PM
I've been working for a while now trying to get a 2-axis system running on a cRIO-9076 chassis with an NI 9263 AO module and an NI 9401 DIO module. Due to some particulars with our control scheme, we needed to write our own PID loop to run on an FPGA. I *think* I have the FPGA side of things running smoothly. I had a single axis RT and FPGA code set running (based off example VI's) but I'm having lots of trouble getting two to work. Currently, running *just* the FPGA VI seems to work, but when running the RT interface VI, the Scan Engine will go into Fault mode fairly shortly (within a minute or two of running) with error code -66460 "LabVIEW: The I/O scan time exceeded the NI Scan Engine period you specified on the Scan Engine page of the target properties dialog box."
Right now I'm running at a 20 ms Scan Period and a 200 ms Network Publishing Period. Everything seemed to be working fine with a 10 ms Scan Period earlier. I'd like to get down to 10 or even 5 ms, but I don't know exactly what needs to happen during the Scan Engine Period.
What can I change in order to reduce this timeout error? I currently have the Chassis I/O hardware terminals, 6 digital inputs (two quadrature encoders with index), and 2 analog outputs (drive signals for each axis).
I'm not using the Scan Clock hardware terminal on the FPGA to control timing (as I saw in some examples) but I'm using a synchronization loop with a Begin and End Sync Transaction and an Update Scan Control VI to synchronize the RT stuff with the FPGA stuff. My main axis loop (sending position targets, receiving current position/index, etc) is in Timed loop that is synchronized to the Scan Engine. I don't think this loop is taking terribly long to run, but of course I could be mistaken.
Any advice here on how to reduce resource usage during a single Scan Engine cycle? I must admit I'm not entirely sure what the Scan Engine is doing for my project, since I'm reading in all of the hardware signals manually on the FPGA. I'm pretty new to this as well, so if anything doesn't make sense please let me know and I'll attempt to clarify it for you.
Thanks for any help you can offer!
Bert
Edit: I'll also mention I have a lot of controls and indicators on the front panel of my FPGA VI -around 120 or so for a slew of position setpoints, some debug intermediates, scan synchronization controls, etc. I'd venture a guess that 70% of them are FXP with the rest Bools. I have two clusters with several elements in them but no arrays. Most of these are used to communicate configuration settings, and therefore don't need to be updated in real time at the full Scan Engine period (like the position command and feedback). I don't know if those numbers affect resource usage during the Scan Period. I can try changing them to some other type of data transfer, but that's the way they were implemented in the examples and it's going to be a pain to switch it all if I don't have to.
11-05-2013 11:14 AM
Hi Bert,
If you increase the Scan Period to more than 20ms, do you still see this error? I understand that you would like to get this time down, but for now this could help us troubleshooting if your timing is close, or if something else is going wrong in the application causing this fault.
Would it be possible for you to upload your project? It would be easier to diagnose what might be causing these timing issues if we could see the implementation. Do you have a support contract with National Instruments? If you have support and would prefer not to post your code online, you could also create a service request at ni.com/support.
Thank you!
11-05-2013 01:08 PM - edited 11-05-2013 01:29 PM
As best as I can tell, 20ms is around the "sweet spot". I've tried it at 10ms and almost immediately started getting faults. At 20ms it's a bit intermittent- sometimes it'll run fine for several minutes and then get a fault, sometimes not. I've tried running at 30ms as well but it's hard to prove a fault would *never* happen.
Part of my problem is that I don't understand what all needs to happen during this timeframe. Is this an internal loop that's running too slowly, or is my Axis interface code running too slow? Would having too many front panel controls/indicators slow down FPGA access? Should I be using some type of buffer to send configuration data, and keep front panel controls to a minimum?
I understand that front panel controls can use up memory in an FPGA, but I've got enough space, so I assumed that would be OK, but I'm certainly not sure about any of this as it's all quite new to me.
I did go ahead and start a service request, but I noticed it was possibly a 2-day turnaround. I'm hoping someone can give me a hand on the forums as that's both quicker and more easily accessible for future users with similar problems.
Edit: I just did a run at 30 ms, and got the fault about 6 minutes into the run. I've got the RT VI running with the front panel on my computer, along with the Distributed System Manager, and am working on other things while it runs. Not sure how repeatable this will be but take it as it is.
11-05-2013 03:15 PM
Doesn't look like I can edit my last post, so apologies for double posting.
I am also getting a second fault after running for a while. I went away to do something else and left it running (accumulating faults) and saw this. It may be related to the initial error but I'm not sure. The second fault is 65512: CompactRIO: The data transfer for some I/O variables on this target could not be completed in the allotted time and the updates for some values may have been delayed. Increase the Scan Period to avoid this problem.
11-06-2013 04:47 PM
Hi BertMcMahan,
In order to help narrow down what's taking up this time, it would really help to see your project, or at least some screenshots of the real-time loop. If you'd prefer to send this in on your service request instead of posting it publicly, you can absolutely continue to work on it that way.
Thanks!