Back
[00:06:14] -!-
micges has quit [Quit: Leaving]
[00:07:39] H264 is now known as
WalterN
[00:08:27] -!-
djdelorie has quit [Quit: Leaving]
[00:13:10] -!-
asdfasd has quit [Ping timeout: 260 seconds]
[00:21:42] -!-
Loetmichel has quit [Ping timeout: 272 seconds]
[00:24:53] -!-
andypugh has quit [Remote host closed the connection]
[00:40:01] -!-
mhaberler has quit [Quit: mhaberler]
[00:50:34] -!-
phantoxeD has quit [Ping timeout: 245 seconds]
[00:58:08] -!-
Nick001 has quit [Ping timeout: 246 seconds]
[01:14:38] -!-
theorbtwo has quit [Ping timeout: 240 seconds]
[01:24:23] -!-
Nick001 [Nick001!~Nick001@plns-64-111-156-4-pppoe.dsl.plns.epix.net] has joined #linuxcnc-devel
[01:24:45] -!-
Nick001 [Nick001!~Nick001@plns-64-111-156-4-pppoe.dsl.plns.epix.net] has parted #linuxcnc-devel
[01:32:57] -!-
linuxcnc-build has quit [Ping timeout: 245 seconds]
[01:34:49] -!-
linuxcnc-build [linuxcnc-build!~linuxcnc-@184-96-166-164.hlrn.qwest.net] has joined #linuxcnc-devel
[02:17:43] -!-
theorbtwo has quit [Read error: Connection reset by peer]
[02:24:37] -!-
Tom_itx has quit [Ping timeout: 245 seconds]
[02:25:49] -!-
zlog has quit [Ping timeout: 265 seconds]
[02:34:26] -!-
skunkworks__ has quit [Remote host closed the connection]
[02:35:07] -!-
djdelorie has quit [Quit: Leaving]
[02:39:57] -!-
FinboySlick has quit [Quit: Leaving.]
[02:40:09] -!-
demacus_ has quit [Ping timeout: 245 seconds]
[02:45:05] -!-
phantoxe has quit []
[02:45:40] -!-
djdelorie has quit [Remote host closed the connection]
[03:20:25] -!-
ve7it [ve7it!~AndChat39@S0106001c10b7770f.pk.shawcable.net] has joined #linuxcnc-devel
[03:22:06] -!-
WalterN has quit [Read error: Connection reset by peer]
[03:31:35] -!-
ve7it has quit [Quit: Bye]
[03:39:32] -!-
sjd has quit []
[04:09:02] -!-
mhaberler [mhaberler!~mhaberler@195.191.253.94] has joined #linuxcnc-devel
[04:20:12] -!-
FinboySlick has quit [Quit: Leaving.]
[04:21:17] -!-
Nick001 has quit [Ping timeout: 245 seconds]
[04:40:20] -!-
stevegt_1 has quit [Ping timeout: 260 seconds]
[04:49:25] -!-
iwoj has quit [Ping timeout: 248 seconds]
[04:58:54] -!-
psha[work] [psha[work]!~psha@195.135.238.205] has joined #linuxcnc-devel
[05:03:52] -!-
Fox_Muldr has quit [Ping timeout: 265 seconds]
[05:44:12] cylly2 is now known as
Loetmichel
[06:26:15] -!-
vladimirek has quit [Remote host closed the connection]
[06:48:35] -!-
DJ9DJ has quit [Disconnected by services]
[06:48:39] DJ9DJ_ is now known as
DJ9DJ
[07:05:35] -!-
vladimirek has quit [Read error: Connection reset by peer]
[07:08:34] -!-
gambakufu has quit [Ping timeout: 265 seconds]
[07:15:17] -!-
vladimirek has quit [Read error: Operation timed out]
[07:22:39] -!-
mk0 has quit [Read error: Connection reset by peer]
[07:34:28] e-ndy|afk is now known as
e-ndy
[07:36:38] -!-
vladimirek has quit [Read error: Connection reset by peer]
[07:55:43] -!-
dimas has quit [Read error: Connection reset by peer]
[07:56:55] -!-
vladimirek has quit [Remote host closed the connection]
[08:03:19] -!-
rob_h [rob_h!~rob_h@5ace70d6.bb.sky.com] has joined #linuxcnc-devel
[08:05:03] e-ndy is now known as
e-ndy|afk
[08:06:13] e-ndy|afk is now known as
e-ndy
[08:11:43] <mhaberler> here we go: jog-during-auto-paused:
http://www.youtube.com/watch?v=2wabcOH9YAA
[08:12:22] -!-
PCW has quit [Ping timeout: 265 seconds]
[08:14:28] -!-
SWPadnos_ [SWPadnos_!~Me@74-92-8-208-NewEngland.hfc.comcastbusiness.net] has joined #linuxcnc-devel
[08:15:51] -!-
kb8wmc_ [kb8wmc_!~chatzilla@nat.mtp.cmsinter.net] has joined #linuxcnc-devel
[08:16:53] -!-
factor has quit [Read error: No route to host]
[08:20:39] -!-
e-ndy- [e-ndy-!~e-ndy@fantomas.bestit.cz] has joined #linuxcnc-devel
[08:20:55] -!-
kb8wmc has quit [Ping timeout: 246 seconds]
[08:20:56] -!-
ReadError has quit [Ping timeout: 246 seconds]
[08:20:56] -!-
SWPadnos has quit [Ping timeout: 246 seconds]
[08:20:56] -!-
GeorgeH has quit [Ping timeout: 246 seconds]
[08:20:56] -!-
A0Sheds has quit [Ping timeout: 246 seconds]
[08:20:56] -!-
e-ndy has quit [Ping timeout: 246 seconds]
[08:20:57] -!-
the_wench has quit [Ping timeout: 246 seconds]
[08:20:57] -!-
cpresser has quit [Ping timeout: 246 seconds]
[08:21:01] kb8wmc_ is now known as
kb8wmc
[08:26:09] <alex_joni> mhaberler: cool
[08:26:23] -!-
Tom_itx has quit [Ping timeout: 265 seconds]
[08:26:29] -!-
zlog has quit [Ping timeout: 248 seconds]
[08:27:17] <alex_joni> one issue I see with it.. it's joint jogging, not axes
[08:27:27] <mhaberler> see mailing list
[08:27:48] <mhaberler> there was a preference for coord jog
[08:28:20] <mhaberler> I *am* jogging axes, or I am missing something fundamental
[08:39:27] <alex_joni> how are you jogging axes?
[08:40:55] <alex_joni> I can't really imagine how you would do that in hal
[08:41:18] <alex_joni> the motion controller plans axes, then it runs through kins and then it goes out to hal
[08:41:42] <alex_joni> currently (pre-ja3) they are named axis.*.foo but that's incorrect
[08:43:20] <mhaberler> all jogging goes through tpAddLine in coord mode
[08:44:11] <alex_joni> hmm.. maybe I didn't see how you implemented it
[08:44:25] <alex_joni> I thought you only added some HAL blocks for offsetting
[08:44:59] <mhaberler> well, its a bit more that
[08:45:00] <mhaberler> http://git.mah.priv.at/gitweb/emc2-dev.git/blob/078d97b87cbb60b7a840b59d7e9946aa034fc7a0:/src/emc/motion/control.c#l695
[08:46:45] <alex_joni> so that goes at fh_vel? (defined in the ini I guess?)
[08:46:55] <mhaberler> yes
[08:47:05] <mhaberler> no, comes in from HAL
[08:47:18] <alex_joni> ah ok. so you can add a slider for fh_vel
[08:47:21] <mhaberler> can be preset from ini in python halcomp
[08:47:30] <mhaberler> yes
[08:47:33] -!-
micges [micges!~micges@dcf40.neoplus.adsl.tpnet.pl] has joined #linuxcnc-devel
[09:02:57] e-ndy- is now known as
e-ndy
[09:08:23] -!-
acemi has quit [Quit: WeeChat 0.3.2]
[09:10:59] -!-
mhaberler has quit [Quit: mhaberler]
[09:13:15] -!-
mhaberler [mhaberler!~mhaberler@195.191.253.94] has joined #linuxcnc-devel
[09:19:17] -!-
mk0 has quit [Ping timeout: 248 seconds]
[09:37:14] -!-
linuxcnc-build has quit [Ping timeout: 245 seconds]
[09:37:17] -!-
hm2-buildmaster has quit [Ping timeout: 244 seconds]
[09:50:37] -!-
linuxcnc-build [linuxcnc-build!~linuxcnc-@75-166-183-97.hlrn.qwest.net] has joined #linuxcnc-devel
[09:50:53] -!-
hm2-buildmaster [hm2-buildmaster!~hm2-build@75-166-183-97.hlrn.qwest.net] has joined #linuxcnc-devel
[10:20:46] <alex_joni> mhaberler: what happens if you push the regular pause button?
[10:21:05] <mhaberler> didnt try
[10:21:52] <mhaberler> it is not 'paused' in the motion pause sense - it just looks like a motion which takes very long
[10:22:14] <alex_joni> right, but was wondering if you did push pause, and then try the hack
[10:23:38] <mhaberler> I just tried, it is ignored - the jog hold overrides it
[10:25:04] <mhaberler> in that path, motion doesnt consider pause
[10:44:05] -!-
JT-Shop has quit [Read error: Connection reset by peer]
[10:45:40] -!-
mhaberler has quit [Quit: mhaberler]
[10:47:48] -!-
jthornton has quit [Ping timeout: 252 seconds]
[10:49:36] -!-
JT-Shop [JT-Shop!~John@184.20.140.167] has joined #linuxcnc-devel
[10:49:47] -!-
jthornton [jthornton!~john@184.20.140.167] has joined #linuxcnc-devel
[11:01:21] -!-
Nick001 has quit [Ping timeout: 272 seconds]
[11:05:51] -!-
micges has quit [Quit: Leaving]
[11:10:13] -!-
cevad has quit [Quit: Leaving]
[11:14:26] -!-
mhaberler [mhaberler!~mhaberler@195.191.253.94] has joined #linuxcnc-devel
[11:25:19] <psha[work]> is there transition packages for emc2?
[11:25:22] <psha[work]> and emc2-sim?
[11:34:59] -!-
micges [micges!~micges@dcf40.neoplus.adsl.tpnet.pl] has joined #linuxcnc-devel
[11:37:57] <psha[work]> hm, looks like there is no such package
[11:56:17] -!-
mhaberler has quit [Quit: mhaberler]
[12:02:47] -!-
mhaberler [mhaberler!~mhaberler@195.191.253.94] has joined #linuxcnc-devel
[12:03:56] -!-
viesturs has quit [Quit: Leaving.]
[12:05:16] <alex_joni> psha[work]: package?
[12:05:23] <alex_joni> no, the available translations are included
[12:13:45] <mhaberler> transition, not translation
[12:13:58] <mhaberler> aka: fallout from the big rename
[12:15:03] -!-
adb has quit [Ping timeout: 245 seconds]
[12:19:27] -!-
mhaberler has quit [Quit: mhaberler]
[12:23:18] <psha[work]> alex_joni: transition, not translation as pointed by mah :)
[12:23:37] <psha[work]> it means empty emc2 package with only purpose to depend on linuxcnc package
[12:24:47] <alex_joni> ah, no idea ;)
[12:25:07] <alex_joni> sorry.. misread
[12:25:18] -!-
sumpfralle has quit [Quit: Leaving.]
[12:26:07] <psha[work]> i've old camunits stuff which still depends on 'emc2' names and thus is not usable :(
[12:30:41] -!-
fatpandas has quit [Ping timeout: 260 seconds]
[13:07:32] <cradek> psha[work]: no transition package, but linuxcnc has the correct magic to replace emc2, which is replaces + provides + conflicts
[13:14:43] <psha[work]> i see, but i've to provide proper deps myself to ensure seamless installations
[13:14:51] <psha[work]> otherwise it'll break telling you that there is no such packages
[13:18:30] -!-
syyl has quit [Ping timeout: 252 seconds]
[13:44:00] -!-
vladimirek has quit [Remote host closed the connection]
[13:51:49] -!-
micges has quit [Ping timeout: 248 seconds]
[13:59:03] -!-
mhaberler [mhaberler!~mhaberler@195.191.253.94] has joined #linuxcnc-devel
[14:05:30] -!-
micges [micges!~micges@ddv183.neoplus.adsl.tpnet.pl] has joined #linuxcnc-devel
[14:37:31] -!-
Valen has quit [Quit: Leaving.]
[14:38:06] -!-
vladimirek has quit [Remote host closed the connection]
[15:04:33] -!-
phantoxe has quit [Remote host closed the connection]
[15:09:14] -!-
viesturs1 has quit [Ping timeout: 252 seconds]
[15:12:37] -!-
bumb has quit [Remote host closed the connection]
[15:20:58] -!-
psha[work] has quit [Quit: Lost terminal]
[15:26:31] -!-
L84Supper has quit [Quit: puff of smoke]
[15:26:48] -!-
A0Sheds has quit [Changing host]
[15:27:38] -!-
viesturs has quit [Ping timeout: 240 seconds]
[15:51:07] e-ndy is now known as
e-ndy|afk
[15:58:38] -!-
acemi has quit [Quit: WeeChat 0.3.2]
[16:15:44] -!-
tiago has quit [Remote host closed the connection]
[16:21:17] -!-
mhaberler has quit [Quit: mhaberler]
[16:27:12] -!-
mhaberler [mhaberler!~mhaberler@195.191.253.94] has joined #linuxcnc-devel
[16:32:15] -!-
ve7it [ve7it!~LawrenceG@S0106001c10b7770f.pk.shawcable.net] has joined #linuxcnc-devel
[16:34:20] -!-
n2diy has quit [Ping timeout: 260 seconds]
[17:01:17] -!-
cevad has quit [Ping timeout: 245 seconds]
[17:05:35] -!-
davec has quit [Ping timeout: 252 seconds]
[17:07:00] -!-
stevegt_ has quit [Ping timeout: 260 seconds]
[17:07:10] -!-
mhaberler_ [mhaberler_!~mhaberler@195.191.253.94] has joined #linuxcnc-devel
[17:07:45] -!-
mhaberler has quit [Read error: Connection reset by peer]
[17:07:45] mhaberler_ is now known as
mhaberler
[17:12:43] -!-
pcw_home has quit [Ping timeout: 246 seconds]
[17:29:55] -!-
phantoxe has quit []
[17:57:15] ReadError_ is now known as
ReadError
[18:06:20] -!-
joe9 has quit [Quit: leaving]
[18:07:49] -!-
andypugh [andypugh!~andy2@cpc2-basl1-0-0-cust639.basl.cable.virginmedia.com] has joined #linuxcnc-devel
[18:08:00] -!-
andypugh [andypugh!~andy2@cpc2-basl1-0-0-cust639.basl.cable.virginmedia.com] has parted #linuxcnc-devel
[18:19:39] e-ndy|afk is now known as
e-ndy
[18:24:11] -!-
IchGuckLive has quit [Quit: ChatZilla 0.9.87 [Firefox 11.0/20120310193829]]
[18:36:45] -!-
syyl_ws has quit [Quit: Verlassend]
[18:50:15] -!-
Tecan has quit [Ping timeout: 260 seconds]
[18:55:57] -!-
ve7it has quit [Remote host closed the connection]
[19:32:24] -!-
andypugh [andypugh!~andy2@cpc2-basl1-0-0-cust639.basl.cable.virginmedia.com] has joined #linuxcnc-devel
[19:43:02] e-ndy is now known as
e-ndy|afk
[20:00:56] <mhaberler> cradek: can we discuss moving offsetting to motion a bit?
[20:02:00] -!-
GeorgeH_ has quit [Ping timeout: 260 seconds]
[20:02:53] -!-
Strykerg has quit [Quit: Bye Bye]
[20:05:02] -!-
asdfasd has quit [Ping timeout: 265 seconds]
[20:08:33] -!-
motioncontrol has quit [Quit: Sto andando via]
[20:10:42] shdhdfghd is now known as
asdfasd
[20:49:03] <cradek> mhaberler: I have 12 minutes
[20:49:16] <mhaberler> great
[20:49:27] <mhaberler> I start with a naive todo list
[20:49:47] <cradek> I'm sad that you and KL are solving jog-while-paused by implementing a whole new kind of jogging :-/
[20:50:11] <cradek> I really understand not wanting to touch task, but yikes.
[20:50:31] <andypugh> I am not convinced that that is the best way either, but it might be an expedient middle-ground for this release
[20:50:50] <mhaberler> right, thats just a stopgap for now
[20:51:35] <mhaberler> anyway (11mins left):every offset definition, and application is mutated into an NML message through interpl, task, to motion. Motion acts on application messages based on the definition message values.
[20:51:47] <mhaberler> now whats with rotation, thats handed down as well?
[20:52:18] <mhaberler> second, tool offsets. Did you read back what I said about commits and views on tool info?
[20:52:31] <cradek> don't think I saw that
[20:52:52] <mhaberler> ok: to summarize my understanding what you said:
[20:53:32] <mhaberler> interp starts out on a committed view of the tt and generates canons.
[20:54:19] <mhaberler> now if downstream a comp like motion were to change an offset, that defines a local view of offsets, that means: does not change interp commited view as it continues to generate canons in parallel
[20:54:55] <mhaberler> locally changed offets are applied on the fly post task, probably before or in canon
[20:55:17] <cradek> I think there's a wrench in these works
[20:55:47] <mhaberler> end of program means: any locally defined changes to the tt offets post task are committed, so the next interp execution uses the new commit
[20:56:03] <mhaberler> wrench.. sand in gearbox? so, where?
[20:56:04] <cradek> offset/rotation are in the interp so they can be applied at the right times
[20:56:31] <mhaberler> queuing preserves ordering
[20:56:47] <cradek> consider no rotation/offset, tool at 1,0
[20:57:02] <cradek> now rotate 90, tool is now at 0,-1
[20:57:33] <mhaberler> so?
[20:57:55] <cradek> be patient, I'm trying to come up with how to explain
[20:58:11] <mhaberler> you pressed, not me ;-)
[20:58:51] <cradek> the basic problem is a gcode move doesn't have to move all axes, and the ones you don't move need to stay the same
[20:59:23] <cradek> like if you change TLO and then g0 x... y... you should get a move that doesn't go up or down
[20:59:48] <cradek> only when you move Z does that TLO change get "added" in
[21:00:16] <cradek> same for rotations, if you program g0 y... you should get a move parallel to the (maybe new) X axis
[21:00:16] <mhaberler> oh, those ops need masks
[21:00:35] <cradek> yeah maybe something like masks that show what words were there in the command?
[21:00:43] <mhaberler> because the interp has no null value, just zero
[21:01:01] <cradek> I'm trying to think through it all
[21:02:04] <mhaberler> that would help; I ran into that the same issue in tt i/o and I think introducing a None (either by mask or some other mechanism is it)
[21:02:38] <mhaberler> basically there's no way to distinguish between zero and 'not defined/used'
[21:02:51] <cradek> but it feels like you have a lot of dependence on the intricacies of gcode stuffed down in motion now
[21:03:14] -!-
ve7it [ve7it!~LawrenceG@S0106001c10b7770f.pk.shawcable.net] has joined #linuxcnc-devel
[21:03:22] <mhaberler> I'm talking about moving bugs from a to b;)
[21:03:26] <cradek> knowledge about combinations of words and how they interact
[21:04:18] <mhaberler> is it fair to say: EmcPose needs a mask?
[21:04:45] <cradek> I have no idea if that fixes it
[21:05:04] <cradek> are you proposing that the interp wouldn't know the final current position at all?
[21:05:13] <cradek> final = offsetted/rotated
[21:05:37] <mhaberler> she could, but only as know at interpretation time; if use aims at foot and shoots: bad karma
[21:05:40] <cradek> right now we have the final position in all sorts of places
[21:06:23] <mhaberler> you mean because of limit violation or because of pose comparison?
[21:06:46] <cradek> it's tempting to think it should be only in motion, but it's not clear to me that you could for instance tell whether an arc command was valid (matching radii)
[21:07:37] <cradek> because you can change the final "current" point elsewhere/later by altering the offsets
[21:07:37] -!-
fliebel has quit [Remote host closed the connection]
[21:08:23] <mhaberler> does the interpreter has any need to understand offsets? (foot im mouth)
[21:08:55] <mhaberler> assume feedback is unoffsetted if it were for comparison
[21:09:01] <alex_joni> mhaberler: if the interpreter needs to distinguish valid code from invalid one, then yes
[21:09:12] <alex_joni> and I don't mean strictly semantically correct
[21:09:18] <mhaberler> give me an example why
[21:10:06] <alex_joni> for instance gouging
[21:10:11] <cradek> I think detecting the arc with mismatched radii is an example?
[21:10:35] <cradek> I'm struggling to see how it would work with feedback of unoffset current position
[21:11:06] <cradek> because it's not the current position of motion we're interested in, it's the interpreted-so-far position
[21:11:23] <mhaberler> I still dont buy it. first, take a view where the interp passes on offets and other than that has zero clue
[21:11:50] <mhaberler> second, assume offsetting and rotation are local to the machine, and not subject to reporting *to interp*
[21:11:54] -!-
ve7it has quit [Remote host closed the connection]
[21:11:59] <mhaberler> other than limit checks
[21:12:16] <mhaberler> I still dont see your conceptual issue (foot in mouth #2)
[21:12:32] <cradek> and I'm 12 minutes over
[21:13:06] <alex_joni> mhaberler: I think the arc is a good example
[21:13:08] <andypugh> Isn't the arc offset always, by definition, radial, so the start/finish/centre are equally valid for tool-centre or tangent-point?
[21:13:36] <alex_joni> what about gouging then?
[21:13:48] <alex_joni> you need to see if a bigger tool fits into a small segment
[21:13:53] <cradek> andypugh: talking about the check distance(current->center) =~ distance(final->center)
[21:13:58] <mhaberler> that is an issue with cutter radius and CRC
[21:14:32] <alex_joni> so you don't want to move those?
[21:14:36] <cradek> andypugh: that's a check you can't have if you don't know current, or current might change between now and the time it's executed
[21:14:39] <alex_joni> only offsets?
[21:14:52] <mhaberler> gouging per see has nothing to do with offsets, but with radius as I understand it
[21:15:20] <andypugh> cradek: It will be equal for both offset and unoffset paths, as far as I can see. (Different for each path, but equal for each end of each)
[21:15:21] <cradek> yes moving crc out of interp is a whole other problem I think
[21:15:41] -!-
freespace has quit [Ping timeout: 260 seconds]
[21:15:44] <andypugh> Now, if you intend to change the offset part way through the arc...
[21:15:48] <mhaberler> 'offsets' is sloppy - in tt it includes radius and radius change might invalidate CRC but it has nothing to do with coordinate transformations
[21:16:30] <alex_joni> what about naive cam det. ?
[21:16:45] <mhaberler> that is path fudging, not offsetting
[21:16:46] <alex_joni> that would probably also be affected by not interpreting offsets anymore
[21:17:09] <mhaberler> ok, let me define what I mean by offset.
[21:17:14] <cradek> I have to go
[21:17:21] <mhaberler> talk to you later
[21:17:54] <mhaberler> an offset in the mah sense is a set of a..w of null or non-null values
[21:18:05] <mhaberler> period. Tool dia is something else
[21:18:30] <alex_joni> so no rotations?
[21:18:33] <mhaberler> I am talking about offsetting, and not radius fiddling
[21:18:50] <alex_joni> what causes these offsets?
[21:18:53] <mhaberler> ?
[21:19:44] <alex_joni> maybe I misundestood what you really want to do
[21:20:02] <mhaberler> ok. The point is:
[21:20:54] <mhaberler> the application of offsets (my defn) in linuxcnc happens too early, muddled into canon. The consequence is::
[21:21:17] -!-
DJ9DJ has quit [Quit: bye]
[21:21:31] <mhaberler> the interplist has changes commit which cannot be undone by an on-the-fly-offset change in motion because the information is already lost.
[21:22:01] <alex_joni> still I don't understand what you want to do
[21:22:15] <alex_joni> I mean what is the reason behind this
[21:22:21] <mhaberler> change offsets during pause?
[21:22:27] <alex_joni> what offsets?
[21:22:30] <mhaberler> touchoff
[21:22:34] <alex_joni> right
[21:22:38] <mhaberler> see?
[21:22:42] <alex_joni> and that includes tool dimensions
[21:22:47] <alex_joni> including tool radius
[21:22:52] <alex_joni> and messes up crc
[21:22:58] <mhaberler> forget tools for now, this is an orthogonal problem
[21:23:09] <alex_joni> some people touch off tools in more than one dimension
[21:23:28] <alex_joni> so not only toollength (aka orthogonal problem), but also radius
[21:24:05] <alex_joni> I'm afraid you're trying to solve one problem at a time, by moving one thing at a time to motion
[21:24:06] <andypugh> I don't think we can touch-off radius?
[21:24:18] <mhaberler> can we separate the crc/radius discussion, this is yet another example of a fuzzy data model in linuxcnc
[21:24:19] <alex_joni> until everything is there
[21:24:36] <alex_joni> andypugh: if we can't, we should
[21:24:53] <micges> sorry for interfere: I haver machine with TLO in X and Z
[21:25:14] <mhaberler> thats fine because this is just linear transformation
[21:25:37] <alex_joni> mhaberler: I'm thinking about a robot though
[21:26:07] <alex_joni> and when I change a tool there, a lot of things happen TCP changes (that's a XYZ translation from UVW)
[21:26:09] <mhaberler> the point where the concept confusion begins is: when you talk about 'offsets' 'somehow include radius' in offsets, and suddenly see CRC being messed up
[21:26:29] <alex_joni> but also TOV changes (tool orientation vector) and that means rotations around UVW
[21:26:47] <andypugh> touch off is basically G10. G10 L1 and G10 L2 allow tool radius change. I don't think we can access radius setting from the GUI though.
[21:27:15] <alex_joni> andypugh: but you could from running a procedure
[21:27:27] <alex_joni> measure with M66 then use G10 L2
[21:27:35] <alex_joni> but that's irrelevant
[21:27:49] -!-
maximilian_h [maximilian_h!~bonsai@130.255.104.157] has joined #linuxcnc-devel
[21:27:59] -!-
maximilian_h [maximilian_h!~bonsai@130.255.104.157] has parted #linuxcnc-devel
[21:28:02] <alex_joni> or rather a sidetrack
[21:28:15] <mhaberler> Please ignore for now what is in G10 dot foo. I am talking about moving *idempotent coordinate transformations* from one point in linuxcnc to another point in linuxcnc.
[21:28:36] <alex_joni> how about feedrate for an arc?
[21:28:43] <andypugh> I am not clear how you would measure a radius with M66, but I suppose someone might find a way to compute it from the data. But I think it is important to realise that Cutter Radius Compensation is completely different from what mah is discussing.
[21:28:55] <alex_joni> if the offsetting is done radially, the speed surely changes
[21:29:25] <mhaberler> amen
[21:29:44] <alex_joni> mhaberler: that's calculated in canon atm though
[21:29:52] <mhaberler> this is the issue
[21:29:53] <alex_joni> and passed on to motion
[21:30:13] <mhaberler> yes, and then it is too late to do anything sensible with it.
[21:30:25] <mhaberler> that is my whole, and single point.
[21:30:27] <andypugh> alex_joni: Are you sure? I have never been clear if F is tool-centre velocity or tangent-point velocity when CRC is active. If CRC is not active, then it is irrelevant.
[21:30:52] <alex_joni> andypugh: I was thinking not active
[21:31:06] <alex_joni> but I still don't see mhaberler's point of moving offsets
[21:31:09] <andypugh> Then R has no effect on F at all, I think?
[21:31:29] <alex_joni> well, it does for inverse time ;)
[21:31:58] <mhaberler> I'm sure you've read the eternal thread about touchoff-during-pause
[21:32:10] <alex_joni> I've been reading about that for 3+ years ;)
[21:32:15] <mhaberler> see?
[21:32:29] <alex_joni> I don't think this is the way to solve it though
[21:32:35] <mhaberler> that is offset application in motion, thats all (note: MY definition of offset)
[21:32:54] <alex_joni> as people said.. next they want handwheel jogging
[21:32:57] <alex_joni> and whatnot
[21:33:00] <andypugh> alex_joni: Only with CRC active. Or are you saying that the _actual_ cutting velocity becomes wrong if you massively change the tool radius, don't offset the path, and leave the F the same? In that case, yes, but so what>
[21:33:07] <mhaberler> I am not discussing any motion hacks here, I want to address an architectural decision
[21:33:23] <alex_joni> or me for example I want to be able to switch from world to joint and back
[21:33:43] <alex_joni> surely any architectural discussion about moving offsets won't solve that in any way
[21:33:56] <mhaberler> Please explain.
[21:34:39] <alex_joni> mhaberler: you said you don't actually pause motion, but rather let task know a move is taking really long
[21:34:51] <alex_joni> so that means GUI still thinks it's moving
[21:35:04] <mhaberler> I said: I am not discussing motion code right now.
[21:35:07] <alex_joni> so there is no provision to use the regular jogging keys
[21:35:18] <andypugh> I think the point is that the current order that things are done in, and the data passed downstream, precludes offset-while-paused. The question is how that sequence/data-flow would need to change to enable offset-while paused.
[21:35:18] <mhaberler> forget this, please. This is not the theme.
[21:35:22] <alex_joni> no, I'm talking about the solution in general
[21:35:46] <alex_joni> andypugh: that's not the point for me
[21:35:55] <mhaberler> No, it occurs to me you read my code and think this is what I am discussing,
[21:36:09] <mhaberler> cut that out
[21:36:14] <alex_joni> because after that you'll want to change the sequence/flow for the next thing, and so on
[21:36:22] <mhaberler> YES
[21:36:46] <mhaberler> if you mean changed offset
[21:37:21] -!-
maximilian_h [maximilian_h!~bonsai@130.255.104.157] has joined #linuxcnc-devel
[21:37:22] <alex_joni> andypugh: I'm sure the current order precludes a LOT of things, and changing one of them won't solve much (except this one thing)
[21:37:25] <mhaberler> if you mean: me wanting to change things: my take is that the current location of applying offsets is suboptimal
[21:37:46] <andypugh> I think that, if I understand correctly, the offset demonstrated today is a temporary hack. This discussion was intended to be about how to do it properly.
[21:37:49] -!-
maximilian_h [maximilian_h!~bonsai@130.255.104.157] has parted #linuxcnc-devel
[21:38:03] <mhaberler> maybe you want to read back to yesterday, chris already saw the point I think
[21:38:19] <mhaberler> I reapeat: forget this.
[21:38:32] <alex_joni> lets rewind, and start clean
[21:38:32] <mhaberler> yes, it is about doing it properly.
[21:38:36] <mhaberler> amen.
[21:38:45] <alex_joni> mhaberler: state your issue
[21:39:09] <alex_joni> and don't say suboptimal design, because there are tons of those, and they don't bother anyone ;)
[21:39:35] <mhaberler> Opinions vary on that, esp with the type of machine you own
[21:39:58] <alex_joni> I'm not talking about the can'tjogwhile paused
[21:40:06] <mhaberler> but I am
[21:40:06] <alex_joni> I agree that's a bug not a suboptimal design
[21:40:14] -!-
acemi has quit [Quit: WeeChat 0.3.2]
[21:40:41] <andypugh> Ah, so suboptimal but functional is OK? That seems fair, or no code would ever get released.
[21:40:51] <mhaberler> thats just a name tag and doesnt help in addressing the issue
[21:41:09] <alex_joni> mhaberler: I'm still waiting for you to state your issue ;)
[21:41:36] <mhaberler> alex: I just said it, maybe I need to try a different angle to say it more clearly
[21:41:41] <alex_joni> right
[21:42:09] <alex_joni> saying "we need to move where we apply offsets from interp to motion because it's a better design if we do", doesn't really convince me of anything
[21:42:52] <mhaberler> did I say that?
[21:43:08] <alex_joni> well, that's what I got so far :)
[21:43:14] <andypugh> I saw "mhaberler: the interplist has changes commit which cannot be undone by an on-the-fly-offset change in motion because the information is already lost."
[21:43:40] <mhaberler> you did a qualification. I just stated a fact.
[21:43:44] <alex_joni> and then the question is .. why do you need to undo them?
[21:43:55] <alex_joni> that was for andypugh
[21:44:41] <alex_joni> mhaberler: to clarify my position (hope I'm not causign you grief)
[21:44:56] <alex_joni> 1. I understand you are trying to solve a problem
[21:45:17] <alex_joni> 2. I think the problem you are solving is actually a part of a bigger problem which you are not solving
[21:45:35] <mhaberler> you need to explain 2)
[21:45:42] <alex_joni> 2.1 after solving this particular problem, you'll get to the next and you'll need yet another redesign
[21:45:55] <alex_joni> well, you want to move offsets now
[21:46:02] <alex_joni> because people want to touchoff
[21:46:11] <andypugh> I think may wants to solve the bigger problem, starting with defining it.
[21:46:35] <andypugh> (may / mah)
[21:46:50] <alex_joni> I get that, it's easier to do in motion, then doing it in task (which would mean flush the queue, new offsets, rebuild the queue, etc)
[21:47:33] <alex_joni> but next would come someone who wants to adjust his path based on tool wear. pause somewhere, measure the tool diameter and continue the program with the adjusted path
[21:47:49] <alex_joni> and that would mean moving crc and whatnot
[21:47:56] <mhaberler> I'm sorry, you are suggesting I said something I didnt.
[21:48:13] <alex_joni> mhaberler: did you mean me?
[21:48:20] <mhaberler> yes.
[21:48:30] <alex_joni> can you be more specific?
[21:50:01] <mhaberler> you are coming from a feature a,b,c perspective, and that's not the point where I started the discussion with chris, and you tuned in. I was talking about architectural decisions which prevent ore enable some things to be achieved.
[21:50:25] <mhaberler> the rest imo is your interpretation of recent emails.
[21:51:47] <alex_joni> but that's the point, I didn't manage to see what moving offsets accomplishes from an architectural point of view, except allow for feature a
[21:52:30] <mhaberler> I was discussing, when you tuned in, what the implications of a late vs early binding decision of offsets are.
[21:52:48] <mhaberler> then you decided to jump on me, thanks very much
[21:54:07] <alex_joni> I did no such thing :)
[21:54:23] <alex_joni> and I did read back the discussion you had with cradek twice ;)
[21:54:27] <mhaberler> well, that is what I thought I read here
[21:54:36] <mhaberler> there are lots of places where exactly that decision: late vs early - has long range implications, and I'd think it is valid to discuss
[21:54:43] <alex_joni> well, I'm sorry if I came on too strong ;)
[21:54:49] <mhaberler> yes you did
[21:54:59] -!-
syyl_ has quit [Quit: Leaving]
[21:55:05] <alex_joni> mhaberler: ok, then lets forget everything else (except what's pertinent) and discuss it
[21:55:10] <mhaberler> ok
[21:55:15] <mhaberler> issue closed
[21:55:27] <alex_joni> thought we wanted to discuss it ;)
[21:55:44] <mhaberler> do you see my point in late vs early binding?
[21:55:55] <alex_joni> I see there is a distinction
[21:56:06] <alex_joni> but I don't see the benefit from either yet
[21:56:19] <alex_joni> wait, that's not true
[21:56:33] <alex_joni> I agree that late binding (in motion) is conceptually better
[21:56:36] <andypugh> <checks map> You know Szeged is just about equidistant between you. It's a nice place too.
[21:56:37] <alex_joni> BUT
[21:56:54] <alex_joni> andypugh: I doubt szeged is equidistant
[21:57:27] <alex_joni> mhaberler: my concearn is this: right now it's early binding, and it's working
[21:57:41] <mhaberler> so you're concerned about stability
[21:57:43] <mhaberler> ?
[21:57:54] <alex_joni> what are the arguments to make it late binding, and possibly only working after lots of work
[21:57:59] <andypugh> Well, I was guessing Salzburg and Bucharest, but that's getting off the subject rather
[21:58:25] <alex_joni> andypugh: probably budapest. szeged is 150km from here
[21:59:56] <alex_joni> mhaberler: again, my point is purely philosophical <grin>, as you'll probably do the coding, it's your decision if it's worth it or not
[22:00:32] <alex_joni> but I don't see the advantages to doing it (besides the fixing offsets while paused)
[22:00:59] -!-
skunkworks__ [skunkworks__!~chatzilla@str-bb-cable-south-3-102.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[22:02:01] <mhaberler> my point is that the early binding implies immutable behaviour (read: pause or abort are your only options if something goes wrong). And that is one of major drawbacks of linuxcnc vs other controls. Did you happen to read the fanuc retract stuff I posted? these obviously come from some valid customer requirements.
[22:02:33] <alex_joni> I don't think that's true
[22:03:00] <alex_joni> if you are paused (execution time) there's nothing stopping you (in theory) from reinterpreting the initial file with new offsets
[22:03:00] <mhaberler> our opinions diverge here;)
[22:04:23] -!-
djdelorie has quit [Ping timeout: 244 seconds]
[22:04:38] <alex_joni> do you agree with my last statement?
[22:04:58] <andypugh> I can see ways to do it for G1/2/3. As those moves can be reinterpreted as shorter moves from the stored stop point
[22:05:12] <mhaberler> I agree about the 'in theory' part wrt abort and rfl, but it stops there
[22:05:31] <alex_joni> I don't necessarely mean abort and rfl
[22:05:56] <alex_joni> I mean a mechanism which currently isn't implemented (just as moving offsets isn't)
[22:06:04] <alex_joni> just talking possibilities
[22:06:08] <mhaberler> explain
[22:06:28] <alex_joni> well, you said early binding implies immutable behaviour
[22:06:38] <alex_joni> I don't agree that it's immutable
[22:07:18] <mhaberler> so whats the possibility you're referring to
[22:07:46] <alex_joni> like I said, when you are paused you have one move that you're on, and the next ones are all queued
[22:08:04] <alex_joni> both in the motion queue and also in the interp queue
[22:08:15] <mhaberler> ok
[22:08:18] <alex_joni> you can throw away the queues and refill them
[22:08:36] <alex_joni> surely task will need to be able to handle this
[22:09:09] <alex_joni> rewind the interpreter to the paused position (restoring the state of the currently executing move)
[22:09:13] <mhaberler> I discussed exactly that with chris recently. there is a showstopper making it non-idempotent
[22:09:26] <mhaberler> and that are features like feed override
[22:09:35] <mhaberler> which result in different paths
[22:09:56] <alex_joni> I don't see how that fits in
[22:10:06] <alex_joni> we are talking about moves that didn't happen yet
[22:10:08] <mhaberler> you have parameters which are not controllable at interpretation time which change the path
[22:10:20] <skunkworks__> something to remember - the thing that comes up is replacing a broken tool... That would require you to pause - replace the too - reset tool lenght and maybe diameter, and (wait for it) start a few lines back.....
[22:10:35] <mhaberler> yes,yes,yes
[22:11:03] <alex_joni> skunkworks__: so we're discussing a moot point?
[22:11:23] <mhaberler> not moot at all
[22:12:08] <alex_joni> no, but what skunkworks__ means is that after replacing the tool you don't want to resume, but actually resume from earlier in the program?
[22:12:17] <skunkworks__> I am not sure.. (just throwing in my 2 cents)
[22:12:18] <mhaberler> if your argument was: I can always recompute a path with changed offsets and leave off at the point where shit happened: this doesnt work
[22:12:20] <skunkworks__> alex_joni: ye
[22:12:22] <skunkworks__> yes
[22:12:36] <skunkworks__> are you going to notice exactly when the tool breaks?
[22:12:50] <alex_joni> you might have a sensor on spindle load ;)
[22:13:11] <alex_joni> mhaberler: the current move is busted, I don't think you can do much about it either way
[22:13:12] <mhaberler> the toolchange when paused because of broken tool is exactly my point on doing offsets late
[22:13:22] <mhaberler> not necessarily
[22:13:44] <alex_joni> say offsets have changed
[22:13:59] <mhaberler> with the motion hack I posted these days, this restarts *within* a move
[22:14:01] <alex_joni> you're in the wrong position then (if you stay on the earlier path)
[22:14:01] <andypugh> pause - rewind - retract - restart..
[22:14:18] <alex_joni> andypugh: yes, if you rewind
[22:14:35] -!-
ThadiusB has quit [Ping timeout: 272 seconds]
[22:14:36] <alex_joni> but then you're not inside the move anymore, you're before this move - and the move didn't happen yet
[22:14:53] <andypugh> Stuart Stevenson might not want to go right back to the start of a 20' cut :-)
[22:15:02] <mhaberler> that move might be very, very long
[22:15:08] <alex_joni> right
[22:15:47] <mhaberler> to be worth any work, it must be restartable intra-move, which imo excludes all the rfl attempts
[22:16:20] <mhaberler> and that is because the point where shit happened isnt replayable due to feed override and blending
[22:16:50] <mhaberler> blending just has to be live because of fo
[22:17:04] <alex_joni> ok, I see that point
[22:17:14] <mhaberler> aaaaaaaaahhhhh
[22:17:49] <mhaberler> I would love it to be that way, but I think going the replay route is a hit-and-miss game
[22:18:52] <mhaberler> someday oracle will be fast enough we can roll this back by servo cycle ;)
[22:20:27] <mhaberler> but until then we'll have to see how we can work with the information available at that point, and what still can be modified at that point without aborting
[22:22:14] <andypugh> Aha! I have just found out that where I stayed in Romania was the little village of Rusca, near Teregova.
[22:22:19] <alex_joni> mhaberler: it feels like a hack
[22:22:28] <alex_joni> andypugh: cool
[22:23:03] <mhaberler> I cherish you feeling. Now lets return to architectural part which makes this doable wthout hacks ;)
[22:25:08] <mhaberler> skunkworks was on spot: what do you do if the tool breaks? interp replaying simply isnt an option.
[22:25:31] <alex_joni> then you need motion replaying ;)
[22:25:42] <alex_joni> and if you can do that, then even EDM guys are happy
[22:26:09] <andypugh> Yeah, that is something else we ought to look at facilitating
[22:26:37] <mhaberler> in a sense, yes, under the side condition: a new tool was inserted, which translates into changed offsets for me (disregarding radius changes for now)
[22:27:42] <mhaberler> except for the owners of machines/toolholders where this isnt an issue, which I still have to find in the linuxcnc crowd
[22:28:09] <mhaberler> but they do exist, they are just outside the addressable market of linuxcnc
[22:28:20] <alex_joni> well, not really
[22:28:39] <alex_joni> even if you have a toolholder that doesn't mean the next tool you have available has the same dimensions
[22:28:54] <alex_joni> you might break one tool off, and only have another to finish the job
[22:29:00] <mhaberler> right, this was a fuzzy argument
[22:29:23] <skunkworks__> if a tool breaks - I am not going to have a holder with the same diameter and length. (I am going to pull the current holder and replace the broken tool)
[22:29:48] <JT-Shop> as will 99% of Linuxcnc users
[22:30:16] <alex_joni> well, we usually do things for 100% of the users ;)
[22:30:29] <andypugh> replacement inserts would be close enough in many cases, but that is no argument to support the view that LinuxCNC doesn't need offset-while-paused
[22:30:45] <skunkworks__> in the olden days - there where tool setters.. so the program was never altered. (and the machines didn't have length and offset comp)
[22:30:47] <mhaberler> and then touch off (or wish they could), or just hope and resume?
[22:31:26] <mhaberler> Ah. A tool setter is an early binding device ;)
[22:31:31] <skunkworks__> heh
[22:33:37] <mhaberler> ok, lets take the high road. Is this an issue which needs addressing, or not?
[22:33:47] <rob_h> lol now u just slap the tool in adn run the setting cycle ;)
[22:34:08] <mhaberler> which changes offsets, I would guess
[22:34:10] <alex_joni> sure, people complain about not beeing able to jog and change tools during a pause :)
[22:34:37] -!-
isssy has quit [Quit: Bye Bye]
[22:34:50] <alex_joni> you need to jog (that implies individual axes - either buttons or handwheels)
[22:34:58] <alex_joni> then you might want to turn spindle on/off
[22:34:59] <JT-Shop> that does seem to the most heard about
[22:35:06] <alex_joni> then you might want to change tools
[22:35:14] <alex_joni> including offsets
[22:35:17] <alex_joni> and also diameter
[22:35:23] <mhaberler> not just yet
[22:35:36] <alex_joni> well.. you asked ;)
[22:36:05] <mhaberler> no i did not. this is a different discussion from the one I started, you cued in with crc and radius
[22:36:46] <mhaberler> it is a valid discussion, but it muddles the issue at hand
[22:37:08] <andypugh> But, people are going to want to change radius on the fly too. Any solution has to not preclude radius change.
[22:37:50] <mhaberler> right, but to begin running lets start with walking
[22:38:34] <mhaberler> this is another late/early binding point, but it'd be great if we come to a conclusion on offsets (minus radius for now)
[22:40:53] <mhaberler> both issues boil down to 'can I pause within a move, change something, and continue without abort/replay'; the change mechanisms are very different but the basic point - where do you do it in the pipeline - is the same
[22:41:42] -!-
stevegt_ has quit [Ping timeout: 245 seconds]
[22:42:55] <alex_joni> right
[22:43:08] <alex_joni> there are 2 possible points: motion or task
[22:43:15] <alex_joni> but probably both need to know about it
[22:43:39] <mhaberler> that is not a given IMV
[22:45:00] <mhaberler> it could very well be a vehicle between. lets call it the offset/crc applicator task, which feeds from task, and to motion, and is replayable at the task/applicator level
[22:46:37] <mhaberler> both the applicator (what a f..g name) and the current motion hack have something in common: nothing else is affected (or so I hope)
[22:47:10] <mhaberler> I am all for impact minimization
[22:47:37] <alex_joni> good :)
[22:47:51] <mhaberler> hell, I have just one life
[22:51:46] <mhaberler> alex: I think you see this isnt about the next commit for master or 2.5 - the current thingie is a stopgap at best
[22:53:25] <alex_joni> yup, sure
[22:53:48] <alex_joni> but if you plan to put something like this somewhere, my vot would be for ja3 ;)
[22:54:20] <mhaberler> merge it into master as soon as practical so the shakeout begins asap
[22:55:07] <mhaberler> because every week you wait (board hat on) is a week less of bug shakeout
[22:55:36] <cradek> frankly we should consider merging ja3 into master, and then it becomes moot
[22:56:02] <cradek> delete all the old sample configs that become invalid (or probably already are)
[22:56:40] <alex_joni> sounds good to me ;)
[22:59:03] <cradek> bbl
[23:00:36] <andypugh> Gets my vote too.
[23:01:22] <andypugh> I think we might want to consider accepting that master becomes temporarily incompatible with existing configs.
[23:01:50] <alex_joni> that's not a real issue imo
[23:02:11] <micges> ok ok you don't need to ask, I'll do it ;)
[23:02:16] <andypugh> OK, so, I can create HAL pins in Python, how do I change their value?
[23:02:53] -!-
djdelorie has quit [Ping timeout: 244 seconds]
[23:03:24] <mhaberler> I think keep-a-broken-config is be tter than deleting, no loss of history and a motive to fix them up
[23:03:46] <micges> andypugh: paste line where hal module is created in python?
[23:03:53] -!-
the-jub has quit [Remote host closed the connection]
[23:05:14] <andypugh> I, err, don't know?
[23:05:26] <mhaberler> gladevcp?
[23:05:28] <andypugh> Yes
[23:08:25] <alex_joni> mhaberler: maybe you should post to the mailing list about jog/whatnot while paused
[23:08:35] <alex_joni> see what people think about what should be possible
[23:08:41] <alex_joni> and then we try to come up with a plan
[23:10:46] <mhaberler> ok, assume I do it. How do we assure we come to a conclusion? I lack the exampes a bit, if you know what I mean
[23:11:47] <andypugh> mhaberler: You spend months coding it, then someone says "I don't like it" and rejects it. How long have you worked on this project? Surely you know how it works now?
[23:17:01] <mhaberler> There are a lots of issues you can take on in isolation and they make an impact. But those are necessarily limited in scope. That one impacts folks other than me. So me proposing something on the list with a 'great, lets do it response' isnt necessarily the type of consensus I would wish to have as a basis for that.
[23:18:11] <andypugh> Quite
[23:20:23] <mhaberler> all I'm saying is - some things need a bit of a better qualified quorum than what is usually obtainable through an average mailing list response
[23:22:50] <skunkworks__> wait - that isn't going to work for me! I want.... ;)
[23:23:18] <mhaberler> and in retrospect of the month of coding on the remapping stuff, I now wish I would have been more insisting on consensus about change than I did, it would have saved me a lot of work on retaining warts
[23:35:43] <cradek> nobody on the mailing list is better equipped to come up with a plan than the people in this channel
[23:36:42] <cradek> (and as an aside, I hate cross-posts to both lists because two separate conversations always develop)
[23:38:00] -!-
rob_h has quit [Ping timeout: 260 seconds]
[23:44:25] -!-
mhaberler has quit [Quit: mhaberler]
[23:46:12] -!-
mozmck has quit [Remote host closed the connection]
[23:47:22] -!-
mozmck [mozmck!~moses@client-74.117.92.175.dfwtx.partnershipbroadband.com] has joined #linuxcnc-devel
[23:49:46] <micges> mozmck: hi
[23:53:16] <alex_joni> I wasn't suggesting to use the lists to develop a plan
[23:53:26] <alex_joni> just to get some ideas what needs to be solved
[23:53:32] <alex_joni> but if that's clear.. forget it
[23:55:39] <micges> alex_joni: do you have kernel packages made by mozmck on your mirror?
[23:56:23] <micges> I can't find then on linuxcnc.org