Interesting cRIO delays

[EricVanWyk]

Originally Posted by baronep

I don't? I am measuring the current encoder rate.

DMA is typically used when you want to guarantee that you see all the values that have been generated. If you only care about the most recent value, you don't need to bother with DMA.

[baronep]

The problem that we ran into with the regular code is that we were not seeing all of the data. Our encoders have 256 pulses per rotation and at ~1000 rpm the cRio was losing pulses. Therefore we figured that DMA would be a good choice to not lose any pulses (which would screw up rate). We are just having a delay problem which may or may not be related to the DMA. Anyone have any explanation for the twitchy robot?

[Greg McKaskle]

The encoder should be good for close to 40,000 per second, far more than you describe. Additionally, the DMA cannot go faster than the decoding, so it will not help to speed up encoders.

Greg Mckaskle

[baronep]

Is there a downside to using the DMA though?

Robot twitching?

[wireties]

Do you have any other threads sharing time with or stealing time from your encoder thread? We don't use NI on the robot. We use C++ and would just raise the relative priority (by lowering the priority number) of the encoder thread/task to make sure it runs when needed. Is there a way to do that in LabView? Greg?

HTH

[Joe Ross]

Originally Posted by baronep

Is there a downside to using the DMA though?

You'll spend a lot more time processing data, without any improvement to your problem.

[baronep]

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?

[Greg McKaskle]

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

[baronep]

Alright, I will work on that this afternoon

[baronep]

It worked! Using just the regular encoder function in the Timed While Loop produces clean results. Thanks everyone