#linuxcnc-devel | Logs for 2013-07-07

[00:13:14] -!- BJfreeman has quit [Ping timeout: 252 seconds]
[00:25:15] -!- tjb1 has quit [Client Quit]
[00:44:39] -!- Laremere has quit [Ping timeout: 256 seconds]
[01:22:31] -!- c-bob| has quit [Ping timeout: 276 seconds]
[01:36:18] -!- Roguish has quit [Remote host closed the connection]
[02:05:30] -!- i_tarzan_ has quit [Ping timeout: 264 seconds]
[02:10:57] -!- jerryitt has quit [Read error: Connection reset by peer]
[02:11:25] _BJFreeman is now known as BJfreeman
[02:19:17] -!- L33TG33KG34R has quit [Ping timeout: 256 seconds]
[02:40:59] -!- BJfreeman has quit [Ping timeout: 252 seconds]
[02:42:42] -!- AR_ has quit [Ping timeout: 264 seconds]
[02:43:13] <jepler> aha, finally a case for G0 not being coordinated: filament retraction
[02:43:43] <jepler> in extruder-based 3d printers, when you need to move without extruding you actually want to *retract* the filament by a fixed amount. e.g., move A by -1 or -5 or some tunable number
[02:43:55] <jepler> and of course you want to move to the next location
[02:44:07] <jepler> so you end up with G0 X- Y- Z- A-
[02:44:21] <jepler> but you want the A- motion to complete as fast as possible, otherwise you leave a fine undesired filament along the way
[02:44:42] <jepler> you could program G0 A / G0 X- Y- Z- to retract before beginning the motion at all, but what you really want is for A to not be coordinated with XYZ
[02:45:05] <andypugh> It seems to me that the G0 A... belongs in a separate block, really.
[02:45:40] <jepler> or maybe with the Z-only move to the safety height
[02:45:41] <andypugh> Basically what you describe depends on an accidentally useful behaviour.
[02:45:53] <jepler> but apparently the practice on some of those embedded gcode interpreters is to do a non-coordinated move
[02:46:30] <skunkworks> disconect axis from motion - move - reconnect ;)
[02:47:01] <jepler> anyway, just a thought I had while reading charles's blog. http://bb-lcnc.blogspot.com/2013/07/slicing-for-linuxcnc.html
[02:47:17] <andypugh> On the subject of accidental behavioir: The 8gb ssd I am going to install a 64-bit OS on arrived today, and then I can start replacing the broken 32-bit-assumption counters in my code. The stuff that, for example, breaks the 7i49 driver on a 64 bit install.
[02:48:18] <jepler> yuck
[02:48:24] <jepler> let me know if you need another set of eyes
[02:49:27] _BJFreeman is now known as BJfreeman
[02:50:09] <jepler> res->accum += (signed long)(hm2->resolver.position_reg[i] - res->old_reg );
[02:50:18] <jepler> maybe this needs to be int32_t or __s32 or whatever the spelling is?
[02:50:44] <Tom_itx> was charles the one at the fest?
[02:50:53] <jepler> Tom_itx: yes he was the one with the 3d printer at fest
[02:51:33] <andypugh> jepler: Yes, that's the code.
[02:52:18] <andypugh> I could do with access to a 33 bit system to be sure :-)
[02:52:45] <jepler> that probably would be enough to reproduce the bug
[02:52:53] <andypugh> Right, 4am, time to lie down.
[02:53:07] <jepler> yeah it's about bedtime here too
[02:53:58] -!- andypugh has quit [Quit: andypugh]
[02:56:07] -!- lyzidiamond has quit [Quit: lyzidiamond]
[02:58:05] <Tom_itx> did he port linuxcnc to the bbb?
[03:05:24] -!- Loetmichel has quit [Ping timeout: 268 seconds]
[03:10:33] -!- AR__ has quit [Ping timeout: 256 seconds]
[03:13:11] BJfreeman is now known as Guest84243
[03:13:14] -!- Guest84243 has quit [Ping timeout: 252 seconds]
[03:13:19] _BJFreeman is now known as BJfreeman
[03:18:07] -!- zlog [zlog!~zlog@ip68-102-196-238.ks.ok.cox.net] has joined #linuxcnc-devel
[03:28:27] -!- Servos4ever has quit [Quit: ChatZilla 0.9.90 [SeaMonkey 2.14.1/20121129191050]]
[03:38:07] -!- PetefromTn has quit [Quit: Bye]
[03:51:00] -!- BJfreeman has quit [Ping timeout: 252 seconds]
[04:08:13] _BJFreeman is now known as BJfreeman
[04:09:34] -!- mattiasb has quit [Ping timeout: 276 seconds]
[04:25:20] -!- postaL has quit [Read error: Connection reset by peer]
[04:28:58] -!- mhaberler [mhaberler!~mhaberler@extern-186.stiwoll.mah.priv.at] has joined #linuxcnc-devel
[04:34:21] -!- AR__ has quit [Ping timeout: 264 seconds]
[04:34:22] -!- BJfreeman has quit [Quit: had a good time]
[04:41:25] -!- dgarr has quit [Ping timeout: 276 seconds]
[05:03:31] -!- Fox_Muldr has quit [Ping timeout: 276 seconds]
[05:13:49] -!- skorasaurus has quit [Ping timeout: 256 seconds]
[05:29:58] -!- Laremere has quit [Ping timeout: 256 seconds]
[06:03:29] -!- kwallace2 [kwallace2!~kwallace@smb-83.sonnet.com] has joined #linuxcnc-devel
[06:03:30] -!- kwallace has quit [Read error: Connection reset by peer]
[06:21:55] -!- vladimirek [vladimirek!~vladimire@] has joined #linuxcnc-devel
[06:21:56] -!- vladimirek has quit [Read error: Connection reset by peer]
[06:38:34] -!- karavanjo has quit [Remote host closed the connection]
[06:43:45] -!- L33TG33KG34R has quit [*.net *.split]
[06:43:45] -!- c-bob|| has quit [*.net *.split]
[06:43:45] -!- Tecan has quit [*.net *.split]
[06:43:45] -!- juxta_ has quit [*.net *.split]
[06:43:46] -!- uwe__ has quit [*.net *.split]
[06:43:46] -!- vax__ has quit [*.net *.split]
[06:43:46] -!- mle has quit [*.net *.split]
[06:43:46] -!- pjm has quit [*.net *.split]
[06:43:46] -!- shurshur has quit [*.net *.split]
[07:30:35] -!- tjtr33 has quit [Quit: Leaving]
[07:31:24] -!- mourner has quit [Quit: mourner]
[07:38:00] Cylly is now known as Loetmichel
[07:49:37] -!- kwallace2 [kwallace2!~kwallace@smb-83.sonnet.com] has parted #linuxcnc-devel
[08:38:41] -!- cpresser has quit [Quit: Lost terminal]
[09:02:26] -!- mourner has quit [Quit: mourner]
[10:07:04] -!- Nickparker has quit [Ping timeout: 256 seconds]
[10:14:15] -!- lyzidiamond has quit [Quit: lyzidiamond]
[10:36:08] -!- Simooon has quit [Read error: Connection reset by peer]
[10:45:23] -!- i_tarzan has quit [Read error: Operation timed out]
[10:57:47] -!- mhaberler has quit [Quit: mhaberler]
[10:58:50] -!- andypugh [andypugh!~andy2@cpc16-basl9-2-0-cust685.20-1.cable.virginmedia.com] has joined #linuxcnc-devel
[11:09:06] -!- stsydow has quit [Remote host closed the connection]
[11:12:10] -!- mourner has quit [Quit: mourner]
[11:13:39] -!- maximilian_h [maximilian_h!~bonsai@g226135243.adsl.alicedsl.de] has joined #linuxcnc-devel
[11:19:36] _BJFreeman is now known as BJfreeman
[11:21:12] -!- maximilian_h has quit [Quit: Leaving.]
[11:25:15] -!- BJfreeman has quit [Ping timeout: 252 seconds]
[11:26:26] _BJFreeman is now known as BJfreeman
[11:32:33] -!- xxoxx has quit [Ping timeout: 264 seconds]
[11:35:37] -!- Valen has quit [Quit: Leaving.]
[11:42:52] -!- Heinz_60 has quit [Ping timeout: 246 seconds]
[11:43:59] -!- mhaberler [mhaberler!~mhaberler@macbook.stiwoll.mah.priv.at] has joined #linuxcnc-devel
[12:02:54] -!- BJfreeman has quit [Quit: had a good time]
[12:40:06] -!- dgarr [dgarr!~dgarrett@174-26-249-207.phnx.qwest.net] has joined #linuxcnc-devel
[12:54:42] -!- gambakufu has quit [Ping timeout: 264 seconds]
[12:55:33] -!- martin__ has quit [Ping timeout: 248 seconds]
[13:03:01] -!- Heinz_60 has quit [Ping timeout: 246 seconds]
[13:40:22] -!- stsydow has quit [Remote host closed the connection]
[14:32:11] -!- Connor has quit [Read error: Operation timed out]
[14:40:31] -!- pcw_home has quit [Quit: ChatZilla 0.9.90 [Firefox 21.0/20130512194440]]
[14:43:29] -!- pcw_home [pcw_home!~chatzilla@ip-66-80-167-54.sjc.megapath.net] has joined #linuxcnc-devel
[14:49:56] -!- kwallace [kwallace!~kwallace@tmb-255.sonnet.com] has joined #linuxcnc-devel
[14:57:24] -!- kwallace2 [kwallace2!~kwallace@smb-55.sonnet.com] has joined #linuxcnc-devel
[14:58:45] -!- kwallace has quit [Ping timeout: 248 seconds]
[14:59:10] -!- kwallace2 [kwallace2!~kwallace@smb-55.sonnet.com] has parted #linuxcnc-devel
[14:59:47] -!- kwallace2 [kwallace2!~kwallace@smb-55.sonnet.com] has joined #linuxcnc-devel
[15:06:58] -!- erasmo [erasmo!~erasmo@77-255-238-64.adsl.inetia.pl] has joined #linuxcnc-devel
[15:18:28] -!- zzolo has quit [Quit: zzolo]
[15:30:09] -!- AR__ has quit [Ping timeout: 264 seconds]
[15:30:43] <skunkworks> jepler: so - if I have a setp parport.0.pin-01-out true and a ssetp parport.0.pin-01-out-reset true
[15:31:29] <skunkworks> after the reset - the hal file will force the port true the next period?
[15:31:58] <skunkworks> (I don't have to do anything else except setp the port true once in the hal file...)
[15:41:53] _BJFreeman is now known as BJfreeman
[15:42:09] -!- jerryitt has quit [Quit: Leaving.]
[15:44:48] -!- Laremere has quit [Ping timeout: 256 seconds]
[15:45:08] -!- erasmo has quit [Remote host closed the connection]
[15:49:37] -!- gregory has quit [Ping timeout: 276 seconds]
[15:50:39] <cradek> in reset mode, the input being true means "generate a pulse this period". you've got that turned on, so it'll make pulses until you turn it off.
[15:52:22] <skunkworks> ah - ok
[15:52:25] -!- stsydow has quit [Remote host closed the connection]
[15:53:35] <skunkworks> hmm - wait. I want to send pulses out of the printer port every period. so those 2 lines should be all I need?
[15:53:46] <skunkworks> (other than the reset function)
[15:53:57] <skunkworks> and the reset time..
[15:55:04] <skunkworks> or would I have to be runing a function that sets the pin high each period?
[15:57:28] <skunkworks> (I will be playing with actual hardware later today - so I can just play with it then..)
[16:14:07] -!- Heinz_60 has quit [Ping timeout: 246 seconds]
[16:21:23] -!- skunkworks has quit [Remote host closed the connection]
[16:33:45] -!- Roguish [Roguish!~Roguish@c-50-161-56-130.hsd1.ca.comcast.net] has joined #linuxcnc-devel
[16:35:07] -!- capricorn_one has quit [Ping timeout: 276 seconds]
[16:39:45] -!- mattiasb has quit [Ping timeout: 264 seconds]
[16:57:10] -!- mattiasb has quit [Ping timeout: 246 seconds]
[16:59:10] -!- Laremere has quit [Ping timeout: 276 seconds]
[17:01:44] -!- zzolo has quit [Quit: zzolo]
[17:10:13] -!- Laremere_AFK has quit [Ping timeout: 276 seconds]
[17:12:58] -!- gregory has quit [Quit: Quitte]
[17:13:12] -!- mattiasb has quit [Ping timeout: 256 seconds]
[17:19:57] -!- i_tarzan has quit [Ping timeout: 264 seconds]
[17:28:47] -!- mattiasb has quit [Ping timeout: 256 seconds]
[17:35:39] -!- ve7it [ve7it!~LawrenceG@S01060014d19d0b68.pk.shawcable.net] has joined #linuxcnc-devel
[17:46:34] -!- IchGuckLive has quit [Quit: ChatZilla 0.9.87 [Firefox 20.0/20130329043827]]
[17:48:27] -!- Heinz_60 has quit [Quit: Bye]
[17:49:58] -!- syyl_ws has quit [Quit: Verlassend]
[17:51:46] -!- [1]Heinz_60 has quit [Ping timeout: 246 seconds]
[17:54:07] -!- bdiu has quit [Remote host closed the connection]
[18:27:49] -!- Laremere has quit [Ping timeout: 246 seconds]
[18:27:56] -!- zzolo has quit [Quit: zzolo]
[18:49:44] -!- stsydow has quit [Remote host closed the connection]
[19:03:18] -!- lyzidiamond has quit [Quit: lyzidiamond]
[19:09:35] -!- syyl_ws has quit [Quit: Verlassend]
[19:15:40] -!- mattiasb has quit [Ping timeout: 276 seconds]
[19:16:31] -!- zzolo has quit [Client Quit]
[19:21:35] <mhaberler> bizarre question of the day: I need a reliable way to cause an RT missed deadline fault in an RTAI thread function. Any suggestions?
[19:22:00] -!- stsydow has quit [Remote host closed the connection]
[19:24:02] <jepler> mhaberler: repeatedly call rtapi_delay() until you're sure to have gone on too long?
[19:24:13] <mhaberler> ok
[19:24:32] <jepler> (do it based on an I/O pin that you set back to 0, so it only happens once? or a rising edge on an IN pin?
[19:24:36] <jepler> )
[19:24:44] <Tom_itx> will rtapi_delay() accept a delay parameter?
[19:24:58] <jepler> man rtapi_delay says it will
[19:25:07] <Tom_itx> instead of multiple calls
[19:25:25] <jepler> well it's designed so that it can only delay for rtapi_delay_max, typically 1/4 of a period
[19:25:30] <mhaberler> all in place already; turned out the rtapi exception handling was all cleaned up in the ub branch already - I just had forgotten I did it already
[19:25:33] <Tom_itx> oh
[19:25:35] <jepler> so you'd need to call it 4 times to be sure you've wasted an entire period
[19:25:57] <mhaberler> so rt fault behavior and pins are now defined by a loadable halcomp
[19:26:16] <mhaberler> which can redefine default behavior (just printing errors)
[19:26:33] -!- mattiasb has quit [Ping timeout: 264 seconds]
[19:36:34] -!- mattiasb has quit [Ping timeout: 256 seconds]
[19:36:38] <zultron> http://pastebin.ca/2420162
[19:37:15] <zultron> Whoops, meant for mhaberler. Anyway, mhaberler, bit of a bizarre error....
[19:52:41] <jepler> zultron: doesn't ring a bell with me, or with google :-/
[19:53:35] -!- sharpen047 has quit [Ping timeout: 250 seconds]
[19:58:29] BJfreeman is now known as Guest60223
[19:58:36] _BJFreeman is now known as BJfreeman
[19:58:42] -!- rob_h [rob_h!~rob_h@] has joined #linuxcnc-devel
[19:58:54] -!- Guest60223 has quit [Ping timeout: 252 seconds]
[19:59:31] <zultron> Thanks, jepler. mhaberler set me straight; I was doing something I shouldn't have been.
[20:01:31] <jepler> I won't worry about it any further
[20:39:54] -!- arekm has quit [Ping timeout: 268 seconds]
[20:47:27] -!- arekm has quit [Read error: Operation timed out]
[21:03:31] <mhaberler> jepler: this is the state of affairs with RT fault handling: http://git.mah.priv.at/gitweb?p=emc2-dev.git;a=shortlog;h=refs/heads/ub-rtfault-handling
[21:04:05] <mhaberler> all RT faults are funneled through a single exception handler in RTAPI, and that can be redirected
[21:04:35] <mhaberler> rtmon.comp is a HALcomp which bends the exception handler onto itself and hence can implement policy how to deal with faults
[21:04:59] <mhaberler> (unpolished, but works )
[21:14:00] -!- DJ9DJ has quit [Quit: bye]
[21:15:57] -!- Heinz_60 has quit [Quit: HydraIRC -> http://www.hydrairc.com <- Go on, try it!]
[21:24:08] -!- chillly has quit [Quit: Leaving]
[21:33:40] -!- Tom_garage [Tom_garage!~Tl@unaffiliated/toml/x-013812] has joined #linuxcnc-devel
[21:34:43] -!- Tom_itx has quit [Ping timeout: 256 seconds]
[21:34:52] Tom_garage is now known as Tom_itx
[21:34:57] -!- mhaberler has quit [Ping timeout: 264 seconds]
[21:36:20] -!- Kenneth_Lerman [Kenneth_Lerman!~chatzilla@24-151-1-146.static.nwtn.ct.charter.com] has joined #linuxcnc-devel
[21:37:51] <cradek> Kenneth_Lerman: do you think this is something? http://sourceforge.net/p/emc/bugs/315/
[21:42:12] <cradek> Kenneth_Lerman: trying the first block, I do get the error, and I can't spot anything wrong with it when reading the docs
[21:42:45] -!- Tom_garage [Tom_garage!~Tl@unaffiliated/toml/x-013812] has joined #linuxcnc-devel
[21:43:26] <Kenneth_Lerman> It may be something. Unforch, I haven't played with this is a few years. I don't have a working recent configuration.
[21:43:41] <cradek> can I do anything to help you get set up again?
[21:43:58] -!- Tom_itx has quit [Disconnected by services]
[21:44:04] Tom_garage is now known as Tom_itx
[21:44:51] <andypugh> I think Nick is the gcodetools guy, so he has probably looked at the easy answers..
[21:45:29] <Kenneth_Lerman> Have you tried it and seen it fail? I'd be interested in knowing which line is sees the error in. And what illegal character it is seeing.
[21:47:30] <Kenneth_Lerman> Is this the entire file that is being read? Does it occur when run right after the program is started? (Or might there be some lingering incorrect context)|
[21:49:25] <Kenneth_Lerman> Are there two bugs in this one fragment? Is he saying that taking out either the break or the return fixes things completely?
[21:49:26] <cradek> it errors for me as AXIS loads it and runs it to generate the preview, on a new linuxcnc startup
[21:49:53] <cradek> I typed the program myself so I know it's not got nonascii garbage in it (that tripped up someone recently)
[21:50:35] <cradek> 'o124 break' is the implicated line, but of course those can be off by 1
[21:50:36] <Kenneth_Lerman> Has anyone tried this test on an old version? (Does it fail on just newer releases?)
[21:51:05] <cradek> I don't know that
[21:51:18] <cradek> and I haven't tried the second block at all
[21:51:55] -!- mhaberler [mhaberler!~mhaberler@extern-186.stiwoll.mah.priv.at] has joined #linuxcnc-devel
[21:52:08] -!- zzolo has quit [Quit: zzolo]
[21:52:14] <cradek> I'm going to build v2.5_branch
[21:57:05] <cradek> in 2.5 branch I do not get an error, so perhaps someone has broken it in master
[21:57:27] -!- stsy has quit [Read error: Operation timed out]
[21:58:40] <cradek> it should be possible to bisect it
[21:58:48] <cradek> but not on this very slow computer...
[22:01:10] <Kenneth_Lerman> As far as the second bug is concerned, that might be a feature rather than a bug. :-{ My recollection is that the code for O words does a static evaluation of subroutine definitions. That means that after iit hits the O<multipass> SUB, it is no longer executing code. For that reason, #<sub> = #1 won't be evaluated. And therefore, it is undefined. Defining it somewhere that is executed, will...
[22:01:11] <Kenneth_Lerman> ...leave it defined, and we won't get the error.
[22:01:45] <cradek> it's unfortunate there are two reports combined into one
[22:04:37] <cradek> Bisecting: 648 revisions left to test after this (roughly 9 steps)
[22:04:39] <cradek> (sigh)
[22:05:16] <Kenneth_Lerman> Yes, it would be nice to be able to just stamp them reject and tell them to resubmit. We have an answer for the second one, though. The documentation should be changed to clarify (1) how it works and (2) what is being done won't work requires that the variable be predefine. On the other hand, it might be fixable by skipping the error generation for this case.
[22:05:59] <cradek> with persistence here I should be able to find the breakage for the first block in the report
[22:07:04] <Kenneth_Lerman> It might be faster to manually bisect this. Most of the 648 do not relate to the interpreter. If you can determine which ones do, you can pick your bisection points to be in the middle of those changes. That might cut your bisections in half.
[22:08:40] <cradek> also there's a way to tell git that only changes in certain directories count
[22:08:51] <cradek> I'll go to a faster machine AND do that
[22:11:07] -!- bedah has quit [Quit: Ex-Chat]
[22:12:03] <mhaberler> Hi Ken - good to see you out in IRC land!
[22:14:23] -!- mhaberler has quit [Quit: mhaberler]
[22:17:29] -!- mhaberler [mhaberler!~mhaberler@extern-186.stiwoll.mah.priv.at] has joined #linuxcnc-devel
[22:17:43] <Kenneth_Lerman> I'm not usually here. I returned from our summer place in Otis, MA, connected my laptop, and happened to see cradek's note. My status (as shown on my computer) is "away". I don't know why "chatzilla" doesn't show that (or how it would appear on irc).
[22:18:50] <Kenneth_Lerman> I had a chat with Stuart about five axis tool compensation and have been thinking about it.
[22:19:16] <Kenneth_Lerman> I think it is easy if you consider it to be five axis tool *wear* compensation.
[22:19:39] <cradek> you mean assume small "diameters"?
[22:20:06] <cradek> that sure makes you less likely to have invalid/degenerate paths
[22:20:10] <Kenneth_Lerman> That is, you create the path for a nominal tool and can only enter the difference (a negative number) into the tool table.
[22:20:29] <Kenneth_Lerman> That means you will never have invalid paths.
[22:22:02] <cradek> I'm quite sure you're not right about "never"
[22:22:08] <cradek> less likely to
[22:22:28] <cradek> negative just means swap left/right, nothing more, it's no kind of magic bullet
[22:23:02] <Kenneth_Lerman> So, if you have a radius wear of .005, you offset the tool .005 in the direction perpendicular to the motion of the tool (and to the axis of the tool). It is a magic bullet because the tool can always fit in the radius (since it is smaller).
[22:23:36] <Kenneth_Lerman> For tool length compensation, you just offset the tool along its axis (that one is easy).
[22:23:38] <cradek> you'll still fail cutting inside on your .001 inch radius arc
[22:25:00] <cradek> well that would have failed without the compensation
[22:25:04] <cradek> I need to think harder
[22:25:26] <cradek> er no, it wouldn't have
[22:25:28] <Kenneth_Lerman> Sorry, I should have been more clear. This would be a *new* mode called cutter wear compensation. All it would do would be to offset the tool by the appropriate amount. For arcs, it would move in or out depending on the left or right side and direction of the arc.
[22:25:49] <cradek> I don't see how that's different?
[22:28:04] -!- Tecan has quit [Ping timeout: 276 seconds]
[22:28:21] <cradek> argh these bisect targets don't build
[22:28:26] <cradek> it's maddening
[22:31:12] <Kenneth_Lerman> The difference is that the user (Stuart in particular) knows what will happen and doesn't care. I think the calculation is pretty simple. Before, we had to worry about the tool fitting in the corner. Stuart just wants us to follow the specified path, but just shift over a little to correct for the worn tool. He knows that when he specifies four corners of a pocket by moving in four straight...
[22:31:14] <Kenneth_Lerman> ...lines he will get rounded corners. We will adjust things so that the pocket is the same size -- except that the corner radii are .005 smaller (in my example). He's OK with that. (That's my understanding) If he wanted to specify an exact radius, he could program the arcs, and so long as the cutter was smaller than specified, he would get the right shape.
[22:33:17] <cradek> I've heard him say that before ("just move the tool over!") but I don't see how you can avoid the concave corner problem by just waving your hands
[22:34:45] <Kenneth_Lerman> Well, you know the tool will fit into the desired shape because a larger tool fit into that shape.
[22:35:32] <cradek> maybe we are not talking about the same thing at all
[22:36:13] <cradek> you still have to analyze the moves and calculate new endpoints at every corner, right?
[22:36:13] <Kenneth_Lerman> That's why *I* specify tool *wear* compensation. A tool can't wear to a larger size. (That's NOT true. The radius of a lathe tool can get larger as the point wears.)
[22:37:14] -!- mourner has quit [Quit: mourner]
[22:37:20] <cradek> to me, -.005 right is exactly the same as +.005 left; maybe I'm missing something conceptually
[22:38:11] <Kenneth_Lerman> Yes. At every change of motion. On a straight move: add the wear to the length of the move, if following on the right side- move the target tool position to the right by the wear amount.
[22:39:13] <cradek> I don't follow that at all
[22:39:14] <Kenneth_Lerman> Nope -- the length of the move amount is wrong. It depend, I think, on the angle of the next move.
[22:39:28] <cradek> sure it does
[22:39:46] <cradek> it might make an inside or outside corner
[22:40:49] <cradek> this is exactly what cutter comp already does
[22:41:13] -!- skunkworks [skunkworks!~chatzilla@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[22:41:45] <skunkworks> after a couple of false starts - that seemed to work
[22:43:02] <cradek> if the corner is concave you have to stop short, if it's convex you have to go around (or past) it
[22:43:30] <cradek> fwiw, stuart thinks going past (make a longer pointy corner) instead of around (make an arc) simplifies it - I don't agree
[22:46:14] <Kenneth_Lerman> Stuart is talking about having the path specified with small negative changes in tool diameter. You are correct that the general problem where the edge is specified and we must offset around the outside is not easy. Postscript tackled this problem with lots of special cases and parameter that determine how "pointy" a very sharp edge might me.
[22:47:33] <cradek> I still don't understand why negative tool diameter means anything special. SMALL tool diameter helps you not fail to find the new path but negative doesn't help as far as I can see
[22:48:12] <cradek> yes I've seen postscript can give you a fillet instead of a super pointy corner - that'd be a lousy answer in cutter comp
[22:50:09] <cradek> I'm failing to bisect this. I can't find a nearby ref that even builds.
[22:50:56] <andypugh> That seems strange.
[22:51:35] <cradek> current failure is e200945b4b9b11c2406268ad23a186a08df8b668
[22:51:46] <cradek> it contains merge conflict markers
[22:51:55] <cradek> and the log message contains "mopup"
[22:52:05] <Kenneth_Lerman> One of the docs on tool diameter compensation discusses two ways in which it might be used. In the first, the *part* is described by the motion (as if the tool diameter were zero) and the compensation creates the part by offsetting... appropriately. In the second, the *path* is specified for a nominal tool and the compensation adjusts the path so that the correct part is created. I think...
[22:52:06] <Kenneth_Lerman> ...Stuart is talking about the second case. It's my (perhaps naive) claim that so long as the tool diameter is smaller than the one for the calculated path, we cannot have gouging problems. Furthermore, it should be pretty straightforward to compute the path.
[22:52:36] <cradek> I understand the two use cases and I assert that the code to accomplish them is exactly the same
[22:52:48] <cradek> and they have exactly the same problems
[22:52:48] <zultron> cradek, maybe follow the instructions and mop it up? >:D
[22:53:07] <zultron> Sorry, not constructive.
[22:53:14] <cradek> the only benefit is in having smaller offsets in #2 - you're less likely to become degenerate
[22:53:21] -!- mhaberler has quit [Quit: mhaberler]
[22:53:45] BJfreeman is now known as Guest52991
[22:53:52] _BJFreeman is now known as BJfreeman
[22:54:27] <cradek> zultron: bad vc hygeine in the past is a gift that keeps giving :-(
[22:54:32] <andypugh> Stuart was discussing "East Coast" v "West Coast" in this context. Being from neither coast, I saw them as "right" and "wrong".
[22:55:15] -!- Guest52991 has quit [Ping timeout: 252 seconds]
[22:55:33] <Kenneth_Lerman> My understanding of the degenerate cases is that line segments disappear because the tool becomes larger and that causes a segment to be swamped out of the path (I know that doesn't mean anything concrete).
[22:55:43] <cradek> yes
[22:56:24] <cradek> well not because the tool becomes larger -- it's that the path is moved
[22:56:36] <Kenneth_Lerman> In the case of a smaller tool, I don't think that occurs (of course, what seems obvious isn't always true).
[22:56:37] <cradek> whether you're moving the path + or - doesn't matter
[22:57:05] <andypugh> Do the "gouging" errors inidcate that the tool path generator can't solve the path, rather than it being a very annnoying attempt to save us from ourselves?
[22:57:17] <cradek> that is not true. you're thinking of the tool getting smaller when you should be thinking of moving the given path left or right
[22:57:46] -!- mhaberler [mhaberler!~mhaberler@extern-186.stiwoll.mah.priv.at] has joined #linuxcnc-devel
[22:58:00] -!- stsydow has quit [Client Quit]
[22:58:12] -!- f1oat [f1oat!~f1oat@AMontsouris-553-1-111-235.w92-151.abo.wanadoo.fr] has joined #linuxcnc-devel
[22:58:30] <cradek> mhaberler: I think it's likely that this bug 315 is caused by your interp changes, but I'm utterly failing to bisect it because many of the commits don't compile
[23:00:04] <mhaberler> what makes you think so?
[23:00:37] <cradek> they are sweeping changes, and there have been no other sweeping changes since v2.5_branch
[23:01:16] <mhaberler> anything more exact than that ;-?
[23:01:18] <cradek> my bisect is failing because there is a large number of adjacent commits that are uncompileable because they contain merge conflict markers
[23:01:52] <mhaberler> which one you tried, the first or the second?
[23:01:55] <cradek> no sorry, I would have the exact commit by now if not for the poor vc hygeine
[23:02:02] <cradek> still on the first
[23:03:09] <cradek> maybe this will save you a little time: http://timeguy.com/cradek-files/emc/315.ngc
[23:03:53] <cradek> in v2.5_branch I get the "breaking" comment; in master it fails to load
[23:04:14] <Kenneth_Lerman> cradek: I think I've made an example that shows you are correct in that you still get degenerate segments. :-( On the other hand, Stuart would say that is his problem. Just compute the points and the moves one at a time and execute them. If there are problems with the part, they are the programmer's problem.
[23:04:45] <cradek> Kenneth_Lerman: I agree he says things like that, but I don't buy it for a second
[23:05:03] <Kenneth_Lerman> because...
[23:05:05] <cradek> go ahead and have the control do something random and wrong - we'll notice it and work around it, don't worry
[23:05:23] <cradek> can't say that with a straight face
[23:05:33] -!- Nick001-Shop has quit [Ping timeout: 264 seconds]
[23:05:48] Nick001-Shop_ is now known as Nick001-Shop
[23:05:49] <Kenneth_Lerman> Well, not really random. Actually, well defined (if nothing else read the code :-{ )
[23:06:21] <cradek> the current cutter comp code errors in the cases where it would make the tool cut into the part incorrectly
[23:06:30] -!- rob_h has quit [Ping timeout: 240 seconds]
[23:06:37] <cradek> if you are saying that is not a necessary requirement I just disagree
[23:07:11] <cradek> I agree it's not random, that was unnecessarily hyperbolic of me
[23:07:44] <andypugh> Better hypoerbolic than hypergolic.
[23:08:04] <Kenneth_Lerman> I think Stuart would disagree in that he would say that your definition and his (of incorrectly) are different. (I know you knew that -- my comment was unnecessarily snarky).
[23:08:29] <cradek> heh
[23:08:34] <andypugh> Talking of hypergolic, this amused me: http://www.tor.com/stories/2012/07/a-tall-tail
[23:09:11] <andypugh> "what's the worst possible rocket fuel, and what would be the worts possible oxidiser to go with it"
[23:10:00] <Kenneth_Lerman> Should we let the user (or perhaps the integrator) make the choice, though? I'd certainly "trust" Stuart to be responsible for the consequences of his actions. (Although I don't know about the average user.)
[23:10:13] <cradek> Kenneth_Lerman: I just think he's not thought it through, that's all.
[23:10:32] <cradek> I think that's sorta the wrong question.
[23:10:59] <andypugh> I came in late. What prevents you from using the current tool compensation the way described?
[23:11:22] <Kenneth_Lerman> Well, the real question is can we make it do what he really needs?
[23:11:43] <cradek> I've heard similar thoughts about the ijk that you can easily misspecify (mismatched radii). Why not let me set the tolerance to 10 inches and let the user avoid the error? because it will do a wrong thing. erroring is always better than doing a wrong thing.
[23:11:52] <cradek> ... ijk arcs
[23:12:36] <Kenneth_Lerman> The current tool compensation fails (and doesn't continue) if it detects that the cutter won't fit in the corner it is trying to cut. Some users just say that it should just do what you said -- even if that isn't what you meant.
[23:12:46] <cradek> I'm not a fan of "making it an option" as a way of avoiding the work of doing it right
[23:13:07] <cradek> if that's the problem you're trying to fix, then you should make it handle the removal of degenerate moves
[23:13:39] <Kenneth_Lerman> Is this a case where we can do it right? I should have guessed that you would say that.
[23:14:11] <cradek> a user who changed an offset and then got a ruined part is NEVER going to say "serves me right! At least it didn't error and tell me it was impossible!", I think that's just fiction
[23:14:46] <cradek> if you're talking about degenerate moves, sure you could handle them, but it's complicated
[23:14:52] <Kenneth_Lerman> OK. I need to think about how to detect and remove degenerate moves.
[23:15:05] <cradek> ok that's a goal that makes sense to me :-)
[23:15:32] <cradek> this has nothing to do with 5 axis now though, right?
[23:16:30] <Kenneth_Lerman> Well, I'm not sure I making it a goal yet. But I do want to understand it better. You are correct in that the number of axes doesn't really matter once you hit the magic number two.
[23:16:33] <cradek> (I should say: you can probably come up with the right thing to do about certain degenerate moves in certain cases)
[23:17:06] <cradek> we sorely need shared pencil and paper to talk about this in a reasonable way :-/
[23:18:10] <Kenneth_Lerman> degenerate moves makes me think of the pervert going after the underage girl. I'm outta here to get some dinner. Thanks for chatting.
[23:18:19] <cradek> also, if you are considering writing a new comp algorithm I suggest making it possible to be at a level outside the interpreter
[23:18:23] <Tom_itx> whiteboard
[23:19:00] <cradek> there are architecture problems that could possibly be solved by doing that separation
[23:19:04] -!- BJfreeman has quit [Ping timeout: 252 seconds]
[23:19:19] <cradek> we should chat more about it, and you're welcome for, uh, raining on things
[23:27:01] -!- syyl_ has quit [Ping timeout: 248 seconds]
[23:31:19] -!- atom1 has quit [Changing host]
[23:32:53] -!- mhaberler has quit [Quit: mhaberler]
[23:33:31] <KGB-linuxcnc> 03dgarrett 05master eb06ff3 06linuxcnc 10(17 files in 6 dirs) * pyngcgui: more fixes for package builds
[23:34:51] <cradek> dgarr: thanks for working on that
[23:35:07] -!- mhaberler [mhaberler!~mhaberler@extern-186.stiwoll.mah.priv.at] has joined #linuxcnc-devel
[23:35:59] <cradek> oh how I love the buildbot
[23:47:55] -!- andypugh has quit [Quit: andypugh]
[23:52:25] -!- Nick001-Shop has quit [Remote host closed the connection]