Back
[00:00:14] -!- yuvipanda has quit [Ping timeout: 260 seconds]
[00:00:15] yuvipanda_ is now known as yuvipanda
[00:00:33] -!- ve7it has quit [Remote host closed the connection]
[00:00:33] -!- logger[mah] has quit [Remote host closed the connection]
[00:00:42] -!- logger[mah] [logger[mah]!~loggermah@ns2.mah.priv.at] has joined #linuxcnc-devel
[00:01:11] -!- Nick001-Shop has quit [Remote host closed the connection]
[00:05:41] -!- yuvipanda has quit [Ping timeout: 256 seconds]
[00:05:42] yuvipanda_ is now known as yuvipanda
[00:10:15] -!- Connor1 has quit [Ping timeout: 252 seconds]
[00:10:18] -!- sumpfralle has quit [Ping timeout: 264 seconds]
[00:13:28] -!- servos4ever has quit [Quit: ChatZilla 0.9.85 [SeaMonkey 2.0.11/20101206162726]]
[00:13:32] <KGB-linuxcnc> 03jthornton 05master 89bfc1b 06emc2 10docs/src/remap/structure.txt * Docs: rebranding
[00:15:16] -!- sumpfralle1 has quit [Ping timeout: 248 seconds]
[00:17:13] -!- yuvipanda has quit [Ping timeout: 244 seconds]
[00:17:19] yuvipanda_ is now known as yuvipanda
[00:20:18] -!- zzolo has quit [Quit: zzolo]
[00:24:36] -!- andypugh has quit [Quit: andypugh]
[00:25:47] -!- tjb1 has quit [Quit: tjb1]
[00:31:16] -!- yuvipanda has quit [Ping timeout: 245 seconds]
[00:31:45] -!- sumpfralle has quit [Read error: Connection reset by peer]
[00:33:55] -!- sumpfralle1 has quit [Client Quit]
[00:35:36] -!- jd896 has quit [Remote host closed the connection]
[00:37:36] -!- Tom_L has quit [Client Quit]
[00:42:11] -!- rob_h has quit [Ping timeout: 255 seconds]
[00:43:46] -!- bradsimantel has quit [Quit: bradsimantel]
[00:49:06] -!- yuvipanda has quit [Read error: Connection reset by peer]
[00:51:18] -!- adampassey has quit [Ping timeout: 245 seconds]
[00:56:34] hdokes|werkin is now known as hdokes
[01:00:30] -!- racycle has quit [Quit: racycle]
[01:14:13] -!- bradsimantel has quit [Client Quit]
[01:14:27] -!- mhaberler has quit [Ping timeout: 276 seconds]
[01:18:32] -!- sumpfralle has quit [Ping timeout: 268 seconds]
[01:20:26] -!- yuvipanda has quit [Ping timeout: 255 seconds]
[01:20:27] yuvipanda_ is now known as yuvipanda
[01:28:32] hdokes is now known as hdokes|werkin
[01:29:29] -!- toastyde1th has quit [Read error: Connection reset by peer]
[01:34:51] -!- FinboySlick has quit [Remote host closed the connection]
[01:44:35] <seb_kuzminsky> thanks JT-Shop
[02:10:08] -!- kmiyashiro has quit [Ping timeout: 252 seconds]
[02:25:57] -!- paideia has quit [Quit: Leaving]
[02:30:38] <skunkworks> http://www.cnczone.com/forums/pic_programing_design/165498-rt-8p8c_-_pic32_based_ethernet.html
[02:48:16] -!- micges has quit [Quit: Wychodzi]
[02:55:58] -!- yuvipanda has quit [Ping timeout: 252 seconds]
[03:02:36] -!- skunkworks has quit [Ping timeout: 240 seconds]
[03:15:35] -!- bradsimantel has quit [Ping timeout: 265 seconds]
[03:15:36] bradsimantel_ is now known as bradsimantel
[03:28:55] <seb_kuzminsky> is it true that there is no parameter (numbered or named) that has the current position in the g53 coordinate system?
[03:29:41] <seb_kuzminsky> #5221-#5230 has the current coords in g54...
[04:12:11] -!- Valen has quit [Ping timeout: 256 seconds]
[04:17:45] -!- bradsimantel has quit [Ping timeout: 276 seconds]
[04:17:45] bradsimantel_ is now known as bradsimantel
[04:19:18] -!- Valen has quit [Ping timeout: 264 seconds]
[04:27:44] -!- Valen has quit [Quit: Leaving.]
[04:36:06] <KimK> seb_kuzminsky: Hi Seb. I think there is no current position parameter at all. If there were, wouldn't the parameter table have to be re-written to file almost continually? And the #5221-#5230 are not really the current coordinates in g54, just the current offsets in g54, so that only has to be re-written rarely. Does that sound right to you?
[04:36:36] -!- yuvipanda has quit [Ping timeout: 240 seconds]
[04:42:03] <KimK> Or if the parameter table was not re-written to file, but just to memory, then we would have to tolerate a difference between memory and file and write RAM to file before something goes wrong and we forget? (Sounds like trouble waiting to happen?)
[04:47:12] <KimK> seb_kuzminsky: I can only guess what you're up to, but would you like to be able to write (in g-code) something like: if [HAL.axis0.current-position GT 12.3456] (then do something?)
[05:06:31] -!- bradsimantel has quit [Quit: bradsimantel]
[05:22:26] sliptonic is now known as sliptonic_away
[05:40:05] -!- mhaberler [mhaberler!~mhaberler@extern-181.stiwoll.mah.priv.at] has joined #linuxcnc-devel
[05:55:26] -!- asdfasd has quit [Ping timeout: 245 seconds]
[06:00:42] -!- LeelooMinai has quit [Ping timeout: 264 seconds]
[06:02:29] -!- Fox_Muldr has quit [Ping timeout: 260 seconds]
[06:02:47] sliptonic_away is now known as sliptonic
[06:11:28] -!- psha[work] [psha[work]!~psha@195.135.238.205] has joined #linuxcnc-devel
[06:24:16] -!- tjb1 has quit [Quit: tjb1]
[06:45:59] -!- kmiyashiro_ has quit [Read error: Connection reset by peer]
[06:48:22] -!- kmiyashiro__ has quit [Read error: Connection reset by peer]
[06:48:51] -!- kmiyashiro has quit [Ping timeout: 244 seconds]
[06:48:51] kmiyashiro___ is now known as kmiyashiro
[06:50:26] -!- kmiyashiro_ has quit [Ping timeout: 245 seconds]
[06:50:31] -!- kmiyashiro__ has quit [Read error: Connection reset by peer]
[06:51:23] -!- kmiyashiro__ has quit [Read error: Connection reset by peer]
[06:52:29] -!- kmiyashiro___ has quit [Read error: Connection reset by peer]
[06:53:09] -!- kmiyashiro____ has quit [Read error: Connection reset by peer]
[06:53:45] -!- kmiyashiro has quit [Ping timeout: 276 seconds]
[06:53:45] kmiyashiro____ is now known as kmiyashiro
[06:55:06] -!- kmiyashiro_ has quit [Ping timeout: 240 seconds]
[06:56:31] -!- kmiyashiro__ has quit [Ping timeout: 256 seconds]
[06:56:41] -!- kmiyashiro___ has quit [Ping timeout: 245 seconds]
[07:01:27] -!- racycle has quit [Quit: racycle]
[07:04:09] -!- kmiyashiro has quit [Ping timeout: 276 seconds]
[07:16:58] -!- kmiyashiro has quit [Ping timeout: 252 seconds]
[07:22:18] -!- maximilian_h [maximilian_h!~bonsai@f051129072.adsl.alicedsl.de] has joined #linuxcnc-devel
[07:22:31] -!- maximilian_h has quit [Client Quit]
[07:33:32] -!- jd896 has quit [Remote host closed the connection]
[07:33:35] sliptonic is now known as sliptonic_away
[07:54:06] -!- herron has quit [Ping timeout: 264 seconds]
[08:03:20] sliptonic_away is now known as sliptonic
[08:08:33] -!- satyag has quit [Read error: Connection reset by peer]
[08:19:06] -!- herron has quit [Ping timeout: 268 seconds]
[08:40:33] -!- Loetmichel has quit [Read error: Connection reset by peer]
[08:58:01] -!- mozmck has quit [Ping timeout: 244 seconds]
[09:16:33] -!- mozmck [mozmck!~moses@client-204.235.45.161.wcfltx.partnershipbroadband.com] has joined #linuxcnc-devel
[09:19:15] -!- rob_h [rob_h!~rob_h@5e045844.bb.sky.com] has joined #linuxcnc-devel
[09:24:35] -!- Loetmichel has quit [Ping timeout: 252 seconds]
[09:31:42] -!- satyag has quit [Read error: Connection reset by peer]
[09:35:10] -!- zlog has quit [Ping timeout: 246 seconds]
[09:50:03] -!- zlog [zlog!~zlog@ip24-255-189-172.ks.ks.cox.net] has joined #linuxcnc-devel
[09:50:57] -!- hewball has quit [Quit: No Ping reply in 180 seconds.]
[10:23:08] -!- yuvipanda has quit [Ping timeout: 255 seconds]
[11:03:03] -!- gambakufu has quit [Ping timeout: 244 seconds]
[11:05:14] -!- yuvipanda has quit [Quit: yuvipanda]
[12:10:20] -!- theos has quit [Disconnected by services]
[12:31:58] -!- dhoovie has quit [Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/]
[12:43:46] -!- skunkworks [skunkworks!~skunkwork@68-115-41-210.static.eucl.wi.charter.com] has joined #linuxcnc-devel
[12:51:04] -!- elmo40 has quit [Quit: Leaving.]
[13:19:19] -!- mk0 has quit [Quit: Looking for access to www.icdd.com bases.]
[13:48:38] -!- Valen has quit [Quit: Leaving.]
[13:57:25] <seb_kuzminsky> KimK: i want to print it out in a test, for debugging purposes
[13:58:30] <KGB-linuxcnc> 03jthornton 05v2.5_branch dfad000 06emc2 10docs/src/hal/ 10images/stepgen-type11-14.svg 10images/stepgen-type2-4.svg 10images/stepgen-type5-10.svg
[13:58:30] <KGB-linuxcnc> Docs: replace pahse with phase in the svg files
[13:58:30] <KGB-linuxcnc> this does not fix the png files that are used by the docs
[13:58:30] <KGB-linuxcnc> I'm still looking at how to convert the svg to png and end
[13:58:30] <KGB-linuxcnc> up with a quality photo
[13:58:30] <KGB-linuxcnc> Signed-off-by: John Thornton <jthornton@gnipsel.com>
[14:02:42] <seb_kuzminsky> ^^^^^^^^^^^ wow, that's some positive reinforcement for me to put stuff in the bug tracker...
[14:04:06] <jthornton> lol, I even read them from time to time
[14:04:34] <jthornton> now if we can convert the svg to png and get a quality result we will have it made
[14:04:53] <seb_kuzminsky> yeah that would be cool
[14:06:26] -!- kmiyashiro has quit [Read error: Connection reset by peer]
[14:06:31] -!- sumpfralle has quit [Ping timeout: 252 seconds]
[14:06:38] <seb_kuzminsky> i'll take a look at autogenerating pngs from svgs in a week or several
[14:07:05] -!- sumpfralle1 has quit [Read error: Operation timed out]
[14:07:06] <seb_kuzminsky> do you want to close the rebranding bug or shall i?
https://sourceforge.net/tracker/?func=detail&aid=3581973&group_id=6744&atid=106744
[14:07:40] -!- archivist has quit [Ping timeout: 244 seconds]
[14:07:46] <jthornton> I don't know how to close them so you should
[14:07:52] <seb_kuzminsky> ok
[14:08:24] -!- the_wench has quit [Ping timeout: 260 seconds]
[14:09:06] <seb_kuzminsky> hm, actually the docs still mentions emc in a couple of places
[14:09:11] <seb_kuzminsky> http://www.linuxcnc.org/docs/devel/html/remap/structure.html
[14:09:34] <seb_kuzminsky> maybe the webpage is out of date? or maybe not all instances got changed to linuxcnc?
[14:09:55] <jthornton> that has to wait for a push uphill
[14:10:33] -!- sumpfralle2 has quit [Ping timeout: 276 seconds]
[14:10:53] <seb_kuzminsky> ok cool
[14:11:00] <seb_kuzminsky> bbl, work
[14:11:32] <jthornton> ok
[14:27:57] -!- ybon has quit [Quit: WeeChat 0.3.8]
[14:29:06] -!- sumpfralle has quit [Ping timeout: 268 seconds]
[14:29:21] -!- vladimirek has quit [Read error: Connection reset by peer]
[14:33:02] -!- vladimirek [vladimirek!~vladimire@95.105.250.72] has joined #linuxcnc-devel
[14:42:21] -!- odogono has quit [Ping timeout: 252 seconds]
[14:47:56] -!- kmiyashiro has quit [Read error: Connection reset by peer]
[14:59:18] -!- jpk has quit [Ping timeout: 276 seconds]
[15:00:45] -!- psha[work] has quit [Quit: Lost terminal]
[15:06:54] -!- kmiyashiro has quit [Quit: kmiyashiro]
[15:08:25] -!- kmiyashiro has quit [Client Quit]
[15:11:59] -!- yuvipanda has quit [Ping timeout: 260 seconds]
[15:13:38] -!- automata__ has quit [Ping timeout: 252 seconds]
[15:14:01] -!- ve7it [ve7it!~LawrenceG@S0106001c10b7770f.pk.shawcable.net] has joined #linuxcnc-devel
[15:35:00] -!- ybon has quit [Quit: WeeChat 0.3.8]
[15:42:33] -!- zzolo has quit [Quit: zzolo]
[16:00:04] <skunkworks> http://electronicsam.com/images/KandT/wrench.JPG
[16:11:50] <seb_kuzminsky> nice wrench
[16:24:57] -!- bmwyss has quit [Quit: bmwyss]
[16:31:15] <seb_kuzminsky> skunkworks: how did you get the sharp corners?
[16:31:24] <cradek> haha
[16:31:47] <seb_kuzminsky> what?
[16:31:56] <cradek> see #linuxcnc
[16:32:01] <seb_kuzminsky> ok
[16:32:49] <seb_kuzminsky> great minds think alike, and apparently so do we
[16:33:01] <cradek> yes I was just thinking that
[16:39:24] -!- sumpfralle1 has quit [Ping timeout: 244 seconds]
[16:40:13] <mhaberler> the xenomai-kernel port just runs its first RT thread
[16:41:16] <mhaberler> this is like RTAI - kernel modules, kernel threads - not userland like the rt-preempt work
[16:41:22] <seb_kuzminsky> cool!
[16:41:54] <mhaberler> on 3.2.21, i.e. postwar ;)
[16:44:36] -!- sumpfralle has quit [Ping timeout: 245 seconds]
[16:54:19] -!- sumpfralle1 has quit [Ping timeout: 260 seconds]
[16:56:29] yuvipanda is now known as YuviPanda|Storm
[17:02:18] -!- YuviPanda|Storm has quit [Ping timeout: 244 seconds]
[17:10:19] yuvipanda is now known as YuviPanda|Storm
[17:12:21] -!- ybon has quit [Quit: WeeChat 0.3.8]
[17:19:36] YuviPanda|Storm is now known as SadPanda|Storm
[17:21:22] -!- andypugh [andypugh!~andy2@cpc2-basl1-0-0-cust639.basl.cable.virginmedia.com] has joined #linuxcnc-devel
[17:28:36] <KGB-linuxcnc> 03seb 05v2.5_branch 7f8cef3 06emc2 10docs/ 10src/gcode/tool_compensation.txt 10src/gcode/tool_compensation_de.txt 10src/gcode/tool_compensation_es.txt 10src/gcode/tool_compensation_pl.txt * docs: tool numbers & pocket numbers must be unique
[17:28:41] -!- ve7it has quit [Remote host closed the connection]
[17:32:15] -!- Guest22805 [Guest22805!~nikola@78-83-51-185.spectrumnet.bg] has joined #linuxcnc-devel
[17:34:19] -!- SadPanda|Storm has quit [Ping timeout: 260 seconds]
[17:34:25] yuvipanda_ is now known as SadPanda|Storm
[17:44:59] <KGB-linuxcnc> 03seb 05g10-toolno-pocket-differ 260bfe6 06emc2 10tests/interp/ 10(5 files) * add a test for the "toolno != pocket number" bug
[17:45:00] <KGB-linuxcnc> 03seb 05g10-toolno-pocket-differ e8b3631 06emc2 10src/emc/rs274ngc/interp_find.cc * optimize and simplify find_tool_pocket()
[17:45:03] <KGB-linuxcnc> 03seb 05g10-toolno-pocket-differ 0b5d2a8 06emc2 10src/emc/rs274ngc/interp_convert.cc * fix a bug in convert_setup_tool(), aka G10
[17:45:09] <KGB-linuxcnc> 03seb 05g10-toolno-pocket-differ fb54913 06emc2 10src/emc/task/emccanon.cc * fix a bug in GET_EXTERNAL_TOOL_SLOT()
[17:45:16] <KGB-linuxcnc> 03seb 05g10-toolno-pocket-differ c527af7 06emc2 10src/emc/rs274ngc/interp_convert.cc * rename a variable in convert_tool_length_offset()
[17:45:32] <seb_kuzminsky> i'd appreciate a code review on the g10-toolno-pocket-differ branch if anyone has spare cycles
[17:45:48] <seb_kuzminsky> the test in the first commit fails before the fix and passes after
[17:46:10] <seb_kuzminsky> you can also reproduce it by hand:
[17:46:39] <seb_kuzminsky> run sim/axis/axis, goto mdi, t99999 m6 g43, f3, touch off to the tool table, the dro does not update
[17:46:46] <andypugh> Are we meant to know what the tooln != pocketn bug is?
[17:46:52] <seb_kuzminsky> after those commits the dro updates correctly
[17:47:08] <seb_kuzminsky> i've mentioned it on the mailing list
[17:47:17] <seb_kuzminsky> and i tried to describe it in irc just now...
[17:47:45] <andypugh> Yes, I remember it now.
[17:47:47] <seb_kuzminsky> but i'd be happy to tell you more about it if you want
[17:49:10] <seb_kuzminsky> i tried to make the commit messages descriptive enough to speak for themselves
[17:49:31] <andypugh> I recall that touch-off didn't always update the DRO, I hadn't realised what the underlying cause was.
[17:51:59] <andypugh> Grrr! The garage PC has a habit of hanging the ethernet port. I need to plug/unplug the cable to get it back to life. It is round the back and all locked up.
[17:52:27] <seb_kuzminsky> are you on the console or logged in over said ethernet cable?
[17:52:28] <andypugh> (When I say "habit' I mean 3 times yesterday evening)
[17:52:46] <andypugh> I am logged in over it.
[17:55:33] Keith____ is now known as KeithT
[17:56:59] SadPanda|Storm is now known as BasicPanda|Storm
[17:57:58] -!- yoyoek1 has quit [Quit: Ex-Chat]
[18:01:08] -!- ve7it [ve7it!~LawrenceG@S0106001c10b7770f.pk.shawcable.net] has joined #linuxcnc-devel
[18:12:14] -!- BasicPanda|Storm has quit [Ping timeout: 240 seconds]
[18:15:14] <mhaberler> xenomai runtests: Runtest: 46 tests run, 46 successful, 0 failed + 0 expected ;)
[18:31:37] <seb_kuzminsky> how is xenomai different from rtai? are they both based on adeos?
[18:37:07] -!- ve7it has quit [Remote host closed the connection]
[18:38:07] -!- automata__ has quit [Ping timeout: 252 seconds]
[18:40:52] <alex_joni> seb_kuzminsky: yes
[18:41:13] <alex_joni> mhaberler: x86?
[18:41:58] <mhaberler> yes
[18:42:22] <alex_joni> nice
[18:42:31] <mhaberler> but I dont see why it shouldnt compile on an arm; maybe some bitops need to be polished up for arm
[18:42:36] <mhaberler> asm I mean
[18:43:40] <alex_joni> right, and maybe some parts of rtapi_math
[18:43:47] -!- ilias has quit [Remote host closed the connection]
[18:43:53] <alex_joni> iirc some of that uses some x86 asm
[18:44:23] <mhaberler> well I carried over a bit of rtai_math, but it needs only 8 or so functions, not the whole wash
[18:44:59] <mhaberler> right, the rtapi_math might need work, but its only half a page or so
[18:45:20] <mhaberler> actually its common source with rtai, just ifdefs
[18:46:23] <mhaberler> the xenomai kernel thing might not be the best option anyway, because thats going to deperecate eventually as well except for a few functions
[18:46:54] <mhaberler> but I understand better what's broken in my userland xenomai attempt;)
[19:01:41] <jthornton> can we we now have 99999 entries in the tool table?
[19:02:28] -!- zzolo has quit [Read error: Connection reset by peer]
[19:09:56] -!- Nick001-Shop has quit [Read error: Connection reset by peer]
[19:11:27] <mhaberler> yessir, but andy needs to get on the case first
[19:11:45] <jthornton> cool
[19:12:09] <mhaberler> old german barrack yard joke:
[19:12:10] <mhaberler> "who can play the piano?" asks the drill sergeant
[19:12:11] <mhaberler> "me" says private innocent
[19:12:11] <mhaberler> "you get to clean the latrines!" says the sergeant
[19:12:14] <jthornton> I thought there was some nml limit or some other problem limiting the number of entries
[19:12:57] <mhaberler> yes, it needs to be moved out of nml, but making sure its synchronized *with* emcstatus which is the tricky part
[19:13:29] <jthornton> ok so in 2.5 we still have the 56 tool limit in the tool table?
[19:14:52] <seb_kuzminsky> in 2.5 there is a max of 56 entries in the tool table
[19:15:14] <seb_kuzminsky> but each entry can have any tool number 1-99999 and any pocket number 1-99999
[19:15:31] <jthornton> you removed the part about 56 entries?
[19:16:24] <seb_kuzminsky> no, it's still there, above and below
[19:16:36] <seb_kuzminsky> i think that limitation doesn't belong in the discussion about the gcode syntax
[19:16:47] <jthornton> ok, I just looked at the commit
[19:16:49] <seb_kuzminsky> i'll be happy to change it back if you disagree
[19:17:14] -!- IchGuckLive has quit [Quit: ChatZilla 0.9.87 [Firefox 14.0.1/20120713225625]]
[19:17:20] -!- zzolo has quit [Read error: Connection reset by peer]
[19:18:49] <jthornton> I just forgot it was in the text describing the tool table and is less wishy washy now in the format area :)
[19:18:58] <mhaberler> and here for the daring: LinuxCNC on Xenomai - sneak preview:
http://git.mah.priv.at/gitweb/emc2-dev.git/commit/b8111e592949b72075dd9dd2909efff3900336d0
[19:21:50] <seb_kuzminsky> mhaberler: how is xenomai different from rtai? aside from being more actively maintained/developed
[19:21:56] <seb_kuzminsky> jthornton: ok so we're good? :-)
[19:22:04] <jthornton> seb_kuzminsky, I cracked the pahse nut too and will push that in a moment :)
[19:22:19] <jthornton> yes it look great
[19:22:27] <seb_kuzminsky> ok cool :-)
[19:22:48] <mhaberler> runs on other platforms than x86, like various arm machines; larger community
[19:22:57] <seb_kuzminsky> i came across that part of the docs while trying to understand the tool table code and the words confused me
[19:23:19] <seb_kuzminsky> mhaberler: how does the latency compare to rtai?
[19:23:46] <mhaberler> I need to move over to them labs to measure on a real box, will post later; this is virtualbox for now
[19:23:56] <seb_kuzminsky> ah ok
[19:24:18] -!- ilias has quit [Quit: Ex-Chat]
[19:24:25] <KGB-linuxcnc> 03jthornton 05v2.5_branch bb3c4e6 06emc2 10docs/src/hal/ 10images/stepgen-type11-14.png 10images/stepgen-type2-4.png 10images/stepgen-type5-10.png 10rtcomps.txt * Docs: fix spello in step type images
[19:24:29] * jthornton is off to the shop now
[19:24:36] <seb_kuzminsky> see you jthornton
[19:25:00] <cradek> seb_kuzminsky: did you figure out the tool table weirdness?
[19:25:06] <seb_kuzminsky> i think so
[19:25:38] <seb_kuzminsky> http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=shortlog;h=refs/heads/g10-toolno-pocket-differ
[19:25:53] <seb_kuzminsky> not sure if i fixed it *right*, but it now doesnt have the bad behavior i was seeing earlier
[19:26:10] <seb_kuzminsky> i'd appreciate another couple of eyeballs on that before i push it
[19:29:25] <mhaberler> that was terribly confusing.. there was NML message with a field named tool..something and ir carried: a pocket..
[19:30:58] <seb_kuzminsky> i'm often confused by nml
[19:31:23] <cradek> > The result of the bug is that running G10 on a tool whose tool-number differs form its pocket-number, while that tool is in the spindle (as is done during Axis tool-table touch-off), would fail to update the active TLO.
[19:31:50] <seb_kuzminsky> and lately I've been wanting strong typing in C, so that "ints that are pocket numbers" and "ints that are tool numbers" would not be so easy to confuse
[19:31:54] <cradek> is this description of the bug correct and complete? I'm so sure I do this all the time.
[19:32:11] <cradek> is it maybe nonrandom only?
[19:32:23] <seb_kuzminsky> yes that could well be
[19:32:57] <seb_kuzminsky> nonrandom puts the tool back in the pocket it came from, while random moves tools between pockets, right?
[19:33:14] <seb_kuzminsky> all this is with nonrandom... i haven't tested random at all
[19:33:31] <seb_kuzminsky> i should probably test that...
[19:33:31] <cradek> random loads a tool by exchanging a certain pocket with the spindle pocket
[19:33:41] <seb_kuzminsky> right...
[19:34:19] <cradek> ok I'd be more apt to believe you now; the combination of nonrandom and tool != pocket is probably a bit rare
[19:34:23] -!- mozmck has quit [Ping timeout: 260 seconds]
[19:34:55] <cradek> I thought with nonrandom the P is saved and rewritten but otherwise totally ignored
[19:35:53] -!- adampassey has quit [Ping timeout: 245 seconds]
[19:37:30] <cradek> this makes me sad and a bit scared
[19:38:08] <seb_kuzminsky> that there's a new bug so late in the 2.5 cycle?
[19:38:46] -!- skunkworks has quit [Read error: Connection reset by peer]
[19:40:59] <cradek> yes, and how complicated it seems to be
[19:41:12] <seb_kuzminsky> cradek: do you agree with the test case? or am i just doing something incredibly dumb here?
[19:41:35] <seb_kuzminsky> the test case in that branch, and the "manual test" in axis that i wrote up there ^^^^^
[19:42:00] -!- mozmck [mozmck!~moses@client-204.235.45.161.wcfltx.partnershipbroadband.com] has joined #linuxcnc-devel
[19:42:53] <cradek> somehow I am not seeing your manual test
[19:44:09] <seb_kuzminsky> run sim/axis/axis, goto mdi, t99999 m6 g43, f3, touch off to the tool table, the dro does not update
[19:45:02] <seb_kuzminsky> or you can fetch the branch, check out the commit that adds the test, build and runtests
[19:45:35] <cradek> ok thanks, building/testing
[19:45:46] -!- yuvipanda has quit [Quit: yuvipanda]
[19:47:43] -!- Guest22805 has quit []
[19:48:14] <cradek> but if I do g43 in mdi afterward, it does update
[19:48:32] <seb_kuzminsky> yes :-/
[19:49:29] <seb_kuzminsky> axis tool-table touch-off does G10 L10, then G43
[19:49:50] <seb_kuzminsky> but that first G43 doesnt get the updated TLO
[19:50:01] <seb_kuzminsky> doing it by hand later gets the right numbers
[19:50:04] Cylly is now known as Loetmichel
[19:50:36] <cradek> when I do g10 l10 p-1 z11 the tool table gets updated. but even several g43 don't make the dro change
[19:50:45] <cradek> [all in mdi]
[19:51:00] <seb_kuzminsky> p-1? is that even accepted?
[19:51:18] <cradek> um isn't that what means currently-loaded tool?
[19:51:58] <seb_kuzminsky> p0?
[19:52:15] <seb_kuzminsky> or p#<current_tool> (not a real parameter!)
[19:52:35] <cradek> did I dream this?
[19:52:55] <seb_kuzminsky> http://www.linuxcnc.org/docs/devel/html/gcode/gcode.html#_g10_l10_set_tool_table_a_id_sec_g10_l10_a
[19:53:08] <seb_kuzminsky> doesn't mention any way to specify "current tool", short of giving its number
[19:53:36] <cradek> ok, yes I dreamed it.
[19:54:09] <seb_kuzminsky> oh, you meant P#<5400> ;-)
[19:55:39] <cradek> I have 4% confidence in my ability to verify your changes :-/
[19:55:50] <cradek> usually I hover around 80%
[19:57:35] -!- factor has quit [Read error: Connection reset by peer]
[19:57:43] <cradek> > // returns the slot/pocket number of the tool currently in the spindle, or 0 if there is no tool in the spindle
[19:57:56] <cradek> this behavior doesn't make sense on a random machine
[19:58:25] <cradek> the tool in the spindle is by definition currently in pocket 0
[19:59:51] -!- satyag has quit [Quit: Leaving]
[20:01:26] <cradek> I guess that's how we get settings.current_pocket
[20:02:30] <seb_kuzminsky> once again i fail at random toolchanger
[20:02:54] <cradek> just need another test, I guess. that's got to be the only way to handle this :-)
[20:03:25] -!- sumpfralle has quit [Read error: Operation timed out]
[20:03:26] <seb_kuzminsky> i think that on nonrandom toolchanger, settings.current_pocket intends to have the pocket that the tool in the spindle came from
[20:03:39] -!- grummund has quit [Ping timeout: 260 seconds]
[20:03:50] <seb_kuzminsky> ugh
[20:03:57] <seb_kuzminsky> yes, moar tests
[20:04:09] <cradek> do you mean matching P word from the tool table, or matching the entry number in the tool array?
[20:04:12] <cradek> I think you mean the latter
[20:04:19] <seb_kuzminsky> the latter
[20:04:33] <cradek> ok I bet you are right
[20:04:42] <seb_kuzminsky> the pocket number in the tool table file is not used, i think
[20:05:00] <cradek> right, except for being saved and rewritten
[20:05:16] <cradek> it's a, uh, special kind of comment
[20:05:28] <seb_kuzminsky> i think the P numbers frmo the tool table file provide relative ordering of the tools, but the "internal" pocket numbers are "compacted"
[20:05:38] <cradek> if(settings->current_pocket == pocket)
[20:05:51] <cradek> this test in convert_setup_tool() makes me think you are correct about that canon call
[20:06:17] <seb_kuzminsky> i mean the first tool in the tool table file gets pocket 1, then each tool after that gets the next pocket number
[20:06:22] <cradek> yes
[20:06:42] <cradek> but externally the P-word-pockets might be meaningful in a tool changer for instance
[20:06:56] <seb_kuzminsky> yeah
[20:09:40] <seb_kuzminsky> i don't know how pocket numbers are handled on random toolchangers
[20:09:50] <seb_kuzminsky> (or how anything else is handled on random toolchangers, for that matter)
[20:11:48] <cradek> random toolchangers have pockets 0..N where 0 is the spindle and 1..N are the carousel
[20:12:19] <cradek> a tool change just swaps a carousel pocket with the spindle pocket and then rewrites the tool table with the P numbers updated
[20:13:00] <cradek> the behavior is utterly simple
[20:13:21] <cradek> you can restart with a tool left in the spindle and everything works fine
[20:13:35] <andypugh> cradek: As I recall it (and that was the point I gave up on a sane gang-tooling solution) was that the Pocket Number is the actual array index that the data is stored in. And Random TC swaps the data between the array elements. This means that there is no way for two tools to share the same pocket, for example.
[20:13:50] <cradek> that is correct
[20:14:23] <andypugh> Which seems to me to tie the carousel and the code together just a bit too closely...
[20:14:51] <cradek> everything about the tool table is too close to everything else
[20:20:19] <seb_kuzminsky> i'll test my changes with a random toolchanger and report back
[20:20:40] <cradek> thanks! I appreciate your digging.
[20:20:50] <seb_kuzminsky> sure :-)
[20:21:01] <seb_kuzminsky> it's purely selfish - this is how i want to use my machine ;-)
[20:21:57] <seb_kuzminsky> and besides i have nothing else to do while waiting for my new drill chuck to arrive ;-)
[20:22:03] <andypugh> How maddening. 2 evenings spent staring at a simple .comp. Begging it to reveal why it crashes RTAPI (needing a reboot). Puzzled why it doesn't work when the very similar one it was cloned from works fine.
[20:22:17] <andypugh> Finally noticed the reason.
[20:22:44] <andypugh> It still had the same component name line as the cloned file…
[20:23:17] <cradek> seb_kuzminsky: wow, you obviously need n>1 drill chucks
[20:23:39] <cradek> andypugh: argh! that sounds like a hal bug.
[20:23:48] -!- KeithT has quit [Ping timeout: 245 seconds]
[20:23:56] <andypugh> If the "component" line in the comp file doesn't match the file name, it all goes rather wrong. I wonder how hard it would be to put a warning in comp.py?
[20:24:05] <seb_kuzminsky> andypugh: that shouldnt crash the machine!
[20:24:19] <andypugh> it only crashes RTAPI
[20:24:21] <cradek> !!1!
[20:24:35] <cradek> ... that sounds like a hal bug.
[20:24:45] <seb_kuzminsky> cradek: i have two chucks and 2 ER collets, and they're all in use for this job :-/
[20:25:04] <cradek> all for different drills?
[20:25:29] <seb_kuzminsky> three drills and one endmill, with a smaller shank than I have end-mill holders for
[20:25:34] <andypugh> There is no reason that serial_resolver.ko should create a HAL module called mesa_uart....
[20:25:54] <andypugh> But yes, something, somewhere ought to catch it.
[20:26:24] <andypugh> I guess that the same will happen with any comp where there is a mismatch. (I haven't tried it)
[20:26:38] <cradek> seb_kuzminsky: ah. that's a lot of tools for one job. sounds like an interesting part.
[20:27:56] <seb_kuzminsky> it's not that interesting probably:
http://store.terawattindustries.com/27-terawatt-industries-universal-y-axis-plate.html
[20:27:59] -!- phantoneD has quit []
[20:28:07] <andypugh> Yes, I just edited "constant.comp" to create a constant called "constant1" and crashed RTAPI.
[20:28:41] <andypugh> Lets hope the ethernet connection survives through this reboot.
[20:28:43] <cradek> seb_kuzminsky: looks tedious :-)
[20:29:12] <seb_kuzminsky> heh, i just noticed, "100% designed and manufactured in Colorado, USA"
[20:29:18] <andypugh> (it would be nice if halrun -U worked as-advertised, but I think modprobe won't let it)
[20:29:18] <cradek> cool
[20:29:23] <seb_kuzminsky> it's not bad actually (at least i think so)
[20:29:51] <cradek> for manual tool change I'd be tempted to try helical milling all those different sized holes
[20:30:03] <seb_kuzminsky> i made a fixture plate, i clamp a stack of rough-cut sheets, run one drill, screw the stack into pre-tapped holes in the fixture, then run the rest of the tools
[20:30:23] <cradek> ah a whole stack at once - better than my idea
[20:30:25] <seb_kuzminsky> would you helix mill even if you didn't have flood coolant for chip clearing? ;-)
[20:30:39] <andypugh> You need a hybrid roughing / thread-milling bit :-)
[20:30:55] <cradek> thread-milling M3, yeahhhh
[20:31:06] <seb_kuzminsky> i don't do any threading on this part, the customer does that by hand later
[20:31:18] <seb_kuzminsky> (i mean my customer, terawatt industries)
[20:31:19] <cradek> oh good
[20:31:24] <seb_kuzminsky> yeah
[20:31:43] <seb_kuzminsky> makes me want to finish the spindle encoder, i could charge him another buck or two per part probably
[20:32:17] <cradek> two different tap sizes?
[20:32:31] <cradek> you'd make it unstackable. couldn't possibly be worth a dollar or two.
[20:32:44] <seb_kuzminsky> just one tap, i think
[20:32:55] <andypugh> It looks like a natural part for a plasma/laser cutter to me.
[20:33:06] <seb_kuzminsky> yeah, i told the guy that when i was bidding on it
[20:33:07] <cradek> oh yeah, maybe just M3
[20:33:10] <cradek> I misunderstood
[20:33:40] <cradek> you can very easily do those with the reversing tapping head
[20:33:59] <seb_kuzminsky> i still haven't dared to spin that up...
[20:35:22] <cradek> I did this table for jeff with that tapping head:
http://media.unpythonic.net/emergent-files/01215190154/table-medium.jpg
[20:35:43] <seb_kuzminsky> nice!
[20:35:46] <cradek> broke 0 taps
[20:35:50] <cradek> it really works fine
[20:35:55] <seb_kuzminsky> that's the best number of taps to break
[20:35:59] <cradek> yes by far
[20:36:07] <seb_kuzminsky> i've often daydreamed about making a fixture plate like that
[20:36:14] <andypugh> I would like to break -1 taps.
[20:36:21] <mhaberler> I wonder what you patch will do to my carefully rigged toolchange demos in master once rolled over ;)
[20:36:38] <seb_kuzminsky> hopefully fix them?
[20:36:50] <cradek> seb_kuzminsky: I've got several of different sizes, they're useful
[20:37:00] <cradek> seb_kuzminsky: so easy to make once you have tapping
[20:37:19] <seb_kuzminsky> yeah, and a giant pain without automatic tapping
[20:40:18] -!- paideia has quit [Quit: Leaving]
[20:42:12] -!- ve7it [ve7it!~LawrenceG@S0106001c10b7770f.pk.shawcable.net] has joined #linuxcnc-devel
[20:43:17] -!- tjb1 has quit [Ping timeout: 256 seconds]
[20:43:25] -!- kmiyashiro has quit [Quit: kmiyashiro]
[21:11:44] -!- FinboySlick has quit [Quit: Leaving.]
[21:24:36] -!- djdelorie has quit [Ping timeout: 240 seconds]
[21:53:45] toudi_ is now known as micges
[22:04:45] -!- micges has quit [Quit: Wychodzi]
[22:06:33] -!- mhaberler has quit [Quit: mhaberler]
[22:08:54] -!- mhaberler [mhaberler!~mhaberler@macbook.stiwoll.mah.priv.at] has joined #linuxcnc-devel
[22:14:19] -!- the_wench has quit [Ping timeout: 260 seconds]
[22:14:31] -!- archivist has quit [Ping timeout: 256 seconds]
[22:15:38] -!- tjb1 has quit [Quit: tjb1]
[22:17:13] -!- factor has quit [Read error: Connection reset by peer]
[22:18:18] -!- DJ9DJ has quit [Quit: bye]
[22:29:51] -!- chillly has quit [Quit: Leaving]
[22:31:35] <mhaberler> I hope I dont have a setup error.. but.. the xenomai figures for latency-test on an atom: 10,4usec on the servo thread and 12,4 on the base thread
[22:33:44] -!- factor has quit [Read error: Connection reset by peer]
[22:34:22] <andypugh> Sounds rather better than anticipated?
[22:34:37] -!- Tom_itx has quit [Ping timeout: 252 seconds]
[22:36:57] <mhaberler> yes
[22:37:28] <mhaberler> I'll let it run overnight with glxgears, lets see tomorrow
[22:37:57] <mhaberler> isolcpus in effect, works fine
[22:38:04] <andypugh> Do you have any way to check parallel port pulse rate (for example)?
[22:38:10] <mhaberler> yes
[22:38:22] <mhaberler> tomorrow… I'm fading
[22:38:28] <mhaberler> you mean just wiggling?
[22:38:38] <mhaberler> or freqgen?
[22:38:44] <andypugh> Yes, just to see it it really that fast.
[22:38:44] -!- zzolo has quit [Quit: zzolo]
[22:39:00] <mhaberler> need to hook up the logic analyzer
[22:39:22] <andypugh> No rush. You have probably done enough for the week.
[22:39:44] <mhaberler> but I am very sure this runs on the rpi mostly unmodified.. same kernel; a few asm headers need attention
[22:40:43] <mhaberler> the nice thing - it is the same modules as rtai, maybe 50 or so ifdefs
[22:41:20] <mhaberler> that promises bug compatibility;)
[22:48:43] <andypugh> I have a Pi to try it on, at some point. Sounds like fun.
[22:50:19] <mhaberler> there are a few hardships with kernel fp math ahead
[22:51:50] <alex_joni> thought I've seen some rpi update that does fp
[22:52:01] <alex_joni> newer rasbian I think
[22:52:50] -!- grummund has quit [Ping timeout: 255 seconds]
[22:55:41] <mhaberler> they are all hw fp
[22:56:00] <mhaberler> but the assembly code aint phun
[23:07:06] <seb_kuzminsky> wowo that's pretty good latency
[23:13:02] -!- vladimirek has quit [Remote host closed the connection]
[23:16:30] -!- mhaberler_ [mhaberler_!~mhaberler@macbook.stiwoll.mah.priv.at] has joined #linuxcnc-devel
[23:18:37] -!- racycle has quit [Quit: racycle]
[23:19:20] -!- mhaberler has quit [Ping timeout: 264 seconds]
[23:19:20] -!- karavanjoW has quit [Ping timeout: 264 seconds]
[23:19:21] mhaberler_ is now known as mhaberler
[23:23:38] <mhaberler> well it goes up with load; will post tomorrow; however, at 3 glxgears rtai is unusable, xenomai is still a good desktop
[23:26:58] -!- skunkworks [skunkworks!~chatzilla@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[23:28:20] -!- oyildirim has quit []
[23:40:17] -!- mhaberler has quit [Quit: mhaberler]
[23:44:39] -!- servos4ever has quit [Quit: ChatZilla 0.9.85 [SeaMonkey 2.0.11/20101206162726]]
[23:48:24] -!- asdfasd has quit [Ping timeout: 276 seconds]
[23:52:27] -!- sumpfralle has quit [Ping timeout: 260 seconds]
[23:53:24] -!- yuvipanda has quit [Ping timeout: 244 seconds]
[23:53:24] yuvipanda_ is now known as yuvipanda
[23:58:19] -!- Nick001-Shop has quit [Quit: ChatZilla 0.9.89 [Firefox 16.0.2/20121024073032]]
