Back
[09:38:28] <micges> suggestion: axis could write some message when postgui hal file cant be found or executed
[09:38:48] <micges> now it only shut down axis with no message
[10:10:49] <alex_joni> it's not AXIS that executes the postgui HAL file
[10:10:53] <alex_joni> it's the emc runscript
[11:29:47] <cradek_> cradek_ is now known as cradek
[12:21:13] <SWPadnos> that would be achange from a few weeks ago, I think
[12:38:46] <jepler> alex_joni: no I am sure you're wrong about that
[12:39:06] <SWPadnos> he is. I just checked :)
[13:07:32] <alex_joni> I am? hmm.. seems odd
[13:14:38] <SWPadnos> AXIS is the only GUI that exports HAL pins, I think
[13:14:49] <SWPadnos> so it's the only one that should need later HAL connections
[13:46:07] <alex_joni> well... that makes some sense
[13:46:25] <alex_joni> and thinking that the GUIs don't return only if they're finished, it makes more sense
[13:46:29] <alex_joni> :/
[13:52:06] <jepler> yeah I don't think there's any practical way for the run script to know when to execute the postgui hal file
[14:12:43] <alex_joni> * alex_joni takes it all back
[15:29:15] <SWPadnos> howdy Seb
[15:30:42] <jepler> hi seb
[15:30:50] <jepler> thanks again for entertaining us on saturday
[15:35:08] <seb_kuzminsky> jepler: hi! that was fun!
[15:35:19] <seb_kuzminsky> SWPadnos: howdy
[15:36:02] <SWPadnos> hmmm. did my second mail to the dev list make it to you guys today?
[15:36:49] <seb_kuzminsky> all i got from you today was the classicladder bug email
[15:37:19] <SWPadnos> oh. I also responded to your mail asking about the TP making a big array of positions then "playing them back"
[15:37:26] <SWPadnos> the answer is no :)
[15:38:06] <seb_kuzminsky> tp computes target points as they're needed, instead?
[15:38:17] <SWPadnos> yep, every servo cycle
[15:38:24] <seb_kuzminsky> right-o
[15:38:48] <SWPadnos> that's how feed override and the like can be acted upon immediately, and it also makes things like spindle-synchronized motion work
[15:39:19] <SWPadnos> you had also asked how following errors are detected
[15:39:26] <seb_kuzminsky> i see. i guess this also lets it push a lagging servo while "throttling back" the leading servos
[15:39:38] <SWPadnos> in theory, it could do that
[15:39:54] <SWPadnos> that's one of the reasons the "adaptive feed override" input pin was added
[15:40:26] <SWPadnos> HAL can calculate some factor by which to scale back motion (AF is only 0-1, so it can't increase above the programmed feed rate)
[15:53:19] <jepler> I don't think there's a fundamental reason why adaptive feed is limited to 1.
[15:53:48] <cradek> I think I agree with that
[15:55:02] <SWPadnos> I'm pretty sure it was intended to slow things down for whatever reason, but I'm not sure how it's actually implemented
[15:55:46] <SWPadnos> yep, it's limited to (0,1)
[15:55:57] <SWPadnos> err - 0 .. 1
[15:58:32] <cradek> it's like FO but realtime (FO is not)
[15:59:52] <SWPadnos> and it's limited to the range 0-1
[16:00:06] <SWPadnos> it's also got a separate enable input
[16:00:27] <cradek> and a gcode to turn it on and off, iirc
[16:00:45] <cradek> I only meant it's implemented the same (at the RT level) as FO
[16:00:50] <SWPadnos> hmmm. that could be what changes the AF_ENABLED bit, maybe it's not an input
[16:01:06] <SWPadnos> yep
[16:01:08] <cradek> no I think it's a gcode/canon call
[16:01:41] <SWPadnos> I don't remember the discussions clearly, but I know we talked about it and decided to limit it to 0-1
[16:46:05] <skunkworks> jepler: the simple cam for blending arcs is in trunk - isn't it? (like g64 does for lines..)
[16:53:29] <jepler> skunkworks: yes I think so
[16:53:50] <skunkworks> ok - thanks
[17:08:22] <BigJohnT> skunkworks: are you going to post an answer to thedoctor on cnczone?
[17:23:44] <skunkworks> BigJohnT:
http://www.cnczone.com/forums/showthread.php?p=508189#post508189
[17:23:49] <skunkworks> sound ok?
[17:24:35] <SWPadnos> um. that's not correct
[17:24:52] <skunkworks> really?
[17:24:56] <SWPadnos> as cradek recently pointed out in #emc, blending has been there since day 1
[17:25:05] <SWPadnos> the naive cam detector isn't the same thing
[17:25:23] <SWPadnos> that removes tiny lines or arcs that would result in no motion
[17:25:35] <SWPadnos> (given a G64 P- tolerance to work with)
[17:26:15] <skunkworks> ah - I am just using the wrong words..
[17:26:28] <SWPadnos> it's possible that the naive cam detector is what that user wants, but blending has been there forever :0
[17:26:29] <BigJohnT> looks better than my answer skunkworks
http://www.cnczone.com/forums/showthread.php?p=508189#post508189
[17:27:25] <BigJohnT> * BigJohnT sees how long it takes skunkworks to change his answer :)
[17:27:57] <skunkworks> yes - when I talk about about the lines - I say they combine line segments.. I should have said something to the effect of 'combining arcs'
[17:28:17] <SWPadnos> yep. combining and blending aren't the same thing
[17:28:20] <SWPadnos> bbl
[17:28:27] <skunkworks> * skunkworks was being a bit lazy
[17:31:02] <skunkworks> I really didn't know how to say that.. as I don't know if jepler combine them or fits a new arc..
[18:27:55] <jepler> skunkworks: if an arc is within the tolerance, it's converted to two lines (start to midpoint to end) and then those lines participate in the existing naive cam detector for lines.
[18:29:46] <jepler> creating arcs from these segments is a possible improvement, but it's not done at the moment -- the final output is lines
[18:31:51] <skunkworks> oh - duh - I remember you explaining that..