Back
[01:31:52] <jepler> cradek: the /dev/rtai_shm udev file should be in the rtai package maybe
[01:32:06] <jepler> the parport disabling is less clear
[01:32:08] <cradek> or just fix emc to use the one rtai happens to provide
[01:32:34] <cradek> I don't remember why it's this way (wrong case)
[01:33:24] <jepler> but there's also the permissions -- must be writable by the emc user (so we make it mode 666)
[01:33:30] <jepler> I think it gets restrictive permissions like 600 otherwise
[01:34:02] <cradek> oh ok
[01:40:51] <jepler> 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
[01:49:32] <cradek> is the random in the thread before the motion controller?
[01:49:58] <jepler> it's userspace
[01:50:31] <jepler> so in sim it could be anywhere with respect to the rtapi_app threads
[01:50:32] <cradek> oh, ok
[01:51:04] <jepler> 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
[01:51:48] <cradek> you're using ddt to get that vel signal too right? that will delay it another tick
[01:52:08] <jepler> yes
[01:52:46] <cradek> I bet it's right
[18:30:40] <ve7it> ve7it is now known as LawrenceG
[21:29:00] <cradek> 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
[21:29:06] <cradek> jepler: ^^
[21:29:18] <cradek> axis must not be waiting for something it should wait for
[21:30:37] <jepler> interesting
[21:31:39] <jepler> def set_joint_mode(*args):
[21:31:41] <jepler> c.teleop_enable(vars.joint_mode.get())
[21:31:50] <jepler> def ensure_manual(*event):
[21:31:51] <jepler> if not manual_ok(): return
[21:31:51] <jepler> ensure_mode(emc.MODE_MANUAL)
[21:31:51] <jepler> commands.set_joint_mode()
[21:32:49] <cradek> does ensure_mode wait?
[21:33:09] <jepler> c.mode(m)
[21:33:09] <jepler> c.wait_complete()
[21:33:16] <cradek> huh
[21:33:23] <cradek> maybe it's not an axis bug
[21:33:40] <SWPadnos> but what does the abort code do?
[21:36:16] <jepler> try changing ensure_mode?
http://pastebin.ca/307098
[21:42:14] <SWPadnos> how long does wait_complete wait?
[21:42:41] <jepler> 1 second
[21:43:59] <jepler> and indeed, wait_complete is returning -1 (command did not complete within timeout)
[21:44:36] <SWPadnos> after the first wait_complete call, the mode will be attempted regardless of the result of wait_complete
[21:45:18] <SWPadnos> maybe another wait function, like ensure_complete should be added (possibly with an argument specifying how long or how many loops to wait)
[21:47:33] <jepler> 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
[21:47:48] <SWPadnos> hmmm
[21:48:21] <SWPadnos> is there an equivalent to event.poll or the like, to run the UI event loop manually?
