Back
[00:03:23] -!- Nick001-Shop has quit [Remote host closed the connection]
[00:03:24] -!- logger[mah] has quit [Remote host closed the connection]
[00:03:31] -!- logger[mah] [logger[mah]!~loggermah@mail.mah.priv.at] has joined #linuxcnc3
[00:03:31] -!- logger[mah] has quit [Remote host closed the connection]
[00:03:37] -!- logger[mah] [logger[mah]!~loggermah@ns2.mah.priv.at] has joined #linuxcnc3
[00:40:00] -!- logger[psha] [logger[psha]!~loggerpsh@195.135.238.205] has joined #linuxcnc3
[00:43:23] -!- ve7it has quit [Remote host closed the connection]
[00:47:57] -!- mhaberler has quit [Quit: mhaberler]
[00:53:26] -!- RagingComputer has quit [Ping timeout: 255 seconds]
[00:56:01] -!- mattions has quit [Ping timeout: 256 seconds]
[01:04:46] -!- andypugh has quit [Quit: andypugh]
[01:05:32] -!- RagingComputer has quit [Ping timeout: 246 seconds]
[01:14:39] -!- gmagno has quit [Quit: Leaving]
[01:18:56] -!- Tom_L has quit []
[01:27:31] -!- tjb1 has quit [Quit: tjb1]
[02:14:13] -!- grummund has quit [Ping timeout: 256 seconds]
[02:17:51] -!- factor has quit [Read error: Connection reset by peer]
[03:00:05] -!- i_tarzan has quit [Ping timeout: 265 seconds]
[03:05:17] -!- cevad has quit [Ping timeout: 247 seconds]
[03:15:08] -!- Keknom has quit [Quit: Leaving.]
[03:27:14] -!- WiillenCMdesign has quit [Ping timeout: 260 seconds]
[03:33:44] -!- Connor has quit [Remote host closed the connection]
[03:49:28] -!- cradek has quit [Changing host]
[03:52:53] -!- Gabe__ has quit [Ping timeout: 248 seconds]
[03:59:02] -!- zzolo has quit [Client Quit]
[04:19:52] -!- jpk has quit [Ping timeout: 252 seconds]
[05:02:22] -!- Fox_Muldr has quit [Ping timeout: 265 seconds]
[05:13:46] -!- dimas_ has quit [Ping timeout: 252 seconds]
[05:35:44] -!- tjb1 has quit [Quit: tjb1]
[05:51:15] -!- archivist_herron has quit [Ping timeout: 256 seconds]
[05:55:44] -!- roycroft has quit [Ping timeout: 244 seconds]
[06:05:44] -!- bradsimantel has quit [Quit: bradsimantel]
[06:19:14] -!- archivist_herron has quit [Ping timeout: 255 seconds]
[06:22:01] -!- mhaberler [mhaberler!~mhaberler@extern-183.stiwoll.mah.priv.at] has joined #linuxcnc3
[06:23:19] -!- bradsimantel has quit [Quit: bradsimantel]
[06:40:09] Cylly2 is now known as Loetmichel
[06:47:07] -!- archivist_herron has quit [Ping timeout: 246 seconds]
[07:05:00] -!- DJ9DJ has quit [Quit: reboot]
[07:08:16] -!- emel has quit [Excess Flood]
[07:19:32] -!- r00t4rd3d has quit [Ping timeout: 252 seconds]
[07:41:22] -!- r00t4rd3d has quit [Changing host]
[07:43:11] -!- rob_h [rob_h!~rob_h@027c035d.bb.sky.com] has joined #linuxcnc3
[08:27:45] -!- ybon has quit [Quit: WeeChat 0.3.7]
[08:35:44] -!- thierry has quit [Client Quit]
[09:33:33] -!- theorb has quit [Quit: leaving]
[09:37:25] -!- mhaberler has quit [Quit: mhaberler]
[09:40:56] -!- mhaberler [mhaberler!~mhaberler@extern-183.stiwoll.mah.priv.at] has joined #linuxcnc3
[09:45:31] -!- sumpfralle has quit [Read error: Connection reset by peer]
[10:16:52] toudi_ is now known as micges
[10:16:59] -!- micges [micges!~toudi@deh112.neoplus.adsl.tpnet.pl] has joined #linuxcnc3
[10:18:42] <micges> mhaberler: hello
[10:18:42] <mhaberler> hi micges
[10:18:43] <micges> I like those ideas you send me
[10:18:43] -!- psha has quit [Quit: leaving]
[10:18:43] <mhaberler> I think that is the simplest possible solution ;)
[10:18:43] <micges> but can you draw what whole system will look like?
[10:18:43] <mhaberler> ok, assume task sends a message
[10:18:45] <mhaberler> this will go to what I call a scheduler - a zmq app
[10:19:03] <mhaberler> gets the message, decides whom to direct to, pushes it, handles replies
[10:19:34] <mhaberler> in case modules generate command messages (layering of comps) these go back up to the scheduler, who decides how to handle it - this is all usrland
[10:20:06] <mhaberler> the comps get a callback interface if a message comes down, and a method to send a message back
[10:20:23] <mhaberler> all the hairy stuff (who gets which message when) can be done in userland
[10:20:43] <mhaberler> (very rough sketch I guess)
[10:20:59] <micges> ok, what about hal device drivers?
[10:21:20] <micges> they should only comunicate with hal modules
[10:21:22] <mhaberler> how are they any different?
[10:21:55] <mhaberler> I would not exclude they could originate and consume messages but I dont see the point yet?
[10:22:09] <micges> there should be no user space between drivers and rest of modules
[10:22:39] <mhaberler> good luck in doing the scheduler in the kernel
[10:23:13] <mhaberler> what is the point? performance on the EMC_MOT_* command level cant be it, that is very low
[10:24:00] <micges> ok
[10:24:01] <mhaberler> I see messages as a 'start this command' and 'I'm done with command X' type interaction
[10:24:17] <mhaberler> so those wouldnt be all too frequent
[10:24:38] <mhaberler> NB: a few other applications fit this bill:
[10:25:09] <micges> so you're talking about task <-> motion interface right>?
[10:25:18] <mhaberler> not only
[10:25:35] <mhaberler> HAL metadata in userland: well rt modules need to upcall for hal_init, hal_malloc, hal_ready etc - well that will be a req/reply pattern between halmodule and the HAL server
[10:26:02] <mhaberler> it will be all the same mechanism
[10:26:31] <micges> what is 'hal metadata'?
[10:27:39] <mhaberler> read up on developers - johnk had the idea to dump all this name management from hal_lib.c and move it to a hal server
[10:28:02] <mhaberler> that hal server could use any mechanism to manage names, including python dict, stl, redis - whatever
[10:28:32] <mhaberler> all that is needed in HAL is: a memory allocator, and a way modules (rt and user) can talk to the HAL server
[10:28:52] <mhaberler> the existing hal_* functions might vanish behind a HAL server RPC
[10:29:02] <mhaberler> and that will be a ZMQ socket req/reply ;)
[10:29:15] <micges> ah now I get it
[10:29:22] <micges> you mean all hal managment code
[10:29:22] <mhaberler> getting that to work in the kernel from init/cleanup code was key
[10:29:26] <mhaberler> YES
[10:29:34] <mhaberler> its going to be all userland
[10:30:31] <mhaberler> assume you use redis to store hal names/types/offsets - suddenly network capable at no extra cost
[10:31:57] <mhaberler> glueing components together with messaging channels becomes a ZMQ URI naming exercise
[10:32:57] <mhaberler> but its ALL the same underlying mechanism - a ZMQ unix domain socket for all of these jobs -rpcs, command handling - no more special cases
[10:33:09] <micges> ok
[10:33:17] <micges> so we have
[10:33:40] <micges> kernel mode hal malloc and user space managent
[10:33:55] <micges> how this fits together
[10:33:57] <mhaberler> hal malloc really is just a hal server upcall
[10:34:08] <mhaberler> from rt mods that is
[10:34:24] <mhaberler> hal server does the memory management and replies with offset address
[10:34:49] <mhaberler> same thing for usercomp - actually hal server cant tell the difference, no need to know
[10:35:11] <micges> and the pool will be kernel mem or user mem?
[10:35:35] <mhaberler> it comes from /halpath/myrtmod or /halpath/yourusermod
[10:35:46] <mhaberler> the pool is always in shared memory
[10:35:54] <mhaberler> oh I see
[10:36:21] <mhaberler> rtapi handles that now fine, I think
[10:36:31] <micges> when it's shared memory then ok
[10:36:37] <micges> I get the point
[10:37:02] <mhaberler> what could be done is to reply with a rtapi shmseg/offest pair in case one segment runs out of space, hal server can alloc another one
[10:37:35] <mhaberler> rt/user comp attaches shmseg as per reply, happy ever after ;)
[10:37:56] <mhaberler> not sure how pin linking would work in this case; multiple segs are probably a stupid idea
[10:38:23] <mhaberler> but when the names and management fluff goes out from the hal shm segment a lot of space becomes free
[10:38:30] jthornton_ is now known as jthornton
[10:38:32] <micges> it would be total mess
[10:38:44] <mhaberler> its mostly management overhead in there now, names etc etc
[10:38:55] -!- sumpfralle has quit [Read error: Connection reset by peer]
[10:39:37] <micges> it's only on hal file parsing, not big deal
[10:39:42] <mhaberler> I think what will be left is hal_malloc blobs. anything else?
[10:40:13] <mhaberler> pins/sigs are in those blobs; need to think about thread chains
[10:40:56] <mhaberler> probably all in the thread module hal_malloced blob
[10:42:06] <micges> yes
[10:42:29] <micges> there are few thread and each one can have space to let say 1024 functions
[10:43:35] -!- theos has quit [Ping timeout: 246 seconds]
[10:44:24] <micges> you should aslo think about hal once executed functions
[10:44:27] <mhaberler> need to look but I guess now those are lists in hal memory
[10:44:48] <mhaberler> what you mean by 'once executed functions'? init/exit?
[10:45:01] <micges> I have very complicated rtnet driver
[10:45:14] <micges> and I need to do some init code in rt context
[10:45:23] <micges> so from rt task
[10:46:07] <mhaberler> if (once) {init(); once=0;} ?
[10:46:58] <mhaberler> does that need to be in RT context or can it be in linux kernel context?
[10:47:00] <micges> it's too late then
[10:47:22] <mhaberler> hm, well drop me an example or a link
[10:47:52] <micges> loadrt mod1
[10:47:57] <micges> loadrt hm2_eth
[10:48:05] <micges> unloadrt mod1
[10:48:23] <micges> loadrt mod2
[10:48:24] <micges> ...
[10:48:34] <micges> call hm2_eth.postinit
[10:48:50] <micges> unloadrt mod2
[10:48:58] <micges> addf hm2_eth.read
[10:48:59] <micges> ..
[10:49:08] <mhaberler> oh man, a callback in rt mode..
[10:49:26] <mhaberler> which thread would execute that?
[10:49:31] <micges> servo
[10:50:02] <micges> oh and I've modified hal to be possible use 'insmod' and 'rmmod' :)
[10:50:27] <mhaberler> well.. that brings me back to my idea of separating function chains and threads
[10:51:07] <mhaberler> a function chain as a first class object (which could be just one function to start with) , plus
[10:51:33] <mhaberler> some logic to execute a fchain in a thread context a certain number of times (maybe forever ;)
[10:51:37] <mhaberler> so its
[10:51:46] <mhaberler> call 'thread' 'chain' condition
[10:51:56] <mhaberler> condition is once, or forever
[10:52:01] <mhaberler> there you have it
[10:52:11] <micges> great
[10:52:31] <mhaberler> it means disassembling the threads module a bit and making it more configurable, but that doesnt strike me as too hard
[10:52:47] <mhaberler> I think function chains are a useful abstraction per se
[10:53:21] <mhaberler> it might help a bit with testing and debugging, too - if you can do that from halcmd
[10:53:28] <micges> it would be full usage of rtai layer
[10:53:56] <micges> now you have only periodic rt tasks
[10:54:32] <mhaberler> oh, you mean there are 'once only' type tasks.. need to look, but sure they are; rt_preempt has that too
[10:56:01] <mhaberler> right, makes sense
[10:56:22] <micges> in rtai user program that call 'make_hard_real_time()' is once only rt task
[10:56:38] <micges> not possible in module init code
[10:56:44] <mhaberler> I see
[10:57:28] <mhaberler> in theory but the zmq kernel socket could do an upcall to have the HAL server do it
[10:57:40] <micges> but when you're connect task to rtai timer, then automagically it is rt task
[10:57:41] <mhaberler> sounds weird
[10:58:24] <mhaberler> so it loses normal user & kernel context in that case, I assume?
[10:58:44] <mhaberler> because rtai threads are really bare metal
[10:58:47] <micges> yes
[10:58:52] <mhaberler> aja
[10:59:15] <micges> you can't done it in module init bcouse you're in kernel mode then
[10:59:29] <mhaberler> well maybe there's a way to fire off a throwaway once-only rtai task from userland (indirection #357 ;-)
[11:00:14] <mhaberler> so we have module init code causes upcall to hal server, hal server fires off once-only rtai task calling post-init func
[11:00:40] <micges> with timeout
[11:00:46] <micges> or trigger
[11:00:58] <mhaberler> who times out?
[11:01:07] <mhaberler> the init code?
[11:01:23] <micges> ah sorry
[11:01:26] <mhaberler> right, that would have to sleep until hal server reply comes down
[11:01:32] <micges> you mean as a command from hal file
[11:01:43] <mhaberler> yes, thats an alternative
[11:01:51] <mhaberler> probably easier
[11:02:05] <mhaberler> halcmd can do it
[11:02:05] <micges> I need from hal file
[11:02:11] <mhaberler> oh, bene
[11:02:34] <mhaberler> so how do you do it now?
[11:02:52] <mhaberler> special purpose module?
[11:03:12] <micges> I'm in the middle of it :)
[11:03:24] <mhaberler> report when done ;)
[11:03:29] <micges> o
[11:03:30] <micges> k
[11:04:01] <mhaberler> that btw is my favorite Winston Churchill management style quote
[11:04:27] <mhaberler> he wanted to have something done *now*, so he wrote on a memo 'action today and report when done' ;)
[11:04:56] <micges> hehe
[11:05:15] <mhaberler> talk about 'accelerated execution';)
[11:05:32] <micges> point is that rtnet is working only in rt context
[11:05:49] <micges> but I need to access net in module init
[11:05:55] <mhaberler> ah, glorified interrupt handler,hm?
[11:06:35] <micges> so I'll make functions in userspace module that can access eth and hm2_eth will call them
[11:06:53] <micges> then I need to rmmod kernel driver and insmod rtnet driver
[11:07:16] <micges> and then I can use hm2_eth.read
[11:07:36] <mhaberler> all this sounds a bit voodoo to me, but I believe you
[11:08:08] <micges> run once thread will make that there is no additional funky modules
[11:08:43] <micges> and I didn't have to use linux eth driver, so it will be disabled all the time
[11:08:51] <micges> uff, that's all
[11:09:43] <micges> ok back to worl
[11:09:55] <mhaberler> ok, cu around - great chat
[11:11:58] <micges> ah one thing
[11:12:28] <micges> init can't be done like if (once) {init(); once=0;}
[11:12:42] <micges> it creates pins and functions
[11:13:07] <micges> so it could be somehow possible
[11:42:27] -!- skunkworks__ has quit [Remote host closed the connection]
[11:51:43] -!- sumpfralle1 has quit [Ping timeout: 260 seconds]
[11:58:59] -!- dhoovie has quit [Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/]
[12:01:16] -!- thierry has quit [Ping timeout: 245 seconds]
[12:12:10] -!- emel has quit [Excess Flood]
[12:15:25] -!- sumpfralle has quit [Ping timeout: 246 seconds]
[12:48:23] -!- logger[psha] [logger[psha]!~loggerpsh@195.135.238.205] has joined #linuxcnc3
[13:36:21] -!- odogono has quit [Ping timeout: 252 seconds]
[13:46:11] -!- broofa has quit [Quit: Computer has gone to sleep.]
[13:46:25] -!- sumpfralle1 has quit [Ping timeout: 244 seconds]
[13:51:31] -!- sumpfralle has quit [Ping timeout: 246 seconds]
[13:52:38] -!- WillenCMD has quit [Ping timeout: 245 seconds]
[13:55:14] -!- psha[work] has quit [Quit: Lost terminal]
[14:14:29] -!- broofa has quit [Quit: Computer has gone to sleep.]
[14:23:13] -!- sumpfralle has quit [Quit: Leaving.]
[14:28:20] toudi_ is now known as micges
[14:28:25] -!- micges [micges!~toudi@deh112.neoplus.adsl.tpnet.pl] has joined #linuxcnc3
[15:05:10] -!- mk0 has quit [Read error: Connection reset by peer]
[15:07:24] -!- JT-Shop has quit [Ping timeout: 252 seconds]
[15:07:45] -!- jthornton has quit [Ping timeout: 256 seconds]
[15:14:43] -!- mattions has quit [Ping timeout: 245 seconds]
[15:15:46] -!- zzolo has quit [Quit: zzolo]
[15:16:38] -!- uw has quit [Quit: Ex-Chat]
[15:21:43] -!- mhaberler has quit [Quit: mhaberler]
[15:30:52] -!- mhaberler [mhaberler!~mhaberler@extern-183.stiwoll.mah.priv.at] has joined #linuxcnc3
[15:32:47] -!- mhaberler has quit [Client Quit]
[16:00:27] -!- mhaberler [mhaberler!~mhaberler@extern-183.stiwoll.mah.priv.at] has joined #linuxcnc3
[16:01:44] -!- bmwyss has quit [Quit: bmwyss]
[16:08:30] -!- mhaberler has quit [Quit: mhaberler]
[16:10:34] -!- wsjr has quit [Read error: Connection reset by peer]
[16:15:08] -!- mhaberler [mhaberler!~mhaberler@extern-183.stiwoll.mah.priv.at] has joined #linuxcnc3
[16:15:39] -!- mhaberler has quit [Client Quit]
[16:24:21] -!- mhaberler [mhaberler!~mhaberler@macbook.stiwoll.mah.priv.at] has joined #linuxcnc3