suggestion: axis could write some message when postgui hal file cant be found or executed
now it only shut down axis with no message
it's not AXIS that executes the postgui HAL file
it's the emc runscript
cradek_ is now known as cradek
that would be achange from a few weeks ago, I think
alex_joni: no I am sure you're wrong about that
he is. I just checked :)
I am? hmm.. seems odd
AXIS is the only GUI that exports HAL pins, I think
so it's the only one that should need later HAL connections
well... that makes some sense
and thinking that the GUIs don't return only if they're finished, it makes more sense
yeah I don't think there's any practical way for the run script to know when to execute the postgui hal file
* alex_joni takes it all back
thanks again for entertaining us on saturday
jepler: hi! that was fun!
hmmm. did my second mail to the dev list make it to you guys today?
all i got from you today was the classicladder bug email
oh. I also responded to your mail asking about the TP making a big array of positions then "playing them back"
the answer is no :)
tp computes target points as they're needed, instead?
yep, every servo cycle
that's how feed override and the like can be acted upon immediately, and it also makes things like spindle-synchronized motion work
you had also asked how following errors are detected
i see. i guess this also lets it push a lagging servo while "throttling back" the leading servos
in theory, it could do that
that's one of the reasons the "adaptive feed override" input pin was added
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)
I don't think there's a fundamental reason why adaptive feed is limited to 1.
I think I agree with that
I'm pretty sure it was intended to slow things down for whatever reason, but I'm not sure how it's actually implemented
yep, it's limited to (0,1)
err - 0 .. 1
it's like FO but realtime (FO is not)
and it's limited to the range 0-1
it's also got a separate enable input
and a gcode to turn it on and off, iirc
I only meant it's implemented the same (at the RT level) as FO
hmmm. that could be what changes the AF_ENABLED bit, maybe it's not an input
no I think it's a gcode/canon call
I don't remember the discussions clearly, but I know we talked about it and decided to limit it to 0-1
jepler: the simple cam for blending arcs is in trunk - isn't it? (like g64 does for lines..)
skunkworks: yes I think so
ok - thanks
skunkworks: are you going to post an answer to thedoctor on cnczone?
um. that's not correct
as cradek recently pointed out in #emc, blending has been there since day 1
the naive cam detector isn't the same thing
that removes tiny lines or arcs that would result in no motion
(given a G64 P- tolerance to work with)
ah - I am just using the wrong words..
it's possible that the naive cam detector is what that user wants, but blending has been there forever :0
looks better than my answer skunkworks http://www.cnczone.com/forums/showthread.php?p=508189#post508189
* BigJohnT sees how long it takes skunkworks to change his answer :)
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'
yep. combining and blending aren't the same thing
* skunkworks was being a bit lazy
I really didn't know how to say that.. as I don't know if jepler combine them or fits a new arc..
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.
creating arcs from these segments is a possible improvement, but it's not done at the moment -- the final output is lines
oh - duh - I remember you explaining that..