More resolution than 20ms
 

We need to watch a sensor, then cut a motor off 100ms later.

Right now we are watching the sensor, waiting for it to trip, set t0, and then watching the elapsed time (System.currentTimeMillis() - t0), and returning true from isFinished() when the elapsed time > 100ms (not doing this all at once, it happens over successive calls to isFinish(), as it should be). All as advertised, dead-simple, and worked the first time...

Doing this in isFinished() *is* introducing wobble in the 100ms: because we only get the CPU every 20ms, we could be as little as 0.00000001ms or much as 19.9999999999ms late in seeing the sensor go, and would could be as little as 0.00000001ms or as much as 19.9999999999ms late in seeing the time elapse. We can adjust for consistent delay, but the +/- 19.9999999999ms overall is something I'd like to tighten up.

I know the PID code starts it's own thread, so we can use that as a model if we want to have a separate (tighter) thread handle this.

Has anyone else done this simpler-than-PID case already? I'm willing to work from scratch using the PID code as a base, but am resistant to reinventing wheels...

Also, do we have access to any interrupt and timer capability on the FPGA from Java that would be helpful here?

Re: More resolution than 20ms
 

I created a class earlier in the season which would latch the output state of a solenoid for a specified duration.
After the duration has elapsed, the output is de-energized.

This implementation makes use of the TimerTask class.

It should be pretty easy to modify this class for your own use.

https://gist.github.com/jcorcoran/7b1ffd41391144ea8df1

I've tried to comment the code sufficiently, but if you have any questions feel free to contact me.

Re: More resolution than 20ms
 

awesome, simple, and easy to explain to students.

is multithreading in Java on the cRIO robust? Do the TimerTasks get scheduled in a timely manner?

Re: More resolution than 20ms
 

I have a related question. Is multithreading in Java on the cRIO handled by the JVM, or does the JVM make calls to vxWorks to handle that?

Re: More resolution than 20ms
 

Yes. It works well enough that we haven't had to really dig into the implementation. We've used an implementation similar to what I linked above to create periodicly executing threads without any problems in the past.

We haven't tried to quanitfy their limitations.

Re: More resolution than 20ms
 

thanks. It ended up being a very simple solution, and quite responsive. Will play with how often to reschedule our TimerTask() and see what happens to CPU utilitization, but it shouldn't be major (look at switch, look at timer, look at state, poke motor controller, update dashboard)...