Back
[01:45:40] <archivist> pcw seems superfish is not the only one of that type
http://www.bbc.co.uk/news/technology-31586610
[08:24:11] <c_morley> seb_kuzminsky: I will look into it after work.
[09:08:01] <seb_kuzminsky> mozmck: thank you!
[09:08:35] <seb_kuzminsky> err, i meant c_morley
[09:14:33] <mozmck> heh, autocomplete?
[09:20:07] <seb_kuzminsky> heh yeah
[09:20:25] <archivist> must be using C++ name mangling :)
[09:20:28] <seb_kuzminsky> i just pummel the keyboard then hit some keys over by tab while sleepily looking at my coffee cup
[09:21:55] <skunkworks> zlog:
[09:35:16] <seb_kuzminsky> hrm
[11:06:47] <kwallace3> The machine I'm working on trips a power input relay to the spindle VFD for any event that one would not want the spindle to spin, such as a power failure recovery, or the spindle door being open for a tool change and others.
[11:08:42] <seb_kuzminsky> turning off the vfd logic or just power to the spindle motor?
[11:09:04] <kwallace3> My problem is that the VFD is reset and powered up just before a call for a normal call for spindle motion, but this takes a while.
[11:09:39] <seb_kuzminsky> yeah, vfds can take a while to boot
[11:10:15] <kwallace3> I'm trying to build a case to only shut down the VFD power on an e-stop.
[11:11:08] <seb_kuzminsky> i'm trying to convince a customer that the VFD should have logic power at all times, and the spindle motor power is the thing that should eb interrupted by estop
[11:11:11] <archivist> a door open stop where you use the vfd stop signal will sto faster that if allowed to run down
[11:11:23] <kwallace3> Then use the enable and care in submitting a normal command for the more common operator lock out events.
[11:12:29] <kwallace3> I need resources to support my case.
[11:13:01] <archivist> the enable/disable is under control, faster and safer than a run down
[11:14:43] <archivist> so a motor can be parked/braked in milli secs under control but a free run can be many seconds
[11:16:23] <mozmck> you can use braking resistors to stop the spindle...
[11:16:50] <kwallace3> My HNC lathe has a power release brake to handle coasting due to power outages.
[11:17:06] <ssi> I ditched the mechanical brake on mine
[11:17:11] <archivist> not all have that brake though
[11:17:57] <archivist> other option is DC injection/resistor brake via the vfd
[11:18:49] <kwallace3> But the power release brake seems like a good idea if coasting while the power is out is a concern.
[11:19:36] <kwallace3> Especially if is supports keeping the VFD powered up if the mains are good.
[11:19:45] <kwallace3> is/it
[11:22:16] <kwallace3> The drive is an Emerson and their big corp website makes one jump through flaming hoops to get a hint of support.
[11:23:31] <archivist> they hide these days to avoid liability
[15:23:03] <PCW> Linuxcnc/hm2_eth runs acceptably at 1 KHz on a Dell E6420 laptop
[15:23:43] <PCW> (despite occasional 200 usec latency spikes)
[15:28:37] <seb_kuzminsky> neat
[15:29:01] <skunkworks> can someone tell me why the images are missing? where the external?
http://linuxcnc.org/index.php/english/forum/41-guis/17806-gscreen-a-gtk--glade--python-based-screen?limitstart=0
[15:37:01] <skunkworks> micges: your loadable tp stuff is already in machinekit...
[15:52:52] <seb_kuzminsky> i'm all for loadable TP modules in linuxcnc too :-)
[16:03:27] <skunkworks> :)
[16:05:08] <micges> skunkworks: I know, I started it ;)
[16:06:47] <micges> I've tried easy way in my loadable_tp branch but it leeds to same approach as in mk
[16:08:07] <micges> so we must define tp interface, is it in hal or anywhere else doesn't matter
[17:03:09] <andypugh> Just to repeat myself here to a wider audience, any ideas how I can find the argument list for Handle.render_cairo() from python-rsvg?
[17:07:43] <Tom_itx> http://nullege.com/codes/search/rsvg.Handle.render_cairo
[17:07:46] <Tom_itx> is that any help?
[17:16:16] <andypugh> Possibly
[17:16:37] <andypugh> It led me to here:
http://ruby-gnome2.sourceforge.jp/hiki.cgi?RSVG%3A%3AHandle#render_cairo
[17:39:57] <PCW> laptop needs the same ethtool stuff as ASRock MB (possibly all Intel MACs need this)
[17:55:02] <PCW> linux portability still amazes me
[17:55:03] <PCW> unplug 64M SATA drive from test MB, plug into Lapto ESATA connector, boot linux
[17:55:05] <PCW> everything just works (well I didnt try the webcam) Didnt try the WIFI but it found lots of neighbors
[18:31:53] <skunkworks> cool huh?
[18:48:02] <PCW> seems fine at 1 KHz (wish I could find what causes the latency spikes so it would run faster but happy it runs reliably at 1 KHz)
[18:48:57] <KGB-linuxcnc> 03Michael Geszkiewicz 05micges/master/limited_jerk dcbbedd 06linuxcnc 10(6 files in 2 dirs) bring back old trajectory planner and use it in motion * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=dcbbedd
[18:48:57] <KGB-linuxcnc> 03Michael Geszkiewicz 05micges/master/limited_jerk 4d010a3 06linuxcnc 10(10 files in 4 dirs) jerk_tp: introduce [AXIN_n]MAX_JERK parameter and forward it to task and motion * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=4d010a3
[18:51:03] <PCW> Yay!
[18:51:50] <micges> slowly but yay
[19:08:53] <linuxcnc-build> build #1167 of 1403.rip-wheezy-amd64 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1403.rip-wheezy-amd64/builds/1167 blamelist: Michael Geszkiewicz <micges@wp.pl>
[19:09:32] <micges> noooo
[19:09:43] <linuxcnc-build> build #1358 of 1404.rip-wheezy-rtpreempt-amd64 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1404.rip-wheezy-rtpreempt-amd64/builds/1358 blamelist: Michael Geszkiewicz <micges@wp.pl>
[19:18:01] <seb_kuzminsky> micges: do you know how to see the errors the buildbot just reported?
[19:18:25] <micges> yeah, looking for them atm
[19:20:11] <linuxcnc-build> build #3011 of 1306.rip-precise-amd64 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1306.rip-precise-amd64/builds/3011 blamelist: Michael Geszkiewicz <micges@wp.pl>
[19:21:27] <linuxcnc-build> build #3010 of 1202.rip-lucid-amd64 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1202.rip-lucid-amd64/builds/3010 blamelist: Michael Geszkiewicz <micges@wp.pl>
[19:25:11] <linuxcnc-build> build #3010 of 1201.rip-lucid-rtai-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1201.rip-lucid-rtai-i386/builds/3010 blamelist: Michael Geszkiewicz <micges@wp.pl>
[19:25:12] <micges> got it
[23:52:51] <KGB-linuxcnc> 03chris morley 052.7 5d074d1 06linuxcnc 10src/emc/usr_intf/stepconf/build_HAL.py stepconf -fix missing parport reset commands * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=5d074d1