Back
[11:28:20] <CIA-8> EMC: 03bigjohnt 07v2_3_branch * r7cc7499502d7 10/docs/src/gcode/rs274ngc.lyx: Remove M62, M63 not implemented
[11:44:12] <CIA-8> EMC: 03bigjohnt 07master * r06c251a1953c 10/docs/src/gcode/rs274ngc.lyx: Remove M62, M63 not implemented
[11:46:45] <micges_work> jthornton: hello
[11:48:37] <jthornton> micges_work: hello
[11:49:32] <micges_work> M62 and M63 works on v2.3 and master
[11:49:48] <micges_work> alex_joni added this
[11:50:27] <micges_work> jthornton: wfm must confirm it
[11:50:33] <jthornton> ok
[11:54:13] <micges_work> yes I'm sure:
http://git.linuxcnc.org/gitweb?p=emc2.git;a=commitdiff;h=f69772e1c22585e67539569255ebe36ce1c0d8a5
[11:55:16] <jthornton> I don't understand
[11:57:24] <jthornton> I removed the line from the manual that says "M62, M63 not implemented"
[11:58:11] <micges_work> jthornton: ahhhhh.... ok sorry ;)
[11:58:39] <micges_work> going for more coffee.. , bbl
[11:59:06] <jthornton> ok, thanks for keeping an eye on me
[11:59:54] <micges_work> jthornton: thanks for docs
[12:02:57] <jthornton> np
[21:18:10] <alex_joni> jmkasunich: got a couple minutes?
[21:40:17] <jmkasunich> yeah
[21:42:49] <alex_joni> cool.. was thinking about your diagram and the code notes on ja3
[21:43:21] <alex_joni> the kins functions have return values, which are not (or only seldom) checked
[21:43:37] <alex_joni> and I was thinking what a good way to do things would be (in the motion controller)
[21:43:50] <jmkasunich> what do the return values mean?
[21:43:58] <alex_joni> that the calculations failed
[21:44:14] <alex_joni> lets take inverse which is more interesting, and more likely to fail
[21:44:27] <alex_joni> either convergence fail, or there's a singularity, etc
[21:45:01] <alex_joni> I think we should support a more gracefull erroring than currently
[21:45:03] <jmkasunich> in the motion controller, a failed calculation is a bad thing
[21:45:21] <alex_joni> (currently = keep insisting on trying the invkins, and setting joint positions to nan and inf)
[21:45:52] <alex_joni> a failed calculation should probably result in an EMCMOT_ABORT or something like that
[21:46:13] <alex_joni> and it should switch to joint mode (with the last known joint values..)
[21:46:26] <alex_joni> er.. current known joint values
[21:46:37] <jmkasunich> that sounds somewhat reasonable
[21:47:09] <alex_joni> another "reasonable" thing is to run invKins in advance one step
[21:47:15] <alex_joni> although that's harder to do
[21:47:38] <jmkasunich> not sure I see what that buys you
[21:47:38] <alex_joni> maybe that doesn't belong in the motion controller
[21:47:54] <alex_joni> a little headroom to stop safely maybe
[21:48:04] <jmkasunich> 1mS isn't much time
[21:48:08] <alex_joni> right
[21:48:24] <alex_joni> so the answer is run the complete move in userspace, before sending it to motion
[21:48:35] <jmkasunich> eww
[21:48:46] <alex_joni> running it in a simulation has the advantage that you can see max vels and accels on joints
[21:48:57] <alex_joni> and clamp the move accordingly
[21:55:07] <alex_joni> not sure how else one can do the per joint clamping
[21:56:30] <jmkasunich> we've been thinking and talking about that issue forever it seems
[21:56:39] <jmkasunich> maybe the only solution is an "eww" one
[22:01:05] <jmkasunich> I worry about the simulation time though
[22:01:34] <jmkasunich> what if the move is one that will take a very long time to execute (either a long complex move, or a very low feed)
[22:02:00] <jmkasunich> the simulation will also take a very long time - not as long, because I'm sure it takes far less than 1mS to compute each point
[22:02:31] <jmkasunich> but I can imagine a move that will take many minutes to run at nornal speed - at simulation speed it might takes a sizable part of a second, or even a few seconds
[22:04:01] <alex_joni> this would happen at interp time I think
[22:04:25] <alex_joni> so the only thing would be queue starvation that might be a problem
[22:04:28] <jmkasunich> so you'd reply on the motion queue to avoid a pause
[22:04:47] <alex_joni> right
[22:05:01] <alex_joni> or maybe have an option to pause motion until the queue is full
[22:05:18] <alex_joni> start program, it starts interpreting/simulating, and fills the queue
[22:05:29] <alex_joni> (another ewww solution ;)
[22:13:16] <jmkasunich> gotta run
[22:18:27] <alex_joni> see you
[22:30:30] <cradek> I think you wouldn't have to simulate anything like every servo cycle.
[22:30:56] <cradek> a good solution would let the kins writer write a smart way to figure out the constraints when possible
[22:49:49] <alex_joni> figuring out the constraints is not that hard
[22:49:55] <alex_joni> err .. limits
[22:50:02] <alex_joni> expressing them is harder
[22:51:37] <alex_joni> * alex_joni heads to bed
[22:51:41] <alex_joni> good night all
[23:45:36] <cradek> I think you express them with a scaled-back vel and/or accel for the whole move
[23:46:40] <cradek> so to me, figuring is the hard part