#linuxcnc-devel | Logs for 2012-04-30

Back
[00:20:37] -!- Loetmichel has quit [Ping timeout: 248 seconds]
[00:23:13] -!- andypugh has quit [Quit: andypugh]
[00:26:15] -!- toast2 has quit [Read error: Connection reset by peer]
[00:33:41] -!- asdfasd has quit [Ping timeout: 256 seconds]
[01:19:26] -!- toastydeath has quit [Ping timeout: 246 seconds]
[01:20:32] -!- mhaberler has quit [Quit: mhaberler]
[01:21:59] toast2 is now known as toastydeath
[01:35:33] -!- MDesade has quit [Ping timeout: 260 seconds]
[02:19:17] -!- demacus has quit [Ping timeout: 246 seconds]
[02:19:39] -!- MDesade has quit [Ping timeout: 256 seconds]
[02:52:18] -!- iwoj has quit [Read error: Connection reset by peer]
[03:30:10] ybit is now known as dailybitcoins
[03:38:21] -!- FinboySlick has quit [Quit: Leaving.]
[03:46:15] -!- A0Sheds has quit [Read error: Connection reset by peer]
[03:50:36] -!- WalterN has quit [Read error: Connection reset by peer]
[04:12:52] dailybitcoins is now known as ybit
[04:30:16] -!- cmorley [cmorley!~chris@d64-180-200-50.bchsia.telus.net] has joined #linuxcnc-devel
[04:32:40] -!- hm2-buildmaster has quit [Quit: buildmaster reconfigured: bot disconnecting]
[04:32:41] -!- linuxcnc-build has quit [Quit: buildmaster reconfigured: bot disconnecting]
[05:00:07] -!- hm2-buildmaster [hm2-buildmaster!~hm2-build@174-29-79-34.hlrn.qwest.net] has joined #linuxcnc-devel
[05:00:09] -!- linuxcnc-build [linuxcnc-build!~linuxcnc-@174-29-79-34.hlrn.qwest.net] has joined #linuxcnc-devel
[05:00:34] -!- hm2-buildmaster has quit [Client Quit]
[05:00:34] -!- linuxcnc-build has quit [Client Quit]
[05:04:14] -!- Fox_Muldr has quit [Ping timeout: 265 seconds]
[05:06:17] -!- hm2-buildmaster [hm2-buildmaster!~hm2-build@174-29-79-34.hlrn.qwest.net] has joined #linuxcnc-devel
[05:06:28] -!- linuxcnc-build [linuxcnc-build!~linuxcnc-@174-29-79-34.hlrn.qwest.net] has joined #linuxcnc-devel
[05:42:28] -!- dimas_ has quit [Ping timeout: 246 seconds]
[05:50:17] -!- A0Sheds has quit [Changing host]
[06:11:25] -!- factor has quit [Ping timeout: 265 seconds]
[06:13:40] -!- micges [micges!~micges@egf2.neoplus.adsl.tpnet.pl] has joined #linuxcnc-devel
[06:27:43] -!- pfred1 has quit [Quit: fascinating]
[06:39:39] -!- mhaberler [mhaberler!~mhaberler@195.191.253.94] has joined #linuxcnc-devel
[06:44:59] -!- vladimirek has quit [Remote host closed the connection]
[06:50:26] e-ndy|afk is now known as e-ndy
[07:21:07] -!- capricorn_one has quit [Quit: Konversation terminated!]
[07:24:22] -!- Valen has quit [Remote host closed the connection]
[07:24:49] e-ndy is now known as e-ndy|afk
[07:40:10] e-ndy|afk is now known as e-ndy
[08:03:50] -!- rob_h [rob_h!~rob_h@5ace70d6.bb.sky.com] has joined #linuxcnc-devel
[08:23:51] -!- mhaberler has quit [Quit: mhaberler]
[08:43:01] e-ndy is now known as e-ndy|afk
[08:45:20] e-ndy|afk is now known as e-ndy
[09:18:07] -!- mhaberler [mhaberler!~mhaberler@089144206022.atnat0015.highway.a1.net] has joined #linuxcnc-devel
[09:22:13] -!- phantoxeD has quit [Ping timeout: 260 seconds]
[09:31:55] -!- factor has quit [Read error: Connection reset by peer]
[09:51:35] -!- mhaberler has quit [Read error: Connection reset by peer]
[10:07:39] -!- mhaberler [mhaberler!~mhaberler@089144206022.atnat0015.highway.a1.net] has joined #linuxcnc-devel
[10:29:08] -!- factor has quit [Ping timeout: 240 seconds]
[10:46:02] -!- mhaberler_ [mhaberler_!~mhaberler@089144206022.atnat0015.highway.a1.net] has joined #linuxcnc-devel
[10:47:14] -!- mhaberler has quit [Ping timeout: 245 seconds]
[10:47:15] mhaberler_ is now known as mhaberler
[10:52:18] -!- jthornton [jthornton!~john@184.20.140.167] has joined #linuxcnc-devel
[10:59:30] -!- mhaberler has quit [Ping timeout: 252 seconds]
[11:03:42] cylly2 is now known as Loetmichel
[11:03:51] -!- mhaberler [mhaberler!~mhaberler@089144206022.atnat0015.highway.a1.net] has joined #linuxcnc-devel
[11:06:38] -!- Nick001 has quit [Ping timeout: 240 seconds]
[11:08:02] <mhaberler> please shoot down the following idea from the kludge zone: "a touchoff during pause can be faked by applying changed offsets in a kins module"
[11:08:07] -!- mhaberler has quit [Read error: Connection reset by peer]
[11:09:04] -!- mhaberler [mhaberler!~mhaberler@089144206022.atnat0015.highway.a1.net] has joined #linuxcnc-devel
[11:23:20] -!- skunkworks__ has quit [Ping timeout: 250 seconds]
[11:29:09] -!- mhaberler_ [mhaberler_!~mhaberler@089144206022.atnat0015.highway.a1.net] has joined #linuxcnc-devel
[11:29:10] -!- mhaberler has quit [Read error: Connection reset by peer]
[11:29:10] mhaberler_ is now known as mhaberler
[11:41:50] -!- mk0 has quit [Read error: Connection reset by peer]
[11:42:23] -!- mhaberler_ [mhaberler_!~mhaberler@089144206253.atnat0015.highway.a1.net] has joined #linuxcnc-devel
[11:45:35] -!- mhaberler has quit [Ping timeout: 246 seconds]
[11:45:50] -!- mhaberler [mhaberler!~mhaberler@089144206022.atnat0015.highway.a1.net] has joined #linuxcnc-devel
[11:47:08] -!- mhaberler_ has quit [Ping timeout: 240 seconds]
[11:49:34] -!- factor has quit [Read error: Connection reset by peer]
[11:59:38] -!- mk0 has quit [Ping timeout: 240 seconds]
[12:00:17] -!- vladimirek has quit [Remote host closed the connection]
[12:01:13] -!- mhaberler has quit [Ping timeout: 252 seconds]
[12:18:12] -!- factor has quit [Read error: Connection reset by peer]
[12:33:35] phantoneD is now known as phantoxeD
[12:34:23] -!- jkastner_ [jkastner_!jkastner@nat/redhat/x-tjlzcsdtauaaclrp] has joined #linuxcnc-devel
[12:40:44] -!- Valen has quit [Quit: Leaving.]
[12:41:55] -!- jkastner_ has quit [Quit: Ex-Chat]
[12:47:54] -!- Geissler has quit [Ping timeout: 260 seconds]
[12:58:41] -!- sumpfralle has quit [Ping timeout: 272 seconds]
[13:17:12] -!- JT-Shop [JT-Shop!~John@184.20.140.167] has joined #linuxcnc-devel
[13:17:13] <cradek> mhaberler: the kludge zone problem is that you must apply the offset when a move happens, so you get a new controlled move to a new endpoint. you can't ever have a jump in position, you must change the endpoints of subsequent moves. kins know *nothing* about moves.
[13:21:34] <cradek> this is why all offsets etc are in the interp, the only place they can currently be before moves are generated. if you're at +1000,0 and you rotate the coordinate system, the machine must not move, you just get a different current point and subsequent moves make sense in the new system.
[13:28:19] <cradek> so if you have offsets that you want to change, you have to be able to delay finalizing the endpoint of the move (and everything that depends on it: feed calculation, soft limit check, crc) until after you know that offset.
[13:28:34] <cradek> I think this answers both your questions
[14:05:12] -!- factor has quit [Read error: Connection reset by peer]
[14:08:16] -!- A0Sheds has quit [Quit: puff of smoke]
[14:12:29] -!- A0Sheds has quit [Changing host]
[14:23:33] -!- factor has quit [Read error: Connection reset by peer]
[14:32:44] -!- skunkworks__ [skunkworks__!~chatzilla@str-bb-cable-south-3-102.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[14:55:50] -!- sumpfralle has quit [Ping timeout: 265 seconds]
[15:16:33] -!- toastydeath has quit [Read error: No route to host]
[15:23:18] <cradek> spelling this out makes me realize something I didn't quite before: if you change tool offset while paused, it's the recovery move that has the new endpoint, and the paused move needs to be translated so it finishes at the new location
[15:24:38] -!- Gromits has quit [Quit: ChatZilla 0.9.88.2 [Firefox 12.0/20120423130206]]
[15:29:43] -!- fliebel has quit [Ping timeout: 276 seconds]
[15:46:30] -!- jepler has quit [Ping timeout: 244 seconds]
[15:53:36] -!- jepler [jepler!~jepler@emc/developer/pdpc.professional.jepler] has joined #linuxcnc-devel
[16:01:51] -!- mhaberler [mhaberler!~mhaberler@089144206022.atnat0015.highway.a1.net] has joined #linuxcnc-devel
[16:01:56] -!- tiago has quit [Remote host closed the connection]
[16:33:55] <mhaberler> cradek: thanks - so it's a 'case of too late binding' . I guess you're assuming vtp here, tool offset applied before move gets queued in the tp?
[16:35:05] -!- acemi has quit [Client Quit]
[16:35:13] <cradek> it seems like the tlo shouldn't be on the vpt at all - so you apply it as you read the vpt. if you change it while paused, you just have to rewrite (translate) the paused move and the recovery move
[16:35:43] <cradek> I'm not sure if I answered your question
[16:35:57] -!- mhaberler_ [mhaberler_!~mhaberler@089144206253.atnat0015.highway.a1.net] has joined #linuxcnc-devel
[16:36:10] <cradek> mhaberler_: ^
[16:38:18] <mhaberler_> so the next motion already has the changed offset applied when it hits the tp
[16:38:19] <mhaberler_> interesting motion actually gets the current tooloffset from upstream, but obviously only as a HAL pin driver, and the motion targets already have it applied
[16:38:44] -!- mhaberler has quit [Ping timeout: 256 seconds]
[16:38:45] mhaberler_ is now known as mhaberler
[16:39:10] <mhaberler> oh, right. it is strictly local to vpt since tooltable is too.
[16:39:57] <mhaberler> so no chance of getting out of sync. I like that aspect
[16:41:14] <mhaberler> when things suddenly become simple, thats a sign they happen in the right place
[16:43:57] <cradek> I'm sad that we will apparently lose the ability to detect soft limit violations at readahead time
[16:45:03] <cradek> that's the only big drawback I see of the new design
[16:45:12] <mhaberler> would it make sense to assume an upper boundary on tool offsets and just work with these bounds? gets false negatives though
[16:46:13] <cradek> tool offsets can vary widely depending on operator procedure
[16:46:31] <cradek> they might tend to be small and centered around zero, or they might be all hugely positive or hugely negative
[16:48:10] <cradek> if we could get it right assuming the tools don't change after interpret time (and approximately right if they don't change much) that is probably adequate
[16:48:47] <cradek> we will still have to abort the move if we find it impossible after it finalizes
[16:49:51] <mhaberler> that's what I just was thinking; assume tt offsets commited, maybe add some user defined leeway for safety, and be done with it - much better than no readaheaddetection at all
[16:50:51] <cradek> to do the same for crc we'd need to do it in two places :-/
[16:50:57] <mhaberler> uh
[16:51:22] <cradek> it's exactly the same problem
[16:53:09] -!- sumpfralle has quit [Quit: Leaving.]
[16:53:35] -!- sumpfralle has quit [Client Quit]
[16:54:22] <mhaberler> practically, the radius changes will be either nonexistent, or known in range, so again user could prime the hit detection with a max change (actually maybe a percentage… if I change a tool during pause, assume radius doesnt vary more than -n/+m %
[16:54:52] -!- sumpfralle has quit [Client Quit]
[16:55:43] <cradek> the change would likely be between nominal and resharpened sizes and/or just tweaked for wear
[16:56:09] -!- bedah has quit [Quit: bye]
[16:56:13] <cradek> it's true you could do the initial crc for testing/discarding based on some maximum tweak value
[16:56:26] <mhaberler> so actually less
[16:56:36] <cradek> less?
[16:56:48] <mhaberler> I think in both cases we should start with some assumed heuristics with the provision for user to prime it
[16:57:11] <mhaberler> tool radius reduced by wear/sharpening
[16:57:15] <cradek> but do you see any way to avoid doing the crc twice, discarding it the first time?
[16:57:33] -!- micges has quit [Quit: Leaving]
[16:57:47] <cradek> to get the soft limits and path geometry checks
[16:58:03] <cradek> we wouldn't have to, but it's more sacrifice if we don't
[16:58:25] <cradek> bbl
[16:58:32] <mhaberler> no, because the offset curve *shape* changes with tooldia, not just some offset
[16:58:32] <mhaberler> cu
[17:04:07] -!- mhaberler has quit [Read error: Connection reset by peer]
[17:04:28] -!- mhaberler [mhaberler!~mhaberler@089144206253.atnat0015.highway.a1.net] has joined #linuxcnc-devel
[17:09:54] -!- mhaberler has quit [Ping timeout: 256 seconds]
[17:12:31] -!- zlog has quit [Ping timeout: 252 seconds]
[17:12:37] -!- Tom_itx has quit [Ping timeout: 265 seconds]
[17:20:06] -!- mhaberler [mhaberler!~mhaberler@089144206253.atnat0015.highway.a1.net] has joined #linuxcnc-devel
[17:20:18] <mhaberler> note that limit checks can be done statically within a vpt sequence - unless a tlo changes. again, from that point, to end of tape, it can be done ahead; but that means the locus of check moves from readahead to vpt sequence. It can even be async to the rt execution, like a checker thread which re-investigates a part of the vpt after a tlo change. 'Readahed' might be the wrong place to do limit checking. Just like it is f
[17:20:19] <mhaberler> offset path computation for crc.
[17:21:06] <mhaberler> while she is at it, she could re-do crc curves as well ;)
[17:21:40] -!- ve7it [ve7it!~LawrenceG@S0106001c10b7770f.pk.shawcable.net] has joined #linuxcnc-devel
[17:21:42] <mhaberler> the only requirement is that the checker may not fall behind the executor
[17:22:32] <mhaberler> and btw with the checker also does the preview - so you get corrected preview after a toooldia change
[17:23:20] <mhaberler> it is in effect speculative execution, which needs to rewind/replay in case of change. Does this sound any different from Axis preview?
[17:26:21] <mhaberler> let me reword that. The checker is in fact the generator for a committed path (one with to applied, ad crc with a given tooldia).
[17:26:29] <mhaberler> tlo applied
[17:28:03] -!- Tom_L has quit [Client Quit]
[17:28:22] <mhaberler> so if tlo or tooldia changes - recompute path from there. The result of the checker is the rt execution recipe, and the display list for the UI preview. Their only conceptual difference is: the display list appears immediately, the motion executor does it piecemeal.
[17:29:45] <mhaberler> any properties like machine boundaries are checked against the committed path; if a part of the committed path is thrown awaye due to a tlo/dia change, check is re-run from there.
[17:31:22] <mhaberler> so, done in the right place checks on boundaries could still be pre-execution time AND exact
[17:34:25] <mhaberler> one might want to limit the length of the path computation for practical considerations
[17:35:13] <mhaberler> btw if the structure holding the path is a circular buffer with some lookback you get stepback here for free
[17:35:16] -!- andypugh [andypugh!~andy2@cpc2-basl1-0-0-cust639.basl.cable.virginmedia.com] has joined #linuxcnc-devel
[17:45:05] -!- sumpfralle1 has quit [Read error: Connection reset by peer]
[17:53:12] -!- mhaberler has quit [Read error: Connection reset by peer]
[17:59:25] -!- adb_ [adb_!~adb@178-211-226-40.dhcp.voenergies.net] has joined #linuxcnc-devel
[18:01:42] -!- mhaberler [mhaberler!~mhaberler@089144206253.atnat0015.highway.a1.net] has joined #linuxcnc-devel
[18:02:42] <mhaberler> modulo blending, that is
[18:17:57] -!- sumpfralle has quit [Ping timeout: 245 seconds]
[18:26:14] -!- micges [micges!~micges@egf2.neoplus.adsl.tpnet.pl] has joined #linuxcnc-devel
[18:37:37] -!- cmorley has quit [Ping timeout: 255 seconds]
[18:39:19] -!- mhaberler has quit [Read error: Connection reset by peer]
[18:45:43] -!- micges has quit [Read error: Operation timed out]
[18:51:57] -!- cmorley [cmorley!~chris@S010688ae1d61f51a.no.shawcable.net] has joined #linuxcnc-devel
[18:52:29] -!- micges [micges!~micges@adcv223.neoplus.adsl.tpnet.pl] has joined #linuxcnc-devel
[18:52:33] -!- ve7it has quit [Remote host closed the connection]
[19:07:53] -!- mhaberler [mhaberler!~mhaberler@195.191.253.94] has joined #linuxcnc-devel
[19:10:21] -!- fliebel_ has quit [Remote host closed the connection]
[19:10:26] -!- sumpfralle1 has quit [Ping timeout: 246 seconds]
[19:56:46] -!- ve7it [ve7it!~LawrenceG@S0106001c10b7770f.pk.shawcable.net] has joined #linuxcnc-devel
[20:16:43] -!- nots has quit [Ping timeout: 244 seconds]
[20:16:46] phantoxeD is now known as ohantoxe
[20:16:51] ohantoxe is now known as phantoxe
[20:17:26] phantoxe is now known as phantoxeD
[20:50:18] -!- DJ9DJ has quit [Quit: bye]
[20:50:34] -!- tom3p has quit [Read error: Operation timed out]
[21:02:26] -!- FinboySlick has quit [Quit: Leaving.]
[21:14:52] -!- pcw_home has quit [Ping timeout: 276 seconds]
[21:30:42] -!- syyl_ws has quit [Remote host closed the connection]
[21:39:38] -!- elmo40 has quit [Ping timeout: 256 seconds]
[21:41:00] -!- fliebel has quit [Remote host closed the connection]
[21:48:08] -!- mhaberler has quit [Ping timeout: 240 seconds]
[21:48:32] -!- mhaberler [mhaberler!~mhaberler@195.191.253.94] has joined #linuxcnc-devel
[21:50:52] -!- jepler has quit [Ping timeout: 244 seconds]
[21:54:26] -!- jepler [jepler!~jepler@emc/developer/pdpc.professional.jepler] has joined #linuxcnc-devel
[21:55:27] -!- toastydeath has quit [Ping timeout: 245 seconds]
[21:58:10] elmo401 is now known as elmo000
[22:01:06] -!- sumpfralle has quit [Quit: Leaving.]
[22:02:00] -!- factor has quit [Read error: Connection reset by peer]
[22:16:34] -!- mhaberler has quit [Read error: Connection reset by peer]
[22:18:11] -!- mhaberler [mhaberler!~mhaberler@195.191.253.94] has joined #linuxcnc-devel
[22:23:14] <alex_joni> mhaberler: hi, any progress?
[22:23:28] <mhaberler> hi
[22:23:36] <mhaberler> on which issue?
[22:24:02] <alex_joni> jog while paused and the needed rewrite
[22:24:07] <alex_joni> moving offsets to motion
[22:24:44] <mhaberler> well I had a very fruitful exchange with Chris and a sketch is emerging
[22:24:51] <alex_joni> cool
[22:25:25] <mhaberler> it's in the irc log since we talked
[22:25:33] <alex_joni> yup, I read that
[22:25:37] <mhaberler> aja
[22:27:33] <andypugh> Hmm, something that one (and only one) user has asked for (for his inverted Tetrapod theatrical special effect, so rather a corner-case) is a way to alter accelleration on the fly...
[22:28:03] <alex_joni> andypugh: only with limit3's on each joint and large ferrors ;)
[22:28:09] <andypugh> I guess the problem with that is that you can reduce the accelleration so that the axis can't stop...
[22:28:14] <mhaberler> I think it will be a significant simplification; eg preview and progress display directly from path (pre) computation and NOT in the UI - meaning a single interpreter, less consistemcy problems etc
[22:30:16] -!- vladimirek has quit [Remote host closed the connection]
[22:30:35] -!- mhaberler has quit [Quit: mhaberler]
[22:31:28] -!- cmorley has quit [Ping timeout: 260 seconds]
[22:49:06] -!- cmorley [cmorley!~chris@d64-180-200-50.bchsia.telus.net] has joined #linuxcnc-devel
[22:54:13] -!- skunkworks__ has quit [Ping timeout: 260 seconds]
[22:57:46] -!- skunkworks__ [skunkworks__!~chatzilla@str-bb-cable-south-3-102.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[23:16:52] -!- micges has quit [Quit: Leaving]
[23:26:53] -!- dimas_ has quit [Ping timeout: 252 seconds]
[23:29:36] -!- sumpfralle1 has quit [Quit: Leaving.]
[23:48:13] -!- servos4ever has quit [Quit: ChatZilla 0.9.85 [SeaMonkey 2.0.11/20101206162726]]
[23:50:13] -!- archivist has quit [Ping timeout: 276 seconds]