#linuxcnc-devel | Logs for 2013-03-02

Back
[00:08:30] -!- tmcw has quit [Remote host closed the connection]
[00:16:26] -!- gasbakid has quit [Remote host closed the connection]
[00:21:04] -!- R2E4_ has quit [Client Quit]
[00:30:19] -!- micges has quit [Quit: Leaving]
[00:35:43] -!- micges [micges!~toudi@aboz197.neoplus.adsl.tpnet.pl] has joined #linuxcnc-devel
[00:37:21] -!- mourner has quit [Quit: mourner]
[00:41:49] -!- asdfasd has quit [Ping timeout: 240 seconds]
[00:51:52] -!- linuxcnc-build has quit [Remote host closed the connection]
[00:53:53] -!- linuxcnc-build [linuxcnc-build!~linuxcnc-@174-16-204-191.hlrn.qwest.net] has joined #linuxcnc-devel
[00:55:25] -!- andypugh has quit [Quit: andypugh]
[00:59:22] -!- mattions has quit [Ping timeout: 272 seconds]
[01:03:31] -!- Thetawaves_ has quit [Ping timeout: 248 seconds]
[01:14:35] -!- micges has quit [Quit: Leaving]
[01:24:04] -!- tmcw has quit [Ping timeout: 272 seconds]
[01:38:38] -!- L84Supper has quit [Ping timeout: 272 seconds]
[01:39:10] -!- adb has quit [Ping timeout: 260 seconds]
[01:40:30] -!- PCW has quit [Quit: ChatZilla 0.9.90 [Firefox 19.0/20130215130331]]
[01:46:42] -!- rob_h has quit [Ping timeout: 244 seconds]
[01:58:11] -!- L84Supper [L84Supper!~Larch@unaffiliated/l84supper] has joined #linuxcnc-devel
[02:03:37] -!- mhaberler has quit [Quit: mhaberler]
[02:07:08] -!- cmorley has quit [Ping timeout: 255 seconds]
[02:14:34] -!- Wildhoney has quit [Ping timeout: 245 seconds]
[02:19:10] -!- L84Supper has quit [Ping timeout: 272 seconds]
[02:21:27] -!- sumpfralle has quit [Ping timeout: 256 seconds]
[02:22:17] -!- cmorley [cmorley!~chris@S010688ae1d61f51a.no.shawcable.net] has joined #linuxcnc-devel
[02:41:27] -!- L84Supper [L84Supper!~Larch@unaffiliated/l84supper] has joined #linuxcnc-devel
[03:04:33] -!- tmcw has quit [Remote host closed the connection]
[03:41:05] -!- FinboySlick has quit [Quit: Leaving.]
[04:00:53] -!- BHSPiMonkey has quit [Read error: Operation timed out]
[04:55:55] -!- s1dev has quit [Ping timeout: 246 seconds]
[05:19:42] -!- Gene34 has quit []
[05:21:18] -!- jfire has quit [Quit: Leaving.]
[05:23:19] -!- AR_ has quit [Ping timeout: 240 seconds]
[05:46:34] <KGB-linuxcnc> 03seb 05v2.5_branch f77bfa3 06emc2 10tests/ 03linuxcncrsh/skip 03t0/nonrandom/skip 03t0/random-with-t0/skip 03t0/random-without-t0/skip * disable the tests that fail because of mdi queueing
[05:47:38] -!- skorasaurus has quit [Ping timeout: 245 seconds]
[05:52:38] -!- hdokes has quit [Ping timeout: 245 seconds]
[05:55:21] <KGB-linuxcnc> 03chrisinnanaimo 05v2.5_branch b0a0c04 06emc2 10src/emc/usr_intf/pncconf/pncconf.py * pncconf -fix error when inverting PWM
[06:02:49] -!- Fox_Muldr has quit [Ping timeout: 240 seconds]
[06:05:55] -!- cmorley has quit [Ping timeout: 256 seconds]
[06:15:30] <KGB-linuxcnc> 03seb 05v2.5_branch 766d39d 06emc2 10src/emc/rs274ngc/interp_convert.cc * update comments for Interp::convert_tool_select (M6)
[06:15:30] <KGB-linuxcnc> 03seb 05v2.5_branch f317acd 06emc2 10src/emc/iotask/ioControl.cc * io: fix a misleading comment
[06:15:33] <KGB-linuxcnc> 03seb 05v2.5_branch 57ab942 06emc2 10src/emc/nml_intf/canon.hh * rename the argument to SELECT_POCKET() to be more clear
[06:15:40] <KGB-linuxcnc> 03seb 05v2.5_branch 49ee157 06emc2 10tests/toolchanger/ 10(15 files in 5 dirs) * add sim tests for the "toolno != pocket number" bug
[06:15:46] <KGB-linuxcnc> 03seb 05v2.5_branch 482423d 06emc2 10src/emc/rs274ngc/interp_convert.cc * fix a bug in convert_setup_tool(), aka G10
[06:15:53] <KGB-linuxcnc> 03seb 05v2.5_branch 43409f4 06emc2 10src/emc/rs274ngc/interp_convert.cc * remove silly code in Interp::convert_setup_tool()
[06:15:59] <KGB-linuxcnc> 03seb 05v2.5_branch ff0bcf3 06emc2 10src/emc/rs274ngc/interp_convert.cc * Interp::convert_setup_tool(): avoid a spurious tool copy
[06:16:06] <KGB-linuxcnc> 03seb 05v2.5_branch f11f0e8 06emc2 10src/emc/task/emccanon.cc * fix a bug in emccanon's GET_EXTERNAL_TOOL_SLOT()
[06:16:12] <KGB-linuxcnc> 03seb 05v2.5_branch d98c12b 06emc2 10src/emc/task/emccanon.cc * comment emccanon's GET_EXTERNAL_SELECTED_TOOL_SLOT()
[06:16:19] <KGB-linuxcnc> 03seb 05v2.5_branch e52411b 06emc2 10src/emc/rs274ngc/interp_convert.cc * rename a variable in Interp::convert_tool_length_offset()
[06:16:25] <KGB-linuxcnc> 03seb 05v2.5_branch 4018140 06emc2 10src/emc/rs274ngc/interp_convert.cc * better comments in Interp::convert_tool_length_offset()
[06:16:32] <KGB-linuxcnc> 03seb 05v2.5_branch f40219e 06emc2 10src/emc/rs274ngc/interp_convert.cc * rename a variable in Interp::convert_cutter_compensation_on() for clarity
[06:16:39] <KGB-linuxcnc> 03seb 05v2.5_branch d7f114b 06emc2 10docs/src/code/Code_Notes.txt * docs: add Code Notes for toolchanger
[06:16:45] <KGB-linuxcnc> 03seb 05v2.5_branch 3e291ed 06emc2 10tests/toolchanger/ 03toolno-pocket-differ/nonrandom/skip 03toolno-pocket-differ/random/skip * skip these tests for now
[06:16:55] <seb_kuzm1nsky> there it is finally
[06:17:19] <seb_kuzm1nsky> the oldest commits in that push are from october 2012...
[06:18:05] <seb_kuzm1nsky> ok, that's all i had queued up for 2.5.2! i'm go for release
[06:28:58] -!- cmorley [cmorley!~chris@S010600c09fc019c2.no.shawcable.net] has joined #linuxcnc-devel
[06:39:00] -!- psha [psha!~psha@213.208.162.67] has joined #linuxcnc-devel
[06:53:51] -!- R2E4_ has quit [Quit: Relax, its only ONES and ZEROS!]
[07:04:21] -!- kwallace1 [kwallace1!~kwallace@smb-35.sonnet.com] has joined #linuxcnc-devel
[07:06:23] -!- kwallace has quit [Ping timeout: 255 seconds]
[07:18:34] -!- ve7it has quit [Remote host closed the connection]
[07:37:58] -!- Thetawaves_ has quit [Ping timeout: 246 seconds]
[07:38:01] * KimK sends seb_kuzm1nsky the "git stash" award
[07:45:26] -!- kwallace1 [kwallace1!~kwallace@smb-35.sonnet.com] has parted #linuxcnc-devel
[07:51:39] <seb_kuzm1nsky> heh
[08:05:56] -!- jdh has quit [Ping timeout: 252 seconds]
[08:11:24] -!- mhaberler [mhaberler!~mhaberler@macbook.stiwoll.mah.priv.at] has joined #linuxcnc-devel
[08:12:25] -!- pikeaero has quit [Quit: No Ping reply in 180 seconds.]
[08:14:30] -!- Thetawaves_ has quit [Client Quit]
[08:19:05] -!- mk0 has quit [Quit: Leaving]
[08:19:33] -!- cmorley has quit [Quit: Leaving.]
[08:42:13] -!- cmorley [cmorley!~chris@S010600c09fc019c2.no.shawcable.net] has joined #linuxcnc-devel
[09:35:05] -!- racycle has quit [Quit: racycle]
[09:35:26] -!- Keknom has quit [Quit: Leaving.]
[10:08:52] -!- psha has quit [Quit: Lost terminal]
[10:15:42] -!- cncbasher [cncbasher!~quassel@cpc15-hart9-2-0-cust101.11-3.cable.virginmedia.com] has joined #linuxcnc-devel
[10:17:01] -!- The_Ball has quit [Ping timeout: 256 seconds]
[10:18:32] -!- davec_ has quit [Ping timeout: 255 seconds]
[10:27:54] -!- norbert [norbert!~norbert@a89-182-20-126.net-htp.de] has joined #linuxcnc-devel
[10:46:36] -!- rob_h [rob_h!~rob_h@5e0473f7.bb.sky.com] has joined #linuxcnc-devel
[11:05:47] -!- Wildhoney has quit [Ping timeout: 255 seconds]
[11:09:50] jthornton_ is now known as jthornton
[11:45:59] -!- dhoovie has quit [Read error: Connection reset by peer]
[11:50:26] -!- syyl has quit [Ping timeout: 272 seconds]
[12:02:49] -!- cmorley1 [cmorley1!~chris@S010600c09fc019c2.no.shawcable.net] has joined #linuxcnc-devel
[12:05:11] -!- cmorley has quit [Ping timeout: 252 seconds]
[12:08:58] -!- andypugh [andypugh!~andy2@cpc16-basl9-2-0-cust685.20-1.cable.virginmedia.com] has joined #linuxcnc-devel
[13:21:08] JT-Shop-2 is now known as JT-Shop
[13:39:14] -!- hdokes has quit [Read error: Connection reset by peer]
[14:12:49] -!- ler_hydra has quit [Remote host closed the connection]
[14:16:24] -!- mourner has quit [Quit: mourner]
[14:22:31] -!- MarkusBec has quit [Ping timeout: 245 seconds]
[14:34:39] -!- phantoxeD has quit []
[14:49:08] -!- zzolo has quit [Quit: zzolo]
[14:50:14] -!- stsydow has quit [Remote host closed the connection]
[15:18:27] -!- dgarr [dgarr!~dgarrett@97-117-216-21.phnx.qwest.net] has joined #linuxcnc-devel
[15:20:25] <dgarr> some tests of rtai 3.5.7 debs on atom motherboard: http://www.panix.com/~dgarrett/rtai357/
[15:24:58] <mhaberler> dgarr: that's quite interesting; in particular the 'idle=poll' observation - confirms my theory that latency is mostly undeterministic wakeups from powersave states
[15:25:08] -!- tronwizard has quit []
[15:25:24] <mhaberler> since that was the same thing with xenomai it cant be the OS
[15:26:46] -!- mourner has quit [Quit: mourner]
[15:26:50] <mhaberler> plus the old idle do-nothing shell script observation - it's all the same story: preventing powersave
[15:27:26] <mhaberler> at least those which fiddle the onboard SMPS regulators - those are slow to come back up
[15:29:21] <skunkworks> Idle = poll didn't help me on the few intel machines I have tried so far with xenomai
[15:29:35] <skunkworks> it did with the amd systems
[15:30:01] <skunkworks> dgarr: you might want to post that to the list
[15:30:34] <skunkworks> But I have not gotten back to testing xonamai yet
[15:30:59] <skunkworks> (now I have a dual boot hd with rtai 3.5.7 and xonamai
[15:38:01] -!- joe9 has quit [Ping timeout: 244 seconds]
[15:40:37] -!- joe9 [joe9!~joe9@c-24-98-97-215.hsd1.ga.comcast.net] has joined #linuxcnc-devel
[15:58:24] -!- AR_ has quit [Ping timeout: 264 seconds]
[15:59:26] -!- skunkworks has quit [Remote host closed the connection]
[16:01:17] <dgarr> for consideration, a patch to indicate where X display is in latencyhistogram (2.5branch): http://www.panix.com/~dgarrett/stuff/0001-latencyhistogram-include-DISPLAY-in-info-text.patch
[16:06:20] <dgarr> why is the modules dir so big for rtai 3.5.7 deb install? $ cd /lib/moduels; du -ms * |sort -n
[16:06:27] <dgarr> 3.5.7-xenomai-2.6.2.1
[16:06:42] <dgarr> 107 3.5.7-xenomai-2.6.2.1
[16:06:42] <dgarr> 109 3.2.0-37-generic
[16:06:42] <dgarr> 1381 3.5.7-rtai+
[16:06:42] -!- kwallace [kwallace!~kwallace@smb-83.sonnet.com] has joined #linuxcnc-devel
[16:08:19] <mhaberler> probably debug syms
[16:21:33] <L84Supper> so if we kill powersave in the firmware that should get us lower consistent latency
[16:28:52] <mhaberler> in the firmware ?
[16:32:13] <mozmck> It should all be turned off in the kernel config - right?
[16:32:31] <mhaberler> not necessarily
[16:32:53] <mhaberler> there are lots of powersave states, not all of them are suspicious
[16:33:06] <mhaberler> the current drain can be dramatic, see here:
[16:33:59] <mhaberler> http://www.hardwaresecrets.com/article/Everything-You-Need-to-Know-About-the-CPU-C-States-Power-Saving-Modes/611/5
[16:35:05] <mhaberler> it would really help to scope the CPU supply voltage on suspicious boards - that should give a strong hint
[16:36:06] <mhaberler> boot=idle basically prevents falling into powersave states by busy looping the OS idle loop
[16:37:25] <mozmck> I know that before with rtai it was recommended to turn off all the power stuff. That's why the computer would not turn off when you shutdown among other things.
[16:37:28] <mhaberler> functionally it doesnt matter where you disable powersave states - since not all cpu's/boards seem to be susceptible compiling that in unchangeable is a bad idea
[16:37:41] <mhaberler> well yes
[16:38:48] <mhaberler> that's one of the consequences and some RTOS build recipes give strong advice, like the xenomai menuconfig already detects bad combinations and tells you
[16:39:09] <mhaberler> I havent tried against that advice yet though ;)
[16:39:21] <mozmck> for a machine controller I think power consumption is almost not a consideration compared to functionality. The machine you are running uses more power than the computer anyhow!
[16:39:58] <L84Supper> firmware = coreboot with none of the power management enabled
[16:40:29] <mhaberler> (I'm tempted to go on a tangent and ask why latency is all that important at least for servo configs, I have not heard a quantitative answer yet)
[16:40:48] <L84Supper> it's not that big a deal for servos
[16:40:56] <mhaberler> there are lots of musings and opining on the issue
[16:41:11] <mhaberler> well my interest would be a hard figure for 'big deal'
[16:41:13] <L84Supper> its just for stepper apps that want every once squeezed out of their chipset
[16:41:33] <mhaberler> tell that to the servo crowd
[16:41:51] <L84Supper> and whats wrong with 5us latency jitter?
[16:42:22] <mhaberler> what's wrong with a Airbus380 jetfan in my convertible
[16:42:45] <mozmck> The people running stepper apps probably outnumber the servo apps I would venture to guess. Much simpler easier and cheaper setup for any kind of hobby stuff.
[16:42:46] <L84Supper> nice
[16:43:21] <mhaberler> I'm would like to discover a quantitatively founded answer to that question eventually. thats all
[16:43:29] <L84Supper> yes, it's mostly steppers for retrofits
[16:43:53] <mhaberler> well yes - still this wont apply to hw stepgen board configs
[16:44:03] <L84Supper> IMHO it's just an opinion formed by the wording on the wiki for the latency test
[16:44:08] <L84Supper> lower is better
[16:44:29] <mhaberler> where I hear that before ;)
[16:44:46] <L84Supper> maybe someone should reword the wiki
[16:45:15] <mhaberler> I think the only relevant quantitive answer is path accuracy in a spatial and temporal dimension
[16:45:30] <mhaberler> for that we dont have a quality indicator
[16:47:29] <mhaberler> the only indirect indicator anywhere relevant I can think of is servo loop noise; but I dont see how the former can be derived from that; it sure limits gain and hence accuracy - so there is a relation
[16:49:37] <mhaberler> I think a valuable direction to investigate would be a spectrum analyzer component
[16:49:58] <mhaberler> say, noise density figures
[16:53:10] <mhaberler> something like that: http://fft-spectra.sourceforge.net/ or gtkspec ; not sure running it on the same machine makes sense but you get the idea
[16:53:49] <mhaberler> you get the machine resonance frequencies displayed for free ;)
[16:59:26] <norbert> Hallo, can someone tell me, how I can interupt an MDI command using a Python command. I have on my screen macro buttons like the ones in touchy, and i want a button to interupt the macro in case of an emergency, but without switching the machine off or pressung the emergency button.
[16:59:45] <mhaberler> send abort()
[16:59:59] <norbert> Thanks I will try that
[17:01:13] <mhaberler> example here: http://www.linuxcnc.org/docs/devel/html/common/python-interface.html
[17:01:34] <mhaberler> or halui
[17:01:46] <mhaberler> that cann abort too
[17:04:20] <seb_kuzm1nsky> ok Esc in Axis, iirc
[17:06:42] <norbert> I just tested self.gscreen.emc.abort(), that works like I wish.
[17:09:38] -!- hdokes has quit [Ping timeout: 272 seconds]
[17:16:15] putnik_ is now known as putnik
[17:37:56] -!- dgarr has quit [Ping timeout: 252 seconds]
[18:03:19] -!- nots has quit [Ping timeout: 260 seconds]
[18:09:07] -!- nots has quit [Ping timeout: 248 seconds]
[18:09:40] -!- SWPLinux has quit [Ping timeout: 248 seconds]
[18:15:43] -!- nots has quit [Remote host closed the connection]
[18:28:57] -!- IchGuckLive has quit [Quit: ChatZilla 0.9.87 [Firefox 18.0/20130108033621]]
[18:36:40] -!- pjm has quit [Ping timeout: 246 seconds]
[18:51:41] -!- cncbasher_ [cncbasher_!~quassel@cpc15-hart9-2-0-cust101.11-3.cable.virginmedia.com] has joined #linuxcnc-devel
[18:53:50] -!- zzolo has quit [Client Quit]
[19:06:27] -!- zzolo has quit [Quit: zzolo]
[19:18:35] <mhaberler> seb_kuzm1nsky: zultron: let's have a coordination round on this channel to work out the rtos build and configure - I could be back in some 2hrs, otherwise let me know when it's convenient for you guys
[19:18:47] <mhaberler> NB: TZ=UTC+1
[19:19:05] <mhaberler> will read back later
[19:24:12] -!- mhaberler has quit [Ping timeout: 264 seconds]
[19:30:00] -!- karavanjoW has quit [Quit: KVIrc 4.0.4 Insomnia http://www.kvirc.net/]
[19:34:17] -!- cncbasher_ has quit [Remote host closed the connection]
[19:34:17] -!- cncbasher has quit [Read error: Connection reset by peer]
[19:38:49] -!- Wildhoney has quit []
[19:42:47] -!- mhaberler [mhaberler!~mhaberler@extern-187.stiwoll.mah.priv.at] has joined #linuxcnc-devel
[19:45:49] -!- asdfasd has quit [Ping timeout: 245 seconds]
[19:47:41] <KGB-linuxcnc> 03chris 05v2.5_branch 572b8b3 06emc2 10scripts/.gitignore * ignore another generated file
[19:47:43] <KGB-linuxcnc> 03dgarrett 05v2.5_branch cab1612 06emc2 10scripts/latencyhistogram.in * latencyhistogram: include DISPLAY in info text
[19:52:14] -!- micges [micges!~micges@egm113.neoplus.adsl.tpnet.pl] has joined #linuxcnc-devel
[19:54:24] <mhaberler> seb - were there any interpreter method changes with the toolchanger fixes? like changed param lists etc
[19:57:00] -!- zzolo has quit [Ping timeout: 260 seconds]
[20:02:25] <seb_kuzm1nsky> mhaberler: the set of params did not change in those patches
[20:02:39] <seb_kuzm1nsky> one or two bugfixes were applied to the params (incorrect updates)
[20:03:22] <seb_kuzm1nsky> i can't have a meeting now, but i could be around for a few hours, starting in ~4-5 hours from now
[20:03:44] <mhaberler> looks fine; zultron: ?
[20:04:01] -!- norbert has quit [Quit: Verlassend]
[20:04:07] <mhaberler> in case he cant - next opportunity?
[20:04:16] <seb_kuzm1nsky> heh, hard to say
[20:04:26] -!- mattions has quit [Ping timeout: 272 seconds]
[20:04:35] <mhaberler> ok, no more rtai builds before that ;)
[20:04:47] <mhaberler> reason: some of the interp methods, in particular wrt toolchange are exposed as python methods and those might change a public api
[20:05:10] <seb_kuzm1nsky> most likely times for me to be available are 21:00-00:00 in UTC-7
[20:05:27] <seb_kuzm1nsky> wait what?
[20:05:41] <seb_kuzm1nsky> what interp methods are changing and why?
[20:06:40] <mhaberler> I wanted to know whether your changes impacted any interpreter methods; boost::python exposes much of it automatically so it wouldnt break builds but users might be surprised
[20:07:13] <mhaberler> say: new parameter added to method - you get a signature error in python
[20:09:28] <mhaberler> time would be fine for me; need to wait for John to tune in, he's busy fixing the house
[20:10:26] <cradek> mhaberler: what change are you talking about? I don't see any canon api changes.
[20:10:49] <mhaberler> that was my question: were there any
[20:11:06] <mhaberler> due to sebs fixups re tool handling
[20:11:08] <cradek> oh you didn't look? or are you talking about changes he hasn't shared yet?
[20:11:20] <cradek> I just now looked at v2.5_branch and don't see any
[20:11:28] <mhaberler> no, I'm not reading every single commit
[20:11:55] <seb_kuzm1nsky> there was a canon change but no interp change
[20:11:56] <cradek> ok, I did it for you then
[20:12:16] <mhaberler> ah, I saw that one
[20:12:19] <seb_kuzm1nsky> hold on, diggign it up
[20:12:23] <cradek> seb_kuzm1nsky: you fixed a canon function but did not change the api (param list, return type, etc)
[20:12:29] <cradek> f11f0e8de
[20:12:38] <seb_kuzm1nsky> http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=commitdiff;h=f11f0e8ded4e5bf4945c0fbc2eb025cd3327666b;hp=ff0bcf33fcafc8e089a500be1e2f2e1d64bb4c59
[20:12:46] <seb_kuzm1nsky> yes
[20:13:00] <seb_kuzm1nsky> cradek: correct
[20:13:18] <seb_kuzm1nsky> the function signature was not changed, but the behavior was
[20:13:20] <mhaberler> that's fine - no signature change
[20:13:48] <seb_kuzm1nsky> looking at my recent push, i notice it's mostly comments & docs
[20:13:55] <seb_kuzm1nsky> that's funny, i thought it was mostly code
[20:14:12] <cradek> precise i386 desktop doesn't boot on my laptop because I don't have pae :-/
[20:14:16] <seb_kuzm1nsky> maybe because the code took so much longer to write?
[20:14:21] <mhaberler> it's the documented learning curve
[20:14:27] <seb_kuzm1nsky> cradek: oops
[20:14:46] <seb_kuzm1nsky> pae is for 32-bit machines with more than 4 GB RAM
[20:14:53] <cradek> I predict they just became incompatible with a bunch more hardware
[20:15:02] <cradek> yeah I know. I guess my cpu doesn't support it.
[20:15:08] <mhaberler> they must be after you
[20:15:11] <seb_kuzm1nsky> older cpu maybe?
[20:15:31] <seb_kuzm1nsky> next time i rebuild the rtai kernel i'll turn it off, probably won't be for several days
[20:15:36] <cradek> yeah I know it's oldish
[20:15:57] <cradek> nah, don't bother unless pae breaks rtai (I know it used to), it's a laptop anyway
[20:16:04] <seb_kuzm1nsky> at some point we should host a rtai repo with our local changes on linuxcnc.org
[20:16:24] <cradek> that's fine and also easy
[20:16:30] <seb_kuzm1nsky> great :-)
[20:16:44] <seb_kuzm1nsky> ok i'll be back in some hours, time to go putter around in the garage for a bit :-)
[20:16:50] <cradek> have fun
[20:19:58] <cradek> I haven't managed to get it to boot on *anything* yet
[20:20:08] <cradek> all my spare hardware is old
[20:20:22] <mhaberler> while you are at it - could you do the same for John's already packaged Xenomai kernels? They are on my machine but I thiink they would be better at home at linuxcnc.org
[20:21:10] <cradek> do you mean debs or git?
[20:21:22] <cradek> I think seb meant git but I'm not sure in retrospect
[20:21:23] <mhaberler> both
[20:22:17] <mhaberler> well there is an RTAI deb archive for linuxcnc on that machine, and I think a matching Xenomai deb archive would be nice
[20:22:31] <mhaberler> RT-PREEMPT we dont need custom debs for
[20:24:03] <cradek> I can pull some stuff to www.linuxcnc.org/some-new-dir any time, but if we want real apt repos we have to figure out how to stir them in with what we already have and get them signed
[20:24:16] <cradek> I can also make a new git repo on git.linuxcnc.org any time
[20:24:26] <mhaberler> well yes, John did all that already
[20:24:35] <mhaberler> it'd be basically a key change
[20:25:16] <mhaberler> I think a kernel repo with branches per build would make sense
[20:26:17] <mhaberler> he did all the automatic build which goes to deb.machinekit.net already, and all code is in a repo (not linux kernel -separate; that would be a good idea too)
[20:27:42] <mhaberler> the more I think of it - two would make sense: the kernel proper plus branches, plus a build scripts repo so as not to taint the kernel repo
[20:27:52] <mhaberler> that was the error I made
[20:29:07] <mhaberler> not sure at this point what some-new-dir will be - I dont think we need one; it's going to be different packages under the existing one
[20:31:07] <cradek> I am going to work on releasing 2.5.2 for existing setups soon - after that we can figure out what additional stuff we want to do for new realtime systems
[20:33:05] <mhaberler> I think we need you mostly for the linuxcnc.org prequsites but we'll work those out with Seb; the repos and some coordination on transfer would help though
[20:33:32] <cradek> I agree with your goal of having a kernel repo we can use to reproduce our kernel package builds. we've had trouble keeping track of that before
[20:33:40] <mhaberler> sorry - work out the build prerequisites with Seb
[20:33:47] <mhaberler> amen
[20:34:05] <mhaberler> (that was very polite ;)
[20:34:32] <mhaberler> that may never happen again
[20:34:52] <cradek> whether/how we'll make and package linuxcnc releases of 2.6/3.0/whatever it is, for several realtime systems, is hugely up in the air as far as I know
[20:35:33] <mhaberler> not for me, but discussing it gets it down to the ground, and that was missing so far
[20:36:33] <mhaberler> please understand that my patience on no response/discourse whatsoever is, well, a bit stretched
[20:36:33] <cradek> well I have not seen that any of the packaging type work is even started. am I mistaken?
[20:37:02] <mhaberler> You'd want to discuss this with Seb too, and I am sure he can clear up the situation for you
[20:37:15] <mhaberler> yes you are mistaken
[20:37:34] <cradek> I did yesterday, and he didn't yet know how it will work
[20:37:36] <mhaberler> but we do need a buildbot VM which can do runtests
[20:38:08] <mhaberler> that's one for Xenomai and one for RT-PREEMPT
[20:38:10] <cradek> yeah the buildbot does need to do it, afaic. that's a luxury I will no longer happily do without
[20:38:22] <mhaberler> before that it's a bit academic
[20:38:34] <mhaberler> otherwise: no runtests
[20:39:04] <mhaberler> I mean we can do that on any public build infrastructure, there are many options - I think the runtests step is valuable though
[20:40:01] -!- jp__ has quit [Ping timeout: 245 seconds]
[20:40:10] <mhaberler> and that is very specific because of the RT OS
[20:45:28] <cradek> cmorley1: I'm getting ready to release 2.5.2. is pncconf on v2.5_branch stable right now?
[20:45:49] <cradek> cmorley1: (that's the only part I don't have any feel for)
[20:46:35] -!- jp__ has quit [Ping timeout: 252 seconds]
[20:49:14] -!- Wildhoney has quit [Client Quit]
[20:50:16] <JT-Shop> is the MAX_LINEAR_VELOCITY in [DISPLAY] a bug?
[20:50:31] <JT-Shop> I think that is in some sample configs
[20:51:01] <cradek> checking
[20:52:51] -!- zzolo has quit [Quit: zzolo]
[20:53:02] <JT-Shop> I see it duplicated in both [TRAJ] and [DISPLAY] in axis.ini
[20:53:57] <cradek> for one purpose it will look for it in DISPLAY and then TRAJ, for another purpose it must be in TRAJ. I think that is the bug
[20:54:34] <JT-Shop> ouch
[20:55:12] <cradek> I can fix
[20:55:26] <cradek> thanks for reminding me about jensor's problem
[20:55:33] <JT-Shop> ok, thanks I'm just heading out in a bit and won't be here tomorrow
[21:02:49] <KGB-linuxcnc> 03chris 05v2.5_branch 80db1ea 06emc2 10src/emc/usr_intf/axis/scripts/axis.py * Fix the top of the maxvel slider being too low
[21:05:55] -!- pikeaero has quit [Remote host closed the connection]
[21:06:32] -!- zzolo has quit [Read error: Connection reset by peer]
[21:06:33] zzolo_ is now known as zzolo
[21:10:00] -!- pikeaero has quit [Read error: Connection reset by peer]
[21:13:24] -!- tronwizard has quit [Ping timeout: 264 seconds]
[21:22:07] -!- Keknom has quit [Quit: Leaving.]
[21:24:33] -!- morfic- has quit [Remote host closed the connection]
[21:25:00] <cradek> well, tried precise i386 desktop on three machines and it boots and runs on exactly zero of them. one says I should use a different kernel, one boots and asks whether I want low video mode and then hangs, the third just says Boot Error and hangs
[21:25:35] <cradek> I did not even bother to try the venerable dual-P3
[21:29:52] <cradek> (all four run lucid great)
[21:32:02] -!- adb [adb!~IonMoldom@178.211.237.94] has joined #linuxcnc-devel
[21:41:11] -!- hdokes has quit [Ping timeout: 255 seconds]
[21:48:58] -!- ler_hydra has quit [Remote host closed the connection]
[21:50:31] -!- zzolo has quit [Quit: zzolo]
[22:05:29] -!- DJ9DJ has quit [Quit: bye]
[22:06:42] -!- Loetmichel has quit [Ping timeout: 256 seconds]
[22:13:01] -!- micges has quit [Quit: Leaving]
[22:27:21] <KimK> Along these lines of thought, any suggestions on what is (now) a good motherboard/chipset/etc ? Is the Atom D525 two-core still a good choice, or is there something better? (Although it now must be mfgd by people other than Intel though, since Intel seems to be getting out of them)
[22:28:52] <KimK> Any and all advice appreciated. And I don't mind spending a little more to get a sufficiently zippy system for menu pull-downs, etc, I hate it when that stuff drags. And I want to try at least a two-core system this time, so I can try isolcpus=1 (or more?)
[22:29:12] <cradek> see emc-users, some good results have been shared lately
[22:30:01] <KimK> OK, thanks, looking
[22:30:16] <KimK> (I'm way behind on the lists)
[22:43:42] <cmorley1> cradek: Yes I got the last major pncconf bug I know of. Thanks for asking.
[23:04:37] <andypugh> Precise boots happily on my VM with the RTAI kernel. Which I guess is good.
[23:04:55] <andypugh> Where do the latency tests live?
[23:05:02] -!- odogono has quit [Quit: odogono]
[23:24:25] -!- mhaberler has quit [Quit: mhaberler]
[23:29:56] -!- The_Ball has quit [Ping timeout: 248 seconds]
[23:32:49] <cradek> cmorley1: excellent
[23:45:19] -!- _ink has quit [Ping timeout: 256 seconds]
[23:46:15] -!- ve7it [ve7it!~LawrenceG@S01060014d19d0b68.pk.shawcable.net] has joined #linuxcnc-devel
[23:48:19] <KGB-linuxcnc> 03chrisinnanaimo 05master 72ad6d4 06emc2 10lib/python/gladevcp/offsetpage_widget.py * gladevcp -fix tooledit widget offest editing error with lathes
[23:54:40] -!- pcw_home has quit [Remote host closed the connection]