Back
[09:38:23] <seb_kuzminsky> anyone look at #412?
https://sourceforge.net/p/emc/bugs/412/
[09:49:50] <pcw_home> Power Off?
[09:52:18] <cradek> he means it ferrors
[09:52:43] <cradek> no idea about "tool will jump in to the bottom" but I think it's a distraction
[09:54:33] <pcw_home> a little hard to guess what tool 215 is
[09:55:36] <cradek> not the greatest bug report, but as soon as we know the version we can at least try running the gcode
[09:55:53] <cradek> I also don't understand "if the feed rate is over the max"
[09:58:51] <pcw_home> if power off the tool will jump to the bottom= no Z brake?
[10:00:16] <pcw_home> is he just complaining about ferror behaviour?
[10:00:35] <cradek> I don't know
[10:01:12] <cradek> you mean he might just have a tuning problem and there's no bug?
[10:02:38] <pcw_home> sounds a bit like that
[10:03:11] <cradek> it's also possible there could be a constraint violations in helixes in the new planner
[10:04:09] <pcw_home> The code runs here ok with the new planner (but i removed the tool stuff so its not a good test)
[10:06:42] <cradek> thanks for trying it
[10:10:08] <pcw_home> "It should not power off, if not slowing down automatically, at least use stop instead power off"
[10:10:09] <pcw_home> sounds mainly like he doesn't want coast-to-stop on ferror
[10:15:38] <cradek> I also think it's possible that's what the bug report means but I'm not even 50% confident
[10:20:00] <pcw_home> too much missing info to test TP
[10:37:26] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.7 cfd37ef 06linuxcnc 10debian/control.in 10src/configure.in build system: tclx is a runtime dependency, not a build-dep * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=cfd37ef
[18:12:56] <KGB-linuxcnc> 03Dewey Garrett 052.7 58ea566 06linuxcnc 10lib/hallib/hookup_moveoff.tcl hookup_moveoff.tcl; remove unneded package cmd * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=58ea566
[19:10:01] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.7 74b396a 06linuxcnc 10docs/src/getting-started/Getting-LinuxCNC.txt docs: clean up md5sum info in Getting Started * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=74b396a
[19:31:34] <skunkworks> ooh...
[21:04:23] <KGB-linuxcnc> 03Dewey Garrett 05dgarr/use_hallib 010cc96 06linuxcnc 10docs/src/getting-started/Running-LinuxCNC.txt Running-linuxCNC.txt: update for hallib * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=010cc96
[21:37:20] <mozmck> Is there any reason to use HAL parameters instead of HAL pins?
[21:37:30] <mozmck> when making a component that is...
[21:38:49] <seb_kuzminsky> i dont think so
[21:38:50] <seb_kuzminsky> use pins
[21:39:35] <mozmck> ok, I didn't know if there was some performance difference or trying to keep namespace clutter down or something.
[22:20:32] <pcw_home> for remote devices its the difference between process data and setup data
[22:21:40] <pcw_home> (where access cost is high)
[22:21:50] <Tom_itx> pcw_home, one more typeo i found...
[22:23:22] <Tom_itx> 7I90 - pdf P7 numbered P3 below the first paragraph talking about the W3 jumper says W4 and i think that should be W3
[22:25:18] <Tom_itx> i like the new release clips on the 50pin ribbon!
[22:25:19] <pcw_home> Yeah thats W3
[22:27:51] <mozmck> pcw_home: but isn't that difference simply in how the component uses the pin or parameter?
[22:29:32] <pcw_home> parameters seem like setup constants (not netted so not updated every thread)
[22:31:54] <mozmck> Hmm, I didn't think about updating. How/when do they get updated?
[22:32:58] <mozmck> Can they be hooked to UI elements for setting? Or is that all just done at startup once somewhere?
[22:34:10] <seb_kuzminsky> whoops, Gene Heskett found an embarrassing bug in the rtai kernel config (my fault)
[22:34:20] <seb_kuzminsky> i forgot to turn on PAE...
[22:34:27] <mozmck> oops!
[22:34:36] <seb_kuzminsky> :-/
[22:34:49] <pcw_home> isnt that false advertising?
[22:34:55] <cradek> who has enough ram to care, anyway
[22:34:56] <seb_kuzminsky> it sort of is
[22:35:02] <seb_kuzminsky> Gene does, apparently
[22:35:44] <seb_kuzminsky> ugh