Back
[00:04:04] -!- sumpfralle has quit [Ping timeout: 272 seconds]
[00:04:05] -!- logger[mah] has quit [Remote host closed the connection]
[00:04:12] -!- logger[mah] [logger[mah]!~loggermah@ns1.mah.priv.at] has joined #linuxcnc-devel
[00:11:53] -!- zzolo has quit [Quit: zzolo]
[00:14:15] -!- andypugh_ [andypugh_!~andy2@cpc16-basl9-2-0-cust685.20-1.cable.virginmedia.com] has joined #linuxcnc-devel
[00:15:31] -!- andypugh has quit [Ping timeout: 248 seconds]
[00:15:32] andypugh_ is now known as andypugh
[00:37:11] -!- logger[psha] [logger[psha]!~loggerpsh@195.135.238.205] has joined #linuxcnc-devel
[00:52:26] -!- rob_h has quit [Ping timeout: 255 seconds]
[00:55:20] -!- Nick001-Shop has quit [Remote host closed the connection]
[01:00:04] -!- JBFromOZ has quit [Ping timeout: 248 seconds]
[01:27:08] cevad is now known as davec
[01:38:26] -!- ve7it [ve7it!~LawrenceG@S01060014d19d0b68.pk.shawcable.net] has joined #linuxcnc-devel
[01:44:21] -!- plushy has quit [Quit: Leaving.]
[01:51:09] -!- JT-Shop-2 [JT-Shop-2!~John@184-63-140-99.cust.wildblue.net] has joined #linuxcnc-devel
[01:51:10] -!- JT-Shop has quit [Read error: Connection reset by peer]
[01:59:11] -!- kwallace1 [kwallace1!~kwallace@smb-144.sonnet.com] has joined #linuxcnc-devel
[02:01:14] -!- kwallace has quit [Ping timeout: 240 seconds]
[02:08:56] -!- mhaberler has quit [Quit: mhaberler]
[02:27:20] -!- joe9 has quit [Read error: Connection reset by peer]
[02:45:24] -!- sumpfralle has quit [Ping timeout: 276 seconds]
[02:48:15] -!- ink has quit [Disconnected by services]
[03:16:51] -!- pfred1 has quit [Quit: ..]
[03:26:13] Guest55760 is now known as abetusk
[03:48:27] -!- dgarr [dgarr!~dgarrett@97-117-216-246.phnx.qwest.net] has parted #linuxcnc-devel
[03:56:36] BTCOxygen is now known as a1111-afk
[03:56:41] -!- zzolo has quit [Quit: zzolo]
[03:57:37] -!- tlab has quit [Quit: Leaving]
[03:59:56] -!- Keknom has quit [Quit: Leaving.]
[04:07:31] -!- pcw_home has quit [Ping timeout: 245 seconds]
[04:10:21] -!- zzolo has quit [Client Quit]
[04:21:15] -!- pcw_home [pcw_home!~chatzilla@ip-66-80-167-54.sjc.megapath.net] has joined #linuxcnc-devel
[04:55:10] -!- yuvipanda has quit [Quit: yuvipanda]
[04:56:04] -!- zzolo has quit [Quit: zzolo]
[04:56:57] -!- vladimirek [vladimirek!~vladimire@95.105.250.72] has joined #linuxcnc-devel
[05:27:49] -!- asdfasd has quit [Ping timeout: 265 seconds]
[05:38:40] -!- Valen has quit [Quit: Leaving.]
[05:48:29] -!- logger[psha] [logger[psha]!~loggerpsh@195.135.238.205] has joined #linuxcnc-devel
[05:54:09] -!- kwallace1 [kwallace1!~kwallace@smb-144.sonnet.com] has parted #linuxcnc-devel
[06:28:24] -!- ve7it has quit [Remote host closed the connection]
[06:37:28] <zultron> Hey skunkworks, I'm John Morris whom mhaberler pointed you to. What's the issue with your 64-bit kernel?
[06:41:11] -!- capricorn_1 has quit [Ping timeout: 252 seconds]
[06:52:33] -!- FinboySlick has quit [Quit: Leaving.]
[07:07:34] -!- mhaberler [mhaberler!~mhaberler@extern-183.stiwoll.mah.priv.at] has joined #linuxcnc-devel
[07:10:44] -!- psyhitus has quit [Ping timeout: 248 seconds]
[07:12:52] -!- psyhitus|2 has quit [Ping timeout: 248 seconds]
[07:15:34] -!- pingufan has quit [Quit: Konversation terminated!]
[07:17:47] -!- AR_ has quit [Ping timeout: 255 seconds]
[07:20:21] -!- psyhitus|3 has quit [Ping timeout: 248 seconds]
[07:23:11] -!- yuvipanda has quit [Quit: yuvipanda]
[07:50:40] -!- archivist_herron has quit [Read error: Operation timed out]
[07:57:08] -!- psyhitus has quit [Read error: Connection timed out]
[08:08:10] -!- tayy has quit [Remote host closed the connection]
[08:08:27] Cylly is now known as Loetmichel
[08:08:34] -!- cncbasher has quit [Ping timeout: 272 seconds]
[08:31:38] -!- racycle has quit [Quit: racycle]
[08:52:21] -!- cncbasher [cncbasher!~quassel@cpc15-hart9-2-0-cust101.11-3.cable.virginmedia.com] has joined #linuxcnc-devel
[09:01:24] -!- psyhitus has quit [Read error: Connection timed out]
[09:02:30] -!- psyhitus has quit [Max SendQ exceeded]
[09:02:57] -!- tjb1 has quit [Ping timeout: 245 seconds]
[09:03:26] -!- psyhitus has quit [Max SendQ exceeded]
[09:04:20] -!- psyhitus has quit [Max SendQ exceeded]
[09:05:16] -!- psyhitus has quit [Max SendQ exceeded]
[09:06:11] -!- psyhitus has quit [Max SendQ exceeded]
[09:08:41] -!- psyhitus has quit [Max SendQ exceeded]
[09:08:42] -!- psyhitus has quit [Max SendQ exceeded]
[09:08:58] -!- psyhitus has quit [Max SendQ exceeded]
[09:09:56] -!- psyhitus has quit [Max SendQ exceeded]
[09:10:49] -!- psyhitus has quit [Max SendQ exceeded]
[09:11:45] -!- psyhitus has quit [Max SendQ exceeded]
[09:12:48] -!- psyhitus has quit [Max SendQ exceeded]
[09:14:32] -!- psyhitus has quit [Max SendQ exceeded]
[09:14:34] -!- psyhitus has quit [Max SendQ exceeded]
[09:15:27] -!- psyhitus has quit [Max SendQ exceeded]
[09:19:13] -!- cncbasher has quit [Remote host closed the connection]
[09:42:45] -!- psyhitus has quit [Ping timeout: 248 seconds]
[09:50:57] theos is now known as Guest31021
[09:54:14] -!- Guest31021 has quit [Ping timeout: 255 seconds]
[10:23:49] -!- mhaberler has quit [Quit: mhaberler]
[10:27:25] -!- mhaberler [mhaberler!~mhaberler@macbook.stiwoll.mah.priv.at] has joined #linuxcnc-devel
[10:36:01] -!- rob_h [rob_h!~rob_h@5e047584.bb.sky.com] has joined #linuxcnc-devel
[10:43:02] -!- yuvipanda_ has quit [Quit: yuvipanda_]
[10:45:46] -!- cncbasher [cncbasher!~quassel@cpc15-hart9-2-0-cust101.11-3.cable.virginmedia.com] has joined #linuxcnc-devel
[10:46:54] -!- pjm__ has quit [Ping timeout: 252 seconds]
[11:26:19] -!- logger[psha] [logger[psha]!~loggerpsh@195.135.238.205] has joined #linuxcnc-devel
[11:54:28] -!- mackerski has quit [Quit: mackerski]
[12:03:02] -!- yuvipanda_ has quit [Client Quit]
[12:08:57] <skunkworks> zultron: It wan't 64bit. I was running ubuntu 12.04 32 with mhaberler 's Xenomai realtime.
[12:09:27] <skunkworks> the couple of motherboards I have tried so far are amd and latencies in the 100us range or more.
[12:09:55] <skunkworks> (one athlon 64 motherboard would not boot)
[12:10:00] <skunkworks> biab
[12:12:38] -!- skunkworks has quit [Remote host closed the connection]
[12:23:46] -!- yuvipanda_ has quit [Client Quit]
[12:32:48] -!- mk0 has quit [Quit: Leaving]
[12:51:01] -!- skunkworks [skunkworks!~skunkwork@68-115-41-210.static.eucl.wi.charter.com] has joined #linuxcnc-devel
[12:51:25] <skunkworks> logger[mah],
[12:51:25] <logger[mah]> skunkworks: Log stored at
http://linuxcnc.mah.priv.at/irc/%23linuxcnc-devel/2013-01-03.html
[13:02:44] -!- tjb1 has quit [Quit: tjb1]
[13:02:52] -!- Valen has quit [Quit: Leaving.]
[13:26:02] -!- adb [adb!~IonMoldom@178.211.237.94] has joined #linuxcnc-devel
[13:28:25] -!- syyl__ has quit [Ping timeout: 240 seconds]
[13:34:22] -!- fatpandas has quit [Quit: leaving]
[13:56:06] -!- DJ9DJ has quit [Quit: bye]
[14:04:25] -!- FinboySlick has quit [Quit: Leaving.]
[14:20:49] -!- cmorley [cmorley!~chris@S010600c09fc019c2.no.shawcable.net] has joined #linuxcnc-devel
[14:23:12] -!- cmorley1 has quit [Ping timeout: 255 seconds]
[14:31:47] -!- yuvipanda_ has quit [Ping timeout: 252 seconds]
[14:35:51] JT-Shop-2 is now known as JT-Shop
[14:54:45] <skunkworks> ok - so I have installed on 2 amd and 2 intel machines. The latest one is an older dual core atom. Following these directions
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?NewRTInstall
[14:56:07] <skunkworks> None of them have had stable latencies. the atom which has decent latencies with rtai (<15us) is shooting to 100us with Xenomai.
[14:56:07] <skunkworks>
[14:56:36] <skunkworks> I did disable hyperthreading and legacy usb on the atom also.
[14:57:38] <skunkworks> So either I am doing something wrong or the kernel still needs a bit of tweeking.
[14:58:10] <skunkworks> How hard is it to change the config with the debs I downloaded? (I have never done this before)
[15:00:52] -!- yuvipanda__ has quit [Ping timeout: 272 seconds]
[15:02:08] -!- yuvipanda_ has quit [Ping timeout: 272 seconds]
[15:09:54] -!- automata_ has quit [Ping timeout: 240 seconds]
[15:11:03] <seb_kuzminsky> skunkworks: probably pretty easy
[15:11:24] <seb_kuzminsky> clone the git repo that the kernel lives in, create a branch for your tweaks, and tweak away
[15:14:09] <seb_kuzminsky> i know one of mhaberler's goals was to manage the realtime kernels a little more closely than our 2.6.32 rtai kernel was, so you rebuilding it will be a valuable test of that
[15:20:52] -!- yuvipanda___ has quit [Ping timeout: 265 seconds]
[15:55:58] <skunkworks> seb_kuzminsky, that may be above my pay grade...
[16:03:18] abetusk is now known as Guest88203
[16:03:18] -!- Guest88203 has quit [Killed (moorcock.freenode.net (Nickname regained by services))]
[16:04:31] <pcw_home> skunkworks: did you try lowering the base thread rate?
[16:04:33] <pcw_home> (I'm wondering if the jitter is even meaningful if its ever greater that the thread rate)
[16:04:42] <pcw_home> than the
[16:15:15] -!- djinni` has quit [Ping timeout: 260 seconds]
[16:15:43] -!- mozmck has quit [Quit: Leaving.]
[16:17:39] -!- mozmck [mozmck!~moses@client-204.235.45.161.wcfltx.partnershipbroadband.com] has joined #linuxcnc-devel
[16:25:28] -!- kb8wmc [kb8wmc!~chatzilla@nat.mtp.cmsinter.net] has joined #linuxcnc-devel
[16:26:02] -!- kwallace [kwallace!~kwallace@tmb-221.sonnet.com] has joined #linuxcnc-devel
[16:30:15] -!- kb8wmc has quit [Read error: Connection reset by peer]
[16:30:46] -!- kb8wmc [kb8wmc!~chatzilla@nat.mtp.cmsinter.net] has joined #linuxcnc-devel
[16:33:48] -!- a1111-afk has quit [Ping timeout: 264 seconds]
[16:37:31] -!- Simon4 has quit [Quit: Leaving.]
[16:43:38] <L84Supper> we will try the new xenomai branch on an AMD later this week for comparison, memleak did the RTAI and kernel work here
[16:44:20] <L84Supper> he's back later today
[16:44:59] -!- sumpfralle has quit [Read error: Operation timed out]
[17:10:49] -!- gambakufu has quit [Ping timeout: 244 seconds]
[17:12:23] -!- riz_ [riz_!457c0137@gateway/web/freenode/ip.69.124.1.55] has joined #linuxcnc-devel
[17:12:28] -!- Holgi has quit [Ping timeout: 244 seconds]
[17:15:24] <riz_> In pid.c I see that the pointer to the array of hal_pid_t structs (i.e. pid_array) is statically defined. Why arent these PID structs dynamically allocated so that they do not lose their values between calls?
[17:16:26] <riz_> Is PID retaining any information each time the thread is executed?
[17:17:15] <jepler> it sounds like you have a misconception about the meaning of the 'static' keyword
[17:18:09] <riz_> i believe you are correct
[17:18:35] <jepler> in C, the 'static' keyword at file scope means that the scope of the identifier is limited to that source file.
[17:19:47] <jepler> but the duration of the storage is from the time the component is loaded until it is unloaded
[17:19:48] <riz_> so the purpose of using static was so you can only access the pid structs from that source file alone
[17:22:19] <riz_> Is this just done as a security so that nothing outside of pid.c accesses the structure?
[17:23:39] <jepler> yes.
[17:25:49] <riz_> So is the dynamic memory allocation done after the pins are exported and stored in some dynamically allocated memory from a function similar to malloc?
[17:26:43] <riz_> For the PID struct that is..
[17:28:45] <jepler> sorry, I don't follow the question.
[17:30:23] -!- mackerski has quit [Quit: mackerski]
[17:34:40] <riz_> I was just wondering how the memory is allocated for the PID struct
[17:36:50] <riz_> Is there a dynamic allocation of memory (on the heap using some memory allocation like malloc or kmalloc) in some other file where it is stored persistently or is it just on the stack with the declaration of the aray of structs in the pid.c file
[17:44:12] -!- motioncontrol has quit [Remote host closed the connection]
[17:45:42] <jepler> the dynamic loader (e.g., insmod or dlopen depending) ensures that the storage is allocated at the time the component is loaded. I am not familiar with the details
[17:45:54] <jepler> you won't find a line that 'mallocs' that file-level static
[17:45:56] -!- odogono has quit [Ping timeout: 252 seconds]
[17:48:19] <riz_> oh ok
[17:49:35] -!- James628 has quit [Quit: Page closed]
[17:50:47] <riz_> I asumed that it was done in hal_lib.c with rtapi_shmem_new()
[17:53:54] <jthornton> is R a copy and paste error for G10 L10?
http://linuxcnc.org/docs/html/gcode/gcode.html#_g10_l10_set_tool_table_a_id_sec_g10_l10_a
[18:02:04] <cradek> yes, R makes no sense for L10 and L11
[18:02:07] <jepler> jthornton: it looks like in G10 L10 and G10 L11 R gives the tool radius
[18:02:12] <cradek> did you verify it gives an error?
[18:02:16] <jepler> if(block->r_flag) settings->tool_table[pocket].diameter = PROGRAM_TO_USER_LEN(block->r_number) * 2.;
[18:02:26] -!- sumpfralle has quit [Ping timeout: 252 seconds]
[18:02:41] <cradek> I'd expect R to work (as radius) with L1 only, but I didn't check
[18:02:54] <JT-Shop> the text says rotation and I'm sure that is wrong
[18:03:05] <cradek> and R as rotation with L2 but not L20
[18:03:18] <cradek> I agree with that much - just trying to figure out what is right
[18:03:18] <JT-Shop> yea, a copy and paste error I'm sure
[18:03:52] <jepler> L1 / L10 / L11 calls convert_setup_tool which seems to always use R as radius
[18:04:31] <JT-Shop> thanks
[18:08:42] -!- micges [micges!~micges@83.23.240.188] has joined #linuxcnc-devel
[18:11:37] -!- kwallace [kwallace!~kwallace@tmb-221.sonnet.com] has parted #linuxcnc-devel
[18:24:08] -!- ve7it [ve7it!~LawrenceG@S01060014d19d0b68.pk.shawcable.net] has joined #linuxcnc-devel
[18:24:44] -!- sumpfralle has quit [Ping timeout: 260 seconds]
[18:26:34] -!- sumpfralle1 has quit [Ping timeout: 240 seconds]
[18:36:38] -!- Connor has quit [Ping timeout: 255 seconds]
[18:36:50] -!- theos has quit [Ping timeout: 272 seconds]
[18:45:44] -!- kb8wmc_ [kb8wmc_!~chatzilla@64.25.194.29] has joined #linuxcnc-devel
[18:48:02] -!- motioncontrol has quit [Quit: Sto andando via]
[18:48:24] -!- kb8wmc has quit [Ping timeout: 240 seconds]
[18:48:38] kb8wmc_ is now known as kb8wmc
[18:49:57] <zultron> skunkworks, let me check what I've got. Do you mean your AMD mobos are some 32-bit, one 64-bit, but in all cases you're running 32-bit ubuntu?
[18:50:12] <skunkworks> yes
[18:51:22] <zultron> Ok. Also, reading more backlog, I think I can provide you simple instructions for modifying and rebuilding the ubuntu kernel pkgs.
[18:52:09] <skunkworks> That would be cool - I would not mind playing on my off time
[18:52:41] <zultron> I have a lot of infrastructure in RH-like distros, so there's a huge switching cost for me, but when I found how easy it is to build custom deb kernels I couldn't help being tempted to switch. :)
[18:54:56] <cncbasher> i'd be interested too
[18:57:13] <zultron> cncbasher: interested in what? A kernel config, kernel packaging instructions, or just a kernel package?
[18:58:04] <skunkworks> zultron, I also installed 12.03 - 32 on a couple of intel boards and the latency was in the 100k
[18:58:46] -!- cmorley1 [cmorley1!~chris@S010600c09fc019c2.no.shawcable.net] has joined #linuxcnc-devel
[18:58:47] <cncbasher> just about all three ...
[18:59:35] <cncbasher> i'd like to get xemomai into something like ' dam small linux etc
[19:00:04] <cncbasher> a real cut down bare bones kernel
[19:00:20] <cncbasher> with only whats needed for linuxcnc etc
[19:00:41] <zultron> Ha ha, all three! Ok, it's been a few weeks since I did it. I'll let y'all know when I've retraced my steps.
[19:00:42] -!- cmorley has quit [Ping timeout: 264 seconds]
[19:00:50] <cncbasher> so i can realy customise it
[19:01:15] <zultron> Yep, I'm with ya, that's my interest too.
[19:02:58] <KGB-linuxcnc> 03jthornton 05v2.5_branch 9c912e0 06emc2 10docs/src/gcode/gcode.txt * Docs: fix copy and paste error
[19:13:32] -!- IchGuckLive has quit [Quit: ChatZilla 0.9.87 [Firefox 17.0.1/20121129170341]]
[19:30:35] <mhaberler> cradek: time to discuss a gcode issue? remember we cooked up '(abort, foo)' a while ago
[19:30:44] <mhaberler> I think it should be a queue buster
[19:31:02] <mhaberler> but just before the abort
[19:31:18] <mhaberler> see this thread:
http://www.linuxcnc.org/index.php/english/forum/10-advanced-configuration/25994-abort-msg-in-o-sub?start=12#28354
[19:31:47] <mhaberler> he faked the queuebuster with an M6x pin read and got it to work
[19:35:09] <mhaberler> actually I found the Delta Tau Gcode interpreter has an explicit queue-buster G-code which basically says 'dont lookahead/parse beyond here until you get here'
[19:36:17] <mhaberler> it is a tad esoteric, but there is some logic to it - it would also make a lot of sense in the context of Drogge's parameter access patch
[19:40:29] -!- rob__H [rob__H!~rob_h@5e086765.bb.sky.com] has joined #linuxcnc-devel
[19:42:37] -!- riz_ has quit [Quit: Page closed]
[19:43:48] -!- rob_h has quit [Ping timeout: 248 seconds]
[19:51:31] <mhaberler> cradek: see 'G103 Lookahead Mode', page 152, this document:
http://www.deltatau.com/manuals/pdfs/PMAC-NC%20PRO2.pdf?id=634701792253582640
[19:52:25] -!- motioncontrol has quit [Quit: Sto andando via]
[19:55:05] -!- zzolo has quit [Quit: zzolo]
[20:02:36] -!- cncbasher has quit [Read error: Connection reset by peer]
[20:11:54] -!- cncbasher [cncbasher!~quassel@cpc15-hart9-2-0-cust101.11-3.cable.virginmedia.com] has joined #linuxcnc-devel
[20:15:51] -!- riz_ [riz_!457c0137@gateway/web/freenode/ip.69.124.1.55] has joined #linuxcnc-devel
[20:16:24] -!- vladimirek has quit [Remote host closed the connection]
[20:16:37] <riz_> Is there a program that simulates a motor that can be used for testing linuxcnc?
[20:17:04] <cradek> there is a sim configuration that simulates closed loop servo operation
[20:17:04] <seb_kuzminsky> stepper motors don't need any simulating, since they don't produce any signals back to linuxcnc
[20:17:56] <riz_> Oh that is why I see all that "#ifdef SIM" stuff?
[20:18:32] <jepler> What is it about a motor you want to simulate?
[20:18:37] <riz_> I am trying to mess around with the PID function and I just wanted something that would simulat a servo motor
[20:18:40] <cradek> no
[20:18:46] <seb_kuzminsky> riz_: no, the SIM #define is totally different
[20:18:52] <cradek> yes in that case see the servo-sim config
[20:19:39] <riz_> Ok, I will check it out. I just want a function that will accept a command velocity and return a position feedback
[20:19:58] <riz_> So what is the SIM stuff for?
[20:20:52] <jepler> SIM is defined when compiling linuxcnc without support for realtime or hardware control; it means you can run it without a special kernel and without special permissions
[20:21:00] <cradek> well there is an integ component if that's all you want
[20:21:01] <zultron> riz_, which repo/branch are you working from?
[20:21:28] <cradek> but I think servo-sim emulates some of the characteristics of actual motors. have a look at the hal file.
[20:21:51] <riz_> I will definitely look at that hal file, thanks
[20:21:57] <jepler> anyway, servo-sim has PID, has a simple simulation of motor "inertia" and encoder feedback.
[20:22:29] <riz_> I'm not too familiar with the repo/branch stuff. I know I pulled the latest version from git
[20:23:42] -!- cncbasher has quit [Remote host closed the connection]
[20:24:14] <jepler> The configuration file is apparently called configs/sim/tklinuxcnc/servo_sim.ini
[20:24:38] <jepler> there may also be a leftover servo_sim.hal file (not used) in configs/sim
[20:26:05] <riz_> ok cool
[20:26:25] -!- KimK has quit [Ping timeout: 246 seconds]
[20:28:16] -!- KimK [KimK!~Kim__@wsip-184-176-200-171.ks.ks.cox.net] has joined #linuxcnc-devel
[20:29:02] <jepler> for instance, here I visualize a short rapid move (starting at y = -0.01, g0 y.01):
http://emergent.unpythonic.net/files/sandbox/servo_sim.png
[20:29:18] <jepler> you can see that the feedback position is (A) quantized and (B) lags the command by a small amount
[20:30:08] <riz_> oh i see
[20:30:26] <riz_> you just used an integrator or was that the sim file?
[20:30:56] <jepler> that's the sim file
[20:31:15] <mhaberler> cradek: time to discuss this (pls read back=?
[20:31:23] <jepler> Here, I made the tuning bad (by setting lowpass.1.gain 0.01, to give a greater effective inertia to the motor, without re-tuning pid):
http://emergent.unpythonic.net/files/sandbox/servo_sim_detuned.png
[20:31:51] <riz_> oh nice
[20:31:53] <jepler> as a result, I got very poor following at acceleration, and then overshoot at deceleration
[20:32:16] -!- cncbasher [cncbasher!~quassel@cpc15-hart9-2-0-cust101.11-3.cable.virginmedia.com] has joined #linuxcnc-devel
[20:33:15] <riz_> While looking into pid_calc() I noticed pid->index_enable. I am not quite sure what that is. Can anyone explain?
[20:33:47] <jepler> The manual page for pid explains the use of this pin
[20:34:13] <riz_> I am also seeing that it has something to do with a problem with homing from what i read
[20:35:23] <cradek> mhaberler: in general we don't want comments to bust queue, but magic comments probably should
[20:35:27] <jepler> (documentation here:
http://linuxcnc.org/docs/html/man/man9/pid.9.html)
[20:35:40] <cradek> mhaberler: so that's the fix I propose, not adding a gcode as a workaround
[20:36:20] <cradek> (if I understand the question)
[20:36:48] <mhaberler> well the way it was done it has unintended side effects - it jumps the queue
[20:37:41] <mhaberler> not sure if changing that ex-post being wiser is a great idea
[20:39:10] <mhaberler> I would think the stop lookahead code is a better solution, because it also allows synchronizing params for instance, and it wont change current semantics ; I dont think many people use it though
[20:39:31] <mhaberler> just making abort a queue buster doesnt allow that
[20:39:44] <mhaberler> it is trivial to do with a remap - 5 lines
[20:39:53] <riz_> I read the manual, but I am still not clear as to what it is really saying about index_enable. Sorry for the ignorance haha
[20:40:16] <mhaberler> I think the best course of action is:
[20:40:23] <mhaberler> document behabvior
[20:40:43] <mhaberler> add an example stop lookahead remap code in master examples
[20:40:50] <mhaberler> refer to it from the manual
[20:41:41] <mhaberler> that would have prevented the trap h_muktell fell into
[20:42:13] <jepler> riz_: when you home to index, there can be a large step change in the encoder feedback (maybe 100s of mm in 1ms even on a small machine) at the moment the index pulse is encountered
[20:42:47] <jepler> riz_: a step in command of 100m/s makes even a small ff2 term contribute a large amount to the pid output
[20:43:00] <jepler> this results in a big audible 'thunk'
[20:43:19] <jepler> when all the index-enable pins are hooked together properly, that glitch is avoided by not updating the ff2 term for 1ms
[20:43:43] <jepler> (or whatever the servo period is)
[20:44:46] <riz_> So, what causes the large step change? Is it because of something is uninitialized before homing?
[20:44:46] -!- sumpfralle2 has quit [Ping timeout: 272 seconds]
[20:44:54] <riz_> I know I am vague and incoherent
[20:45:01] <riz_> not really sure what I am trying to ask
[20:45:22] <jepler> well suppose you home to a switch at the far end of X travel, but power off the machine at the middle of X travel
[20:45:32] <jepler> homing goes out to the far end until it finds the switch
[20:45:48] <jepler> then, in the case of index homing, continues (or reverses) until it encounters the next index pulse on the encoder
[20:46:10] <riz_> right
[20:46:17] <jepler> so your encoder had counted to +100mm (say) at the time it encountered the index pulse
[20:46:31] <jepler> at that moment it changes the feedback from +100mm to 0mm
[20:46:37] <jepler> and it also changes the index-enable value from 1 to 0
[20:46:52] -!- Holgi has quit [Quit: Bye]
[20:46:52] -!- sumpfralle has quit [Ping timeout: 244 seconds]
[20:46:59] <jepler> that's where the big step change in position comes from, the reset from <any value> to 0 at encoder index
[20:48:14] -!- sumpfralle1 has quit [Ping timeout: 260 seconds]
[20:48:27] <riz_> oh ok. I think I understand it better. Thanks for the thorough explanation!
[20:48:38] <jepler> and of course 100mm is a small machine; now imagine that it's 1000mm or 10000mm!
[20:48:55] <riz_> right
[20:50:13] -!- dhoovie has quit [Ping timeout: 246 seconds]
[20:56:18] -!- sumpfralle has quit [Client Quit]
[20:56:45] -!- holst has quit [Quit: Leaving]
[20:58:00] -!- sumpfralle has quit [Client Quit]
[21:01:08] -!- sumpfralle1 has quit [Ping timeout: 255 seconds]
[21:07:44] -!- riz_ has quit [Quit: Page closed]
[21:07:53] -!- sumpfralle has quit [Ping timeout: 255 seconds]
[21:07:54] -!- bpuk [bpuk!~ben@boopotter.plus.com] has joined #linuxcnc-devel
[21:20:58] <KGB-linuxcnc> 03git 05master d50d514 06emc2 10configs/ 10(6 files in 3 dirs) * stop-lookhead: demo G-code which stops interpreter lookahead
[21:26:35] -!- PCW [PCW!~chatzilla@99.88.10.65] has joined #linuxcnc-devel
[21:31:35] -!- Loetmichel has quit [Ping timeout: 265 seconds]
[21:48:04] -!- odogono has quit [Quit: odogono]
[21:51:16] -!- djdelorie has quit [Quit: Leaving]
[21:58:42] -!- DJ9DJ has quit [Quit: bye]
[22:01:05] -!- memleak [memleak!~memleak@unaffiliated/memleak] has joined #linuxcnc-devel
[22:01:11] <memleak> Hello!
[22:01:31] -!- bpuk has quit []
[22:02:59] <seb_kuzminsky> hi memleak
[22:03:02] <L84Supper> mhaberler: memleak is here to help compile kernels + rtai or xenomai
[22:03:24] <mhaberler> whohoo!
[22:03:38] <mhaberler> hi memleak!
[22:04:59] <L84Supper> memleak posted those RTAI from scratch howtos for Arch and gentoo
[22:05:11] <mhaberler> ah!
[22:05:16] <mhaberler> on the wiki
[22:05:25] <L84Supper> yeah as NTU
[22:05:29] <memleak> my google code page
[22:05:47] <mhaberler> where?
[22:06:31] <memleak> http://code.google.com/p/neo-technical/wiki/emc2arch Outdated as I no longer run Arch
[22:06:32] -!- FinboySlick has quit [Quit: Leaving.]
[22:07:17] <mhaberler> link saved, we can tal now ;)
[22:08:22] <memleak> I have a wiki in the works though for gentoo, it'll be public once I get 3.X kernels going. 2.6 is a stick in the mud IMO.
[22:08:33] <mhaberler> anyway. I did a pedestrian xenomai/3.2.21 kernel which seems to have issues on some AMD's
[22:08:49] <mhaberler> John aka zultron is looking into it too I think
[22:09:06] <memleak> That's what I'm going to try and get working on my AMD board. Compiling kernels is my favorite cup of tea :)
[22:09:32] <mhaberler> for some it works great like here like cncbasher's results: imagebin.org/241580
[22:09:40] <memleak> 3.5.3 is what I'm shooting for.
[22:09:46] <zultron> Hi memleak, which distro will you be building for?
[22:09:55] <mhaberler> ah, so you're tracking the xenomai list
[22:10:15] <memleak> gentoo but I'll be making the wiki page as universal and distro-independant as possible.
[22:10:25] <L84Supper> zultron: we are using Gentoo
[22:10:44] <mhaberler> that's the src I'm building off, configs and readme under linuxcnc in this repo
[22:10:55] <memleak> I'm not writing a gazillion ebuilds to get xenomai working, maybe after I figure it out well enough to automate it.
[22:11:15] <mhaberler> I would guess PAE is missing to make skunkworks happy
[22:11:21] <memleak> and make it "gentoo friendly" but for now it's getting it going.
[22:11:29] <zultron> I see. I'm mostly interested in writing kernel packages for use with LCNC. I have some for RHEL6 and enough done that deb won't be hard.
[22:11:53] <mhaberler> then there's one buildbot requirment - seb_kuzminsky - around?
[22:12:00] <skunkworks> PAE?
[22:12:02] <mhaberler> he needs the virtio drivers
[22:12:25] <mhaberler> dont ask me, some hw vendor voodoo ;)
[22:12:31] <zultron> Still haven't figured out exactly how deb packages are reproduced from scratch though....
[22:13:37] <zultron> Isn't PAE just for 32-bit hosts with more than 4GB RAM? I've never needed one of those. :)
[22:13:50] <mhaberler> the thing where I'm losing the plot is version numbering and how things are inserted into a package stream - I dont even know who inserts a kernel package on linuxcnc.org and where
[22:14:20] <mhaberler> skunkworks: any chance you get us a copy of the crash message?
[22:15:02] <skunkworks> for the amd that didn't boot?
[22:15:05] <mhaberler> maybe even a photo of the screen is better than nothing
[22:15:07] <mhaberler> right
[22:15:21] <skunkworks> sure - give me a few minutes
[22:15:36] <mhaberler> ah! forensics
[22:15:52] -!- syyl has quit [Ping timeout: 255 seconds]
[22:16:23] <zultron> mhaberler, what's the concern about version numbering?
[22:16:32] -!- pjm has quit [Ping timeout: 252 seconds]
[22:17:21] <mhaberler> update sequencing, I guess - I never looked into what gets into a debian/ubuntu package pathname
[22:18:59] <mhaberler> assume we build a xenomai kernel and put it into the linuxcnc dists dir - who gets it and when (asked, automatic..)
[22:19:53] <mhaberler> as for rt-preempt - do we have acceptable external packages which can be used?
[22:20:16] <mhaberler> zultron: did I get this right you fixed the module versioning issue?
[22:20:39] <zultron> I'm not familiar with deb. For RH-like distros, I build a package 'linuxcnc-xeno_user'. That has a requirement for a package called 'kernel-xenomai'.
[22:21:18] <zultron> I build with module versioning on, yes, no problems in either kernel-mode thread system.
[22:21:26] <mhaberler> great
[22:22:13] <zultron> The problem with that is for each new kernel version, you need a new, matching linuxcnc package build.
[22:22:34] <mhaberler> really only with the kernel thread styles
[22:22:34] <zultron> It's not really a problem, though, once you put the infra in place to automate that.
[22:22:46] <zultron> Yeah, only with kernel-mode threads.
[22:22:49] <mhaberler> not an issue with xenomai rt-preempt and posix
[22:22:52] <zultron> Right.
[22:22:57] <zultron> Or xeno-user.
[22:23:11] <mhaberler> so we have the following issues: skunkworks amd crash - may or may bot need a separate package
[22:23:12] <zultron> (xeno-kernel it's still an issue)
[22:23:19] <mhaberler> right
[22:24:11] <mhaberler> then: getting a most generic package for the linuxcnc repo - the RTAI kernel seems to run on any washer and dryer
[22:24:23] <zultron> So, I found this repo of ubuntu kernels:
http://kernel.ubuntu.com/~kernel-ppa/mainline/
[22:25:23] <zultron> They only build three kernels per release: amd64, i686, and i686 PAE. For x86 arch, that should be all that's necessary.
[22:25:32] <zultron> Add one more for beaglebone.
[22:25:54] <mhaberler> then: a decent rt-preempt kernel, better from some external repo, self-built if none can be found
[22:26:22] -!- taber38 has quit [Quit: Page closed]
[22:26:48] <mhaberler> re ubuntu kernels - I still have to understand what makes them special relative to mainline, I have yet to see an issue with a mainline kernel under ubuntu
[22:26:51] <zultron> Yeah, I seem to remember seeing a vendor for rt-preempt pkgs for debian.
[22:27:17] <mhaberler> pengutronix.de probably
[22:28:02] <zultron> I'm working on patching one of those packages from kernel.ubuntu.com with xenomai.
[22:28:06] <mhaberler> so one thing we have to decide is to whether to go with my mainline-based 3.2.21 for now or rebase on ubuntu-3.2.21-precise
[22:28:11] <mhaberler> aja
[22:28:45] <skunkworks> http://imagebin.org/241608
[22:28:48] <mhaberler> memleak, what do you think? I really dont have any founded preference
[22:29:00] <zultron> The reason I'm going for those packages is because I want to use their .config, which is generic enough to run on lots of hardware, and do minimal tweaks to enable xeno.
[22:29:17] <skunkworks> This hd will boot and run on other hardware (intel and amd)
[22:29:46] <skunkworks> (and run the latency test)
[22:30:29] <mhaberler> it couldnt mount the rootfs
[22:30:58] <skunkworks> But this was installed on an athalon 64 3200+ and when I installed the xenomai deb - did this
[22:31:00] <mhaberler> I would guess it is a kernel command line issue
[22:31:02] <zultron> skunkworks, looks like your kernel is missing a driver, maybe your disk controller.
[22:31:14] <zultron> Not related to the CPU.
[22:31:46] <mhaberler> it didnt find the disk, yes driver likely missing
[22:31:59] <skunkworks> zultron, the 12.04 install worked up until I installed the xenomai debs.
[22:32:40] <skunkworks> asus goal3 motherboard
[22:32:43] <zultron> You mean the xenomai kernel debs, right? Yeah, that makes sense. Where did those come from?
[22:32:47] -!- dgarr [dgarr!~dgarrett@97-117-216-246.phnx.qwest.net] has joined #linuxcnc-devel
[22:32:52] <mhaberler> ahem
[22:32:59] <zultron> Ha ha
[22:33:42] <zultron> Well, figure out what kind of disk controller that mobo has, and we can check that the driver is enabled in the .config.
[22:33:51] <skunkworks> ok
[22:34:12] <mhaberler> here on some german website a guy reports rootdelay=xxx fixed that for him
[22:34:19] <zultron> Otherwise, I'm going with this approach for deb kernels exactly for this reason.
[22:34:52] <mhaberler> he says adding 'rootdelay=45' to the kernel command line made it go away (that is very long but anyway)
[22:35:04] <zultron> mhaberler, is that to give the controller time to initialize before trying to mount a rootfs?
[22:35:28] <memleak> mhaberler, yeah it works good for flaky ATAPI controllers
[22:35:37] <mhaberler> this could be it:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/278176
[22:36:20] <memleak> that was to zultron, whoops
[22:37:24] <mhaberler> pretty sure this will run fine once it gets massaged to find the disk with the rootfs, so the amd/pae idea was likely unneeded
[22:38:01] <mhaberler> skunkworks: could you try it with that rootdelay param and see what happens?
[22:39:18] <skunkworks> I will try that - but I cannot until tomorrow.
[22:39:38] <skunkworks> (I have to go home) ;)
[22:40:00] <mhaberler> waht might help is if you record a boot log (dmesg) from a working kernel so we see which driver that uses
[22:40:03] <zultron> I can't find which controller the goal3 has. And I need to go to the last holiday family dinner (whew, so glad it's almost over). I'll report back with .dpkg progress.
[22:40:21] <mhaberler> sure, see you around!
[22:40:28] -!- skunkworks has quit [Read error: Connection reset by peer]
[22:40:34] <zultron> (Isn't it past your bedtime, mhaberler? You've got a big event tomorrow! ;)
[22:40:45] <mhaberler> just drivng 5hrs
[22:40:56] <mhaberler> saturday takoff #1
[22:41:26] <mhaberler> ok, bedtime. I heary. Cu!
[22:41:33] <zultron> Be safe, and take lots of pics. Ciao!
[22:41:33] -!- mhaberler has quit [Quit: mhaberler]
[22:44:52] <dgarr> i have an amd machine that runs rtai but wont boot with 3.2.21-xenomai+ from mah deb -- same as skunkworks, cant find by uuid at boot, rootdelay=45 (and bigger) nohelp
[22:45:46] <dgarr> the same machine will run with a xenomai kernel i found somewhere: $ uname -a
[22:45:47] <dgarr> Linux shop-lucid 3.2.21-xenomai-2.6.1 #1 SMP Wed Jul 25 11:24:55 EDT 2012 i686 GNU/Linux
[22:49:09] <memleak> Does EMC / LinuxCNC use IPIPE legacy functions? Not sure if to leave on or off in kernel.
[22:49:21] <dgarr> boot log (for the one that boots is at)
http://www.panix.com/~dgarrett/stuff/x.log
[22:51:17] <memleak> I remember paolo mante telling me I needed it, did anyone here have a successful boot turning it off? This _IS_ xenomai after all, not RTAI.
[22:54:14] -!- sumpfralle1 has quit [Ping timeout: 265 seconds]
[22:57:00] -!- sumpfralle has quit [Ping timeout: 276 seconds]
[22:58:18] -!- memleak has quit [Quit: new kernel]
[23:05:40] -!- syyl_ws has quit [Quit: Verlassend]
[23:10:21] <dgarr> config-2.6.38.8-xenomai+:CONFIG_PATA_VIA=m
[23:10:21] <dgarr> config-3.2.21-xenomai+:# CONFIG_PATA_VIA is not set
[23:10:27] -!- memleak [memleak!~memleak@unaffiliated/memleak] has joined #linuxcnc-devel
[23:10:55] <jepler> dgarr: I do believe you've found it
[23:12:37] <dgarr> i had another (intel atom) machine with an ide disk that wouldn't boot 3.2.21-xenomai+ but i can't retest since I replaced the disk with a sata ssd disk that worked
[23:19:10] -!- cncbasher has quit [Remote host closed the connection]
[23:20:23] <memleak> hey hey 3.5.3 works without issue!
[23:20:54] <memleak> a bunch of other problems but nothing to do with latency.. yet.. >_>
[23:24:43] -!- zzolo has quit [Quit: zzolo]
[23:25:32] -!- mhaberler [mhaberler!~mhaberler@macbook.stiwoll.mah.priv.at] has joined #linuxcnc-devel
[23:26:31] <mhaberler> hi dgarr! thanks, thats very valuable - will build new debs
[23:27:29] <mhaberler> memleak: you have a working 3.5.3 xenomai? is that 'their' .deb?
[23:28:04] <dgarr> welcome, latencyfor the 3.2.21-xenomai-2.6.1 that boots (1*glxgears):
http://www.panix.com/~dgarrett/stuff/screenshots/3.2.21-xenomai-2.6.1.png
[23:29:23] <mhaberler> good start!
[23:31:07] <memleak> mhaberler, all built myself
[23:31:18] <memleak> from source, in gentoo, no packages
[23:31:22] <mhaberler> I see
[23:32:24] -!- bradsimantel has quit [Ping timeout: 276 seconds]
[23:32:29] <mhaberler> I see the xenomai folks are working on debian packaging, not sure if its shaken out yet
[23:37:13] <memleak> im really starting to like xenomai... this is my first time looking at it.
[23:38:52] -!- ybon has quit [Quit: WeeChat 0.3.8]
[23:39:11] <memleak> would it be possible in theory to have the PREEMPT_RCU as the real-time subsystem or do you need CONFIG_PREEMPT_RT at a minimum?
[23:40:23] <mhaberler> puh
[23:40:35] <memleak> https://rt.wiki.kernel.org/index.php/CONFIG_PREEMPT_RT_Patch
[23:40:58] <mhaberler> well yes, but how does that relate to xenomai?
[23:41:25] <mhaberler> they are moving to converge on this eventually, but now its not a base or so I understand it
[23:41:36] <memleak> It doesn't, I'm talking about a fourth alternative to Xenomai, RTAI, and PREEMPT_RT
[23:41:57] <mhaberler> well that 3rd alternative is in fact RT_PREEMPT
[23:42:05] <mhaberler> its all in place
[23:42:24] <mhaberler> oh I guess I'm missing something here
[23:42:55] <mhaberler> why dont you give it a try? the rt-preempt-user build has fairly minimal kernel requirements
[23:42:58] <memleak> RT_PREEMPT, PREEMPT_RT whatever you wanna call it. The patch by the kernel.org which adds real-time.
[23:43:10] <memleak> *the kernel.org team
[23:43:38] <mhaberler> right well that is one of the build options in rtos-integration-preview3
[23:44:12] <mhaberler> so we are talking about the RT_PREEMPT patch, well that can be used, yes
[23:44:52] <memleak> PREEMPT (non-RT) is the most stable, tested (and secure) preemption model but worse latency than RT_PREEMPT (I'd assume..)
[23:45:08] -!- Nick001-Shop has quit [Ping timeout: 244 seconds]
[23:45:11] Nick001-Shop_ is now known as Nick001-Shop
[23:45:19] <memleak> PREEMPT (non-RT again) is the one in the upstream vanilla kernel source, no patches needed.
[23:45:45] <memleak> I'm talking about EMC running with that, if it's even possible or not.
[23:46:10] <mhaberler> yes it is. ./configure --with-threads=rt-preempt-user
[23:46:12] <mhaberler> now
[23:46:34] <memleak> is that the ./configure line for LinuxCNC?
[23:46:39] <mhaberler> yes
[23:46:54] <mhaberler> it makes no difference for the build really
[23:46:57] <mhaberler> except for figues
[23:47:00] <memleak> Wow, the EMC guys have been working hard!
[23:47:36] <mhaberler> dgarr: building
[23:48:41] <mhaberler> actually if you run an RT_PREEMPT kernel, it will autodetect so ./configure is enough
[23:48:50] <memleak> whats the ./configure line for the PREEMPT_RT patch set? is this documented somewh........ oh, thanks!
[23:49:29] <mhaberler> nb: latency is signifcantly worse with rt-preempt compared to xenomai
[23:49:46] <memleak> just to be clear, CONFIG_PREEMPT you have to use --with-threads=rt-preempt-user correct?
[23:50:11] <memleak> (the PREEMPT option in vanilla kernel source with no patches needed)
[23:50:28] <mhaberler> that has no impact whatsoever
[23:50:37] <mhaberler> it doesnt change the ABI
[23:50:54] <memleak> so whats the latency like?..
[23:51:47] <memleak> same as CONFIG_PREEMPT_VOLUNTARY (Desktop) ?
[23:52:40] <mhaberler> never measured the CONFIG_PREEMPT* stuff
[23:53:05] <mhaberler> its way off anyway so why bother
[23:53:30] <mhaberler> that I understand not to be anywhere near 'RT' capable
[23:54:03] <mhaberler> RT_PREEMPT is lots better, but maybe twice the latency of xenomai
[23:54:17] <memleak> oh ok, thanks! how did you learn about all this?
[23:54:27] <mhaberler> reading and trying
[23:55:01] <mhaberler> pulling together code from some disparate and vanished attempts
[23:55:08] <memleak> RT_PREEMPT is most likely much more stable than xenomai though.
[23:55:18] <mhaberler> fine, then use that
[23:55:33] <mhaberler> it might just not be an option for some
[23:55:44] <mhaberler> the issue is on non-pc platforms
[23:56:02] <mhaberler> the key is hires timers, no rt kernels without it
[23:56:33] <mhaberler> so if you do that you might just as well use the ipipe patch and get better performance
[23:56:35] <memleak> But I want to get your AMD xenomai system working :P
[23:57:00] <mhaberler> thats what everybody in arm space is doing, no rt-preempt there seen yet
[23:57:38] <mhaberler> well first I dont have an AMD, so I'd be a bad customer
[23:57:54] <memleak> I got confused then.. who needed their AMD xenomai system working?
[23:58:04] <mhaberler> and then there are some which run xenomai 3.2.21 on amd just fine
[23:58:27] <mhaberler> skunkworks, but that is a driver load issue and unrelated to xenomai
[23:58:39] <memleak> ah that was him, whoops haha
[23:58:50] <mhaberler> with a 3.5.3 xenomai kernel for all relevant platforms you'll be the star ;)
[23:59:06] -!- tjb1 has quit [Quit: tjb1]
[23:59:09] <memleak> 3.5.3 is almost working the way it's supposed to
[23:59:20] <memleak> few more reboots
[23:59:23] <mhaberler> just a small step for men..
[23:59:30] -!- sumpfralle2 has quit [Ping timeout: 264 seconds]
