Back
[00:04:14] -!-
theorbtwo has quit [Ping timeout: 240 seconds]
[00:04:26] theorb is now known as
theorbtwo
[00:12:38] -!-
micges has quit [Quit: Ex-Chat]
[00:41:29] -!-
Dallur has quit [Quit: Leaving.]
[00:53:03] -!-
EDocToor has quit [Quit: ChatZilla 0.9.86 [Firefox 3.6.13/20101203075014]]
[00:53:44] -!-
EDocToor [EDocToor!~chatzilla@69-196-141-71.dsl.teksavvy.com] has joined #emc-devel
[00:55:31] <PCW> Look like we fixed the 8I20 parser bug so we well send you new 8I20 firmware Monday
[00:55:32] <PCW> (you wont notice any difference unless you send lots of crap to the 8I20 to try and confuse it)
[01:21:37] mndlbld is now known as
mendelbuilder
[01:29:11] -!-
PCW has quit [Remote host closed the connection]
[01:36:25] -!-
robh__ has quit [Ping timeout: 240 seconds]
[01:39:57] -!-
mendelbuilder has quit []
[01:52:04] -!-
tlab [tlab!~tlab@c-69-243-187-136.hsd1.in.comcast.net] has joined #emc-devel
[02:51:42] <jepler> andypugh: yes, using rebase you can "drop" commits so that they're no longer in the history of that branch
[02:52:09] <andypugh> It seems you can do that, even if you don't want to.
[02:52:36] <jepler> andypugh: you can use 'git reflog' to find a previous HEAD that has the commit you want in its history, then git log that HEAD to find the ref to cherry-pick
[02:53:28] <andypugh> I was trying to persuade it to work, and didn't realise that thoughtlessly using --skip would have potentially disasterous consequences. Luckily I had accidentally put a backup in Gmail
[02:53:31] <jepler> so step 1: 'git reflog' and figure out what line corresponds to before you did the rebase you aren't happy with
[02:53:51] <jepler> for instance, your reflog might look like this:
[02:53:51] <jepler> d164a91 HEAD@{2}: rebase: tooledit: refactor for single tool table type
[02:53:51] <jepler> 67fd234 HEAD@{3}: rebase: tooledit: reload should respect toplevel resize
[02:53:52] <jepler> 02d9bfa HEAD@{4}: checkout: moving from master to 02d9bfa0d7ff1e3feb586bf0c83ab6
[02:53:54] <jepler> aba324a HEAD@{5}: am: tooledit: refactor for single tool table type
[02:54:21] <jepler> in that case, the commit before the rebase started is aba324a
[02:54:29] <jepler> so next I would gitk aba324a or git log aba324a to find a commit to cherry-pick
[02:54:46] <andypugh> git-gui "visualise history" seemed to indicate that the stuff was just gone, disappeared. Not even any sign of the last 3 commits.
[02:54:48] <jepler> alternately, I could 'git reset --hard aba324a' to move my HEAD back to before the rebase
[02:55:49] -!-
tlab has quit [Quit: Leaving]
[02:58:21] -!-
ries has quit [Quit: ries]
[03:02:25] <jepler> 'night
[03:09:09] -!-
encryptio has quit [Remote host closed the connection]
[03:10:13] <andypugh> Just checked reflog, definitely three commits just evaporated and gone. Good information though
[03:36:28] -!-
qq- has quit [Ping timeout: 265 seconds]
[04:29:11] -!-
andypugh has quit [Quit: andypugh]
[04:48:29] -!-
Valen has quit [Quit: Leaving.]
[05:13:06] -!-
emcrules_laptop has quit [Quit: Visitor from www.linuxcnc.org]
[05:29:38] -!-
LawrenceG has quit [Remote host closed the connection]
[05:37:35] -!-
mozmck has quit [Quit: Leaving.]
[06:17:46] -!-
dgarr has quit [Ping timeout: 246 seconds]
[07:00:58] -!-
toastyde1th has quit [Ping timeout: 240 seconds]
[07:44:02] -!-
nullie has quit [Ping timeout: 255 seconds]
[07:56:34] -!-
psha [psha!~psha@213.208.162.69] has joined #emc-devel
[09:33:39] -!-
nullie has quit [Quit: Ex-Chat]
[09:50:01] -!-
EDocToor has quit [Read error: Operation timed out]
[10:06:23] -!-
micges [micges!~micges@adfa45.neoplus.adsl.tpnet.pl] has joined #emc-devel
[10:18:10] -!-
robh__ [robh__!~robert@5ace70af.bb.sky.com] has joined #emc-devel
[11:01:30] -!-
psha has quit [Quit: Lost terminal]
[11:01:55] -!-
ISSSY has quit [Quit: Visitor from www.linuxcnc.org]
[11:09:16] -!-
psha [psha!~psha@213.208.162.69] has joined #emc-devel
[11:29:41] -!-
rooks has quit [Quit: So long, and thanks for all the fish.]
[11:36:54] -!-
micges has quit [Ping timeout: 265 seconds]
[11:50:22] -!-
micges [micges!~micges@adfa45.neoplus.adsl.tpnet.pl] has joined #emc-devel
[11:52:28] -!-
psha has quit [Quit: leaving]
[12:17:23] -!-
ries [ries!~ries@200.125.129.54] has joined #emc-devel
[12:17:54] -!-
micges has quit [Ping timeout: 260 seconds]
[12:44:49] -!-
micges [micges!~micges@adfa45.neoplus.adsl.tpnet.pl] has joined #emc-devel
[12:45:57] -!-
psha [psha!~psha@213.208.162.69] has joined #emc-devel
[12:46:48] -!-
Valen has quit [Quit: Leaving.]
[12:52:13] -!-
micges has quit [Ping timeout: 246 seconds]
[12:52:48] -!-
Dallur has quit [Quit: Leaving.]
[12:58:51] -!-
qq- [qq-!~Moldovean@178-211-232-101.dhcp.voenergies.net] has joined #emc-devel
[12:58:51] -!-
qq- has quit [Changing host]
[12:58:51] -!-
qq- [qq-!~Moldovean@unaffiliated/qq-] has joined #emc-devel
[13:02:13] -!-
Poincare has quit [Ping timeout: 276 seconds]
[13:05:56] <jthornton> the emc liveCd includes a braille device... brltty
[13:06:16] <jthornton> just discovered that trying to play with my arduino uno
[13:07:31] -!-
EDocToor [EDocToor!~chatzilla@69-196-141-71.dsl.teksavvy.com] has joined #emc-devel
[13:14:42] -!-
JT-D510 [JT-D510!~chatzilla@216-41-143-50.semo.net] has joined #emc-devel
[13:16:22] -!-
ries has quit [Quit: ries]
[13:18:35] -!-
JT-D510 has quit [Client Quit]
[13:18:45] -!-
micges [micges!~micges@adfa45.neoplus.adsl.tpnet.pl] has joined #emc-devel
[13:18:57] -!-
micges has quit [Client Quit]
[13:25:15] -!-
mendelbuilder has quit [Ping timeout: 272 seconds]
[13:45:59] -!-
nullie has quit [Ping timeout: 260 seconds]
[13:50:18] -!-
awallin_ [awallin_!~quassel@2001:708:110:1020:224:7eff:feda:7c7d] has joined #emc-devel
[14:42:49] -!-
EDocToor has quit [Quit: ChatZilla 0.9.86 [Firefox 3.6.13/20101203075014]]
[14:51:36] -!-
dgarr [dgarr!~dgarrett@adsl-75-61-65-2.dsl.pltn13.sbcglobal.net] has joined #emc-devel
[14:53:08] -!-
mozmck [mozmck!~moses@client-173.225.233.241.dfwtx.partnershipbroadband.com] has joined #emc-devel
[15:24:14] -!-
EDocToor [EDocToor!~chatzilla@69-196-141-71.dsl.teksavvy.com] has joined #emc-devel
[15:26:45] -!-
psha has quit [Read error: Connection reset by peer]
[15:27:00] -!-
psha [psha!~psha@213.208.162.69] has joined #emc-devel
[15:37:33] -!-
psha has quit [Quit: Lost terminal]
[15:51:00] -!-
psha [psha!~psha@213.208.162.69] has joined #emc-devel
[15:51:23] -!-
qq- has quit [Read error: Connection reset by peer]
[15:55:50] -!-
nullie has quit [Quit: Ex-Chat]
[16:00:58] -!-
SWPLinux has quit [Ping timeout: 240 seconds]
[16:01:30] -!-
pcw_home [pcw_home!~chatzilla@ip-66-80-167-54.sjc.megapath.net] has joined #emc-devel
[16:06:49] -!-
qq- [qq-!~Moldovean@unaffiliated/qq-] has joined #emc-devel
[16:18:40] -!-
nullie has quit [Quit: Ex-Chat]
[16:18:47] -!-
skunkworks [skunkworks!~chatzilla@98-125-96-223.dyn.centurytel.net] has joined #emc-devel
[16:23:34] -!-
TonnyG has quit [Ping timeout: 276 seconds]
[16:32:51] -!-
nullie has quit [Quit: Ex-Chat]
[16:44:46] -!-
EDocToor_ [EDocToor_!~chatzilla@69-196-141-71.dsl.teksavvy.com] has joined #emc-devel
[16:45:40] -!-
EDocToor has quit [Ping timeout: 276 seconds]
[16:45:42] EDocToor_ is now known as
EDocToor
[16:54:37] -!-
nullie has quit [Quit: Ex-Chat]
[16:54:52] -!-
qq- has quit [Ping timeout: 240 seconds]
[17:02:38] -!-
TonnyG has quit [Ping timeout: 260 seconds]
[17:17:38] -!-
qq- [qq-!~Moldovean@unaffiliated/qq-] has joined #emc-devel
[17:32:48] -!-
seb_kuzminsky [seb_kuzminsky!~seb@97-118-161-152.hlrn.qwest.net] has joined #emc-devel
[17:33:30] -!-
awallin_ has quit [Remote host closed the connection]
[17:42:10] -!-
SWPLinux [SWPLinux!~ChattyOne@wsip-70-165-184-42.lv.lv.cox.net] has joined #emc-devel
[17:46:25] -!-
andypugh [andypugh!~andy2@cpc2-basl1-0-0-cust1037.basl.cable.virginmedia.com] has joined #emc-devel
[17:48:20] -!-
LawrenceG [LawrenceG!~LawrenceG@S0106009027972e37.pk.shawcable.net] has joined #emc-devel
[17:50:32] -!-
pcw_home has quit [Remote host closed the connection]
[17:52:19] -!-
pcw_home [pcw_home!~chatzilla@ip-66-80-167-54.sjc.megapath.net] has joined #emc-devel
[18:03:09] -!-
SWPLinux has quit [Changing host]
[18:03:09] -!-
SWPLinux [SWPLinux!~ChattyOne@emc/developer/SWPadnos] has joined #emc-devel
[18:03:15] -!-
SWPLinux has quit [Quit: Reconnecting…]
[18:03:32] -!-
SWPLinux [SWPLinux!~ChattyOne@wsip-70-165-184-42.lv.lv.cox.net] has joined #emc-devel
[18:04:00] -!-
SWPLinux has quit [Changing host]
[18:04:00] -!-
SWPLinux [SWPLinux!~ChattyOne@emc/developer/SWPadnos] has joined #emc-devel
[18:11:16] -!-
qq- has quit [Ping timeout: 255 seconds]
[18:14:45] -!-
qq- [qq-!~Moldovean@unaffiliated/qq-] has joined #emc-devel
[18:19:48] -!-
qq- has quit [Ping timeout: 246 seconds]
[18:27:19] -!-
Dallur has quit [Quit: Leaving.]
[18:30:07] -!-
qq- [qq-!~Moldovean@unaffiliated/qq-] has joined #emc-devel
[18:36:51] -!-
qq- has quit [Ping timeout: 272 seconds]
[18:39:55] -!-
qq- [qq-!~Moldovean@unaffiliated/qq-] has joined #emc-devel
[18:43:40] -!-
theorbtwo has quit [Ping timeout: 255 seconds]
[18:43:44] theorb is now known as
theorbtwo
[18:45:18] -!-
skunkworks_ [skunkworks_!~chatzilla@98.125.122.80] has joined #emc-devel
[18:46:34] -!-
skunkworks has quit [Ping timeout: 276 seconds]
[18:46:39] skunkworks_ is now known as
skunkworks
[18:52:25] -!-
wobblybootie has quit [Quit: Page closed]
[19:10:59] <skunkworks> cradek: in regards to rigid tapping - is there an issue if the spindle take too long to de-accellerate? it seems to get lost if I try 1000rpm and a pitch of .01
[19:13:55] -!-
tlab has quit [Quit: Leaving]
[19:17:03] -!-
pcw_home has quit [Remote host closed the connection]
[19:20:18] <jthornton> your a brave guy
[19:21:57] <skunkworks> heh - still in the air...
[19:25:13] -!-
LawrenceG has quit [*.net *.split]
[19:25:13] -!-
psha has quit [*.net *.split]
[19:25:13] -!-
awallin has quit [*.net *.split]
[19:25:13] -!-
celeron55 has quit [*.net *.split]
[19:25:13] -!-
tris has quit [*.net *.split]
[19:25:13] -!-
lerman has quit [*.net *.split]
[19:26:13] -!-
LawrenceG [LawrenceG!~LawrenceG@S0106009027972e37.pk.shawcable.net] has joined #emc-devel
[19:26:13] -!-
psha [psha!~psha@213.208.162.69] has joined #emc-devel
[19:26:13] -!-
awallin [awallin!~quassel@cs27061165.pp.htv.fi] has joined #emc-devel
[19:26:13] -!-
lerman [lerman!~lerman@24-151-1-146.static.nwtn.ct.charter.com] has joined #emc-devel
[19:30:14] <skunkworks> ok - so if I do a command like g33.1z.25k.01 (starting at 1 inch - so tapping .75 inch) - when the as the spindle is decelerating it gets to .15 and the axis stops... (then it gets lost) and I don't seem to get an error. let me try it from cammand line
[19:30:33] <skunkworks> command
[19:34:52] <skunkworks> ok - no error that I can see - but it seems like that once the z axis gets to .15 (.1 past the stopping point of .25) the axis stops - but the spindle keeps de-accellerating and reverses. but the z axis still stays at .15.
[19:35:16] <skunkworks> then tapping seems to stop working correctly
[19:40:21] <skunkworks> (restart of emc - wonder if that is what ichudov on the list saw...)
[19:41:41] -!-
pcw_home has quit [Remote host closed the connection]
[19:43:21] -!-
pcw_home has quit [Remote host closed the connection]
[19:47:28] -!-
ries [ries!~ries@200.125.129.54] has joined #emc-devel
[20:33:38] -!-
psha has quit [Quit: leaving]
[20:41:27] <cradek> skunkworks: yes - it will only allow you so many turns before it reverses -- I figured it's better to snap a tap if the spindle "never" reverses, instead of just going forward forever
[20:41:45] <cradek> from memory I think it's 10 turns?
[20:47:04] <jthornton> that's good to know cradek
[20:53:43] -!-
andrus has quit [Ping timeout: 255 seconds]
[21:01:28] <skunkworks> ah - ok - that makes sense...
[21:02:53] <andypugh> Any scope for water-cooled braking resistors to slow the spindle faster and make a pot of tea?
[21:04:11] <skunkworks> that would make sense as 100 threads per inch - 10 turns would be .1
[21:04:42] <cradek> // allow 10 turns of the spindle to stop - we don't want to just go on forever
[21:04:45] <cradek> tc.target = line_xyz.tmag + 10. * tp->uu_per_rev;
[21:04:57] <skunkworks> our vfd is the limiting factor... the transmission has a large rotational mass..
[21:05:18] <cradek> 10 turns farther than you asked for seems like too far :-)
[21:06:24] <skunkworks> we are just going to have to tap at lower speeds.
[21:06:38] <cradek> or higher gear?
[21:07:03] <skunkworks> have to play with it.
[21:18:30] <andypugh> skunkworks: You need a heavy weight on a bit of string wrapped round the spindle to help it reverse.
[21:19:46] <andypugh> seb_kuzminsky: You there?
[21:32:56] <dgarr> two small patches for haltcl.in:
http://www.panix.com/~dgarrett/stuff/haltcl.mbox
[21:44:22] -!-
awallin_ [awallin_!~quassel@cs27061165.pp.htv.fi] has joined #emc-devel
[21:44:32] -!-
awallin has quit [Ping timeout: 240 seconds]
[22:11:38] -!-
TonnyG has quit []
[22:13:22] <andypugh> I am trying to work what to do with the sserial driver.
[22:14:29] <andypugh> Currently it works OK, and could be submitted, although half a day of testing tomorrow would be wise.
[22:16:16] -!-
emcrules_laptop has quit [Ping timeout: 240 seconds]
[22:17:15] <andypugh> However, the way that ports are enabled/disabled doesn't match the structure of other components. One consequence of this is that it is not all that easy to
[22:17:54] <andypugh> ... rearrange things to better match the function separation that Seb has in the rest of the code.
[22:21:28] <andypugh> The answer is probably a bit of a rewrite, so instead of a bit mask like "conf_sserial = 0x000080FF" to enable all the channels of port 0 and the last one of port 1, I could (probably) change it to be "num_sserial=8,1,0,0". This means that the active channel on port 1 in this example has to be channel0.
[22:26:01] <andypugh> If I do this, then I can call the hm2_pins_allocate_all() function and create a function in hm2_ioport to write the registers to enable the pins to allow the sserial driver to poll the devices and check what is there. (there would probably need to be a hm2_ioport_clear() function added too, to return the ports to default afterwards.
[22:34:28] <skunkworks> do I remember reading an issue with a previous trunk (head) that the tool prep caused the motion/spindle to stop when running a program?
[22:36:17] <andypugh> I think one fundamental problem here with trying to conform to the existing layout is that not only do you have 0 to 4 sserial ports, but each has 0 to 8 channels active.
[22:37:06] <andypugh> And the existing pin/port handler isn't great at coping with that.
[22:38:59] <andypugh> So, does anyone have any opinions on the best way to proceed?
[22:39:43] -!-
micges [micges!~micges@afpb2.neoplus.adsl.tpnet.pl] has joined #emc-devel
[22:53:39] -!-
Fox_Muldr has quit [Read error: Connection reset by peer]
[23:01:31] -!-
qq- has quit [Ping timeout: 255 seconds]
[23:01:31] -!-
foxdung has quit [Quit: Relax, its only ONES and ZEROS!]
[23:02:52] -!-
seb_kuzminsky has quit [Read error: Operation timed out]
[23:09:32] -!-
tlab has quit [Quit: Leaving]
[23:11:43] -!-
tom3p has quit [Client Quit]
[23:16:34] -!-
mndlbld has quit [Read error: Connection reset by peer]
[23:16:50] -!-
mendelbuild has quit [Read error: Connection reset by peer]
[23:26:43] <skunkworks> ok - the latest trunk pauses all motion pre-fetching the tool
[23:27:07] <andypugh> is that bad?
[23:27:11] <skunkworks> yes
[23:27:28] <andypugh> I am fuzzy on the whole trunk/head/master thing
[23:29:39] <skunkworks> well - I mean master
[23:29:47] <skunkworks> I guess.
[23:29:56] <andypugh> So mharberlers changes then?
[23:30:03] <robh__> kinda defeats a pre fetch then
[23:31:10] <skunkworks> well - the master from a month or two ago did the same thing.
[23:32:49] -!-
odiug has quit [Ping timeout: 260 seconds]
[23:35:03] -!-
skunkKandT [skunkKandT!~chatzilla@98.125.122.80] has joined #emc-devel
[23:35:09] <skunkKandT> http://pastebin.com/v105QXcB
[23:35:38] <skunkKandT> so - that program should start moving while it finds t6153
[23:36:40] <andypugh> It isn't finishing the motion and waiting at the M6?
[23:37:08] <skunkworks> tool prep and tool change are 2 different things
[23:38:24] <andypugh> I am assuming that T6153 means "get that tool in the changer" and then M6 means "put that tool in"?
[23:38:27] <skunkworks> it sits and does nothing until after it finds the t6153 as will all the tool preps
[23:39:23] <skunkworks> *with all the tool preps
[23:39:35] <skunkworks> unless - of course I am doing something wrong ;)
[23:40:08] <andypugh> don't ask me, toolchange is a mystery I have yet to investigate.
[23:40:31] <robh__> you meant, it outputs tool-prep and waits for tool-preped before continueing the gcode
[23:40:55] <skunkworks> yes
[23:41:02] <andypugh> I have just found that the difference between for ( ;*token != ' ';token++) and for ( ;*token |= ' ';token++) is a proper complete lock-up crash, and not.
[23:42:22] <skunkworks> heh
[23:47:43] <skunkworks> andypugh: I am assuming that T6153 means "get that tool in the changer" and then M6 means "put that tool in"?
[23:47:45] <skunkworks> yes
[23:48:28] <skunkworks> although - for our machine it is more like 'get t6153 in position for a tool change'
[23:48:45] <andypugh> How many tools do you have?
[23:48:52] <skunkworks> few hundred
[23:49:03] <skunkworks> the chain holds 60
[23:49:13] <andypugh> But not 6500
[23:49:50] <skunkworks> no - but the reason was that you could have hundreds of jobs setup and the tools stored away for each job
[23:50:18] <andypugh> How many bits on the barcodes then?
[23:50:39] <skunkworks> 15 :)
[23:51:07] <andypugh> 32768 tools max then? Oh dear!
[23:51:29] <skunkworks> yep ;)
[23:53:56] <skunkworks> I am reading the tools binary- the original machine read them octal - so what is that then?
[23:54:17] <skunkworks> oh - that is the same
[23:54:41] <skunkworks> duh