cradek: the /dev/rtai_shm udev file should be in the rtai package maybe
the parport disabling is less clear
or just fix emc to use the one rtai happens to provide
I don't remember why it's this way (wrong case)
but there's also the permissions -- must be writable by the emc user (so we make it mode 666)
I think it gets restrictive permissions like 600 otherwise
this looks weird (the rise in speed is almost entirely after the rise in adaptive feed) but I think it's still OK: http://emergent.unpy.net/files/sandbox/random-adaptive-feed-2.png
is the random in the thread before the motion controller?
so in sim it could be anywhere with respect to the rtapi_app threads
most likely rtapi_app runs long enough without being interrupted, that the transitions in random are seen by both the motion controller and halscope in the same cycle
you're using ddt to get that vel signal too right? that will delay it another tick
I bet it's right
ve7it is now known as LawrenceG
with a very slow accel, emc takes so long to abort that I get an error: can't do that (EMC_TRAJ_SET_TELEOP_ENABLE) in auto mode with the interpreter idle
axis must not be waiting for something it should wait for
if not manual_ok(): return
does ensure_mode wait?
maybe it's not an axis bug
but what does the abort code do?
try changing ensure_mode? http://pastebin.ca/307098
how long does wait_complete wait?
and indeed, wait_complete is returning -1 (command did not complete within timeout)
after the first wait_complete call, the mode will be attempted regardless of the result of wait_complete
maybe another wait function, like ensure_complete should be added (possibly with an argument specifying how long or how many loops to wait)
that needs more work in general -- for instance, during that 1 second the whole GUI is frozen, so you can't even see that it's decelerating
is there an equivalent to event.poll or the like, to run the UI event loop manually?