Has anyone been successful in triggering an interrupt using a DIO in LabVIEW? I have verified that my signal is present on the correct DIO port and have tried different DIO ports, but still no luck.
Anyone care to give it a try?
I haven’t tried this year yet, but I have been successful in the past (2013 was the last year I think I used it). Could you share your code (screenshot will do) and circuit?
Some things to keep in mind, the DIO ports are pulled high to 3.3V using a 40 kOhm resistor. If you want to trigger something, you have to pull that signal to ground. You’ll probably want to use a falling-edge trigger.
We used them last year in LabVIEW and they worked.
Can we see a screenshot of your code? Including the Open VI and then the actual wait for interrupt VI.
Here’s the code! Ignore everything else around it except for the interrupt.
This code should blink the “Timed Out” LED 5 times/sec. There is a square wave going into MXP DIO0 on the RoboRIO.
Thanks!
There are several mistakes that I see. From what I can tell (and would have been important to mention) is that you’re trying to create an interrupt for your gyro.
-
The Interrupt Wait block will wait indefinitely for an interrupt. The timeout is disabled by default, and you do not have a non-default value going into it. So once your interrupt hits, it will return ‘false’ on the Wait block, no matter what (since the timeout is disabled). So it will always output ‘false’ to the “Timed Out” indicator.
-
You should not have any sleep timers in an interrupt able loop. That sort of defeats the purpose of an interrupt (meaning to do something immediately). If your gyro is creating an interrupt 1000 times per second, it will still only read it 5 times per second because of that 200ms wait.
-
You mention that there is a square wave. Is that a constant square wave, or just one transition, from say, low to high. Keep in mind that the all of the DIO ports are pulled-up internally to 3.3V on the RoboRIO using a 40k resistor. Did you measure that while it was connected to the RoboRIO? I have a feeling that the gyro might pull-down when not asserting the interrupt, and pushing high when asserting the interrupt. That won’t work with the RoboRIO. You’ll have to create invert that signal going in.
Lucky for you, I can barely make out that you have an IMU 16448, which I think means you have an Analog Devices ADIS16448. Take a look at Page 20 in the datasheet. The Data Ready indicator (aka your interrupt) can be inverted by setting MSC_CTL[2:0] to 100 or 101, depending on which ADIS DIO port you’re using (DIO2 = 101, DIO1 = 100).
Let me know if that helps.
Hi Ryan, thanks for the feedback! I don’t have my RoboRIO with me to test the code, so I’ll have to let you know the results tomorrow morning.
-
I assumed that the Interrupt block’s default was -1, not 0. I’ve added a -1 to the timeout input to hopefully fix this issue.
-
I’m not sure I agree. An interrupt (in the embedded world) means “stop what you’re doing, do this other thing, and return to what you were doing”. In this case, I’m trying to improve the 448 sampling by only reading data from the sensor when it outputs valid data (~100 Hz) instead of polling the sensor and hopefully catching valid data. For this specific example however, I’m just trying to understand what the interrupts actually do on the RoboRIO.
-
There is a data ready signal being output from the sensor to MXP DIO0. I have verified that the signal looks as it should (data valid = high) using an oscilloscope connected to MXP DIO0. I hadn’t taken into account the pull-up resistor, but do I need to? Even though there is a pull-up resistor on the DIO, as long as I configure the interrupt to trigger off the proper edge it shouldn’t matter. The sensor should pull the pin low however I configure it since it doesn’t high-z when inactive.
I’ve made the changes to the code using your feedback below:
-1 disables the timeout. Your indicator will never be true. If it’s supposed to trigger at 100 Hz, or every 10ms, maybe put a 50 or 100ms timeout on the device. Otherwise, the indicator will never light up.
Right. That’s what I said, isn’t it?
You had a 200ms wait in the while loop that will block the interrupt from doing what you needs it to do, which is read the data at 100 Hz. Remember that the while loop will only loop after all of the programming within the while loop has executed. If the 200ms wait is the slowest thing in the critical path within the while loop, then it will only loop at 5 Hz (much slower than the 100 Hz)
That word ‘should’… You need to verify that part. Figure out a way to hook the oscilloscope to the signal while connected to the RoboRIO. That will tell the rest of the story.
Thanks for your help Ryan! I managed to get the ADIS16448 example to work using interrupts instead of constantly reading the registers and coming up with a pseudo-dt. Check out the code here: https://github.com/juchong/ADIS16448-RoboRIO-Driver
And if you want an IMU to play with, get one here: http://firstchoicebyandymark.com/fc16-115
We’re planning to get this sensor from FIRST Choice. I’ll let you know if I can get the interrupts working with it.
Do you know if the ADIS16448 can be used for determining the robot’s relative position? I understand how to find heading information, but is there sufficient resolution to integrate the acceleration to get relative position on the field?
Does the ADIS16448 device have more/different features from the NavX device?
Hi darrellt! If in your code you first assume that the robot starts in the same position on the field, you should be able to calculate your position in 3D space. The ADIS16448 has been used by many engineers in position tracking applications with great success.
At the heart of NavX is a consumer-grade 6DOF sensor versus the industrial-grade ADIS16448. The 448 has been calibrated over temperature and is built for rugged navigation applications (like robots!). Lots of parametrics such as ARW, Bias Stability, Rate Noise Density, etc. are much better than the NavX and the interface is much more reliable and robust.
At this point, I’m the only person developing code for the 448, so the lack of C++/Java support is a big gap that I hope to fill as time permits. If anyone would like to port the LabVIEW code over, please let me know!