Back
[00:00:25] <anna_emc> how are you?
[00:00:32] <Jacky^> CC fs/ext2/fsync.o
[00:00:34] <Jacky^> CC fs/ext2/ialloc.o
[00:00:39] <Jacky^> :D
[00:00:51] <Jacky^> at the moment well
[00:01:31] <Jacky^> anna_emc: finish to sing in pal ?
[00:01:38] <anna_emc> no
[00:01:57] <Jacky^> what are you singing ?
[00:02:33] <anna_emc> image
[00:02:40] <Jacky^> wow ..
[00:03:02] <Jacky^> I like bob dylan :P
[00:03:05] <Jacky^> you know
[00:03:26] <anna_emc> yes
[00:03:48] <Jacky^> and now ?
[00:03:54] <Jacky^> aaahh
[00:04:05] <Jacky^> make: *** [fs] Error 2
[00:04:07] <Jacky^> ghghghg
[00:04:11] <anna_emc> prrrrrrrrrrrr
[00:04:17] <Jacky^> make[1]: *** [fs/reiserfs] Error 2
[00:04:22] <Jacky^> prrrr ??
[00:04:25] <Jacky^> to me ??
[00:04:33] <anna_emc> yes
[00:04:34] <Jacky^> O_O
[00:04:44] <Jacky^> why ?
[00:04:54] <anna_emc> uai e notte
[00:05:11] <Jacky^> * Jacky^ removing reiserfs module from config..
[00:06:30] <Jacky^> anna_emc: what do you think about reiserfs ?
[00:06:38] <Jacky^> i dont like it :\ bleahhh
[00:07:41] <anna_emc> ma nessuno c'�
[00:07:46] <anna_emc> in room
[00:07:51] <Jacky^> yes
[00:07:58] <jacky^^> sure
[00:08:15] <Jacky^> 2 peoples
[00:08:25] <Jacky^> ops.. 3
[00:08:46] <anna_emc> spe vado a cantare
[00:08:49] <anna_emc> come si dice
[00:08:55] <Jacky^> boh ..
[00:09:01] <Jacky^> i'm going to sing ?
[00:09:06] <Jacky^> :D
[00:09:38] <Jacky^> umpf ..
[00:09:48] <Jacky^> fs/ext2/built-in.o: could not read symbols: Bad value
[00:09:53] <Jacky^> mmmhh
[00:11:17] <anna_emc> I'll just have some wine
[00:11:30] <Jacky^> * Jacky^ slurp
[00:11:35] <Jacky^> red wine ? :P
[00:11:40] <anna_emc> :-)
[00:11:47] <Jacky^> smack
[00:11:48] <anna_emc> yes red wine
[00:11:49] <Jacky^> :)
[00:12:12] <Jacky^> i've an ext2 module that wont compile
[00:12:18] <Jacky^> * Jacky^ sigh
[00:13:16] <Jacky^> uhuh
[00:13:22] <Jacky^> it seem go on now :P
[00:15:47] <Jacky^> probably.. red wine like to pc ..
[00:15:50] <Jacky^> :D
[00:16:07] <Jacky^> or pc like to red wine..
[00:16:28] <Jacky^> the*
[00:18:57] <anna_emc> pc<'
[00:19:03] <anna_emc> pc?
[00:19:04] <Jacky^> eh ?
[00:19:23] <Jacky^> pciuk ?
[00:19:26] <Jacky^> smack
[00:19:26] <anna_emc> sigh
[00:19:28] <Jacky^> :)
[00:21:35] <Jacky^> System is 1666 kB
[00:21:36] <Jacky^> Kernel: arch/i386/boot/bzImage is ready
[00:21:40] <Jacky^> uaa
[00:21:48] <Jacky^> isnt too big ?
[00:22:34] <anna_emc> big? yes you are big
[00:22:40] <Jacky^> :)
[00:22:43] <Jacky^> thanks
[00:22:51] <Jacky^> the kernel too ..
[00:22:55] <Jacky^> too much :\
[00:23:06] <Jacky^> lets try ..
[00:23:45] <Jacky^> i'm 1,70 cm big
[00:23:56] <Jacky^> the kernel is 1666 kb ..
[00:23:59] <anna_emc> cala
[00:24:02] <anna_emc> ah ah
[00:24:03] <Jacky^> :)
[00:24:24] <Jacky^> con itacchi noo ?
[00:24:26] <Jacky^> :)
[00:24:51] <anna_emc> O_O
[00:37:41] <zwelch> * zwelch grins... he just saw the bootscreen for EMC2 on his non-RT system
[00:38:02] <zwelch> now if only it would finish launching.... :/
[00:42:43] <anna_emc> night
[02:08:50] <Jacky^> wow
[02:08:52] <Jacky^> :)
[02:08:59] <Jacky^> Linux localhost.localdomain 2.6.12.6-magma #1 Sun Sep 25 00:57:42 CEST 2005 i686 GNU/Linux
[02:10:14] <Jacky^> next step cthe conquist of planet :P
[02:28:01] <Jymmm> jacky^^: "What do you want to do tonight Brain? The same thing we do every tonight Pinky... TRY TO TAKE OVER THE WORLD!"
http://www.gotwavs.com/cgi-bin/tvmp3s.cgi?Pinky_And_The_Brain=pinky-gb.mp3
[02:28:26] <Jymmm> http://www.filegirl.com/images/0804/brainworld.JPG
[02:28:51] <Jacky^> haha
[02:28:53] <Jacky^> :)
[02:38:55] <Jacky^> ouch
[02:39:06] <Jacky^> configure: WARNING: Multiple RT signatures found, try to specify one by --with-rtai=<path>
[02:57:24] <Jacky^> mmmhh probably LD_PATH missing ..
[02:57:31] <Jacky^> goodnight !
[11:25:25] <Jacky^> morning
[11:33:00] <Jacky^> cmsdiag.cc:28: internal compiler error: Segmentation fault
[11:33:11] <Jacky^> compiling emc2, anyone know ?
[11:33:33] <Jacky^> i'm using no flag options
[11:47:59] <Jacky^> morning paul_c
[11:49:47] <paul_c> Morning Jacky^
[11:50:05] <ValarQ> mornin folks
[11:50:07] <Jacky^> paul_c: , i'm tryng to get emc2 up and running ..
[11:50:26] <Jacky^> i get a segmentation fault diring make process
[11:50:36] <Jacky^> cmsdiag.cc:28: internal compiler error: Segmentation fault
[11:50:45] <Jacky^> make[1]: *** [all] Error 2
[11:50:45] <Jacky^> make[1]: Leaving directory `/home/james/emc2/src/libnml'
[11:50:45] <Jacky^> make: *** [all] Error 2
[11:50:54] <ValarQ> ow
[11:50:55] <Jacky^> what i'm missing ?
[11:51:14] <ValarQ> what compiler do you use?
[11:51:14] <paul_c> What version of g++ is installed ?
[11:51:41] <Jacky^> there are many version, the lates should be 4
[11:52:03] <paul_c> Running Sid or Sarge ?
[11:52:12] <Jacky^> sarge
[11:52:15] <Jacky^> testing
[11:52:19] <ValarQ> * ValarQ compiled emc2 with debian stable yesterday
[11:52:36] <Jacky^> i compiled the kernel 2-6-12-magma yesterday
[11:52:38] <paul_c> What does "g++ -dumpversion" return ?
[11:53:10] <Jacky^> 4.0.1
[11:54:03] <paul_c> Remove it and install g++-3.3.5
[11:54:07] <ValarQ> is gcc4 considered "stable" already?
[11:54:09] <Jacky^> ok
[11:56:52] <paul_c> Probably not - gcc-2.95 is still the prefered compiler for kernels..
[11:57:45] <ValarQ> paul_c: ok
[11:59:33] <Jacky^> paul_c: it seem thers no 3.3.5 vers. of g++ available from apt
[11:59:45] <Jacky^> 3.4
[12:00:47] <ValarQ> well, debian testing nowadays is... for testing
[12:00:48] <Jacky^> cpp-3.4 g++-3.4 gcc-3.4 gcc-3.4-base libstdc++6-dev
[12:01:43] <Jacky^> and I aready added deb
http://mirrors.neuron.com/emc-bdi/apt/ sarge updates extras in the sources.list
[12:01:52] <paul_c> comment out testing & unstable - Use stable
[12:02:04] <Jacky^> oh ..ok
[12:05:23] <paul_c> if not, "apt-get install g++-3.3"
[12:06:04] <Jacky^> ok, thanks, i'm upgrading
[12:23:58] <Jacky^> now ./configure fails
[12:24:07] <Jacky^> configure: error: no acceptable C compiler found in $PATH
[12:24:21] <Jacky^> checking for gcc... no
[12:25:24] <paul_c> apt-get install g++
[12:25:58] <Jacky^> ok
[12:25:59] <paul_c> probably find the symlinks were not set..
[12:26:18] <Jacky^> i was thinking .. LD_Path ?
[12:26:25] <Jacky^> could be ?
[12:27:01] <ValarQ> maybe its a diffent path to the binaries
[12:27:10] <ValarQ> source /etc/profile # might help
[12:27:27] <Jacky^> ok
[12:28:03] <paul_c> LD_PATH is for libraries, not applications.
[12:28:21] <Jacky^> ok ..
[12:29:17] <Jacky^> ouch :\
[12:29:34] <Jacky^> apt want install again g++-4.0
[12:29:46] <Jacky^> giving apt-get install g++
[12:32:24] <paul_c> g++-4.0 is not in stable, so you must still have other repositories listed (or you didn't do an update)
[12:32:55] <Jacky^> sorry .. right
[12:33:06] <Jacky^> i missing to save the sources.list
[12:33:08] <Jacky^> doh
[12:33:17] <Jacky^> missed*
[12:34:25] <Jacky^> damn .. i edit it as user and forget to save
[12:34:39] <Jacky^> just pressed esc : q!
[12:34:46] <Jacky^> lol
[12:34:53] <Jacky^> too fast ..
[12:35:52] <Jacky^> Get:1
http://ftp.it.debian.org stable/main Packages [3347kB]
[12:35:58] <Jacky^> now its ok ..
[12:38:15] <Jacky^> yesterday night I printed the HAL for Integrators pdf ..
[12:38:19] <Jacky^> very nice
[12:39:43] <Jacky^> paul_c: should be ok: Configuro g++ (3.3.5-3) ...
[12:41:04] <Jacky^> ./configure succesful finished
[12:41:15] <Jacky^> lets see make
[12:47:13] <Jacky^> paul_c: great, thanks a lot
[12:47:33] <Jacky^> i've another issue, running emc2
[12:47:47] <Jacky^> but probably i missed something
[12:47:59] <Jacky^> find: /lib/modules/2.6.12.6-magma/rtai: No such file or directory
[12:51:13] <Jacky^> infact, ive not /lib/modules/2.6.12.6-magma/rtai dir..
[12:52:48] <paul_c> uname -r
[12:53:00] <Jacky^> 2.6.12.6-magma
[12:53:39] <paul_c> apt-get install rtai-modules-2.6.12.6-magma
[12:53:53] <Jacky^> :)
[12:54:29] <Jacky^> installing
[12:55:24] <Jacky^> i wonder what if I copy the modules from /home/james/emc2/rtlib in /lib/modules/2.6.12.6-magma/rtai ?
[12:56:14] <Jacky^> probably also modules conf should be updated after .. in etc
[12:56:43] <Jacky^> anyway, installing from apt
[12:56:44] <paul_c> modules.conf should be OK as it is.
[12:57:05] <Jacky^> so, just coping the files could be work ?
[12:57:13] <Jacky^> .ko
[12:57:27] <paul_c> copying emc2 modules to the /lib/modules/`uname -r`/ tree is a waste of time at present
[12:57:42] <Jacky^> :)
[12:58:08] <paul_c> the run scripts know nothing about finding modules outside the build tree (unless something has changed..)
[12:58:26] <Jacky^> oh.. okay
[13:24:30] <paul_c> why are you rebooting ?
[13:26:52] <Jacky^> installed the new kernel image
[13:27:10] <Jacky^> now ive 2 2.6.12-magma in grub
[13:27:29] <Jacky^> one compiled from myself (withou rtai modules)
[13:27:36] <Jacky^> the other is the kernel image
[13:27:47] <Jacky^> run ok with this latest
[13:28:21] <Jacky^> emc2 run now
[13:28:32] <Jacky^> show the bootsplash
[13:28:45] <Jacky^> but close for config file ..
[13:28:51] <Jacky^> not a problem :)
[13:33:28] <Jacky^> emc2 script can't open config/emc.nml
[13:33:35] <Jacky^> looking for..
[13:48:58] <jacky^^> paul_c: nothing ..
[13:49:14] <jacky^^> heres the report
http://rafb.net/paste/results/Z7wd3574.html
[13:49:21] <jacky^^> wont run
[13:50:12] <paul_c> cd /home/james/emc2
[13:50:29] <paul_c> scripts/emc.run
[13:51:55] <jacky^^> doh
[13:52:09] <jacky^^> thanks ! up and running
[13:53:56] <jacky^^> cool
[13:54:21] <jacky^^> ok, im going to insert the pci parport card now and run some example
[13:54:32] <jacky^^> paul_c: thanks a lot
[13:54:56] <Jacky^> :)
[15:15:04] <paul_c> Hi Ray.
[15:15:14] <rayh> Hi Paul
[15:15:36] <rayh> I got another revised ini from kerry. Will test it in a few minutes.
[15:17:21] <paul_c> Did they try the last build ?
[15:17:45] <rayh> I believe so but I didn't get an answer from Tom.
[15:26:53] <les> hello paul and ray
[15:26:59] <les> kinda quiet
[15:29:16] <rayh> Hi Les
[15:51:38] <cncuser> hi folks :)
[15:52:08] <cncuser> has someone a good link to the configfile parameters for emc2 and what they mean ?
[15:53:36] <cncuser> id like to configure it for mm usage and have some "strange behavior" when fiddling around with default_velocity and max_velocity. infact it does some extra movement in the direction and then some steps in the oposit
[15:54:07] <cncuser> linear_units=1 for mm i assume
[15:56:25] <cncuser> UNITS also is a interesting thing
[15:57:41] <rayh> Sounds to me like overshoot that will require some PID tuning.
[15:58:17] <ValarQ> cncuser: there are som other settings that needs to be updated when changing to mm
[15:58:23] <paul_c> sounds like you need to bug JMK if you are running steppers
[15:59:08] <cncuser> ValarQ: yes, i think so. is there some howtoon how to fiddle you stepperdata into an ini ?
[15:59:27] <ValarQ> cncuser: i don't know
[15:59:42] <cncuser> ic thanks
[16:00:00] <ValarQ> cncuser: you could have a look at my config thought
[16:00:40] <paul_c> JMK split the PID code in to a hal module, so if it isn't loaded, gains will have no affect.
[16:03:51] <rayh> Oh right. Thanks paul_c
[16:04:40] <rayh> So why would it overshoot. Inertia?
[16:05:00] <rayh> Accel/decel to high?
[16:07:33] <paul_c> apart from an occassional check to make sure it compiles, I have never run emc2 HEAD on a real machine..
[16:12:20] <cncuser> i have 1.8 degrees / step. one 360degree turn = 200 steps. a single step equals 0,005 mm. anyone a hint on what options to change ?
[16:13:20] <paul_c> so 1mm=200 steps..
[16:13:28] <cncuser> yes
[16:13:47] <paul_c> input & output SCALE = 200
[16:13:52] <paul_c> UNITS = 1
[16:16:14] <cncuser> thank you paul_c, wasnt there something with ferror and min_ferror to do also ?
[16:17:26] <paul_c> set ferror to 5.0 and min_ferror to hrmmm... 0.1
[16:17:48] <paul_c> sloppy settings, but it will get you started.
[16:18:04] <cncuser> thank you :))
[16:18:21] <cncuser> what does ferror mean anyhow ?
[16:18:49] <paul_c> the distance from commanded position before an error is triggered.
[16:19:24] <cncuser> ok, ic
[16:21:15] <paul_c> * paul_c hands over to rayh for his lecture (including diagrams)
[16:22:23] <cncuser> hmm, ok, i now have a really slow movement any hints ?
[16:23:02] <paul_c> velocity & acceleration...
[16:23:37] <cncuser> paul_c: ic, i play around with those
[16:28:31] <rayh> Boy I wish I had a wiki on ferror.
[16:28:57] <rayh> Should do that from the recent post.
[16:37:57] <cncuser> MAX_VELOCITY and MAX_ACCELERATION to mm/s and mm/sec^2 does that mean like 5 and 25 ? for the default is 1.2 and 20
[16:39:34] <paul_c> If you changed UNITs to 1.0, then yes, max velocity will be 1.2mm per Sec
[16:39:48] <paul_c> or 72mm/min
[16:40:11] <cncuser> hmmm
[16:40:18] <cncuser> i got it working faster once
[16:40:28] <cncuser> but i think it was misconfigured then.
[16:43:11] <cncuser> its doing more like 0.12mm / second
[16:43:24] <cncuser> right now
[16:46:42] <cncuser> CYCLE_TIME = 0.010
[16:46:43] <cncuser> DEFAULT_VELOCITY = 0.0167
[16:46:49] <cncuser> those may be the ones
[16:49:23] <paul_c> libnml down to 201K from rcslib's 900K
[16:54:09] <cncuser> nice :)
[16:54:34] <cncuser> with upz or just with compileoptions and striping ?
[16:55:16] <paul_c> hatchet plus strip --strip-unneeded
[16:55:18] <cncuser> i play around with a rambased distro and need small binaries :)
[16:55:33] <cncuser> ic
[16:55:56] <jepler> "hatchet" is software, or it describes your methodology?
[16:56:00] <cncuser> hmm, 10 millimeter equals about 3 millimeter.. somethings wrong with my config
[17:36:25] <paul_c> Hello Anna
[18:04:53] <Jacky^> table.var is used to create a phase stepping table ?
[18:05:35] <Jacky^> is there some doc about phase stepping table on emc ?
[18:05:45] <Jacky^> better, emc2
[18:22:59] <jepler> in emc1 I think the tables for phase stepping are just hardcoded in emcmot.c
[18:24:34] <Jacky^> jepler: i'm looking at datasheet of an IC stepper driver
[18:25:12] <Jacky^> it has ph1 ph2, and 4 digital inputs for current output regulation
[18:25:48] <Jacky^> i've the table sequence for 1/2 step or 1$ step
[18:26:06] <Jacky^> i eard emc cuold be drive this ic
[18:26:25] <Jacky^> but cant find some doc.. to learn how to :(
[18:27:33] <Jacky^> 1/2 step or 1/4 step *
[18:30:39] <cncuser> hmm, still got no correct dimensions
[18:31:50] <cncuser> i use the motmod module with elra steppers. could it be that it has something todo with microsteps (i dont think so) ?
[18:33:04] <Jacky^> i'm tryng to know it ..
[18:33:23] <Jacky^> emc2 could do it maybe ..
[18:33:28] <cncuser> with the sherline Driver Box
[18:35:48] <rayh> The Sherline Driver box uses 1/4 stepping.
[18:36:14] <Jacky^> hi rayh ,
[18:36:17] <cncuser> 800 steps per revolution (microstepping), equates to 16,000 steps/inch with .050" pitch leadscrew
[18:36:19] <cncuser> hmmm
[18:36:29] <cncuser> ok, so its 200*4 = 800
[18:36:30] <rayh> So you will need 4 times the number of steps required to get one mm.
[18:36:33] <cncuser> ok
[18:36:34] <Jacky^> what about phase stepping table on emc2 ?
[18:36:50] <rayh> Oh Jacky^ .
[18:36:51] <cncuser> sounds good, i try
[18:37:06] <rayh> That has to be a question for jmk or a read of the code itself.
[18:37:23] <Jacky^> ok, thanks :)
[18:38:07] <cncuser> so inpoutscale and outputscale should be 800, right
[18:39:41] <rayh> Oh hey, Jacky^ , there is a good writeup of stepgen and stepping type in hal_doc.
[18:40:42] <rayh> Hal_Introduction.pdf should give it to you. All we have to do is find a copy on line.
[18:40:50] <Jymmm> lol
[18:40:56] <Jacky^> rayh: i read something in HAL for Integratos, i prinet yesterday night..
[18:41:15] <Jacky^> the pdf file, are we talking about the same doc ?
[18:41:36] <Jacky^> i dont think ..
[18:41:40] <cncuser> rayh: thanks, that did it, it seems to work
[18:41:41] <Jacky^> let me check..
[18:41:46] <Jacky^> :)
[18:41:55] <Jacky^> hi Jymmm
[18:41:57] <rayh> Where did you get the document Jacky^?
[18:42:04] <Jacky^> a moment ..
[18:42:19] <rayh> cncuser: Sometimes we have a success.
[18:44:03] <Jacky^> ouch lost the link :\
[18:44:30] <cncuser> rayh: well, emc seems very succesfull to me. allways :)
[18:45:03] <Jacky^> ok, rayh , here:
http://www.linuxcnc.org/EMC2-description.html
[18:45:22] <Jacky^> the file i printed is
http://www.linuxcnc.org/Hal_Introduction.pdf
[18:45:45] <cncuser> hmm, emc changes my inifile everytime i start it it has OUTPUT_SCALE = 800 and after i close it its OUTPUT_SCALE = 1.000 0.000
[18:46:05] <cncuser> but the distances seem to be right.
[18:46:38] <rayh> You need to edit the ini file while EMC is not running.
[18:47:25] <rayh> I'm not clear on how HAL reads these ini variables and sets it's own internal hal parameters from them.
[18:48:31] <cncuser> rayh: i edit it while its not running. but it ignores the outputscale... which obviously has no negative effect
[18:49:18] <rayh> Okay. That must mean that for steppers the input scale is the only one used.
[18:49:32] <rayh> with hal that is.
[18:49:37] <cncuser> seems to me
[18:51:48] <rayh> Someday soon I must get my head around the HAL.
[18:52:19] <cncuser> i need to get my head on the overall way emc and cnc works
[18:52:25] <rayh> Jacky^: I'm downloading that PDF now. If it is out of date, I'll put a new one there.
[18:52:52] <rayh> The one in the doc directory of emc2 is out of date. I'll put the new one there as well.
[18:53:28] <Jacky^> rayh: thanks a lot
[18:53:46] <cncuser> wheres the emc2 doc diredctory ?
[18:54:05] <Jacky^> righ now i'm looking at the Step types, pag 41
[18:55:36] <rayh> cncuser: after you download the cvs module named emc2 it will be docs under that.
[18:56:12] <rayh> Jacky^: Is there only a paragraph that describes stepping types 2-15
[18:56:31] <Jacky^> rayh: yeah, ive seen
[18:57:48] <rayh> Okay. Then this is an older version. I'll get the new pdf into both places.
[18:58:14] <Jacky^> rayh: thanks
[18:59:48] <rayh> 640k v 3++k for the old
[18:59:59] <rayh> Sorry for the inconvenience.
[19:00:46] <Jacky^> :)
[19:00:55] <Jacky^> np
[19:01:45] <rayh> I'll upload to linuxcnc.org first. Sourceforge second. Will take most of an hour each.
[19:02:27] <Jacky^> ok.. dont worry.. thanks
[19:06:20] <Jacky^> dinner time ..
[19:06:28] <Jacky^> later
[19:45:31] <jmkasunich> that was strange...
[19:46:40] <Jymmm> jmkasunich netsplit
[19:46:44] <dmwaters> {global notice} Hi all! this was all my fault, I went to jupe a smaller server, and accidently juped the hub... I apologize for this, and thank you for using freenode!
[19:46:57] <Jymmm> jmkasunich I was told to ask you if you wanted any of the 'pseudo pendant' using an ext NUMPAD keybindings for potential inclusion
[19:47:12] <jmkasunich> huh?
[19:47:26] <Jacky^> hi jmkasunich
[19:47:31] <jmkasunich> hi
[19:47:45] <Jacky^> i've a question ..
[19:48:12] <Jymmm> jmkasunich I'm rewriting the key bindings to tkemc/mini to use a externap numpad as a pendant.
[19:48:31] <Jymmm> s/rewriting/adding/
[19:48:40] <Jacky^> do you think is possible to drive a phase stepping driver using Ph1,Ph2, microstepping using emc2 ?
[19:48:48] <jmkasunich> I know nothing about GUIs, who told you to ask me?
[19:49:01] <Jymmm> jmkasunich three guesses....
[19:49:14] <Jymmm> and the first two dont count.
[19:49:16] <jmkasunich> I think I only need one
[19:49:21] <Jymmm> lol
[19:49:46] <Jymmm> well, he thought you might want to include it in emc2 (*shrug*)
[19:50:44] <jmkasunich> it is probably a good thing for emc2, but I'm not "Mr emc2"
[19:51:22] <Jymmm> that's not what I've been told =)
[19:51:37] <Jymmm> Will the REAL Mr EMC2 please stand up
[19:52:01] <jmkasunich> it's an open source project, I don't think there is a single "mr emc2"
[19:52:14] <Jymmm> jmkasunich Ok, so wth ARE you working on? (just curious)
[19:52:30] <jmkasunich> we have folks that know the GUIs, folks that know the low level code, folks that know the interpreterm, etc
[19:52:47] <jmkasunich> my area is low level code, the motion controller and drivers and such
[19:52:55] <Jymmm> ah, ok
[19:53:14] <Jymmm> I'll slap him around a bit the next time I see him, you should do the same =)
[19:58:52] <alex_joni> greetings all
[19:59:13] <jmkasunich> hi alex
[20:02:24] <Jacky^> hi alex_joni
[20:02:56] <jmkasunich> sorry jacky, got distracted and didn't answer your question
[20:03:13] <jmkasunich> I don't understand exactly what you were asking
[20:03:14] <Jacky^> jmkasunich: np
[20:03:55] <Jacky^> i'd like to drive some IC stepper drive type LB11847
[20:03:58] <jmkasunich> what is a "phase stepping driver using Ph1,Ph2, microstepping"?
[20:04:10] <Jacky^> right today i get emc2 up and running
[20:04:26] <alex_joni> jmkasunich: long time no see ;)
[20:04:29] <alex_joni> what's new?
[20:04:34] <jmkasunich> not much
[20:04:37] <Jacky^> i've the table step sequence for 1/2 and 1/4 step
[20:04:41] <alex_joni> nice
[20:04:42] <alex_joni> * alex_joni is home
[20:04:45] <alex_joni> that's smthg new :D
[20:04:45] <Jacky^> but,
[20:05:01] <Jacky^> there are also 4 digital input for current control
[20:05:30] <Jacky^> i've seen that maybe stepgen could do something ..
[20:05:34] <Jacky^> i'm not sure
[20:05:44] <jmkasunich> what kind of driver is this? do you have a URL for docs?
[20:05:47] <Jacky^> and i found few doc
[20:06:06] <Jacky^> theres a small pdf online
[20:06:15] <Jacky^> give me a sec..
[20:06:32] <alex_joni> jmkasunich: got time to think about my last mail?
[20:06:56] <Jacky^> jmkasunich: javascript:openreq('
http://www.ortodoxism.ro/datasheets/sanyo/ds_pdf_e/LB1845.pdf')
[20:07:06] <alex_joni> lol :)
[20:07:14] <alex_joni> jmkasunich does javascript now?
[20:07:25] <Jacky^> ops, sorry .. its java.. damn
[20:07:33] <Jacky^> http://www.datasheetcatalog.com/datasheets_pdf/L/B/1/8/LB1845.shtml
[20:07:39] <jmkasunich> * jmkasunich looks for alex's last email
[20:07:45] <Jacky^> you should click on the right
[20:08:24] <Jacky^> it is from an old epson printer, i would like to build a small robotic harm
[20:08:32] <jmkasunich> just a chip, not a complete driver?
[20:08:44] <Jacky^> the table is on pag 5 of datasheet
[20:08:59] <Jacky^> it is a printer driver
[20:09:12] <Jacky^> it work,
[20:09:38] <Jacky^> of course the inputs are controlled by microchip and usb port at the moment
[20:09:56] <Jacky^> but i know the pins to use
[20:10:28] <anonimasu> hm
[20:10:36] <alex_joni> hey anonimasu
[20:10:36] <Jacky^> hi anonimasu
[20:10:39] <anonimasu> hello
[20:11:46] <jmkasunich> jacky: that chip is not designed for microstepping
[20:12:03] <Jacky^> half step ?
[20:12:12] <Jacky^> 1/4 step ..
[20:12:16] <jmkasunich> full, half, or maybe "quarter"
[20:12:49] <Jacky^> i've seen 2 tables, 1/2 and 1/4
[20:13:44] <Jacky^> i wonder if is possible to drive pin I01,I11,I02,I12
[20:14:00] <Jacky^> they are digital inputs to set the current
[20:15:06] <Jymmm> WooHoo! finally cnc my first piece!
[20:15:15] <alex_joni> thank god
[20:15:22] <alex_joni> * alex_joni marks his calender
[20:15:23] <Jacky^> Jymmm: :D congrats
[20:15:35] <Jymmm> * Jymmm hands alex_joni a marker
[20:15:53] <Jymmm> * Jymmm tatoos alex_joni ass witht he date too!
[20:16:10] <anonimasu> Jymmm: how does it look?
[20:16:12] <LawrenceG> Hi Jacky... you should be able to set up the table and wire up the i/o to make that work... each "step" just increments or decrements through the table
[20:16:41] <jmkasunich> jacky: I think those pins are for things like reducing current during standby
[20:16:44] <Jymmm> anonimasu like the drawing =)
[20:16:51] <anonimasu> drawing?
[20:16:56] <jmkasunich> they wouldn't be usefull for microstepping I think
[20:16:57] <Jymmm> anonimasu just a square with a circle in it.
[20:17:01] <Jacky^> LawrenceG: yeah..
[20:17:10] <anonimasu> oh, so you didnt cut metal :/
[20:17:18] <Jacky^> jmkasunich: do you think can i ignore them ?
[20:17:25] <anonimasu> yet :)
[20:17:27] <anonimasu> congratulations
[20:17:27] <Jymmm> anonimasu it's a gantry router =)
[20:17:30] <Jacky^> maybe not for a long time stand by ..
[20:17:35] <anonimasu> Jymmm: and?
[20:17:41] <anonimasu> :)
[20:17:56] <jmkasunich> pull them low probably
[20:18:03] <anonimasu> * anonimasu is packing for germanu
[20:18:05] <Jymmm> anonimasu I never intended to do anything but wood/plastic (though I'll eventually try way doen the road)
[20:18:05] <anonimasu> germany
[20:19:44] <Jacky^> jmkasunich: the datasheet says The ouptut current can bre set to 1/3 2/3 or full by setting these pins to appropriate combinations og H of L level
[20:19:58] <Jacky^> so, i can try different combination
[20:20:06] <Jacky^> to see what work better ..
[20:20:15] <Jacky^> I suppose
[20:20:25] <jmkasunich> there is a table - both low = full current, both high = off, etc
[20:20:34] <Jacky^> yeah ..
[20:21:00] <Jacky^> should be not hard
[20:21:40] <Jacky^> instead, for the phase stepping table.. i was looking for some doc
[20:21:51] <Jacky^> maybe in the modules code ?
[20:21:54] <rayh> Okay jacky^^ the latest Hal_introduction.pdf is up at linuxcnc.org.
[20:22:06] <Jacky^> rayh: thanks a lot
[20:22:15] <jmkasunich> the phase sequences are in that doc
[20:22:37] <Jacky^> ok, jmkasunich , thanks for the patience :)
[20:23:19] <Jacky^> i'm going to dowload the uptadet docs
[20:25:59] <rayh> jmkasunich: I'm putting that in emc2/docs right now.
[20:27:31] <alex_joni> hey rayh
[20:27:56] <jmkasunich> OK Ray, thanks
[20:28:11] <alex_joni> jmkasunich: found that mail?
[20:28:16] <jmkasunich> yeah
[20:37:50] <rayh> Hi Alex
[20:38:03] <alex_joni> what's up rayh?
[20:42:02] <rayh> the faster I go the further behind I get.
[20:42:20] <cradek> hi all
[20:44:03] <alex_joni> hey chris
[20:49:22] <CIA-8> 03rayhenry * 10emc2/docs/Hal_Introduction.pdf: 25 sept 06 pdf
[20:49:54] <jmkasunich> rayh: 06?
[20:50:29] <alex_joni> next year version
[20:50:33] <alex_joni> * alex_joni wants a copy
[20:50:40] <rayh> oops.
[20:50:51] <rayh> Getting ahead of myself by a year.
[20:55:52] <Jymmm> 1406
[20:56:12] <Jymmm> wb alex_joni
[20:56:15] <alex_joni_> thx
[20:56:38] <Jymmm> anybody know how to cleanup after wood carving?
[20:56:49] <alex_joni_> napalm should work
[20:56:51] <paul_c> hoover.
[20:57:00] <Jymmm> lol...
[20:57:17] <alex_joni_> hi paul_c
[20:57:21] <Jymmm> lil stray bits in the text carving
[20:57:53] <Jymmm> a toothbrush seems to help, but not for all of it
[20:59:11] <ValarQ> alex_joni_: hello civilian
[20:59:42] <alex_joni_> hello captain
[20:59:42] <alex_joni_> :D
[21:00:15] <Jymmm> alex_joni == Gilligan?
[21:00:35] <ValarQ> :)
[21:00:50] <alex_joni_> Jymmm == island ;)
[21:01:00] <Jymmm> If alex_joni == Gilligan, I want to know who Ginger is?
[21:01:18] <jmkasunich> mmmmm... Ginger.... spicy
[21:01:44] <Jymmm> * Jymmm tosses jmkasunich on a barrel of horseradish!
[21:01:48] <alex_joni_> ginger ale
[21:01:50] <paul_c> 198K...
[21:01:50] <Jymmm> s/on/in/
[21:04:29] <les> clean up?
[21:04:48] <les> scotchbrite
[21:05:29] <les> if incised letters us the coarsest abrasive loaded bristle wheel
[21:07:02] <les> you know, nylon bristles with imbedded grit particles
[21:11:10] <alex_joni_> bye biatch
[21:11:19] <alex_joni_> alex_joni_ is now known as alex_joni
[21:22:51] <paul_c> * paul_c wonders if zwelch is awake..
[21:23:23] <alex_joni> * alex_joni poors a bucket of cold water over zwelch
[21:23:58] <paul_c> * paul_c hands alex_joni a 'u'
[21:24:23] <alex_joni> right
[21:27:48] <Jymmm> * Jymmm takes away paul_c alphabet cuz he doens't know how to spell COLOR!
[21:28:27] <paul_c> * paul_c hands Jymmm The Oxford English Dictionary.
[21:28:36] <cradek> * cradek offers Jymmm a 's, a "cause", and a "doesn't"
[21:28:51] <Jymmm> * Jymmm burns it
[21:31:48] <paul_c> * paul_c mails Jymmm an American<->English dictionary
[21:32:30] <Jymmm> cradek the doesn't was a typo, the cuz was to be funny - quit mucking up my jokes by being a pita
[21:33:09] <Jymmm> paul_c alright.... go write some html/css using "COLOR" for the spelling and see what happens =)
[21:33:19] <jmkasunich> English is a foreign languate
[21:33:24] <jmkasunich> English is a foreign languag
[21:33:28] <jmkasunich> dammit!!!!
[21:33:29] <Jymmm> lol
[21:33:31] <jmkasunich> English is a foreign language
[21:33:33] <cradek> haha
[21:33:48] <jacky^^> O_O
[21:33:52] <paul_c> that (most) Americans haven't spoken for years.
[21:34:20] <paul_c> [G.B. Shaw]
[21:34:52] <Jymmm> paul_c yo momma!
[21:35:32] <paul_c> Spanish seems to be more widely spoken in most parts of the USA
[21:35:43] <Jymmm> Si Senior
[21:35:53] <anonimasu> heh
[21:36:54] <jacky^^> ciao :D
[21:37:56] <jacky^^> i'm tryng to understand this pahse stepping ..
[21:38:09] <jacky^^> but is antic aramaic !
[21:38:59] <jacky^^> probably, after ill read it 1-2k times..
[21:39:14] <jepler> "antic"?
[21:39:33] <jacky^^> very old..
[21:39:40] <jacky^^> antiques ?
[21:40:22] <jacky^^> ancient !
[21:41:09] <Jymmm> Jacky^ just be lucky it's not a ancient chinese dialect
[21:41:26] <jacky^^> :\
[21:41:49] <alex_joni> Jymmm: aramaic might be older
[21:42:03] <Jymmm> alex_joni but chinese harder
[21:42:04] <alex_joni> anyways.. for ancient chinese you might find somebody that still knows it
[21:42:18] <Jymmm> there's over 3000 chinese dialetcs
[21:43:56] <alex_joni> and over a billion chinese guys
[21:44:02] <alex_joni> very probable ;)
[21:59:30] <paul_c> Oh fer.... sake....
[22:00:05] <alex_joni> wot's wrong?
[22:00:08] <paul_c> Got some herbert wanting an emc2 deb..
[22:00:25] <alex_joni> heh ;)
[22:00:27] <alex_joni> and?
[22:01:05] <paul_c> exactly.... "and".
[22:01:38] <alex_joni> you might be wellbehaved and set one up for him :D
[22:01:49] <alex_joni> although..
[22:01:53] <rayh> does bdi support sata?
[22:02:02] <alex_joni> sata is evil
[22:02:03] <alex_joni> :D
[22:02:43] <paul_c> rayh: sata modules are compiled and installed.
[22:03:22] <rayh> Thanks guys.
[22:04:05] <paul_c> I don't have any sata drives or MoBo to test them on..
[22:07:53] <paul_c> alex_joni: I really don't see any point in packaging emc2 as a deb at the moment...
[22:08:12] <alex_joni> just to prove you can ;)
[22:08:36] <jmkasunich> IMO emc2 should be compiled by the user right now
[22:09:16] <jmkasunich> if you can't follow the relatively simple instructions for compiling (on the wiki for instance) you aren't ready to use EMC2 (more accurately EMC2 isn't ready for you)
[22:11:05] <paul_c> alex_joni: Are you sitting in front of a Debian install ?
[22:12:33] <jepler> I'm proud to announce AXIS 1.1rc1.
http://axis.unpy.net/index.cgi/01127680343
[22:13:26] <alex_joni> paul_c: right now?
[22:13:31] <alex_joni> nope
[22:14:33] <paul_c> Hohumm... No point in getting you to install the advanced system recovery manpages then...
[22:14:48] <paul_c> apt-get install asr-manpages
[22:14:58] <alex_joni> jepler: nice to hear that
[22:15:04] <robin_sz> hi alex
[22:15:27] <alex_joni> hey rayh
[22:15:29] <alex_joni> robin_sz
[22:15:33] <alex_joni> darn autocomplete ;)
[22:21:05] <robin_sz> how the world of welding?
[22:21:08] <alex_joni> nice
[22:21:17] <alex_joni> the fair in essen was worth the trip
[22:21:32] <robin_sz> plenty of robot gear?
[22:33:24] <alex_joni> yeah
[22:33:28] <alex_joni> more than plenty
[22:38:30] <alex_joni> robin_sz: a few exhibitors:
http://www.schweissenundschneiden.de/index.php?content=01030000&lang=de&action=showlist
[22:38:43] <robin_sz> looking
[22:40:14] <alex_joni> do you know microstep?
[22:41:35] <zwelch> * zwelch pokes his head in
[22:41:44] <zwelch> * zwelch waves to paul_c and jmkasunich
[22:41:47] <alex_joni> morning zwelch
[22:41:53] <zwelch> * zwelch waves to alex_joni too
[22:42:06] <alex_joni> * alex_joni waves back
[22:42:15] <alex_joni> paul_c was looking for you sooner
[22:42:53] <alex_joni> robin_sz: www.microstep.com , some nice plasma cutting machines
[22:43:44] <zwelch> jmkasunich: i hear that you're the person to clue me in about building emc2 without RT bits
[22:44:18] <jmkasunich> without RT? not currently possible
[22:44:26] <zwelch> i know
[22:44:33] <alex_joni> he wants to code that
[22:44:36] <zwelch> however, i've got it building without it
[22:44:52] <alex_joni> and I told him you might be the man to ask about stuff like that
[22:44:57] <jmkasunich> how'd ja do that?
[22:45:09] <zwelch> * zwelch points to his axe... "lots of hacking"
[22:45:18] <zwelch> it's not pretty
[22:45:21] <zwelch> but it compiles
[22:45:30] <jmkasunich> you hacked rtapi?
[22:45:34] <paul_c> jmkasunich: Let me introduce you to Number 51
[22:45:39] <zwelch> yes, i implemented the sim rtapi
[22:45:48] <alex_joni> hope not area 51 ;)
[22:45:57] <jmkasunich> developer 51?
[22:46:13] <zwelch> * zwelch points to the fresh barcode on his forehead and nods
[22:46:35] <alex_joni> nice tatoo
[22:46:56] <jmkasunich> is the sim_rtapi in CVS anywhere
[22:46:59] <jmkasunich> * jmkasunich wants to look
[22:47:04] <zwelch> jmkasunich: the thing is... the sim api was implemented with pthreads, yah?
[22:47:11] <zwelch> (or wanted to be?)
[22:47:24] <zwelch> i.e. there was existing pthread code there, so i "finished" implmented the module
[22:48:10] <zwelch> but after getting "everything" to compile, i realized that it will be a bit more work to build the system sans kernel modules
[22:48:17] <jmkasunich> I haven't touched the sim code in about 2 years
[22:48:30] <jmkasunich> "bit more work" is an understatement
[22:48:40] <zwelch> i.e. build the rtapi and all the hall modules as UL code (done) and then link them to the UL spaces
[22:48:44] <zwelch> yes, i know
[22:48:51] <zwelch> i know now, i should say ;)
[22:49:04] <jmkasunich> and since HAL relies on the ability of one kernel module to call functions in another, I couldn't see a way to do it in user space
[22:49:24] <zwelch> "export"? :/
[22:49:28] <jmkasunich> (calls are based on run-time "linking"
[22:49:33] <zwelch> erm... "extern" i mean
[22:49:38] <zwelch> * zwelch uses too many programming languages
[22:50:07] <zwelch> is there any strict reason why you can't link at compile-time?
[22:50:27] <jmkasunich> I don't think so - two kernel modules can be insmoded separately but share the same kernel address space so one can export functions to HAL, and later the HAL lib can call the functions
[22:50:39] <robin_sz> * robin_sz falls off his chair
[22:50:43] <robin_sz> well , bar stool
[22:50:48] <jmkasunich> but if they were linux user processes instead, they would each have their own address spaces
[22:50:57] <zwelch> huh?
[22:51:16] <jmkasunich> hmmm... how to explain
[22:51:34] <zwelch> you can have N threads in one address space
[22:51:41] <alex_joni> * alex_joni picks robin_sz up, and puts him to bed to sleep his drunkness out
[22:51:48] <zwelch> * zwelch is intimately familiar with pthreads
[22:51:53] <jmkasunich> * jmkasunich is not
[22:52:00] <alex_joni> threads yes, but not processes, afaik
[22:52:19] <robin_sz> alex_joni: I was just shocked to see someone compiling emc without RT support .. thats considered heresy in some parts around here ...
[22:52:23] <zwelch> * zwelch doesn't want to get into that story... no one wants to hear how someone woke up with a hangover next to a threading library
[22:52:26] <jmkasunich> what HAL needs is the ability for a single thread to execute code that is part of several modules
[22:52:52] <alex_joni> which are actually different processes
[22:53:00] <alex_joni> as in different programs
[22:53:23] <jmkasunich> for example, you can insmod a parport driver, and a step generator, and they are both in kernel space, so HAL can call the step gen first to generate steps, then the parport driver to output them
[22:53:30] <robin_sz> one thing linux is good at is stopping one program peeking at what another one is doing
[22:53:41] <jmkasunich> but if they were in user space, stepgen and parport would be two different processes
[22:53:59] <zwelch> okay, i know how to solve this
[22:54:06] <jmkasunich> it would be hard to call the stepgen and then the parport code
[22:54:07] <paul_c> for non-rt sim, would you need h/w drivers ?
[22:54:20] <alex_joni> not really
[22:54:27] <zwelch> paul_c: you would probably need a simulated driver
[22:54:33] <alex_joni> but you still have the iocontroller, and interpreter, and motion controller
[22:54:40] <alex_joni> and others aswell
[22:54:44] <jmkasunich> ok, so bad example, but you might want an encoder module to count the pulses generated by the stepgen
[22:54:51] <robin_sz> I suspect zwelch is planning on real hardware, wwithout realtime supprt
[22:54:53] <alex_joni> so you still have more than one process
[22:54:53] <paul_c> interp is not a hal modules.
[22:54:59] <alex_joni> not yet
[22:55:01] <alex_joni> ROFLMAO
[22:55:10] <paul_c> alex_joni: Not ever.
[22:55:13] <alex_joni> just teasing.. strike that
[22:55:35] <zwelch> anyway, i think the real trick here is to get all those modules to build as libraries code which can either be linked as a kernel module or as a convenience library
[22:55:38] <robin_sz> zwelch: you intending to drive real hw with the non-rt stuff?
[22:55:43] <zwelch> robin_sz: no
[22:55:49] <robin_sz> oh, ok, just asking
[22:55:56] <zwelch> i want the latest tree to build for anyone, on any distro
[22:56:09] <alex_joni> maybe external hardware pulsegenerators might be driven by it
[22:56:14] <alex_joni> and it might even work
[22:56:15] <zwelch> without having to so much as change their kernel
[22:56:17] <jmkasunich> HAL basically implements DLL type stuff, where the user (or a config file) defines what is linked to what
[22:56:22] <robin_sz> alex_joni: careful now ...
[22:56:54] <zwelch> jmkasunich: right, given that design, i think the easist path is to create an alternate link target that builds the sim-version
[22:57:17] <robin_sz> zwelch: isnt there a danger of it being so far removed from the real version that development on non rt platofrms is not sufficiently close to reallity to make it worthwhile?
[22:57:32] <jmkasunich> if you want... but for me, the whole point of HAL is being able to interactivly link/unlink stuff
[22:57:42] <zwelch> robin_sz: umm, i'm working from the current HEAD and plan to push my changes there asap...
[22:58:14] <zwelch> jmkasunich: for a simulator without real hardware, does that matter?
[22:58:37] <jmkasunich> I think so, but I may be in the minority
[22:58:45] <zwelch> i agree that modularity is better, and we can get there...
[22:59:02] <paul_c> zwelch: You (should) commit little and often - That way, more than one can assist with testing/debugging
[22:59:07] <jmkasunich> HAL sort of works like a breadboard for electronic circuits
[22:59:14] <zwelch> paul_c: yeah, i get that a lot
[22:59:34] <jmkasunich> and we can see what you have in mind
[23:00:07] <zwelch> well, this discussion is helping me determine whether or not i have been barking up the wrong line of development
[23:00:22] <zwelch> ... and, thus, whether or not the bits i've got are worth committing
[23:00:32] <zwelch> personally, i don't think they are...
[23:00:40] <robin_sz> commit them to a branch, so we can ll look
[23:00:58] <zwelch> because once i got everything compiling, i realized how kernel centric the application is
[23:01:33] <zwelch> and it made me rethink some of the fundamental changes that i made (that would invalidate most successive changes)
[23:01:59] <jmkasunich> my approach might make more sense if you know that my background is small system embedded work, single address space, no MMU, etc
[23:02:07] <paul_c> About the only thing from using "normal" kernel space for the RT code is the shared memorylayer.
[23:02:10] <jmkasunich> so kernel space is more "normal" to mee
[23:02:16] <zwelch> which is why i am here trying to determine just how big the mountain of getting EMC2 to build exclusively in userland
[23:02:21] <robin_sz> I suspect anyone doing ang any real development would just build an RT kernel ... sim was mainly so newbies could "see what it did" with minimal fuss, before installign it properley
[23:02:56] <zwelch> robin_sz: stop trolling
[23:03:19] <jmkasunich> that was a troll?
[23:03:24] <robin_sz> oh ffs .. ok I give up
[23:03:24] <zwelch> i am a "real developer", not a "newbie"
[23:03:30] <paul_c> looked like a precursor
[23:04:53] <zwelch> robin_sz: if your half dozen last comments were not trolls, you really need to take a few more minutes to consider your choice of wording and how it might be perceived by others
[23:06:06] <zwelch> jmkasunich: i have been doing embedded linux work for five years, and kernel space is not normal for applications
[23:06:36] <alex_joni> zwelch: not normal for linux applications, I agree
[23:06:48] <jmkasunich> define "embedded work"... if you have kernel space and user space, it isn't the kind of embedded I'm referring to
[23:06:58] <alex_joni> but if you do embedded programs (as in no kernel, just one program), then it might relate to a kernel app
[23:07:14] <jmkasunich> I mean things like Z-80, or 32 bit machines with flat address space and running perhaps 4 threads (ISRs), code in ROM, etc
[23:07:32] <robin_sz> sorry, but I cannot see anything vaguely troll like in there ... to the best of my knowledge sim was intedned for "tryouts" ... if you manage to read some sort of troll attempt into it .. or any other of my comments, then its beyond me
[23:07:32] <zwelch> jmkasunich: if you're running linux, then the hardware should be beyond the level of resources that cover the class of embedded you are describing
[23:08:06] <zwelch> * zwelch shrugs
[23:08:06] <jmkasunich> the original sim was indeed intended for newbie tryouts, that's not a troll, just a statement of fact
[23:08:15] <jmkasunich> zwelch is trying to do far more than that tho
[23:08:26] <robin_sz> yeah, I know ...
[23:08:39] <robin_sz> I was kinda wondering why .. thats all.
[23:08:48] <Jacky^> sorry.. can I saya word ?
[23:09:00] <robin_sz> if you take it too far, then does it actually remian of use?
[23:09:05] <robin_sz> thats all ...
[23:09:06] <zwelch> robin_sz: the statement before "the fact" was what bothered me so much... the presumption that "anyone doing any real development would just build an RT kernel"
[23:09:09] <Jacky^> one thing is to talk about an indea, another is to try and test it
[23:09:09] <jmkasunich> zwelch: yes, the rescources are far beyond, but for better or worse, I'm using the techniques I'm familiar with
[23:09:41] <zwelch> robin_sz: and the pattern of "contrary sans constructive" comments preceeding it
[23:10:14] <zwelch> jmkasunich: okay, well, i'm not saying that i'm unimpressed with what's been done
[23:10:18] <robin_sz> zwelch: you are reading into my comments way, WAY more than I can see here ...
[23:10:59] <alex_joni> guys, can we get back to dev talk?
[23:11:04] <jmkasunich> please
[23:11:17] <alex_joni> * alex_joni is tired
[23:11:37] <alex_joni> I am trying to focus on stuff, but troll talking doesn't help :)
[23:11:50] <zwelch> jmkasunich: the conclusion i have reached from this conversation is this: "there's probably no reason for having as much of the code in the kernel as there is"
[23:12:20] <jmkasunich> except that I can't see a way to make a single thread execute code from multiple user space processes
[23:12:22] <zwelch> i assure you that you can get the same kind of "plug and play" modularity from UL as you're getting from the kernel modules
[23:12:32] <jmkasunich> at least not without much overhead
[23:12:42] <zwelch> well, throw out that as an "unncessary assumption"
[23:12:42] <jmkasunich> how?
[23:12:50] <zwelch> UL can do modules
[23:13:25] <jmkasunich> 'splain it to me
[23:13:28] <zwelch> and macros can wrap an necessary late binding code
[23:13:34] <zwelch> libltdl?
[23:13:45] <zwelch> man dlopen and friends
[23:14:10] <jmkasunich> * jmkasunich googles
[23:14:12] <zwelch> moreover, i've implemented this stuff in the past
[23:14:21] <zwelch> no really, run 'man dlopen' :)
[23:14:32] <jmkasunich> nothing on my box (not installed I guess)
[23:14:33] <alex_joni> but this is compiletime
[23:14:37] <alex_joni> nor runtime
[23:14:42] <alex_joni> correct me if I am wrong..
[23:14:48] <zwelch> jmkasunich: odd
[23:15:03] <zwelch> alex_joni: you can compile time call functions in loadable modules
[23:15:05] <zwelch> no problem
[23:15:06] <jmkasunich> brand new default BDI-4.27 install
[23:15:19] <paul_c> apt-get install manpages-dev
[23:15:21] <zwelch> jmkasunich: ah, probably doesn't have the man-pages package, or something
[23:15:27] <zwelch> apt-get install man-pages? :)
[23:15:36] <paul_c> apt-get install manpages-dev
[23:15:40] <zwelch> ah
[23:15:57] <zwelch> or maybe it's in the glibc-man-pages (if such exists?)
[23:16:00] <zwelch> * zwelch shrugs
[23:16:34] <jmkasunich> installing now
[23:16:58] <paul_c> The default install doesn't include much of the dev stuff.
[23:17:17] <jmkasunich> ahh... that's better
[23:17:23] <zwelch> * zwelch isn't surprised... you shouldn't have dev stuff on a production box
[23:17:39] <zwelch> and if "a RT machine control system" doesn't count as production, i don't know what does
[23:17:50] <jmkasunich> this is my main workstation / development system
[23:18:06] <alex_joni> heh
[23:18:24] <alex_joni> * alex_joni has seen to many doze production boxes
[23:18:49] <alex_joni> even blue-screened ones ;)
[23:19:17] <zwelch> jmkasunich: well, "shouldn't" != "can't" ;)
[23:19:39] <jmkasunich> gonna take some reading to understand the dlopen stuff
[23:19:46] <zwelch> well, don't bother
[23:19:53] <zwelch> it's just the foundation used by libltdl
[23:19:58] <zwelch> which is part of libtool
[23:20:15] <alex_joni> included in autotools
[23:20:16] <zwelch> libltdl wraps the dl* family of calls
[23:20:33] <zwelch> and makes module loading portable across all architectures supported by libtool (including windows)
[23:20:59] <jmkasunich> but to me (again, this is because of my background) those things are far more complex than doing things in kernel space where you have a nice flat memory map, everybody has the same address space, and it acts like a plain old CPU (MMUs are a pain in the ass) ;-)
[23:21:08] <zwelch> no
[23:21:17] <zwelch> i want emc2 to be a single process with N threads
[23:21:26] <zwelch> instead of N processes with M threads
[23:21:38] <zwelch> okay (1:N+M in the future, after seeing the math)
[23:22:03] <zwelch> so, you'll have a single address space :)
[23:22:07] <jmkasunich> huh (I understood the first part, but what is (1:N+M)?
[23:22:15] <alex_joni> 1=N+M
[23:22:31] <zwelch> the new version will have 1 process and N+M threads, given the old way of Np w/ Mt
[23:23:13] <zwelch> i am assuming that some of the currently independent processes have more than one thread
[23:23:16] <zwelch> otherwise, M == 1
[23:23:37] <zwelch> and it collapses back to my original assumption that we'll have N threads in one process
[23:23:44] <jmkasunich> actually, the old way was N processes, each with 1 (user) thread, communicating between each other using NML, and also communicating with a number of kernel modules (not processes per se) that also had several RT threads
[23:24:27] <zwelch> now, the fun part is that we're talking purely conceptual at the moment... but when Linux actually implements pthreads, it does so with processes :)
[23:24:39] <jmkasunich> GUIs will probably want to remain separates processes and use NML to communicate, so that they can run on remote boxes for instance
[23:24:43] <zwelch> so you end up with N processes that share an address space
[23:24:59] <zwelch> yes, guis should always be built on top of an engine, imo
[23:25:06] <jmkasunich> ok, this is starting to sound exciting
[23:25:13] <zwelch> * zwelch grins
[23:25:17] <robin_sz> I'm probably being thick here, and this is not a troll, but are you talking about a system for actual use, with real hardware, or a system purely for developemnt, reverting to RT kernel modules in actual use? I thnik I have sort of lost track here ...
[23:25:35] <zwelch> robin_sz: well, so have i :)
[23:25:39] <jmkasunich> now, how can you dynamically load code and have it share address space with a running process? (I suppose that's where the DLL and shared lib tools come in)
[23:26:04] <zwelch> robin_sz: i'm looking mostly from the perspective of simulation
[23:26:09] <jmkasunich> robin: the RTAI folks do something called LXRT, that is hard RT in user space
[23:26:24] <robin_sz> coo.
[23:26:27] <zwelch> jmkasunich: the dl* family of calls manages mapping in the code at different addresses
[23:26:43] <jmkasunich> so if the dynamic/modularity things can be addressed, then possibly both sim and real can use the same system
[23:26:47] <zwelch> it's like loading lib*.so's at launch
[23:27:13] <jmkasunich> * jmkasunich is clueless about .so stuff ;-/
[23:27:17] <zwelch> jmkasunich: i believe it should be possible for the RT to use these changes
[23:27:24] <zwelch> jmkasunich: dynamic libraries, like libc
[23:27:55] <zwelch> jmkasunich: how do you get to be able to call "printf" in libc? through the magic of dlopen and friends
[23:27:58] <paul_c> jmkasunich: libnml is already .so.0 (at least for the BDI-4 build)
[23:28:09] <jmkasunich> I know they exist, and I know what they do, but how they do it is magic
[23:28:15] <zwelch> jmkasunich: we'll be doing exactly the same kind of thing as the linker
[23:28:23] <jmkasunich> remember, I cut my teeth on systems without disks
[23:28:35] <zwelch> jmkasunich: yeah, i've done that too ;)
[23:28:51] <zwelch> jmkasunich: i can show you some example code
[23:29:14] <jmkasunich> ok
[23:29:43] <zwelch> * zwelch realizes that may be easier said than done ;)
[23:30:38] <jmkasunich> how familiar are you with hal concepts (particularly "loadrt", "addf" and friends)
[23:30:59] <zwelch> jmkasunich: i'm completely clueless
[23:31:11] <zwelch> i've been reading the HAL Introduction pdf in bits
[23:31:40] <zwelch> so i guess i'm more "mostly clueless" ;)
[23:32:41] <zwelch> one of the big questions that i have regards the systems hard RT requirements
[23:33:06] <jmkasunich> that really depends on your hardware and external stuff
[23:33:20] <zwelch> well, i mean in terms of the code
[23:33:44] <jmkasunich> ?
[23:33:58] <paul_c> if you remove the need for h/w IO, RT is not important
[23:34:24] <zwelch> okay, so the answer is "only the h/w IO bits require hard RT", correct?
[23:34:30] <paul_c> IOW - if you just want to simulate, run in usr space.
[23:34:49] <zwelch> * zwelch still isn't sure what the question was, but he thinks that's the answer
[23:35:02] <jmkasunich> perhaps, but you'd still like to be sure that your "1mS" thread executes ten times as often as your "10mS" thread, even if neither one runs at any specific time interval
[23:35:08] <paul_c> There are other parts that require RT if h/w is being controlled
[23:35:38] <zwelch> well, they are probably part of the hw i/o chain, yah?
[23:35:50] <alex_joni> there are some timing you need to assure
[23:35:59] <alex_joni> part of trajectory planing & co
[23:36:14] <alex_joni> those are also critical when controlling HW
[23:36:25] <zwelch> jmkasunich: yeah, i understand that... and i'm definitely looking to implement a "superlinear time" feature ;)
[23:36:44] <jmkasunich> you still must keep things in sync with each other, they just don't need to remain in sync with any outside measure of time
[23:37:24] <zwelch> jmkasunich: right
[23:37:34] <zwelch> well, that's what SCHED_FIFO is for, yah? :)
[23:37:51] <zwelch> * zwelch wishes it was just that easy, but still
[23:38:09] <zwelch> the most important conclusion is that "it can be done"
[23:38:33] <jmkasunich> for me the key thing is retaining modularity and runtime configurability
[23:38:37] <zwelch> * zwelch is starting to feel that can be said, but he needs to take this fresh information and look at the code again
[23:38:51] <jmkasunich> that means using dynamic lib techniques, to keep all loaded code in one process space
[23:39:30] <jmkasunich> I would want to look very closely at LXRT, and try to do the hard RT version using the same techniques as the sim version
[23:39:56] <jmkasunich> I don't want to try to compile the code as kernel modules for hardRT and as user space libs for sim
[23:40:02] <jmkasunich> the build system is bad enough as it is
[23:40:22] <paul_c> lxrt & fusion do not have the latency you need for stepper systems.
[23:40:29] <zwelch> jmkasunich: that's what my hacks have done
[23:40:31] <jmkasunich> however, if we could get away from kernel code and do even the RT part in user space with LXRT, that would be a net improvement to the build system
[23:40:47] <robin_sz> * robin_sz nods
[23:41:10] <zwelch> jmkasunich: got a url for LXRT?
[23:41:13] <jmkasunich> from what Paul says it comes down to performance then
[23:41:21] <zwelch> the other option for user space RT is RTAI/Fusion
[23:41:23] <alex_joni> only if LXRT provides the same functionality
[23:41:25] <jmkasunich> its part of RTAI, not handy right now
[23:41:42] <zwelch> jmkasunich: oh, then Fusion == LXRT? :)
[23:41:48] <robin_sz> google's first link is fascinating ...
[23:41:52] <paul_c> You can apt-get my fusion kernel and run the built in tests...
[23:41:58] <jmkasunich> fusion is new, LXRT is older
[23:42:12] <zwelch> jmkasunich: then i say we jump on the fusion bandwagon
[23:42:26] <paul_c> If you can get better than 40uSec latency, you are doing well.
[23:42:32] <zwelch> or... we'll probably have to support both ;)
[23:42:33] <jmkasunich> first there was kernel only RTAI, then they added LXRT, then they did fusion
[23:42:41] <zwelch> ah :)
[23:42:58] <zwelch> gosh, that almost makes sense ;)
[23:43:07] <paul_c> If you embrace fusion, might as well drop RTLinux support
[23:43:10] <jmkasunich> unfortunatly software generated step pulses are a significant part of the user base, and that needs the best latency possible
[23:43:29] <alex_joni> "RTAI/fusion is an experimental development branch led by the RTAI project, in order to provide a universal, interface-agnostic, hard real-time support to user-space applications, thanks to a complete integration of the Adeos, Xenomai and LXRT technologies into the Linux environment."
[23:43:34] <jmkasunich> 40uS ain't gonna hack it
[23:44:07] <zwelch> paul_c: why do you say that about rtlinux?
[23:44:21] <alex_joni> zwelch: there comes a time when you want to reduce the number of stuff you support
[23:44:23] <jmkasunich> for SW step pulses, folks like to run the fastest thread at 10-50uS (basically as fast as they can get away with, usually 15-20uS on modern boxes)
[23:44:30] <alex_joni> rtlinux, rtai already is a bunch
[23:44:55] <zwelch> alex_joni: well, it should be possible with the proper rtapi abstractions
[23:44:56] <alex_joni> * alex_joni means 2.2, 2.4, 2.6 kernels and various rtlinux and rtai patches
[23:44:58] <jmkasunich> If you are using analog servos, or external pulse generators, then your fastest thread is the servo thread at about 1mS, and things are much easier
[23:45:02] <paul_c> RTLinux is several years behind compared to RTAI
[23:45:11] <zwelch> ah, that's a good reason then
[23:45:13] <alex_joni> and comercial
[23:45:45] <paul_c> Has RTLinux-free got 2.6 kernel patches yet ?
[23:45:53] <alex_joni> zwelch: this is one of the reasons the build system got uglier on emc2
[23:46:01] <jmkasunich> and rtlinux uses the kernel module model - theres no way I want to support both
[23:46:17] <zwelch> well, i think the RT stuff needs to be factored out into rtapi completely
[23:46:37] <zwelch> then emc2 uses rtapi and who cares what is implemented under the hood
[23:46:54] <zwelch> that means having rtapi as its own package, release schedule, etc.
[23:46:56] <paul_c> If you go the whole fusion route, rtapi can be phased out.
[23:46:57] <jmkasunich> well some things can't be hidden under the hood - insmod vs. .so is one of them
[23:46:58] <alex_joni> exactly the reason rtapi got started
[23:47:20] <zwelch> jmkasunich: yes it can: rtapi-config --load
[23:47:23] <alex_joni> but.. as paul_c said, it won't work for fusion
[23:47:40] <zwelch> jmkasunich: in the code have a rtapi_config_load()..
[23:47:44] <zwelch> jmkasunich: only one of the does something
[23:48:02] <alex_joni> based on config.h ?
[23:48:07] <zwelch> so, let's step back from this though:
[23:48:15] <zwelch> fusion... is it the future? :)
[23:48:33] <paul_c> based on current performance. No.
[23:49:03] <jmkasunich> but it is where RTAI is going, I don't know how long rtai-classic will be supported
[23:49:08] <zwelch> do we have reason to believe that the performance limits can neither be elimitated or "tuned around"?
[23:49:43] <jmkasunich> not at the 20uS level, if anything modern CPUs are getting worse, not better, in the latency department
[23:49:57] <paul_c> jmkasunich: There looks like there (is) will be an RTAI-Classic skin
[23:49:57] <alex_joni> nope, but no evidence either
[23:50:01] <jmkasunich> things that are good for general purpose CPUs are bad for RT control\
[23:50:22] <alex_joni> paul_c: skin, as in to run over fusion and simulate a classic?
[23:50:25] <robin_sz> jmkasunich: presumably all the onboard cost saving stuff they tack onto mobos these days
[23:50:36] <jmkasunich> yes, a classic skin, but with the performance of fusion
[23:50:54] <alex_joni> I would expect even worse performance
[23:50:57] <paul_c> zwelch: Will probably be doing some work with the Fusion team on improving performance once other bugs have been squashed.
[23:51:15] <jmkasunich> robin: that, and cache effects, and predictive execution, and so on
[23:51:22] <zwelch> i don't like where this is going: it sounds to me that EMC doesn't have a clear path for RT, without working with the Fusion team
[23:51:44] <alex_joni> the clear path is to go with rtai/3.x right now
[23:51:54] <jmkasunich> well fusion is very much focused on RT in user space, with kernel mode an available option
[23:51:55] <zwelch> alex_joni: i mean for "future development"
[23:52:16] <robin_sz> jmkasunich: yeah, I hadnt thought about that so much .. normally anyting that speeds stuf fup is great, but for RT its BAAAD
[23:52:26] <paul_c> We have a viable path with the current 2.6 kernels
[23:52:26] <alex_joni> seems rtai/classic will be used well into the future
[23:52:31] <alex_joni> https://mail.rtai.org/pipermail/rtai/2017-July/012519.html
[23:52:59] <alex_joni> that's 12 years from now ;)
[23:53:56] <paul_c> who knows what is in the pipeline with 2.8 kernels...
[23:54:01] <robin_sz> alex_joni: they should use RT email .... see what happens with non RT mesagaing systems ;)
[23:56:16] <alex_joni> right
[23:56:32] <alex_joni> ok.. back to sim-emc
[23:56:48] <alex_joni> what parts need RT?
[23:56:57] <alex_joni> HAL does partly
[23:57:23] <paul_c> scrap HAL for sim builds ?
[23:57:24] <alex_joni> and motion does (but might work in UL without much change afaik)
[23:57:29] <alex_joni> hmmm ;)
[23:57:45] <alex_joni> HAL userspace works nicely too
[23:57:59] <paul_c> If you're not driving any hardware, motion doesn't need RT either
[23:58:54] <paul_c> The other advantage of not having any hardware....
[23:59:04] <paul_c> No more running as root.
[23:59:25] <alex_joni> but you might still have modules
[23:59:52] <alex_joni> in order not to change the build concept too much
