Back
[00:14:18] <alex_joni> http://imagebin.org/15290
[00:16:37] <jepler> alex_joni: what symlinks specifically?
[00:16:52] <alex_joni> jepler: /dev/rtai_shm needs to be 666
[00:17:05] <alex_joni> oh, sorry .. different thing :)
[00:17:18] <alex_joni> I change the debian/rules a bit, it does it now
[00:17:33] <alex_joni> (it didn't install the include/asm -> asm-i386 symlink)
[00:17:57] <alex_joni> and a couple of symlinks in the modules dir: rtai_sched.ko -> rtai_*.ko
[00:18:07] <jepler> alex_joni: patches happily acepted. I probably didn't notice these because I'd already done a "make install" ...
[00:18:35] <alex_joni> you have a (find . -type f) just before dh_movefiles
[00:18:47] <alex_joni> I changed that to (find . -type f -or -type l)
[00:19:12] <alex_joni> was wondering how udev is working for you
[00:19:21] <jepler> -type l -or -type f ?
[00:19:24] <alex_joni> yeah
[00:19:38] <alex_joni> type l is symlink, so it copies both to tmp/
[00:19:54] <jepler> probably also something fixed by 'make install' -- I notice there's some magic logic in the makefile concerning that
[00:20:01] <jepler> maybe the magic doesn't trigger when installing to some other prefix
[00:20:16] <alex_joni> dunno, it seems right now
[00:49:47] <skunkworks> jmkasunich: could you (when you get a chance) post your fusee gcode?
[00:50:40] <skunkworks> http://www.cnczone.com/forums/showthread.php?t=54747
[01:41:24] <jmkasunich> skunkworks: I really should do that
[03:19:19] <jmkasunich> ok, I'm perplexed
[03:19:45] <jmkasunich> i've somehow gotten emc and/or axis into a state where it ignores jog commands
[03:19:54] <jmkasunich> and G0 commands
[03:21:50] <SWPadnos> dose it move in G1 or other modes in MDI?
[03:22:05] <SWPadnos> does
[03:22:26] <jmkasunich> dunce cap
[03:22:42] <SWPadnos> Machine not on? :)
[03:22:48] <jmkasunich> I must have somehow changed the feed override to zero
[03:23:00] <jmkasunich> I didn't know there was a key for that - the 0 key does 100%
[03:23:10] <SWPadnos> ok - that would have been question #2 - I was going to ask about feedhold
[03:23:20] <SWPadnos> so I need a small dunce cap, please :)
[03:23:27] <jmkasunich> it was probalby during my panicked stab at escape
[03:23:45] <jmkasunich> after the cut I was taking slipped the spindle belts
[03:24:00] <SWPadnos> oops
[03:24:21] <SWPadnos> that can cause major suckage for getting the parts all thesame
[03:25:56] <jmkasunich> yeah
[13:10:02] <CIA-22> EMC: 03cradek 07concave_comp * 10emc2/src/emc/rs274ngc/interp_convert.cc: I think this is all arc-line and line-arc cases now
[13:12:40] <skunkworks_> Heh
[13:12:43] <jepler> anyone know of a program I could easily feed some halscope or halsampler traces to and perform an fft? I am thinking it would be interesting to look at the successive latency-test results and see periodic anomalies clearly
[13:13:14] <alex_joni> I think you can do that with gnu octave
[13:13:29] <alex_joni> but I never used it to say for sure
[13:14:12] <alex_joni> jepler: maybe this is useful
http://www.captain.at/howto-fftw-spectrograph.php
[13:14:57] <cradek> jepler: apt-cache show grace
[13:15:30] <jepler> cradek: sounds interesting; wanna install it on india for me?
[13:16:24] <cradek> done
[13:17:28] <jepler> thanks
[13:41:39] <jepler> hm, having made a graph of the DFT of my timing data, I have no idea what the scales mean
[13:45:46] <jepler> http://emergent.unpy.net/files/sandbox/aaa.png
[13:46:18] <cradek> hmmm
[13:47:03] <jepler> I assume the right end is either period or period/2, and going to the left indicates lower frequencies
[14:41:49] <SWPadnos> it looks like it might have the frequencies reversed
[14:42:06] <SWPadnos> usually you get a high DC bias, which is a spike at the left side of the graph
[14:45:21] <jepler> yes, there's a DC bias
[14:45:43] <jepler> the data I recorded was interval, so they're all numbers up around 10 million (10ms in ns)
[14:45:58] <SWPadnos> ok, so it's definitely left-right reversed
[14:46:57] <SWPadnos> the plot should run from DC on the left to max nyquist frequency on the right, which would be 1/(2*PERIOD)
[14:47:36] <SWPadnos> and it's linear in frequency - if the scale is from 0-1000 Hz and there are 1001 points, you have 1Hz per point
[15:30:13] <alex_joni> jepler: they classicladder RT part compiled ok for you?
[16:06:00] <cradek> http://timeguy.com/cradek-files/emc/line-arc.png
[16:06:47] <SWPadnos> very nice
[16:07:25] <CIA-22> EMC: 03cradek 07concave_comp * 10emc2/src/emc/rs274ngc/interp_convert.cc: the required one-move lookahead. sequence numbers are wrong.
[16:07:28] <SWPadnos> I don't see any arc-arc transitions
[16:07:34] <cradek> yeah guess why that is
[16:07:38] <cradek> :-)
[16:07:38] <SWPadnos> heh
[16:07:45] <SWPadnos> * SWPadnos whistles and shuffles off
[16:08:30] <cradek> wish I was smart enough to draw those at 137.2 degrees
[16:08:39] <cradek> oh hey ... autocad
[16:09:00] <SWPadnos> yeah - make two intersecting circles and trim
[16:09:47] <cradek> I know arc-arc doesn't work yet... I haven't touched it
[16:12:45] <BigJohnT> drawing arcs cradek: ?
[16:14:31] <alex_joni> playing up on a lost teenage life
[16:14:51] <alex_joni> or childhood.
[16:16:12] <BigJohnT> hmmm
[16:20:58] <cradek> http://timeguy.com/cradek-files/emc/more-angles.png
[16:21:48] <BigJohnT> makes me dizzy to look at it...
[16:22:52] <alex_joni> looks like a heavy metal logo
[16:29:04] <skunkworks_> Nice job chris
[16:30:33] <cradek> skunkworks_: fortunately you haven't seen the cases I haven't shown you :-)
[16:31:25] <skunkworks_> Heh..
[16:49:17] <alex_joni> cradek: what's the command for a verbose make?
[17:13:45] <alex_joni> can someone here try this patch?
[17:13:48] <alex_joni> http://pastebin.ca/959729
[17:23:23] <alex_joni> * alex_joni decides to let the compile farm figure it out :)
[17:23:32] <skunkworks_> heh
[17:28:46] <CIA-22> EMC: 03alex_joni 07TRUNK * 10emc2/src/hal/classicladder/classicladder.h: use rtapi_print as it nicely does the work for RT and userspace
[17:29:15] <CIA-22> EMC: 03alex_joni 07TRUNK * 10emc2/src/hal/classicladder/calc.c: remove unneeded include
[17:29:28] <alex_joni> now we wait?
[17:29:36] <skunkworks_> Now we wait.
[17:51:51] <alex_joni> well.. it seems to work on all platorms
[17:55:46] <SWPLinux> yay!
[17:55:49] <SWPLinux> see you later
[18:40:24] <CIA-22> EMC: 03alex_joni 07TRUNK * 10emc2/debian/emc2.files.in: add a couple of newer files
[18:45:41] <CIA-22> EMC: 03alex_joni 07TRUNK * 10emc2/debian/changelog: add infrastructure files for Ubuntu-8.04
[18:45:44] <CIA-22> EMC: 03alex_joni 07TRUNK * 10emc2/debian/extras-Ubuntu-8.04/emc2.files: add infrastructure files for Ubuntu-8.04
[18:45:53] <CIA-22> EMC: 03alex_joni 07TRUNK * 10emc2/debian/extras-Ubuntu-8.04/etc/modprobe.d/emc2: add infrastructure files for Ubuntu-8.04
[18:45:53] <CIA-22> EMC: 03alex_joni 07TRUNK * 10emc2/debian/extras-Ubuntu-8.04/usr/share/applications/ (5 files): add infrastructure files for Ubuntu-8.04
[18:45:54] <CIA-22> EMC: 03alex_joni 07TRUNK * 10emc2/debian/extras-Ubuntu-8.04/etc/xdg/menus/applications-merged/cnc.menu: add infrastructure files for Ubuntu-8.04
[18:45:55] <CIA-22> EMC: 03alex_joni 07TRUNK * 10emc2/debian/extras-Ubuntu-8.04/usr/share/desktop-directories/cnc.directory: add infrastructure files for Ubuntu-8.04
[18:45:58] <CIA-22> EMC: 03alex_joni 07TRUNK * 10emc2/debian/extras-Ubuntu-8.04/usr/share/pixmaps/emc2icon.png: add infrastructure files for Ubuntu-8.04
[19:42:19] <alex_joni> jepler: do you remember why you added the dependency on bwidget << 1.8 ?
[19:43:50] <jepler> alex_joni: no; I removed it for my emc 2.3~cvs package and all seemed OK
[19:44:28] <alex_joni> ok, I'll do that too (right now I installed with --ignore-depends=bwidget
[19:44:43] <alex_joni> jepler: let me know when you're at home less busy ;)
[20:23:47] <seb_kuzminsky> i dont understand the relationship between rtai and the linux kernel...
[20:23:56] <alex_joni> seb_kuzminsky: what do you mean?
[20:24:11] <seb_kuzminsky> when i compile realtime drivers for emc2/hal, it looks just like a normal kernel module compile
[20:24:15] <seb_kuzminsky> what makes it realtime?
[20:24:31] <seb_kuzminsky> why can't we use the kernel's standard parport driver in hal, for example?
[20:25:02] <alex_joni> if you want to run under RTAI then you need to access RTAI stuff only
[20:25:27] <alex_joni> as that runs in ADEOS space (above the kernel)
[20:25:53] <alex_joni> the part that you're missing is hidden by the rtapi layer
[20:26:41] <alex_joni> I'm not sure I'm expressing this quite right
[20:27:38] <seb_kuzminsky> the drivers all have rtapi_app_main() and rtapi_app_exit(), but other than that they look like normal kernel drivers
[20:27:48] <seb_kuzminsky> they make calls into the rtapi modules
[20:28:20] <seb_kuzminsky> but they're part of the normal kernel address space, right? they show up in lsmod
[20:29:02] <alex_joni> well.. yes and no
[20:29:17] <alex_joni> as they get insmoded they are part of normal kernel space
[20:29:58] <alex_joni> but above that there's a different domain
[20:30:55] <seb_kuzminsky> hal drivers can directly access the usual kernel memory, right? make files in /proc and /sys, etc, call normal kernel helper functions
[20:30:55] <alex_joni> and once you're up there you can't access regular kernel stuff, as that will break real time
[20:31:24] <jepler> seb_kuzminsky: in rtapi_app_main and rtapi_app_exit, yes.
[20:31:56] <jepler> seb_kuzminsky: in functions registered through hal_export_funct, only certain functions may be called
[20:32:11] <seb_kuzminsky> aahhh....
[20:32:14] <jepler> basically, a subset of rtapi calls
[20:32:35] <seb_kuzminsky> hal_export_functs is how you tell the realtime kernel that here's a function it can safely call in realtime context
[20:32:41] <seb_kuzminsky> everything else runs "up in linux"
[20:33:04] <jepler> even if it were possible to use some linux kernel facility in rtapi_app_main and rtapi_app_exit to work with the standard linux parport driver(s), though, there's another reason to *not* do it this way --
[20:33:42] <jepler> a long time ago, Jon Elson had problems with users whose machines would "go crazy" at a certain time of each day (losing communication between the pc and the ppmc)
[20:34:07] <jepler> this was because some userspace program was trying to access /dev/lp, and this broke proper communication with the board
[20:34:40] <jepler> similarly, when linux loads the parport_pc driver, some simple step & direction boards without charge-pump or amplifier-enable signals would take a step
[20:34:42] <seb_kuzminsky> maybe long ago that was a problem, but i think now you can do an "exclusive claim" of a parport and no other process or driver may touch it until you release it
[20:34:58] <jepler> so we completely disable the kernel parport_pc driver so that neither of these will occur
[20:35:13] <seb_kuzminsky> hm, the taking a step thing might be a problem...
[20:35:15] <jepler> emc can't make an "exclusive claim" during the time it's not running, though
[20:35:34] <seb_kuzminsky> it could in rtapi_app_main, and release the parport in rtapi_app_exit
[20:35:45] <seb_kuzminsky> of the hal parport driver, i mean
[20:36:17] <seb_kuzminsky> making hal_parport tie in to the linux-kernel parport subsystem like the lp or ppdev drivers, except claiming exclusive use of the parports
[20:36:48] <seb_kuzminsky> i guess i'd have to audit the parport and parport_pc code to make sure they dont do anything but rtai-allowed function calls
[20:37:23] <jepler> there are two more reasons that come to mind: first, in the early days of emc2 we were trying to support a wider range of kernel versions (e.g., 2.2 through 2.6); these APIs are unlikely to be stable over so many kernel revisions
[20:37:43] <seb_kuzminsky> ugh, why bother with the old stuff?
[20:37:55] <jepler> second, the simple approach of inb / outb to the parport address seemed to work so well, it wasn't necessary to learn about these high-level APIs
[20:38:32] <alex_joni> seb_kuzminsky: some could argue that older kernels run better on embedded stuff with low resources
[20:38:50] <seb_kuzminsky> jepler: but now we have a bunch of spp/epp implementations in src/hal/drivers...
[20:38:53] <seb_kuzminsky> alex_joni: good point
[20:39:13] <seb_kuzminsky> does rtai/rtapi support those old kernels still?
[20:39:27] <alex_joni> seb_kuzminsky: there's no evidence otherwise
[20:39:40] <jepler> I don't know of anyone not on kernel 2.6.
[20:39:55] <seb_kuzminsky> i've got my mom's firewall still on 2.4, does that count? :-)
[20:39:56] <jepler> I do know that the oldest kernels we test are 2.6.
[20:40:03] <jepler> I mean, anyone using emc not on kernel 2.6.
[20:40:04] <alex_joni> 2.6.20 afaik
[20:40:06] <seb_kuzminsky> right
[20:40:09] <cradek> I ran a recent emc2 on a 2.4 kernel a few weeks ago
[20:40:22] <alex_joni> err. I meant 2.6.10
[20:40:32] <seb_kuzminsky> we dont provide packages for anything 2.6.recent
[20:40:45] <alex_joni> seb_kuzminsky: we just finished building some ;)
[20:40:47] <seb_kuzminsky> anyone on older kernels probably isnt upgrading their emc2 or other software
[20:40:49] <alex_joni> for 2.6.24
[20:41:12] <jepler> cradek: oh -- cool
[20:41:13] <seb_kuzminsky> sorry, i meant "we dont' provide packages for anything *BUT* recent"
[20:41:23] <alex_joni> seb_kuzminsky: indeed, that's true
[20:41:29] <seb_kuzminsky> only recent kernels are actively pushed on our users
[20:41:41] <alex_joni> our users tend to stay on the platforms we provide
[20:41:51] <seb_kuzminsky> which makes good sense
[20:41:59] <alex_joni> and even the ones I saw doing it by hand still chose a fairly recent kernel ver
[20:42:19] <alex_joni> so far it's dapper with the most users, and that's 2.6.15
[20:42:24] <alex_joni> and rtai 3.3
[20:42:39] <seb_kuzminsky> so i think there is only one good reason not to use the kernel's parport infrastructure, and that is that parport_pc takes a step on some machines when first loaded?
[20:43:17] <jepler> seb_kuzminsky: the second is, do we know that the kernel's parport infrastructure is suitable for realtime
[20:43:29] <seb_kuzminsky> right.... i'll check
[20:43:39] <jepler> (it can't be in all cases; I assume that the API layer you're talking about would unify USB parports as well)
[20:43:51] <seb_kuzminsky> uhm, except i dont exactly know what the criteria for realtimeliness is...
[20:44:07] <alex_joni> seb_kuzminsky: basicly using functions which aren't precisely deterministic
[20:44:17] <seb_kuzminsky> usb parport dont go through the parport system, since they're not real parports (they're "USB Printer" devices)
[20:44:17] <alex_joni> like get_time_of_day() or how that's spelled
[20:44:50] <jmkasunich> realtime means they never call _anything_ that can _ever_ block
[20:45:00] <seb_kuzminsky> right
[20:45:20] <jmkasunich> I doubt the kernel guys are prepared to guarantee that for their code
[20:45:24] <seb_kuzminsky> is there a list of functions that can or can't block, or should I just RTFS?
[20:45:26] <jmkasunich> so, we don't use it
[20:45:50] <jmkasunich> you mean a list of functions in the kernel, or in emc?
[20:45:54] <jepler> see also
http://www.rtai.dk/cgi-bin/gratiswiki.pl?RTAI_FAQs Q: Can I use all linux kernel functions normally from my RTAI task?
[20:46:04] <seb_kuzminsky> jmkasunich: kernel
[20:46:11] <seb_kuzminsky> jepler: thanks
[20:46:55] <alex_joni> it might be a different story for lxrt
[20:47:32] <jmkasunich> part of the reason rtapi/hal are as they are is my background
[20:47:54] <jmkasunich> my programming has been mostly either DOS or embedded
[20:48:01] <seb_kuzminsky> i love hal
[20:48:02] <jmkasunich> where "you own the computer"
[20:48:07] <seb_kuzminsky> i want to have hals baby
[20:48:48] <jmkasunich> in that environment there was very little pre-written code
[20:49:14] <alex_joni> seb_kuzminsky: lol :)
[20:49:22] <seb_kuzminsky> parport_pc uses current, jiffies, signals, etc... :-(
[20:49:51] <jmkasunich> it does a crapload more stuff than the few inb and outb that we actually need
[20:50:07] <alex_joni> jmkasunich: I think seb started looking at this because of ECP/EPP
[20:50:20] <seb_kuzminsky> yeah i want epp
[20:50:23] <alex_joni> which is a bit more complicated than regular parport inb/outb
[20:50:28] <seb_kuzminsky> but not by much
[20:50:33] <jmkasunich> ECP is a mess, but EPP isn't much more complex than in/out
[20:51:57] <seb_kuzminsky> parport is just one example, there are other drivers i'd like to share with the linux kernel
[20:52:03] <jmkasunich> the EPP part of hal_ppmc.c is something like 70 lines
[20:52:15] <jmkasunich> and that includes copious comments, etc
[20:52:38] <jmkasunich> I guess we're looking at a philosophical difference
[20:52:47] <jmkasunich> anything we share with the kernel, they can break
[20:52:54] <jmkasunich> their goals are not the same as our goals
[20:53:38] <seb_kuzminsky> that makes sense
[20:54:07] <jmkasunich> I think of RTAPI as a way to get the operating system neccessities (module loading, ISR setup, task setup, etc) out of the way, so I can program the machine as if it was an embedded one - like a really fast, really powerfull PIC, or 8051, or AVR, or whatever
[20:57:36] <skunkworks_> http://imagebin.org/15322
[20:57:46] <skunkworks_> http://imagebin.org/15323
[20:58:07] <seb_kuzminsky> hal drivers use the kernel's pci subsystem, i guess that has been audited and found "realtime clean"?
[20:58:52] <alex_joni> seb_kuzminsky: isn't that only during loading time?
[21:00:06] <skunkworks_> alex was patient and walked me thru the debs he made. :)
[21:00:07] <seb_kuzminsky> hm, i guess you're right...
[21:00:22] <seb_kuzminsky> skunkworks: nice numbers... what's the PC hardware?
[21:01:30] <seb_kuzminsky> thanks alex and jmk for cluing me in
[21:02:26] <alex_joni> seb_kuzminsky: skunkworks_ machine is a P4-ish
[21:03:01] <seb_kuzminsky> wow. i'm getting latencies up around 25 us on a P4-ish machine on 2.6.22
[21:03:05] <seb_kuzminsky> what's your magic?
[21:03:20] <alex_joni> seb_kuzminsky: P4 2.8GHz
[21:03:37] <alex_joni> I'm getting 15us here on a Core2Duo laptop
[21:04:06] <skunkworks__> p4 2.6ghz 1g ram asus motherboard p4s8000-x and a radeon 9200
[21:04:31] <skunkworks__> alex_joni: 2.6ghz - I was wrong :)
[21:05:27] <skunkworks_> it is up to 7.2ish us - still pretty awesome
[21:06:23] <seb_kuzminsky> what version of rtai? and can you pastebin the .config?
[21:06:33] <alex_joni> skunkworks__: bet if you abuse it, it will go up a bit
[21:06:41] <alex_joni> glxgears, moving windows around, etc
[21:06:49] <alex_joni> seb_kuzminsky: rtai-3.6
[21:07:22] <skunkworks_> I have been.
[21:07:30] <seb_kuzminsky> heh
[21:08:07] <alex_joni> seb_kuzminsky: jas
[21:08:07] <skunkworks_> I figure any thing sub 10us is pretty damn good
[21:10:09] <seb_kuzminsky> hm, going back to the rtai vs linux discussion... the linux kernel can be pre-empted by rtai threads, right?
[21:10:23] <jmkasunich> yes
[21:10:31] <jmkasunich> thats basically what RTAI is all about
[21:10:34] <jepler> yes, and lower-priority rtai threads can be preempted by higher-priority ones
[21:10:56] <skunkworks_> It will be cool to get this on a livecd and then onto a keychain drive. Before with dapper - the computer hardware that supported booting from usb - for the most part was too new for dapper.
[21:11:06] <seb_kuzminsky> so if i have a driver that exports some functs down to rtai, and also interacts with linux via device files and the such --
[21:11:20] <seb_kuzminsky> then how do you synchronize the two worlds?
[21:11:35] <jmkasunich> my first guess is that you don't
[21:11:56] <jmkasunich> I never call linux from anything other than startup or shutdown code
[21:12:09] <seb_kuzminsky> you do all your linuxy-type stuff in rtapi_app_main(), then let the rtai functions run unmolested until it's rtapi_app_exit() time?
[21:12:15] <jmkasunich> yes
[21:12:49] <jmkasunich> I think the entire device file model is inappropriate for realtime control
[21:13:07] <alex_joni> you can still synchronize stuff from the rtai space through semaphores and shm
[21:13:13] <alex_joni> like motion does it
[21:13:34] <jmkasunich> as long as you do it carefully - you don't want the semaphors on the RT side to ever block
[21:13:42] <jmkasunich> we mostly use shared memory
[21:20:59] <alex_joni> ah, jmkasunich .. good thing I remembered
[21:22:11] <alex_joni> was meaning to ask you about that HOME_VEL patch ;)
[21:22:26] <alex_joni> BigJohnT is quite eager for it, and I'd like it for other reasons
[21:26:12] <BigJohnT> thanks, alex
[21:30:11] <jmkasunich> so what is the intended behavior? if HOME_VEL is present, use it for the final move (absolute value only, ignore sign), and if not make the final move a rapid?
[21:30:23] <alex_joni> yup
[21:30:32] <jmkasunich> I'd suggest HOME_FINAL_VEL, to go along with HOME_SEARCH_VEL and HOME_LATCH_VEL
[21:30:40] <alex_joni> ok
[21:31:09] <alex_joni> BigJohnT: got the pastebin link?
[21:31:20] <BigJohnT> not on this computere
[21:31:21] <jmkasunich> the patch has the stuff needed to get the new param from the inifile into the RT code?
[21:31:31] <alex_joni> jmkasunich: yeah, it's complete
[21:31:38] <alex_joni> afaict :)
[21:31:40] <BigJohnT> alex_joni: it's at home
[21:31:54] <alex_joni> logger_dev: bookmark
[21:31:54] <alex_joni> Just this once .. here's the log:
http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2008-03-27.txt
[21:31:56] <BigJohnT> I can post it again when I get home
[21:32:38] <alex_joni> pastebin.ca/953939
[21:33:52] <alex_joni> hmm.. there's another change in the patch (the RS274NGC_STARTUP_CODE) .. I commited that in the mean time..
[21:42:30] <jmkasunich> alex_joni: regarding the patch
[21:42:35] <jmkasunich> all I have is nitpicking comments
[21:42:45] <alex_joni> oh, feel free..
[21:42:53] <jmkasunich> home_final_vel instead of just home_vel - I think the latter is vague
[21:43:07] <alex_joni> yeah, I was gonna do that anyways
[21:43:13] <jmkasunich> at lines 73-74, formatting
[21:43:26] <jmkasunich> the else code should be on a line after the else, not on the same line
[21:44:02] <jmkasunich> everything else seems fine
[21:44:37] <jmkasunich> oh, btw, I think I might know why BigJohnT sees a nastier accel during homing than when using G0
[21:44:51] <alex_joni> backlash?
[21:44:53] <jmkasunich> if he has blending turned on, all accels in g-code are divided by two, as part of the blending calcs
[21:45:03] <alex_joni> ah
[21:45:47] <jmkasunich> jogs don't have that divide - he should compare G0, max speed jogs, and the homing move
[21:46:54] <alex_joni> I see
[21:47:15] <jmkasunich> he might also want to compare G0 moves with blending turned on and off
[21:53:01] <alex_joni> jmkasunich: still there?
[21:53:09] <jmkasunich> yeah, for a bit
[21:53:27] <alex_joni> should I use: joint->free_vel_lim = abs(..) ?
[21:53:40] <alex_joni> line 73
[21:54:05] <jmkasunich> yes
[21:54:10] <alex_joni> ok
[22:19:33] <CIA-22> EMC: 03alex_joni 07TRUNK * 10emc2/src/emc/ini/iniaxis.cc: allow for HOME_FINAL_VEL in the ini, which specifies the final home move velocity
[22:19:33] <CIA-22> EMC: 03alex_joni 07TRUNK * 10emc2/src/emc/motion/ (command.c homing.c motion.c motion.h): allow for HOME_FINAL_VEL in the ini, which specifies the final home move velocity
[22:19:34] <CIA-22> EMC: 03alex_joni 07TRUNK * 10emc2/src/emc/nml_intf/ (emc.cc emc.hh emc_nml.hh): allow for HOME_FINAL_VEL in the ini, which specifies the final home move velocity
[22:19:35] <CIA-22> EMC: 03alex_joni 07TRUNK * 10emc2/src/emc/task/ (emctaskmain.cc taskintf.cc): allow for HOME_FINAL_VEL in the ini, which specifies the final home move velocity
[22:24:22] <seb_kuzminsky> see you all later
[22:27:30] <CIA-22> EMC: 03alex_joni 07TRUNK * 10emc2/src/hal/classicladder/classicladder.h: silence a warning about debug_printf beeing defined twice for userspace code
[22:46:21] <alex_joni> BigJohnT: you just missed the commit ;P
[22:46:30] <alex_joni> logger_dev: bookmark
[22:46:30] <alex_joni> Just this once .. here's the log:
http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2008-03-27.txt
[22:47:21] <BigJohnT> SWEET!!!!
[22:47:47] <BigJohnT> Thanks alex_joni:
[22:48:24] <alex_joni> BigJohnT: np, let me know if it works ok
[22:48:42] <alex_joni> btw, jmkasunich suggested some reasons why you're getting higher accel than on G0
[22:48:49] <alex_joni> read it in the log..
[22:48:52] <BigJohnT> reading that now
[22:49:43] <BigJohnT> I'll have to look up blending... to see how it is set
[22:50:52] <BigJohnT> alex_joni: when will that show up in the next update?
[23:06:35] <alex_joni> BigJohnT: a while..
[23:06:56] <alex_joni> probably in 2.3.0
[23:07:28] <alex_joni> * alex_joni is off to bed
[23:07:32] <alex_joni> good night all
[23:10:57] <skunkworks> night alex - thanks for the help
[23:11:51] <BigJohnT> night alex
[23:12:02] <jepler> alex_joni: 'night
[23:29:46] <skunkworks> so - blending - why is ti automatically set to acc/2?
[23:33:51] <jepler> skunkworks: imagine starting at X=0. Execute G0 X1 / G0 X0. At the end of the G0 X1 move, the X axis is accelerating in the direction -X at acc/2. At the start of the G0 X0 move, the X axis is accelerating in the direction -X at acc/2. The sum of those two accelerations is acc.
[23:34:07] <jepler> skunkworks: that's why the trajectory planner uses acc/2 as the acceleration limit for individual moves.
[23:34:43] <jepler> (blending is simply overlapping the acceleration phase of the next move with the deceleration phase of the prior move; a little bit of calculus convinces one that this ends up on the right path when you're done)
[23:34:55] <jepler> (well, it convinces Chris at least :-P)
[23:39:20] <skunkworks> heh - thanks. I will digest that.. :)
[23:43:53] <jmkasunich> that reduction is only needed because of the case where the path doubles back on itself, right?
[23:44:03] <jmkasunich> (or at least makes an acute angle)
[23:45:27] <jepler> jmkasunich: in principle yes (and the reduction need not always be to acc/2) but trying to take advantage of that property has proved difficult, because you plan the decel of move N before you have looked at move N+1 (it might not even have come out of the interpreter yet when you place it on the realtime motion list)
[23:50:17] <jmkasunich> ah, good point
