Back
[00:04:11] -!- MarkusBec has quit [Excess Flood]
[00:04:11] -!- logger[mah] has quit [Remote host closed the connection]
[00:04:18] -!- logger[mah] [logger[mah]!~loggermah@mail.mah.priv.at] has joined #linuxcnc-devel
[00:16:10] -!- ybon has quit [Quit: WeeChat 0.3.8]
[00:29:40] -!- MarkusBec has quit [Excess Flood]
[00:31:12] -!- Gene45 has quit [Ping timeout: 255 seconds]
[00:31:29] -!- sumpfralle has quit [Ping timeout: 252 seconds]
[00:35:41] -!- dr00bie has quit [Quit: ChatZilla 0.9.89 [Firefox 17.0.1/20121129165506]]
[00:40:07] -!- MarkusBec has quit [Excess Flood]
[00:42:17] <KGB-linuxcnc> 03chrisinnanaimo 05master 1615693 06emc2 10src/emc/usr_intf/gscreen/gscreen.py * gscreen -stop the jog increments from wrapping at ends
[00:42:17] <KGB-linuxcnc> 03chrisinnanaimo 05master c710014 06emc2 10lib/python/gladevcp/calculatorwidget.py * gladevcp -fix error with calculator widget
[00:42:21] <KGB-linuxcnc> 03chrisinnanaimo 05master a91eb65 06emc2 10src/emc/usr_intf/gscreen/gscreen.py * gscreen -add a spindle preset keypad entry dialog
[00:43:10] -!- dr00bie has quit [Quit: ChatZilla 0.9.89 [Firefox 17.0.1/20121129165506]]
[00:49:57] -!- rob_h has quit [Ping timeout: 276 seconds]
[00:51:30] -!- MarkusBec has quit [Ping timeout: 265 seconds]
[00:51:39] -!- Servos4ever has quit [Quit: ChatZilla 0.9.89 [SeaMonkey 2.14.1/20121129191050]]
[01:05:27] -!- sumpfralle has quit [Ping timeout: 240 seconds]
[01:06:23] -!- MarkusBec has quit [Ping timeout: 255 seconds]
[01:22:05] -!- MarkusBec has quit [Excess Flood]
[01:32:11] -!- MarkusBec has quit [Read error: Connection reset by peer]
[01:33:23] -!- asdfasd has quit [Ping timeout: 255 seconds]
[01:34:49] -!- racycle has quit [Quit: racycle]
[01:37:13] -!- sumpfralle1 has quit [Ping timeout: 245 seconds]
[01:40:20] -!- KimK_laptop [KimK_laptop!~kkirwan@ip68-102-65-151.ks.ok.cox.net] has joined #linuxcnc-devel
[02:27:50] -!- p0g0 has quit [Ping timeout: 255 seconds]
[02:50:28] -!- Valen has quit [Quit: Leaving.]
[03:04:23] -!- p0g0 has quit [Ping timeout: 252 seconds]
[03:24:43] -!- toastydeath has quit [Ping timeout: 245 seconds]
[03:24:59] -!- ve7it [ve7it!~LawrenceG@S01060014d19d0b68.pk.shawcable.net] has joined #linuxcnc-devel
[03:55:47] -!- hafid has quit [Quit: Page closed]
[04:03:14] -!- dimas has quit [Ping timeout: 255 seconds]
[04:38:17] -!- r00t4rd3d has quit [Quit: Leaving]
[04:41:44] -!- yuvipanda has quit [Ping timeout: 252 seconds]
[05:06:37] -!- tjb1 has quit [Quit: tjb1]
[05:41:37] -!- yuvipanda__ has quit [Quit: yuvipanda__]
[05:46:38] -!- yuvipanda_ has quit [Ping timeout: 252 seconds]
[05:50:47] -!- ve7it has quit [Remote host closed the connection]
[06:22:16] -!- FinboySlick has quit [Quit: Leaving.]
[06:31:05] -!- theos has quit [Quit: cya]
[06:42:22] -!- EJTruth has quit [Remote host closed the connection]
[06:43:53] -!- i_tarzan has quit [Ping timeout: 245 seconds]
[06:46:59] -!- kwallace [kwallace!~kwallace@smb-224.sonnet.com] has parted #linuxcnc-devel
[06:51:02] yuvipanda_ is now known as yuvipanda
[07:07:14] -!- pingufan has quit [Quit: Konversation terminated!]
[07:13:49] -!- i_tarzan has quit [Ping timeout: 265 seconds]
[07:23:07] -!- AR_ has quit [Ping timeout: 260 seconds]
[07:35:53] -!- Gene45 has quit []
[07:38:00] -!- vladimirek [vladimirek!~vladimire@95.105.250.72] has joined #linuxcnc-devel
[07:47:48] -!- automata_ has quit [Read error: Connection reset by peer]
[08:02:46] -!- racycle has quit [Quit: racycle]
[08:13:03] -!- sumpfralle has quit [Ping timeout: 245 seconds]
[08:34:08] -!- JBFromOZ has quit [Ping timeout: 255 seconds]
[08:52:17] -!- vladimirek has quit [Remote host closed the connection]
[09:05:33] -!- theos has quit [Ping timeout: 245 seconds]
[09:37:19] -!- yuvipanda has quit [Quit: yuvipanda]
[09:40:57] orr_ is now known as mk0
[09:41:26] -!- sumpfralle has quit [Ping timeout: 240 seconds]
[09:50:17] theos is now known as Guest59769
[09:51:48] -!- Guest59769 has quit [Ping timeout: 245 seconds]
[10:13:26] -!- sumpfralle has quit [Ping timeout: 240 seconds]
[10:29:22] -!- KimK_laptop has quit [Quit: Leaving]
[10:30:32] -!- mk0 has quit [Quit: Ухожу я от вас (xchat 2.4.5 или старше)]
[10:36:48] -!- sumpfralle1 has quit [Ping timeout: 264 seconds]
[10:43:51] -!- rob_h [rob_h!~rob_h@5e047584.bb.sky.com] has joined #linuxcnc-devel
[10:50:43] <mhaberler> logger[mah]: xx
[10:50:43] <logger[mah]> mhaberler: Log stored at
http://linuxcnc.mah.priv.at/irc/%23linuxcnc-devel/2013-01-02.html
[10:57:48] -!- sumpfralle has quit [Ping timeout: 264 seconds]
[11:18:52] -!- sumpfralle has quit [Read error: Connection reset by peer]
[11:34:03] -!- mhaberler has quit [Quit: mhaberler]
[11:34:59] -!- cncbasher has quit [Remote host closed the connection]
[11:39:56] -!- dimas has quit [Ping timeout: 240 seconds]
[11:46:59] jthornton_ is now known as jthornton
[11:54:02] -!- sumpfralle1 has quit [Ping timeout: 255 seconds]
[11:56:06] -!- dhoovie has quit [Read error: Connection reset by peer]
[12:10:38] -!- vladimirek [vladimirek!~vladimire@95.105.250.72] has joined #linuxcnc-devel
[12:14:47] -!- JBFromOZ has quit [Ping timeout: 260 seconds]
[12:27:14] -!- holst has quit [Remote host closed the connection]
[12:28:28] -!- yuvipanda has quit [Remote host closed the connection]
[12:33:58] -!- skunkworks has quit [Remote host closed the connection]
[12:46:52] -!- cncbasher [cncbasher!~quassel@cpc15-hart9-2-0-cust101.11-3.cable.virginmedia.com] has joined #linuxcnc-devel
[12:54:24] -!- cncbasher has quit [Remote host closed the connection]
[12:56:19] -!- yuvipanda has quit [Ping timeout: 260 seconds]
[12:56:20] yuvipanda__ is now known as yuvipanda
[13:23:27] -!- r00t4rd3d has quit [Quit: Leaving]
[13:24:09] -!- mhaberler [mhaberler!~mhaberler@macbook.stiwoll.mah.priv.at] has joined #linuxcnc-devel
[13:28:03] -!- syyl_ has quit [Ping timeout: 245 seconds]
[13:29:02] <KGB-linuxcnc> 03git 05ferror-mode dafe9ea 06emc2 10docs/man/man9/motion.9 10src/emc/motion/control.c 10src/emc/motion/mot_priv.h 10src/emc/motion/motion.c * motion: introduce motion.ferror-mode
[13:32:13] <KGB-linuxcnc> 03git 05ferror-mode-master 1183f93 06emc2 10docs/man/man9/motion.9 10src/emc/motion/control.c 10src/emc/motion/mot_priv.h 10src/emc/motion/motion.c * motion: introduce motion.ferror-mode
[13:35:21] -!- JT-Shop-2 [JT-Shop-2!~John@184-63-140-99.cust.wildblue.net] has joined #linuxcnc-devel
[13:35:22] -!- JT-Shop has quit [Read error: Connection reset by peer]
[13:41:23] -!- yuvipanda has quit [Ping timeout: 245 seconds]
[13:41:30] -!- automata_ has quit [Ping timeout: 276 seconds]
[13:48:44] -!- chillly has quit [Quit: Leaving]
[13:51:46] -!- Simooon has quit [Quit: Leaving]
[14:04:59] JT-Shop-2 is now known as JT-Shop
[14:26:51] -!- nicolas__ has quit [Client Quit]
[14:28:13] -!- nicolas__ has quit [Client Quit]
[14:31:58] -!- Jymmm has quit [Ping timeout: 246 seconds]
[15:31:15] -!- cncbasher [cncbasher!~quassel@cpc15-hart9-2-0-cust101.11-3.cable.virginmedia.com] has joined #linuxcnc-devel
[15:39:37] -!- yuvipanda has quit [Quit: yuvipanda]
[15:55:24] -!- Nick001 has quit [Ping timeout: 264 seconds]
[15:58:04] -!- Poincare has quit [Quit: changing servers]
[16:00:55] -!- pcw_home [pcw_home!~chatzilla@ip-66-80-167-54.sjc.megapath.net] has joined #linuxcnc-devel
[16:07:22] -!- yuvipanda has quit [Read error: Connection reset by peer]
[16:53:03] -!- cncbasher has quit [Ping timeout: 245 seconds]
[16:57:21] -!- cncbasher [cncbasher!~quassel@cpc15-hart9-2-0-cust101.11-3.cable.virginmedia.com] has joined #linuxcnc-devel
[17:05:09] -!- psyhitus has quit [Read error: Connection timed out]
[17:14:50] -!- soooga has quit [Quit: Leaving]
[17:25:40] -!- psyhitus has quit [Read error: Connection timed out]
[17:38:11] abetusk is now known as Guest55760
[17:38:11] -!- Guest55760 has quit [Killed (moorcock.freenode.net (Nickname regained by services))]
[17:46:38] -!- cncbasher has quit [Remote host closed the connection]
[17:50:05] -!- opticdelusion has quit [Remote host closed the connection]
[18:11:51] -!- yuvipanda has quit [Quit: yuvipanda]
[18:20:42] -!- sumpfralle has quit [Read error: Connection reset by peer]
[18:22:16] -!- ve7it [ve7it!~LawrenceG@S01060014d19d0b68.pk.shawcable.net] has joined #linuxcnc-devel
[18:26:59] -!- psyhitus has quit [Read error: Connection timed out]
[18:37:08] -!- psyhitus has quit [Ping timeout: 248 seconds]
[18:38:24] -!- motioncontrol has quit [Client Quit]
[18:39:23] -!- sumpfralle1 has quit [Quit: Leaving.]
[18:49:36] -!- sumpfralle1 has quit [Ping timeout: 255 seconds]
[18:52:12] -!- skunkworks [skunkworks!~skunkwork@68-115-41-210.static.eucl.wi.charter.com] has joined #linuxcnc-devel
[18:52:49] <skunkworks> mhaberler,
http://imagebin.org/index.php?mode=image&id=241442
[18:53:25] <mhaberler> what does this tell me?
[18:53:57] <mhaberler> oh, I see - bad latency on an AMD?
[18:54:28] <skunkworks> yes - with rtai - It is around 30k or so. (not the greatest - but stable at that)
[18:54:47] <skunkworks> I sort of followed the wiki directions and anders.
[18:54:54] <mhaberler> have you followed Kent's website? I think he was in that place before
[18:54:55] <skunkworks> *awallen
[18:55:49] <skunkworks> link?
[18:56:13] <mhaberler> I also suggest to look at the troubleshooting section of the Xenomai website, these figures are indication of something severly wrong
[18:56:24] <mhaberler> need to look
[18:58:09] <skunkworks> this
http://www.newegg.com/Product/Product.aspx?Item=N82E16813131871
[18:58:12] <mhaberler> https://sites.google.com/site/manisbutareed/linuxcnc-2-5
[18:58:24] <skunkworks> and
http://www.newegg.com/Product/Product.aspx?Item=N82E16819106014
[18:58:34] <skunkworks> thanks
[18:58:49] <mhaberler> http://www.xenomai.org/documentation/xenomai-2.6/html/TROUBLESHOOTING/
[19:00:07] -!- ravenlock has quit [Read error: Connection reset by peer]
[19:02:38] <mhaberler> that's how it looks on my atom dw525:
http://static.mah.priv.at/public/atom.png for comparison
[19:03:00] <skunkworks> cool
[19:03:56] <skunkworks> I know when you had your first kernel setup - it seemed to run fine on intel based hardware. But I think I have only tried it on these style amd motherboard/cpu's so far.
[19:06:46] <mhaberler> but 165 usec jitter on a 25usec thread - cant believe it
[19:08:10] <mhaberler> unfortunately I dont have any amd in reach
[19:09:36] <L84Supper> we get ~4us jitter max on AMD Phenom and APU boards with the factory BIOS and RTAI
[19:10:23] <L84Supper> we will start working with your xenomai latches soon
[19:11:31] <skunkworks> doing the easy stuff first.. disabling the lagacy usb in the bios - Now max latency is around 50us
[19:13:54] <L84Supper> skunkworks: out of curiosity, do you happen to know what company that UEFI BIOS is by?
[19:14:24] <L84Supper> they just get worse and worse
[19:15:23] <skunkworks> american megatrends
[19:15:32] <L84Supper> ah AMI
[19:15:49] <skunkworks> you have had issues with them?
[19:18:00] <L84Supper> I've had issues with most closed source BIOS, thats why we started coreboot back in 98 :)
[19:18:00] -!- IchGuckLive has quit [Quit: ChatZilla 0.9.87 [Firefox 17.0.1/20121129170341]]
[19:18:01] <skunkworks> that is cheating...
[19:18:01] <skunkworks> ;)
[19:18:30] <L84Supper> mhaberler: we hope to be of some help to the new xenomai work in another month or so
[19:18:56] <mhaberler> oh, great - in which way? you tuning the s…t out of it ;-?
[19:21:47] -!- Connor has quit [Ping timeout: 260 seconds]
[19:23:30] <skunkworks> (I honestly was just glad to get linuxcnc installed on 12.04...)
[19:24:16] <L84Supper> we are using Gentoo but will try to help with anything debian/ubuntu
[19:28:03] -!- Connor has quit [Ping timeout: 248 seconds]
[19:39:47] -!- Keknom has quit [Ping timeout: 248 seconds]
[19:43:08] -!- dgarr [dgarr!~dgarrett@97-117-216-246.phnx.qwest.net] has joined #linuxcnc-devel
[19:51:32] -!- riz_ [riz_!457c0137@gateway/web/freenode/ip.69.124.1.55] has joined #linuxcnc-devel
[19:51:32] -!- pingufan has quit [Quit: Konversation terminated!]
[19:52:34] <riz_> does anyone know where the mutex is created for hal_data? I see a bunch of calls for get and give, but I cannot find where the mutex is originally created...
[19:54:08] <jepler> riz_: it seems to be an assumption that a zero-initialized mutex is in a defined state (unlocked)
[19:54:39] <jepler> so in that sense it's created by the relevant rtapi_shmem_new() call
[19:55:47] <jepler> er, no, I guess that's not right is it
[19:56:10] <riz_> The only thing I see in rtapi_shmem_new() is "rtapi_mutex_get(&(rtapi_data->mutex))"
[19:56:18] <riz_> I dont see how a mutex is created
[19:57:17] <mhaberler> it's just a zero-initialized int, Jeff is right
[19:57:42] <jepler> long, according to the prototype of rtapi_mutex_xxx
[19:58:23] <jepler> mhaberler: the "not right" caveat is that rtapi_shmem_new is documented as only zeroing the first 4 bytes of the block, so there's no guarantee that rtapi_data->mutex starts out as 0 (unlocked)
[19:58:31] <jepler> as far as I can see, it could start with any value
[19:58:50] <jepler> I'm not sure whether the actual behavior of rtapi_shmem_new is different (all bytes are zero'd, a stronger guarantee than we give)
[19:59:04] <riz_> what is the name of the variable declared and zero-initialized as int?
[19:59:11] <mhaberler> a lot of these semantics rely on implicit RTAI behavior
[19:59:17] <jepler> ... or if [failed] rtapi_mutex_try + rtapi_mutex_give in init_hal_data is what puts it in a defined state
[19:59:44] <mhaberler> like rtai_malloc which I thinks clears memory
[19:59:46] -!- biant92 has quit [Quit: Leaving.]
[20:00:03] <jepler> init_hal_data makes me uneasy for a number of reasons now that I am looking at it
[20:02:06] <riz_> Is hal_data->mutex the thing that is implicitly set to 0?
[20:02:28] <mhaberler> yes
[20:04:55] <riz_> where is the memory space for hal allocated?
[20:05:14] <jepler> by rtapi_shmem_new / rtapi_shmem_getptr
[20:06:24] -!- jp_ has quit [Read error: Operation timed out]
[20:23:21] <dgarr> a latency histogrammer for test: $ wget
http://www.panix.com/~dgarrett/stuff/lhisto.tcl
[20:23:22] <dgarr> some examples:
http://www.panix.com/~dgarrett/stuff/screenshots/
[20:23:31] <dgarr> usage: chmod 755 lhisto.tcl then ./lhisto.tcl --help
[20:23:31] <dgarr> please pastebin screenshot if it works, or terminal errors if it fails, thanks
[20:23:47] -!- mhaberler has quit [Ping timeout: 255 seconds]
[20:23:58] <riz_> I noticed that there is an array, shmem_array[n]. Why is shared memory in an array with n slots? Is each slot of shared memory for a different axis?
[20:26:53] <jepler> shmem_array is an implementation detail of rtapi, but in practice it limits the number of shared memory regions to a compile-time constant, presently 32
[20:27:22] <jepler> in practice there are a modest number of rtapi shared memory segments in use; much less than 1 per axis
[20:27:50] <jepler> components that communicate between realtime and userspace not through HAL pins generally allocate their own shared memory segments
[20:28:32] <jepler> it looks like these each allocate shared memory segments: hal itself, halscope, sampler, streamer, classicladder, and task/motion (grepping for rtapi_shmem_new calls)
[20:29:55] -!- phantoxeD has quit [Ping timeout: 260 seconds]
[20:29:56] -!- riz__ [riz__!457c0137@gateway/web/freenode/ip.69.124.1.55] has joined #linuxcnc-devel
[20:30:28] -!- riz_ has quit [Ping timeout: 245 seconds]
[20:30:43] <jepler> logger[mah]: url
[20:30:43] <logger[mah]> jepler: Log stored at
http://linuxcnc.mah.priv.at/irc/%23linuxcnc-devel/2013-01-02.html
[20:30:47] <riz__> ok
[20:31:23] <riz__> So, allocating their own shared memory segments is the same thing as using HAL pins right? Because arent HAL pins just shared memory segments?
[20:32:12] <jepler> hal pins and signals live within a specific shared memory segment; the pins can be connected with signals dynamically by 'halcmd net'
[20:32:29] <jepler> on the other hand, there are only a small number of types of pin available
[20:32:42] <jepler> and they all store single values
[20:33:17] <jepler> the places that use their own shared memory block are places where the runtime configurability of hal is not needed and the amount of data or types of data don't fit well in the hal model of pins and signals
[20:33:59] <riz__> Is the memory allocated in the same way for HAL as it is for other segments?
[20:34:11] <jepler> so for instance with sampler/streamer/halscope, there's a need to store a potentially large *sequence* of items which are removed as needed. that doesn't fit into the mold of HAL pins
[20:34:43] <jepler> for classicladder, the "program" is represented in a shared memory region; the userspace portion can update the program, while the kernel portion executes it
[20:35:16] <riz__> Basically I am trying to understand why you cant just use a call to malloc to make the memory regions?
[20:35:42] <jepler> because two HAL components don't share the same address space
[20:35:52] <jepler> (don't necessarily share)
[20:38:05] <riz__> Why wouldnt they share the same address space? Arent they in the same process?
[20:38:09] <jepler> no
[20:39:20] <jepler> userspace components are generally 1 component per process
[20:40:00] <riz__> What is an example of a user space component that you are referring to?
[20:40:28] <riz__> I would assume that something like PID is real time
[20:40:40] <riz__> not a user space component
[20:41:13] <jepler> http://pastebin.com/8pDXcMmH
[20:41:24] <jepler> have a look at 'halcmd show comp' while linuxcnc is running
[20:41:51] <jepler> so in this case (simulator) I have 5 userspace components and 6 realtime components
[20:43:14] <jepler> and yes, pid is an example of a realtime component
[20:43:32] <riz__> So why isnt that showing? Is it bc it is a simulator?
[20:43:41] <riz__> Or is it part of motmod?
[20:43:55] <jepler> this configuration doesn't have pid, because it just hooks the requested positions to the feedback positions (perfect following)
[20:44:05] <riz__> oh ok
[20:44:47] <riz__> So, essentially, if linuxcnc was recreated as 1 process with each component on a thread, then HAL would not be needed for communication between the components?
[20:44:58] <riz__> Or would it still be useful?
[20:46:15] <jepler> hal is about more than providing communication between processes and between userspace and realtime
[20:46:49] <jepler> it's also the place where you configure linuxcnc differently depending on whether you've got e.g., steppers on a parallel port or servos on a mesa pci card
[20:47:41] <jepler> very old linuxcnc ("emc1") didn't have hal yet, so if you had a different configuration (like controlling the spindle with a different parallel port pin) you edited the source code and recompiled. That was really inconvenient.
[20:50:20] <riz__> I mean is hal necessary to have different modules communicate to each other? If I have two modules that I want to communicate, instead of creating hal pins for each module and connecting them using signals, is there a more efficient way to communicate without hal, maybe just creating shared memory using malloc?
[20:50:54] <cradek> there is no inefficiency in hal pin connections
[20:51:23] <cradek> both modules have exactly a pointer to an address they share
[20:52:49] <jepler> if internally to one component you need to communicate data
[20:52:58] <jepler> and there's no need for the organization of that communcation to be configurable
[20:53:04] -!- mhaberler [mhaberler!~mhaberler@extern-183.stiwoll.mah.priv.at] has joined #linuxcnc-devel
[20:53:06] <jepler> then there's probably also no benefit to using HAL
[20:53:51] <jepler> for instance, consider ddt.comp, the source of the ddt 'discrete derivative' component
[20:54:04] <jepler> it has to remember from run to run the prior value of the input
[20:54:40] <jepler> it uses a comp statement 'variable' to define a double-precision number called 'old' which is associated with each specific instance of the component.
[20:55:06] <jepler> 'old' could be a pin instead, except what would it be useful to connect it to?
[20:55:42] <riz__> oh i see
[20:55:45] <jepler> in comp, this is actually implemented by allocating (with hal_malloc) a structure which has (among other members) 'double old'
[20:57:30] <jepler> more complicated examples include stepgen.c and encoder.c, which communicate data from the 'fast function' to the 'slow function' (or possibly the reverse); again they're not going through hal pins, but they are allocating the data with hal_malloc
[20:57:30] <riz__> hmmmm
[20:57:57] <jepler> .. not so much because it *has* to be shared data, but because that's the only malloc-like API that is guaranteed to be available
[20:58:23] <jepler> kernel space has APIs like kmalloc, userspace has APIs like calloc
[20:58:38] <riz__> how about just using malloc
[20:59:16] <jepler> I don't believe that function is available in kernel space
[20:59:20] <jepler> I may be mistaken
[21:00:13] <riz__> oh I c, but if you were using a regular RTOS then you could use malloc i'm assuming, you're just trying to use it in kernel space
[21:02:42] <jepler> we've talked about providing some kind of other allocator either as an rtapi_ API or a hal_ API that allocates non-shared memory without unreasonable limits (so unlike hal_malloc, which can only allocate a few hundred kB and always allocates shared memory)
[21:03:09] <jepler> .. specifically to address this limitation that there's no allocation other than hal_alloc that you can write in either a userspace or realtime component without worrying which RTOS you're on
[21:03:38] <jepler> oh, and also it would probably have the same semantic as hal_alloc, which is that the associated memory is freed when the component is unloaded
[21:03:43] -!- tjtr33 has quit [Quit: Ex-Chat]
[21:03:59] <jepler> it's the last bit that makes it a bit irritating to implement for kernelspace realtime modules
[21:04:19] -!- Keknom has quit [Quit: Leaving.]
[21:04:24] <jepler> that and coming up with a good name. hal_alloc_unshared doesn't have much of a ring to it.
[21:06:43] <riz__> ic ic, good stuff
[21:17:18] -!- logger[psha] [logger[psha]!~loggerpsh@195.135.238.205] has joined #linuxcnc-devel
[21:22:04] <mhaberler> jepler: which size limit are you referring to?
[21:23:49] <jepler> mhaberler: HAL_SIZE
[21:24:46] <mhaberler> that's a parameter - where is the limit?
[21:24:59] <jepler> ./hal_priv.h:#define HAL_SIZE 262000
[21:25:15] <mhaberler> sure
[21:25:48] <mhaberler> is there some underlying RTAI limitation which prevents resizing this parameter?
[21:26:06] <skunkworks> mhaberler, I did just try to install 12.04 + xnomi on an older motherboard (asus goal3+ and athlon 3200+) and it doesn't boot. Says something like vender_id "authenticamd" unknown using generic init.
[21:26:23] <skunkworks> your system may be unstable
[21:26:32] <skunkworks> (boots to busybox)
[21:27:51] <jepler> mhaberler: we could pick a different value for HAL_SIZE
[21:28:16] <mhaberler> sure we can, my question was if there are any OS limitations you're aware of
[21:28:48] <jepler> at one point I looked into making it an insmod-time parameter but I must have gotten hung up on some detail
[21:29:16] <mhaberler> I think that is a good idea and herewith steal it ;)
[21:29:54] <mhaberler> make that 'inspired'
[21:30:03] <jepler> please. once you take it from me, it's no longer my burden
[21:30:26] -!- Loetmichel has quit [Ping timeout: 245 seconds]
[21:30:37] <mhaberler> I heard these mumblings about hal memory site limits on and off, all I can find is a #define
[23:22:38] -!- logger[psha] [logger[psha]!~loggerpsh@195.135.238.205] has joined #linuxcnc-devel
[23:32:29] -!- ravenlock has quit [Quit: Leaving]
[23:35:17] -!- syyl_ws has quit [Quit: Verlassend]
[23:41:16] -!- cncbasher has quit [Ping timeout: 272 seconds]
[23:42:01] -!- JBFromOZ has quit [Quit: This computer has gone to sleep]
[23:49:49] -!- cncbasher [cncbasher!~quassel@cpc15-hart9-2-0-cust101.11-3.cable.virginmedia.com] has joined #linuxcnc-devel
[23:51:54] -!- ybon has quit [Quit: WeeChat 0.3.8]
