|
|
|
![]() |
|
|||||||
|
||||||||
![]() |
|
|
Thread Tools | Rate Thread | Display Modes |
|
|
|
#1
|
||||
|
||||
|
Re: Interesting cRIO delays
Alright, it just seemed that our encoder data was much cleaner with DMA than without, but I am willing to give the other way a try. How does one elevate the thread priority of the encoder code?
|
|
#2
|
|||
|
|||
|
Re: Interesting cRIO delays
Timed loops have a priority value, and by default are higher priority than normal code anyway. But as with DMA, be careful playing with priorities, they are an advanced feature and can starve important processing tasks if used inappropriately.
The other place to change priority is on a VI. You go to VI Properties>Execution and you can adjust the priority. I'm not sure what the original issue was, but reading encoders gives the instantaneous value and most recently computed rate. The DMA will give the sequence of values and/or the sequence of whatever else you are adding to the DMA. This is awesome when trying to understand the relationship or trend of data coming from a sensor, but not helpful for your case unless you are smoothing the data or something. Before playing with priorities, I'd turn off DMA, put the code back to the simple form, and see if the issue is back. If so, post some symptoms so that we can determine what may be causing it. Greg McKaskle |
|
#3
|
||||
|
||||
|
Re: Interesting cRIO delays
Alright, I will work on that this afternoon
|
|
#4
|
||||
|
||||
|
Re: Interesting cRIO delays
It worked! Using just the regular encoder function in the Timed While Loop produces clean results. Thanks everyone
|
![]() |
| Thread Tools | |
| Display Modes | Rate This Thread |
|
|