Back
[00:00:35] <linuxcnc-build> build #30 of deb-precise-rtpreempt-binary-x86 is complete: Failure [4failed apt-get-update shell_2] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/deb-precise-rtpreempt-binary-x86/builds/30 blamelist: dummy, Norbert Schechner <nieson@web.de>, Michael Haberler <git@mah.priv.at>, John Thornton <jthornton@gnipsel.com>, Chris Morley
[00:00:36] <linuxcnc-build> <chrisinnanaimo@hotmail.com>, Chris S Morley <chrisinnanaimo@hotmail.com>, Francis Tisserant <tissf@free.fr>, Michael Haberler <mail17@mah.priv.at>, Jeff Epler <jepler@unpythonic.net>, Charles Steinkuehler <charles@steinkuehler.net>, Sebastian Kuzminsky <seb@highlab.com>, Dewey Garrett <dgarrett@panix.com>
[00:00:40] <linuxcnc-build> build #30 of deb-precise-rtpreempt-binary-amd64 is complete: Failure [4failed apt-get-update shell_2] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/deb-precise-rtpreempt-binary-amd64/builds/30 blamelist: dummy, Norbert Schechner <nieson@web.de>, Michael Haberler <git@mah.priv.at>, John Thornton <jthornton@gnipsel.com>, Chris
[00:00:40] <linuxcnc-build> Morley <chrisinnanaimo@hotmail.com>, Chris S Morley <chrisinnanaimo@hotmail.com>, Francis Tisserant <tissf@free.fr>, Michael Haberler <mail17@mah.priv.at>, Jeff Epler <jepler@unpythonic.net>, Charles Steinkuehler <charles@steinkuehler.net>, Sebastian Kuzminsky <seb@highlab.com>, Dewey Garrett <dgarrett@panix.com>
[00:32:35] <zultron> jepler, I'm off to bed, but did you ever figure out what this is about?
http://linuxcnc.mah.priv.at/irc/%23linuxcnc-devel/2013-04-22.html#02:21:21
[00:33:01] <zultron> One of the last problems I'm seeing on posix/rtpreempt.
[00:33:50] <zultron> Affects 32-bit as well.
[00:41:12] <linuxcnc-build> build #30 of deb-precise-xenomai-binary-x86 is complete: Failure [4failed apt-get-update shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/deb-precise-xenomai-binary-x86/builds/30 blamelist: dummy, Norbert Schechner <nieson@web.de>, Michael Haberler <git@mah.priv.at>, John Thornton <jthornton@gnipsel.com>, Chris Morley
[00:41:12] <linuxcnc-build> <chrisinnanaimo@hotmail.com>, Chris S Morley <chrisinnanaimo@hotmail.com>, Francis Tisserant <tissf@free.fr>, Michael Haberler <mail17@mah.priv.at>, Jeff Epler <jepler@unpythonic.net>, Charles Steinkuehler <charles@steinkuehler.net>, Sebastian Kuzminsky <seb@highlab.com>, Dewey Garrett <dgarrett@panix.com>
[00:56:41] <seb_kuzminsky> linuxcnc-xenomai and linuxcnc-xenomai-kernel debs:
http://buildbot.linuxcnc.org/dists/precise/scratch-xenomai/binary-amd64
[00:57:08] <seb_kuzminsky> amusingly, also old pre-ubc xenomai debs from the old rtos-integration branch, from April 2013
[00:57:40] <seb_kuzminsky> oh, the debs are totally untested, but at least they build now
[00:57:44] <seb_kuzminsky> good night
[00:59:53] <linuxcnc-build> build #1325 of deb-lucid-rt-binary-i386 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/deb-lucid-rt-binary-i386/builds/1325 blamelist: dummy, Norbert Schechner <nieson@web.de>, Michael Haberler <git@mah.priv.at>, John Thornton <jthornton@gnipsel.com>, Chris Morley
[00:59:53] <linuxcnc-build> <chrisinnanaimo@hotmail.com>, Chris S Morley <chrisinnanaimo@hotmail.com>, Francis Tisserant <tissf@free.fr>, Michael Haberler <mail17@mah.priv.at>, Jeff Epler <jepler@unpythonic.net>, Charles Steinkuehler <charles@steinkuehler.net>, Sebastian Kuzminsky <seb@highlab.com>, Dewey Garrett <dgarrett@panix.com>
[01:21:14] <linuxcnc-build> build #31 of deb-precise-xenomai-binary-x86 is complete: Failure [4failed apt-get-update shell_3 stage debian package] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/deb-precise-xenomai-binary-x86/builds/31 blamelist: dummy, Norbert Schechner <nieson@web.de>, Michael Haberler <git@mah.priv.at>, John Thornton
[01:21:14] <linuxcnc-build> <jthornton@gnipsel.com>, Chris Morley <chrisinnanaimo@hotmail.com>, Chris S Morley <chrisinnanaimo@hotmail.com>, Francis Tisserant <tissf@free.fr>, Michael Haberler <mail17@mah.priv.at>, Jeff Epler <jepler@unpythonic.net>, Charles Steinkuehler <charles@steinkuehler.net>, Sebastian Kuzminsky <seb@highlab.com>, Dewey Garrett <dgarrett@panix.com>
[09:32:59] <jepler> zultron: no, and I can't provoke it in a sim build with the instruction I provided either
[09:33:19] <jepler> zultron: it's not clear whether my change a few minutes later was intended to be a fix for that or not
[09:33:42] <jepler> zultron: I tried both port 5005 (what I wrote on IRC) and 5007 (the linuxcncrsh port) and didn't get that sort of behavior
[09:33:53] <jepler> bbl
[09:38:10] <zultron> Thanks, jepler. I'm seeing that same loop you are on my Red Hat buildbot, but only in some cases. I'll ping back when I establish the pattern.
[09:49:28] <jepler> there must be a case where a file descriptor becomes bad but tcp_srv.cc doesn't succeed in evicting it from its list of file descriptors
[09:50:10] <jepler> it's not clear whether I was provoking that by crashing linuxcncrsh (and wrote the wrong thing), or by the way I was directly communicating with tcp_srv.cc (the port I wrote on irc)
[12:08:51] <KGB-linuxcnc> 03Norbert Schechner 05master 14de1b2 06linuxcnc 10lib/python/gladevcp/calculatorwidget.py gladevcp - calculator_widget support locale * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=14de1b2
[12:12:22] <seb_kuzminsky> we ship three tcl scripts that specifically call out tclsh8.5 as their interpreter, but on hardy we depend on tcl 8.4
[12:12:38] <seb_kuzminsky> tooledit, ngcgui, and haltcl
[12:12:49] <seb_kuzminsky> this probably means we don't have many users on hardy any more
[12:14:31] <seb_kuzminsky> anyone who knows those tools: do they actually need tcl 8.5, or will 8.4 do?
[12:22:53] <dgarr> seb_kuzminsky: tooledit checks tcl_version and supports column sorting iff >8.5, the others probably work with 8.4 (but it is limiting) 8.5 was released in 2007
[13:35:45] <KGB-linuxcnc> 03Norbert Schechner 05master 22a23d9 06linuxcnc 10share/gscreen/skins/gmoccapy/gmoccapy_handler.py 10share/gscreen/skins/gmoccapy/release_notes.txt gmoccapy_0_9_9_9_2 - feed override now for G0 and G1 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=22a23d9
[15:14:44] <owhite> hi people. I know this is a vague question but does anyone have any guess why the pwm_frequency pin will not stay set once everything gets loaded and the axis interface is up? I set it in my hal file but that it doesnt seem to get set. Running setp hm2_5i20.0.pwmgen.pwm_frequency 40000 after it loads up seems to take.
[15:18:44] <cradek> man hostmot2 says: If the user attempts to set the frequency too high, it will be clipped to the max supported frequency of the board.
[15:19:17] <cradek> this seems like a clue, although it says up to 193000 should be ok
[15:22:55] <skunkworks> also make sure you are editing the hal file you think you are editing...
[16:12:38] <cradek> that sounds like the voice of experience
[16:33:13] <cradek> he's not even here
[16:43:04] <skunkworks> heh
[18:35:03] <owhite> hey people - does anyone have any experience with setting hm2_5i20.0.pwmgen.pwm_frequency at run time?
[18:36:43] <micges> owhite: what are you trying to do?
[18:37:27] <owhite> I'm using gladevcp. I'd like to tie a couple buttons to changing the pwm_frequency.
[18:37:40] <owhite> After I start up the ui, I am to perform...
[18:37:59] <owhite> $ halcmd setp hm2_5i20.0.pwmgen.pwm_frequency 500
[18:38:17] <owhite> that works fine, it will change the frequency of my mesa board.
[18:38:28] <owhite> but when I try this, I get an error...
[18:38:42] <micges> what error?
[18:38:44] <owhite> $ halcmd net n1 hm2_5i20.0.pwmgen.pwm_frequency pwm_tab.laser_hertz_value
[18:38:54] <micges> ah
[18:39:02] <owhite> Pin 'hm2_5i20.0.pwmgen.pwm_frequency' does not exist
[18:39:11] <micges> you can't net it, it's parameter
[18:39:14] <owhite> ^^ the error.
[18:39:26] <owhite> Oh, well but why does the setp work?
[18:39:52] <micges> you can net pins only, but you can setp everything settable
[18:39:52] <owhite> well, I can accept that you can setp some parameters, but cant net them. Can you think of a work around?
[18:39:59] <owhite> ok.
[18:40:43] <micges> fastest is to patch source code to convert it to pin
[18:41:15] <owhite> that would be good advice for most people deserving to be on this channel, but not for me.
[18:41:17] <owhite> :-)
[18:42:03] <owhite> so the UI code that creates a button is glade, and I have a .py program associated with the glade ui. I could try to do the setp there.
[18:42:32] <owhite> But so far the code has not been able to find hm2_5i20.0.pwmgen.pwm_frequency.
[18:43:05] <micges> ?
[18:44:06] <micges> it will work if you will be able to run 'setp etc' on button click, that;'s all
[18:44:06] <owhite> bear with me, I can pastebin some code...
[18:44:14] <micges> ok
[18:44:20] <owhite> hang on...
[18:48:38] <owhite> please have a look at
http://www.pastebin.ca/2589538 line 47
[18:49:31] <owhite> the button press gets to that line, and then gives me attitude when I run: print self.halcomp["hm2_5i20.0.pwmgen.pwm_frequency"]
[18:51:04] <micges> no no
[18:52:35] <owhite> I gues if I could find the documentation on the python hal components I wouldnt be wasting your time. I think i'd try to have hal do the setp.
[18:52:38] <micges> try this:
http://www.pastebin.ca/2589541
[18:53:34] <owhite> well hey break out the sledge hammer and use a system call :-)
[18:57:00] <micges> :)
[19:00:14] <owhite> cant argue with success. It worked.
[19:00:47] <micges> cool
[20:54:29] <CaptHindsight> for testing sebs x86 RTAI (memleak) debs, does the desktop choice matter?
[21:00:02] <memleak> in theory linuxcnc does not touch anything window or desktop manager related features except maybe adding icons to the desktop or start menu. RTAI only touches the kernel side of things and the kernel runs completely independent from the X window system and Xorg server.
[21:01:46] <memleak> certain kernel patches however outside the official kernel source can limit the X server from functioning, such as patches from pax and grsecurity, mainly by restricting access to certain parts of system and video memory, but that's a whole other story.
[21:14:42] <seb_kuzminsky> CaptHindsight: i agree with memleak, the desktop environment shouldnt matter
[21:16:03] <CaptHindsight> ok, it's your fault if I waste 20 minutes downloading thew wrong version :)
[21:16:16] <CaptHindsight> thew/the
[21:21:18] <seb_kuzminsky> heh yeah, let me know if you find one that doesn't work
[21:25:22] <CaptHindsight> I'll be able to compare kernels and also of EFI vs coreboot later this week on the
http://www.asrock.com/mb/overview.asp?Model=E350M1
[21:27:30] <CaptHindsight> the live cd updated to EMC 2.5 with EFI is ~9k max jitter after 5 days
[21:38:06] <seb_kuzminsky> i'm curious how rtai compares to rt-preempt and xenomai
[21:38:20] <seb_kuzminsky> i just pushed a xenomai kernel for precise to the linuxcnc.org deb archive
[21:38:28] <seb_kuzminsky> the rt-preempt kernel from wheezy runs fine in precise
[21:38:31] <seb_kuzminsky> bbl
[21:40:44] <jepler> I notice there's linux-image-3.12-1-rt-amd64 in Debian Jessie. I should give it a whirl, even if just on a laptop.
[21:43:53] <skunkworks> I have an asus laptop (i5) that has pretty decent latency.. <50us iirc. Good enough for rt_preempt and mesa ethernet hardware
[22:00:31] <KGB-linuxcnc> 03Jeff Epler 05master df32629 06linuxcnc 10docs/src/config/ini_config.txt 10docs/src/config/stepconf_es.txt 10docs/src/gcode/gcode.txt 10docs/src/hal/rtcomps.txt Merge branch 'v2.5_branch' * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=df32629
[22:00:43] <KGB-linuxcnc> 03Jeff Epler 05v2.5_branch 4dc4a1a 06linuxcnc fast forward * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=4dc4a1a
[22:04:52] <cradek> weird - I wonder what kgb means by "fast forward" there
[22:05:22] <cradek> the commit looks right
[22:15:27] <jepler> huh, beats me
[22:15:28] <jepler> 'night
[22:18:37] <seb_kuzminsky> i dont understand the commit
[22:20:40] <cradek> by "looks right" I meant he committed what he intended to
[22:33:40] <cradek> seb_kuzminsky: I think I understand it. those are all time_t (longs) and it overflows because a long can't hold the time in nanoseconds for very long
[22:37:13] <cradek> sticking a long-long in there (anywhere) causes them all to be promoted and the math all happens in long-long space
[23:11:23] <seb_kuzminsky> aha, makes sense, thanks