Back
[10:06:30] <alex_joni> jepler: I noticed that after selecting the default touch-off system (Machine->Coordinate System for touch-off->P5), it works as expected when pushing Touch Off. But going to Machine->Select .. it doesn't appear as selected
[12:49:58] <jepler> alex_joni: hmm ok
[12:51:54] <alex_joni> jepler: I'm sure it's nothing too hard to do, if you know where to look
[14:12:38] <alex_joni> jepler: thanks a lot
[14:14:07] <jepler> thanks for the report
[19:35:51] <Skullworks-PGA1> Skullworks-PGA1 is now known as Skullworks-PGAB
[23:30:06] <alex_joni> hi jmkasunich__
[23:36:00] <jmkasunich__> hi
[23:37:18] <alex_joni> so.. was wondering if you can give me your oppinion on something
[23:37:34] <alex_joni> seen
http://www.linuxcnc.org/docs/devel/html/gcode/main/index.html#sec:M66-to-M68: ?
[23:39:42] <jmkasunich__> just read it
[23:40:36] <alex_joni> ok, the part missing is the wait-for-input
[23:41:01] <alex_joni> I got the command down to motion, but I'm not sure what the best way to implement it would be
[23:41:01] <jmkasunich__> what part? interp, task, motion? all of it?
[23:41:37] <alex_joni> all above motion is done
[23:42:02] <jmkasunich__> how many inputs are there?
[23:42:11] <alex_joni> right now 4 digital
[23:42:19] <alex_joni> but I'm planning to expand it
[23:42:27] <jmkasunich__> it seems like the simplest thing to do is to always read them from the HAL pins and add them to the emcmotStatus structure
[23:42:30] <alex_joni> or make user selectable
[23:42:37] <alex_joni> oh, I did that already
[23:42:42] <alex_joni> for the M67 part
[23:43:06] <alex_joni> M67 = read current value of one of the inputs
[23:43:32] <alex_joni> M66 should stop motion, and wait until something happens (rise, fall, high, low)
[23:43:33] <jmkasunich__> define "current value" - is that the value as of when the line is interpreted, or at the end of actually executing the prior line of g-code?
[23:44:04] <alex_joni> it's the same
[23:44:12] <jmkasunich__> no its not
[23:44:23] <alex_joni> there is a thingie in the interp to halt further interpreting
[23:44:44] <jmkasunich__> commands from user space are processed by "command_handler()", and motion ones get stuffed into a queue
[23:44:45] <alex_joni> so it actually does the right thing
[23:45:02] <jmkasunich__> command_handler() has no clue how deep the queue is or when it will be empty
[23:45:16] <jmkasunich__> so command_handler simply cannot do the testing
[23:45:19] <alex_joni> then it needs to get stuffed in the queue
[23:45:39] <jmkasunich__> I was afraid you were gonna say that
[23:45:55] <alex_joni> there also needs to be some blocking mechanism (the wait..)
[23:46:02] <jmkasunich__> thats the other problem
[23:46:02] <alex_joni> the whole thing is quite similar to probing
[23:46:08] <jmkasunich__> you can't block in RT
[23:46:10] <alex_joni> but without actual motion
[23:46:38] <alex_joni> and dealing with timeouts is also a PITA in RT I imagine
[23:47:23] <jmkasunich__> yes
[23:47:38] <jmkasunich__> the only way to pass info back to user space is the status structure
[23:47:44] <alex_joni> yes, I know that
[23:47:49] <jmkasunich__> and all commands MUST "execute" immediately
[23:48:15] <jmkasunich__> in some cases, "execute" means "get stuffed into a queue"
[23:48:23] <alex_joni> so it's probably something like tpAddWait()
[23:48:28] <jmkasunich__> the queue is actually part of the TP
[23:48:30] <jmkasunich__> right
[23:49:13] <alex_joni> do you happen to know how task knows when a motion succeeded ?
[23:49:24] <alex_joni> I mean finished
[23:49:36] <jmkasunich__> no
[23:49:58] <jmkasunich__> I don't know that much about the TP - I leave that to cradek
[23:50:24] <alex_joni> ok, so the conclusion is that the magic stuff needs to happen in the TP
[23:50:43] <alex_joni> then after it triggered, or reached a timeout, the result is passed back via emcmotStatus
[23:50:44] <jmkasunich__> I think so
[23:51:03] <alex_joni> then I need to wait for the command to finish in task/interp
[23:51:21] <alex_joni> and get the results back to interp via canon (that's already in place)
[23:51:34] <jmkasunich__> this is a little like the (rather crufty) hoops we had to jump thru for M51 and friends (FO enable/disable, SO enable/disable, etc)
[23:51:51] <jmkasunich__> we would up queueing a set of four flags with each motion commands
[23:52:06] <alex_joni> yeah, I remember
[23:52:16] <alex_joni> I had a real headache with implementing this in the interp
[23:52:26] <alex_joni> because it also needs to halt the interpreting until it finished
[23:52:34] <jmkasunich__> jmkasunich__ is now known as jmkasunich
[23:52:44] <alex_joni> only after it knows the result it can proceed
[23:52:56] <alex_joni> but it seems there were some hooks available