Back
[09:25:13] <cradek> > I don't have any programming ability. Anyone interested in whipping up a ... ?
[09:26:31] <seb_kuzm1nsky> the iocontrol.tool-number bug that frible described is present in linuxcnc too
[09:26:47] <seb_kuzm1nsky> can you whip up a fix for it?
[09:27:58] <cradek> do I know what you're talking about?
[09:28:42] <seb_kuzminsky> on a random-tc machine, loading a tool shows the tool number in iocontrol.0.tool-number
[09:29:00] <seb_kuzminsky> but restarting linuxcnc sets iocontrol.0.tool-number to 0, instead of the tool it knows is there
[09:29:23] <seb_kuzminsky> #<tool_in_spindle> remembers it correctly
[09:29:38] <seb_kuzminsky> i bet iocontrol just forgets to initialize that pin on startup
[09:31:00] <cradek> void reload_tool_number(int toolno) {
[09:31:00] <cradek> if(random_toolchanger) return; // doesn't need special handling here
[09:33:46] <seb_kuzminsky> hmm, // on nonrandom machines, always start by assuming the spindle is empty
[09:34:18] <cradek> I think that's right...?
[09:35:41] <seb_kuzminsky> i see the initialization for pocket 0 on nonrandom machines but not for random machines
[09:35:47] <cradek> now wait
[09:36:17] <cradek> er no
[09:36:23] <cradek> don't wait
[09:38:15] <seb_kuzminsky> damn the bugs, full speed ahead!
[09:43:20] <seb_kuzminsky> http://pastie.org/10221649
[09:45:28] <cradek> my guess was to put it at the end of EMC_TOOL_INIT_TYPE
[09:45:41] <cradek> but I hadn't tested yet
[09:45:43] <cradek> did you test?
[09:46:16] <cradek> I thought you said toolInSpindle was already right
[09:47:17] <seb_kuzminsky> toolInSpindle is the emcioStatus field, which seems to be correct
[09:47:34] <seb_kuzminsky> the iocontrol.tool-number hal pin incorrectly shows 0 on random machines at startup
[09:47:56] <seb_kuzminsky> hm, where does toolInSpindle get initialized....
[09:49:19] <seb_kuzminsky> does task or someone send io messages at startup?
[09:56:20] <seb_kuzminsky> oops, that patch breaks the tests
[09:57:06] <seb_kuzminsky> nonrandom machines should start up with T0 in P0, that patch makes it, err, T-1
[09:57:23] <cradek> yay tests
[09:57:33] <cradek> boo iocontrol
[09:57:37] <seb_kuzminsky> heh
[10:00:30] <seb_kuzminsky> iocontrol makes me think of a children's story called "this is the theory jack built"
[10:09:01] <seb_kuzminsky> ok, this one passes all the tests and has the iocontrol.tool-number pin correct on random machines at startup
[10:09:04] <seb_kuzminsky> http://pastie.org/10221697
[10:09:07] <seb_kuzminsky> bbl
[10:09:52] <cradek> that change looks really plausible
[10:56:57] <skunkworks> Offline
[10:56:57] <skunkworks> Sonny Jeon
[10:56:57] <skunkworks> MinimizePop-outClose
[10:56:57] <skunkworks>
[10:56:57] <skunkworks>
[10:56:58] <skunkworks>
[10:57:00] <skunkworks>
[10:57:02] <skunkworks>
[10:57:04] <skunkworks>
[10:57:06] <skunkworks> More ▼
[10:57:08] <skunkworks> Sonny: Hi Sam. Thanks for the testing report. I recently have reduced the junction deviation to 0.01, rather than the current default 0.02. I've noticed some stalling on aggressive tool paths. The way Grbl computes its velocity plan is different from LinuxCNC, so its an apples to oranges comparison. For arcs, it's the same thing. Part of the speed difference is from the planner implementation, but also could be th
[10:57:15] <skunkworks> at the planner buffer size isn't large enough to calculate from current speed to zero speed at the end of the buffer. This can make arcs run slow if accelerations are low enough.
[10:57:18] <skunkworks> Sent at 10:19 AM on Wednesday
[10:57:20] <skunkworks> me: Cool to meet you.
[10:57:22] <skunkworks> Sonny: Also Grbl only does G61 exact path at the moment. The 0.02mm junction deviation is a virtual distance that Grbl uses to bound accelerations. If set too high, it can make it go too fast through the junction and exceed acceleration limits as you have found. It's a parameter you have to tweak. That said, it can be used to make things like 3d printers or belt-based hobby CNCs move faster through corners and run
[10:57:27] <skunkworks> jobs quicker. For larger mills, you'd probably want to reduce this to 0.005mm even. Grbl has a mathematically optimal planner, based on its assumptions. It doesn't exceed acceleration limits, except at the junctions when set to do this.
[10:57:31] <skunkworks> Sent at 10:30 AM on Wednesday
[10:57:33] <skunkworks> me: Interesting. I had spent a ton of time recently testing the new trajectory planner in linuxcnc. (N lookahead in the next release version) So I have an idea on how hard it is even when you have computer power behind it. I can't imagine trying to fit it in the arduino. It is really impressive.
[10:58:29] <skunkworks> Sonny: Thanks. I spent a lot of time getting it fast and efficient enough to compute complete plans to under 2-3ms. I've studied nonlinear optimization in grad school. I had to use some of those techniques.
[11:51:50] <skunkworks> http://linuxcnc.org/index.php/english/forum/38-general-linuxcnc-questions/29247-discriminant-in-velocity-calculation-error
[12:07:34] <cradek> > .... It's a linux-based mmorpg that just came out. It's free to sign up and play, and there will be give-aways in a few days
[12:07:37] <cradek> hahahaha
[12:07:54] <cradek> jthornton: you get all the fun ones!
[12:10:16] <cradek> yo dawg, I heard you use linux
[12:12:46] <mozmck> What makes Gmoccapy "industrial" and all other GUIs not?
[12:15:24] <cradek> *sigh*
[12:15:29] <mozmck> The Tormach GUI looks industrial to me, Gmoccapy looks... well, like fisher price?
[12:15:52] <cradek> are you saying it just sounds like a matter of opinion?
[12:15:53] <mozmck> Referring to this post:
http://linuxcnc.org/index.php/english/forum/31-cad-cam/29259-shopfloorpro-a-upcoming-add-on-for-linuxcnc#59377
[12:16:18] <mozmck> Kinda like :)
[12:16:51] <cradek> I think industrial means "reminds me of a particular commercial machine I'm familiar with"
[12:17:44] <mozmck> Well, I haven't seen that many controls, but the pictures I've seen don't look like that.
[12:18:00] <mozmck> oh well, bbl
[12:18:28] <cradek> and I haven't heavily used any commercial machines made in this century
[12:22:40] <seb_kuzminsky> *millenium
[12:23:22] <seb_kuzminsky> what's the correct behavior for status.toolInSpindle, aka iocontrol.0.tool-number, at startup?
[12:23:26] <seb_kuzminsky> i think it's this:
[12:23:38] <seb_kuzminsky> on nonrandom machines it's always 0
[12:23:55] <seb_kuzminsky> on random machines starting up with a tool in P0, it's whatever that tool number is
[12:24:04] <seb_kuzminsky> on random machines starting up with no tool in P0, it's -1
[12:24:10] <seb_kuzminsky> all in favor say aye
[12:24:25] <cradek> yay
[12:24:38] <cradek> yarrr
[12:24:43] <cradek> aye
[12:24:58] <seb_kuzminsky> it bothers me that nonrandom machines dont start up as T=-1, but there's a long tradition of this behavior
[12:25:18] <cradek> the third thing you said might be considered a misconfiguration, and -1 is a fine thing to do if so
[12:25:32] <seb_kuzminsky> hmm, right
[12:26:02] <seb_kuzminsky> ok, i have a test that verifies that above behavior, and a little patch to iocontrol that makes it so, i'll commit tonight
[12:26:13] <cradek> sweet
[12:26:16] <cradek> you're awesome
[12:27:31] <seb_kuzminsky> this must be the first linuxcnc code i've written in months
[13:09:29] <Tom_itx> feelin rusty?
[13:12:48] <seb_kuzminsky> not really
[13:13:06] <seb_kuzminsky> feelin rushed, by the other things in my life
[13:13:30] <seb_kuzminsky> nice to have some time to spend on linuxcnc again, even if it's just for today
[16:03:04] <kwallace> I got a new toy yesterday:
http://www.wallacecompany.com/machine_shop/fire_master_h1818/
[16:03:31] <kwallace> Of course I'll need to find a way to have LinuxCNC control it.
[16:04:23] <kwallace> I'm hoping to make glass mirror blanks:
http://www.mdpub.com/kilncont/
[16:05:16] <cradek> I have one like that #2 photo, and I've slumped glass with it (to make pocket watch crystals)
[16:05:41] <cradek> the slumping worked, but the rest of the process wasn't particularly successful (bet I'd do better today)
[16:06:49] <cradek> the temperature control was mechanical - you put a cone (?) in there that melts at the temperature you want, and a linkage notices (somehow) and turns it off
[16:06:53] <cradek> I don't remember the details
[16:07:07] <kwallace> I've got a lot to learn.
[16:07:27] <cradek> don't we all :-)
[16:07:49] <cradek> "fire master" is a great name
[16:08:40] <kwallace> It looks like they have been out of business for quite a while.
[16:10:11] <kwallace> I guess I just need a couple of heavy duty SSRs and a bit of Glade/HAL foo.
[16:10:34] <cradek> I bet temperature feedback is the hard part
[16:11:11] <kwallace> Oops, that too. K type?
[16:11:16] <cradek> is bang-bang good enough?
[16:12:33] <cradek> surely so
[16:12:36] <kwallace> I suppose on and off at tens of seconds would be good.
[16:12:53] <kwallace> Minutes probably.
[16:12:59] <cradek> I doubt a pc is going to make this easier or better :-)
[16:15:52] <kwallace> The mirror guy has a multi day seven ramp program, so just a timer won't do it.
[16:16:30] <cradek> ah, neat, it's more intricate - I should have read the page.
[16:18:45] <kwallace> There is one section where he needs to get through a certain temperature, so it would be nice to automatically open the top to dump heat.
[16:18:46] <cradek> > A mechanism that detects the softening of a pyrometric cone would kill the power to the kiln when the desired temperature was reached.
[16:18:50] <cradek> heh yep it is the same
[16:20:33] <cradek> I can imagine a program that would let you interactively draw the graph of temperature vs time
[16:21:10] <cradek> desired temperature of course
[16:21:38] <kwallace> Maybe something like HALscope and show the following error.
[16:21:58] <cradek> no I mean the input
[16:22:12] <cradek> you'd draw slopes for rise/fall, or horizontals for steady
[16:22:17] <cradek> along the bottom of the graph would be time
[16:22:39] <kwallace> Oh for programming?
[16:22:44] <cradek> yeah
[16:22:55] <kwallace> In deed.
[16:23:38] <kwallace> oops indeed.
[16:24:31] <kwallace> I'm going out to turn it on.
[17:45:39] <kwallace> Oops. It must have been out in the rain because steam is coming out. I'll need to dry out before I get try to get it to full temperature.
[19:17:58] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.6 a93d5e7 06linuxcnc 10(28 files in 7 dirs) tests: add a test of io startup tool-in-spindle * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=a93d5e7
[19:17:58] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.6 2b27e32 06linuxcnc 10src/emc/iotask/ioControl.cc io: initialize the tool-in-spindle info correctly * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=2b27e32
[19:20:47] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.7 36480be 06linuxcnc 10docs/src/common/User_Concepts.txt Merge remote-tracking branch 'origin/2.6' into 2.7 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=36480be
[19:21:42] <KGB-linuxcnc> 03Sebastian Kuzminsky 05master eb111db 06linuxcnc Merge remote-tracking branch 'origin/2.7' * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=eb111db
[19:22:35] <seb_kuzminsky> this doesn't address frederic rible's issue, but it fixes a related bug in io startup
[20:41:50] <seb_kuzminsky> cmorley1: did you see my reply to your review request?
[20:42:16] <cmorley1> yes, I pushed the work. Thanks
[20:43:38] <seb_kuzminsky> oh! i missed it
[20:44:10] <seb_kuzminsky> oop, yep, there it is
[20:44:11] <seb_kuzminsky> thanks
[20:48:28] <cmorley1> must be getting close to 2.7 now...
[20:50:59] <seb_kuzminsky> still waiting on the encoder dpll thing from pcw/micges, then yes
[21:09:54] <mozmck> how is that going I wonder
[21:15:10] <cradek> have we heard anything about the tp bug? has anyone talked to rob?
[21:23:45] <skunkworks> I sent him an email today - I think he is pretty busy with a new job. He does get back to me though usually :)
[21:29:48] <linuxcnc-build> build #2566 of 4007.deb-precise-i386 is complete: Failure [4failed shell_1] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4007.deb-precise-i386/builds/2566 blamelist: Sebastian Kuzminsky <seb@highlab.com>, John Thornton <bjt128@gmail.com>
[23:08:46] <linuxcnc-build> build #2558 of 4006.deb-lucid-rtai-i386 is complete: Failure [4failed shell_1] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4006.deb-lucid-rtai-i386/builds/2558 blamelist: Sebastian Kuzminsky <seb@highlab.com>, Moses McKnight <moses@texband.net>, John Thornton <bjt128@gmail.com>
[23:16:44] <seb_kuzminsky> cradek: do you mean
https://sourceforge.net/p/emc/bugs/424/ ?
[23:18:08] <cradek> yes
[23:20:22] <seb_kuzminsky> yeap, guess that should be fixed before 2.7.0 too
[23:43:27] <seb_kuzminsky> those two build failures are that permission problem the buildbot deb archive has somtimes
[23:43:37] <seb_kuzminsky> i'm trying some things to debug it