[00:14:18] <alex_joni> http://imagebin.org/15290
alex_joni: what symlinks specifically?
jepler: /dev/rtai_shm needs to be 666
oh, sorry .. different thing :)
I change the debian/rules a bit, it does it now
(it didn't install the include/asm -> asm-i386 symlink)
and a couple of symlinks in the modules dir: rtai_sched.ko -> rtai_*.ko
alex_joni: patches happily acepted. I probably didn't notice these because I'd already done a "make install" ...
you have a (find . -type f) just before dh_movefiles
I changed that to (find . -type f -or -type l)
was wondering how udev is working for you
-type l -or -type f ?
type l is symlink, so it copies both to tmp/
probably also something fixed by 'make install' -- I notice there's some magic logic in the makefile concerning that
maybe the magic doesn't trigger when installing to some other prefix
dunno, it seems right now
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
skunkworks: I really should do that
ok, I'm perplexed
i've somehow gotten emc and/or axis into a state where it ignores jog commands
and G0 commands
dose it move in G1 or other modes in MDI?
Machine not on? :)
I must have somehow changed the feed override to zero
I didn't know there was a key for that - the 0 key does 100%
ok - that would have been question #2 - I was going to ask about feedhold
so I need a small dunce cap, please :)
it was probalby during my panicked stab at escape
after the cut I was taking slipped the spindle belts
that can cause major suckage for getting the parts all thesame
EMC: 03cradek 07concave_comp * 10emc2/src/emc/rs274ngc/interp_convert.cc: I think this is all arc-line and line-arc cases now
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
I think you can do that with gnu octave
but I never used it to say for sure
jepler: maybe this is useful http://www.captain.at/howto-fftw-spectrograph.php
jepler: apt-cache show grace
cradek: sounds interesting; wanna install it on india for me?
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
I assume the right end is either period or period/2, and going to the left indicates lower frequencies
it looks like it might have the frequencies reversed
usually you get a high DC bias, which is a spike at the left side of the graph
yes, there's a DC bias
the data I recorded was interval, so they're all numbers up around 10 million (10ms in ns)
ok, so it's definitely left-right reversed
the plot should run from DC on the left to max nyquist frequency on the right, which would be 1/(2*PERIOD)
and it's linear in frequency - if the scale is from 0-1000 Hz and there are 1001 points, you have 1Hz per point
jepler: they classicladder RT part compiled ok for you?
[16:06:00] <cradek> http://timeguy.com/cradek-files/emc/line-arc.png
EMC: 03cradek 07concave_comp * 10emc2/src/emc/rs274ngc/interp_convert.cc: the required one-move lookahead. sequence numbers are wrong.
I don't see any arc-arc transitions
yeah guess why that is
* SWPadnos whistles and shuffles off
wish I was smart enough to draw those at 137.2 degrees
oh hey ... autocad
yeah - make two intersecting circles and trim
I know arc-arc doesn't work yet... I haven't touched it
drawing arcs cradek: ?
playing up on a lost teenage life
[16:20:58] <cradek> http://timeguy.com/cradek-files/emc/more-angles.png
makes me dizzy to look at it...
looks like a heavy metal logo
Nice job chris
skunkworks_: fortunately you haven't seen the cases I haven't shown you :-)
cradek: what's the command for a verbose make?
can someone here try this patch?
[17:13:48] <alex_joni> http://pastebin.ca/959729
* alex_joni decides to let the compile farm figure it out :)
EMC: 03alex_joni 07TRUNK * 10emc2/src/hal/classicladder/classicladder.h: use rtapi_print as it nicely does the work for RT and userspace
EMC: 03alex_joni 07TRUNK * 10emc2/src/hal/classicladder/calc.c: remove unneeded include
now we wait?
Now we wait.
well.. it seems to work on all platorms
see you later
EMC: 03alex_joni 07TRUNK * 10emc2/debian/emc2.files.in: add a couple of newer files
EMC: 03alex_joni 07TRUNK * 10emc2/debian/changelog: add infrastructure files for Ubuntu-8.04
EMC: 03alex_joni 07TRUNK * 10emc2/debian/extras-Ubuntu-8.04/emc2.files: add infrastructure files for Ubuntu-8.04
EMC: 03alex_joni 07TRUNK * 10emc2/debian/extras-Ubuntu-8.04/etc/modprobe.d/emc2: add infrastructure files for Ubuntu-8.04
EMC: 03alex_joni 07TRUNK * 10emc2/debian/extras-Ubuntu-8.04/usr/share/applications/ (5 files): add infrastructure files for Ubuntu-8.04
EMC: 03alex_joni 07TRUNK * 10emc2/debian/extras-Ubuntu-8.04/etc/xdg/menus/applications-merged/cnc.menu: add infrastructure files for Ubuntu-8.04
EMC: 03alex_joni 07TRUNK * 10emc2/debian/extras-Ubuntu-8.04/usr/share/desktop-directories/cnc.directory: add infrastructure files for Ubuntu-8.04
EMC: 03alex_joni 07TRUNK * 10emc2/debian/extras-Ubuntu-8.04/usr/share/pixmaps/emc2icon.png: add infrastructure files for Ubuntu-8.04
jepler: do you remember why you added the dependency on bwidget << 1.8 ?
alex_joni: no; I removed it for my emc 2.3~cvs package and all seemed OK
ok, I'll do that too (right now I installed with --ignore-depends=bwidget
jepler: let me know when you're at home less busy ;)
i dont understand the relationship between rtai and the linux kernel...
seb_kuzminsky: what do you mean?
when i compile realtime drivers for emc2/hal, it looks just like a normal kernel module compile
what makes it realtime?
why can't we use the kernel's standard parport driver in hal, for example?
if you want to run under RTAI then you need to access RTAI stuff only
as that runs in ADEOS space (above the kernel)
the part that you're missing is hidden by the rtapi layer
I'm not sure I'm expressing this quite right
the drivers all have rtapi_app_main() and rtapi_app_exit(), but other than that they look like normal kernel drivers
they make calls into the rtapi modules
but they're part of the normal kernel address space, right? they show up in lsmod
well.. yes and no
as they get insmoded they are part of normal kernel space
but above that there's a different domain
hal drivers can directly access the usual kernel memory, right? make files in /proc and /sys, etc, call normal kernel helper functions
and once you're up there you can't access regular kernel stuff, as that will break real time
seb_kuzminsky: in rtapi_app_main and rtapi_app_exit, yes.
seb_kuzminsky: in functions registered through hal_export_funct, only certain functions may be called
basically, a subset of rtapi calls
hal_export_functs is how you tell the realtime kernel that here's a function it can safely call in realtime context
everything else runs "up in linux"
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 --
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)
this was because some userspace program was trying to access /dev/lp, and this broke proper communication with the board
similarly, when linux loads the parport_pc driver, some simple step & direction boards without charge-pump or amplifier-enable signals would take a step
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
so we completely disable the kernel parport_pc driver so that neither of these will occur
hm, the taking a step thing might be a problem...
emc can't make an "exclusive claim" during the time it's not running, though
it could in rtapi_app_main, and release the parport in rtapi_app_exit
of the hal parport driver, i mean
making hal_parport tie in to the linux-kernel parport subsystem like the lp or ppdev drivers, except claiming exclusive use of the parports
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
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
ugh, why bother with the old stuff?
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
seb_kuzminsky: some could argue that older kernels run better on embedded stuff with low resources
jepler: but now we have a bunch of spp/epp implementations in src/hal/drivers...
alex_joni: good point
does rtai/rtapi support those old kernels still?
seb_kuzminsky: there's no evidence otherwise
I don't know of anyone not on kernel 2.6.
i've got my mom's firewall still on 2.4, does that count? :-)
I do know that the oldest kernels we test are 2.6.
I mean, anyone using emc not on kernel 2.6.
I ran a recent emc2 on a 2.4 kernel a few weeks ago
err. I meant 2.6.10
we dont provide packages for anything 2.6.recent
seb_kuzminsky: we just finished building some ;)
anyone on older kernels probably isnt upgrading their emc2 or other software
cradek: oh -- cool
sorry, i meant "we dont' provide packages for anything *BUT* recent"
seb_kuzminsky: indeed, that's true
only recent kernels are actively pushed on our users
our users tend to stay on the platforms we provide
which makes good sense
and even the ones I saw doing it by hand still chose a fairly recent kernel ver
so far it's dapper with the most users, and that's 2.6.15
and rtai 3.3
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?
seb_kuzminsky: the second is, do we know that the kernel's parport infrastructure is suitable for realtime
right.... i'll check
(it can't be in all cases; I assume that the API layer you're talking about would unify USB parports as well)
uhm, except i dont exactly know what the criteria for realtimeliness is...
seb_kuzminsky: basicly using functions which aren't precisely deterministic
usb parport dont go through the parport system, since they're not real parports (they're "USB Printer" devices)
like get_time_of_day() or how that's spelled
realtime means they never call _anything_ that can _ever_ block
I doubt the kernel guys are prepared to guarantee that for their code
is there a list of functions that can or can't block, or should I just RTFS?
so, we don't use it
you mean a list of functions in the kernel, or in emc?
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?
it might be a different story for lxrt
part of the reason rtapi/hal are as they are is my background
my programming has been mostly either DOS or embedded
i love hal
where "you own the computer"
i want to have hals baby
in that environment there was very little pre-written code
seb_kuzminsky: lol :)
parport_pc uses current, jiffies, signals, etc... :-(
it does a crapload more stuff than the few inb and outb that we actually need
jmkasunich: I think seb started looking at this because of ECP/EPP
yeah i want epp
which is a bit more complicated than regular parport inb/outb
but not by much
ECP is a mess, but EPP isn't much more complex than in/out
parport is just one example, there are other drivers i'd like to share with the linux kernel
the EPP part of hal_ppmc.c is something like 70 lines
and that includes copious comments, etc
I guess we're looking at a philosophical difference
anything we share with the kernel, they can break
their goals are not the same as our goals
that makes sense
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
hal drivers use the kernel's pci subsystem, i guess that has been audited and found "realtime clean"?
seb_kuzminsky: isn't that only during loading time?
alex was patient and walked me thru the debs he made. :)
hm, i guess you're right...
skunkworks: nice numbers... what's the PC hardware?
thanks alex and jmk for cluing me in
seb_kuzminsky: skunkworks_ machine is a P4-ish
wow. i'm getting latencies up around 25 us on a P4-ish machine on 2.6.22
what's your magic?
seb_kuzminsky: P4 2.8GHz
I'm getting 15us here on a Core2Duo laptop
p4 2.6ghz 1g ram asus motherboard p4s8000-x and a radeon 9200
alex_joni: 2.6ghz - I was wrong :)
it is up to 7.2ish us - still pretty awesome
what version of rtai? and can you pastebin the .config?
skunkworks__: bet if you abuse it, it will go up a bit
glxgears, moving windows around, etc
I have been.
I figure any thing sub 10us is pretty damn good
hm, going back to the rtai vs linux discussion... the linux kernel can be pre-empted by rtai threads, right?
thats basically what RTAI is all about
yes, and lower-priority rtai threads can be preempted by higher-priority ones
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.
so if i have a driver that exports some functs down to rtai, and also interacts with linux via device files and the such --
then how do you synchronize the two worlds?
my first guess is that you don't
I never call linux from anything other than startup or shutdown code
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?
I think the entire device file model is inappropriate for realtime control
you can still synchronize stuff from the rtai space through semaphores and shm
like motion does it
as long as you do it carefully - you don't want the semaphors on the RT side to ever block
we mostly use shared memory
ah, jmkasunich .. good thing I remembered
was meaning to ask you about that HOME_VEL patch ;)
BigJohnT is quite eager for it, and I'd like it for other reasons
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?
I'd suggest HOME_FINAL_VEL, to go along with HOME_SEARCH_VEL and HOME_LATCH_VEL
BigJohnT: got the pastebin link?
not on this computere
the patch has the stuff needed to get the new param from the inifile into the RT code?
jmkasunich: yeah, it's complete
alex_joni: it's at home
Just this once .. here's the log: http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2008-03-27.txt
I can post it again when I get home
hmm.. there's another change in the patch (the RS274NGC_STARTUP_CODE) .. I commited that in the mean time..
alex_joni: regarding the patch
all I have is nitpicking comments
oh, feel free..
home_final_vel instead of just home_vel - I think the latter is vague
yeah, I was gonna do that anyways
at lines 73-74, formatting
the else code should be on a line after the else, not on the same line
everything else seems fine
oh, btw, I think I might know why BigJohnT sees a nastier accel during homing than when using G0
if he has blending turned on, all accels in g-code are divided by two, as part of the blending calcs
jogs don't have that divide - he should compare G0, max speed jogs, and the homing move
he might also want to compare G0 moves with blending turned on and off
jmkasunich: still there?
yeah, for a bit
should I use: joint->free_vel_lim = abs(..) ?
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
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
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
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
see you all later
EMC: 03alex_joni 07TRUNK * 10emc2/src/hal/classicladder/classicladder.h: silence a warning about debug_printf beeing defined twice for userspace code
BigJohnT: you just missed the commit ;P
Just this once .. here's the log: http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2008-03-27.txt
BigJohnT: np, let me know if it works ok
btw, jmkasunich suggested some reasons why you're getting higher accel than on G0
read it in the log..
reading that now
I'll have to look up blending... to see how it is set
alex_joni: when will that show up in the next update?
BigJohnT: a while..
probably in 2.3.0
* alex_joni is off to bed
good night all
night alex - thanks for the help
so - blending - why is ti automatically set to acc/2?
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.
skunkworks: that's why the trajectory planner uses acc/2 as the acceleration limit for individual moves.
(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)
(well, it convinces Chris at least :-P)
heh - thanks. I will digest that.. :)
that reduction is only needed because of the case where the path doubles back on itself, right?
(or at least makes an acute angle)
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)
ah, good point