Back
[00:10:53] <Jacky^> fenn: ??
[00:11:27] <Jacky^> what 'fanciulo' mean ? :P
[00:12:48] <Jacky^> fighting with crapplication ? :)
[00:17:28] <fenn> sorry, I don't speak italian :)
[00:17:39] <Jacky^> ]:)
[00:17:43] <Jacky^> lol
[00:17:47] <fenn> crapplication likes to segfault if you rotate footprints too many times
[00:18:09] <Jacky^> never tryed
[00:18:16] <Jacky^> really ..
[00:19:05] <fenn> at first it's tricky to figure out how to get it to do anything at all
[00:19:09] <fenn> i won't spoil it for you
[00:19:25] <Jacky^> fenn: porably its a a bug
[00:19:45] <fenn> segfault is always a bug
[00:19:47] <Jacky^> hehehehe
[00:19:54] <Jacky^> good
[00:20:02] <Jacky^> if a bug exist
[00:20:09] <Jacky^> a bug can be fixed
[00:20:12] <Jacky^> :D
[00:20:45] <Jacky^> who is developing that app ?
[00:20:51] <fenn> ValarQ.
[00:20:56] <Jacky^> nice
[00:21:04] <Jacky^> yeah
[00:21:11] <Jacky^> now I remmeber
[00:21:34] <fenn> http://arda.no-ip.org/crapahalic.png
[00:21:41] <Jacky^> yes
[00:21:48] <Jacky^> ive seen it time ago
[00:22:09] <Jacky^> fenn: wirch distro are u using ?
[00:22:19] <Jacky^> wich*
[00:22:43] <Jacky^> Debian ?
[00:22:55] <fenn> fedora 3
[00:24:34] <Jacky^> uhmmm ...
[00:24:38] <Jacky^> goood
[00:24:40] <Jacky^> :/
[00:24:43] <Jacky^> hehe
[00:24:46] <Jacky^> :)
[00:25:02] <Jacky^> yeah fedora its nice
[00:25:36] <Jacky^> :)
[00:25:57] <Jacky^> RH based if I remember well
[00:26:17] <Jacky^> but non commercial ad RH
[00:27:17] <Jacky^> Red Hat seem the prefered distro by Linus Torvalds
[00:27:27] <Jacky^> for what I read ..
[00:27:32] <fenn> oh well
[00:27:37] <Jacky^> cool
[00:27:44] <fenn> .rpm's are convenient but not the best thing ever
[00:27:53] <Jacky^> but
[00:27:57] <fenn> it's tolerable if you have apt for rpm
[00:28:08] <Jacky^> i think you can also use deb packages right ?
[00:28:11] <fenn> no
[00:28:30] <Jacky^> with app converter ?
[00:28:36] <fenn> there's a tool "alien" that converts between .deb and rpm, but i've never gotten it to work right
[00:28:46] <Jacky^> yeah
[00:28:55] <Jacky^> is waht I use in debian
[00:29:09] <Jacky^> uhmm
[00:29:10] <fenn> usually easier for me to cut the archive open and spill its guts everywhere
[00:29:17] <Jacky^> yeah
[00:29:17] <fenn> rpm2cpio
[00:29:42] <Jacky^> but, anyway, there are lots of rpm's packages
[00:30:04] <Jacky^> rpm and deb are the 'standard' for linux
[00:30:15] <fenn> yep, and practically the same thing in the end
[00:30:32] <Jacky^> you've rpmfind , if i remember well
[00:30:50] <Jacky^> instead, I use apt-get.org
[00:31:01] <Jacky^> :)
[00:32:13] <fenn> bah. they dont even have emc!
[00:33:24] <Jacky^> oh .. i think we can install emc from source, on any distro, isnt right ?
[00:33:47] <Jacky^> not as package ..
[00:33:54] <Jacky^> from source code
[00:34:52] <Jacky^> always with the right kernel-source package ..
[00:35:38] <fenn> right
[00:36:00] <fenn> there are .debs too, but i dont know too much about it
[00:37:05] <Jacky^> I got emc2 up and running thanks to paul_c
[00:37:34] <Jacky^> but on BDI
[00:38:20] <Jacky^> in Debian should be simple
[00:38:49] <Jacky^> just adding the right deb mirror
[00:39:13] <Jacky^> to get latest magma kernel and modules
[00:41:10] <Jacky^> too
[00:42:47] <fenn> paul's .deb repository seems to be gone
[00:43:14] <fenn> oops, nevermind
[00:43:38] <Jacky^> ive it on the other pc
[00:43:51] <Jacky^> in the sources.list
[00:44:52] <Jacky^> but its unusable in RH based distro
[00:46:00] <fenn> are you trying to install emc on a rh distro?
[00:46:14] <Jacky^> no
[00:46:21] <Jacky^> never tryed
[00:46:55] <Jacky^> but RH
[00:47:01] <Jacky^> should be strong
[00:47:07] <Jacky^> what the prob ?
[00:47:16] <Jacky^> get the source ..
[00:51:41] <Jacky^> * Jacky^ yaaawwssssss
[00:51:47] <Jacky^> *_*
[00:51:52] <Jacky^> anonimasu: :)
[00:52:00] <anonimasu> ^_^
[00:52:02] <anonimasu> YAY!
[00:52:13] <Jacky^> hey !
[00:52:16] <Jacky^> doh
[00:52:23] <Jacky^> you are
[00:52:54] <Jacky^> i'm at 70 %
[00:53:09] <Jacky^> losting steps ..
[00:53:32] <Jacky^> i wake up at 4:40 thi morning ..
[00:53:38] <Jacky^> 01:05 < Jacky^> i wake up at 4:40 thi morning ..
[00:53:40] <Jacky^> :)
[00:54:21] <Jacky^> few hours more and i will get guinness :P
[00:56:00] <Jacky^> /(_._)\
[00:57:37] <Jacky^> Jymmm: what happening there ?
[01:00:57] <Jacky^> -.-
[01:01:03] <Jacky^> g night
[01:01:15] <Jacky^> Jacky^ is now known as Jacky^afk
[01:02:04] <anonimasu> SarahEmm: night
[01:02:08] <anonimasu> wrong place..
[01:02:09] <anonimasu> night..
[01:02:40] <Jacky^afk> /whois SarahEmm ???
[01:02:42] <Jacky^afk> :)
[01:03:00] <Jacky^afk> g night anonimasu
[01:03:01] <anonimasu> Jacky^afk: a tab mistake off #electronics
[01:03:05] <anonimasu> night
[01:39:37] <fenn> heh you are talking to sarahemm.. that funny, i randomly found + bookmarked their bookmark page
[01:42:39] <anonimasu> hehe
[01:43:22] <fenn> it's a small world
[01:43:51] <anonimasu> yep
[01:44:57] <fenn> there's a party at my house right now, and nobody's here so i'm reading about electronics in the basement.. i dont know whether that's a good or bad thing
[02:14:54] <anonimasu> :)
[02:14:58] <anonimasu> it's a good thing
[03:07:19] <CIA-6> 03yabosukz * 10emc2/src/hal/components/ (freqgen.c stepgen.c): fix bug. clean code.
[04:06:35] <zwisk> any axis folks around?
[04:10:43] <dmess> h
[04:12:33] <zwisk> I'm interested in the 'bleeding edge' axis code; but haven't found the magic incantation for checking out of cvs from unpy.net... (I'd like to use cvs rather than snapshots...) Any thoughts?
[04:13:07] <fenn> cvs -d:ext:
[email protected] ?
[04:14:34] <zwisk> hmm.. my cvs foo is weak. Been using svn too much lately...
[04:16:39] <fenn> "cvs -d:ext:
[email protected]/cvs up" seems to do something
[04:16:41] <zwisk> I think I need the path.
[04:17:35] <fenn> uh, nevermind
[04:17:41] <fenn> i dont know what i'm talking about :)
[04:17:59] <fenn> is nightly .tgz's not good enough?
[04:18:22] <zwisk> hmmm... that was close...
[04:18:35] <zwisk> well, I'd like to use CVS so that I can do incremental updates later.
[04:18:46] <zwisk> Maybe nightly builds contain the .CVS directory with the foo...
[04:20:38] <fenn> i'm not aware of anyone besides jepler and cradek who are actively developing axis.. you might just want to ask them when they're around
[04:21:43] <zwisk> yup. Ok, thanks. It looks like your command above is trying to work, but alas, anonymous is either an invalid user, or actually has a real password :)
[04:22:04] <zwisk> And, looks like nightly snapshots don't have the .CVS directory. (Probably they're built using a real username rather than an anonymous checkout.)
[04:54:51] <cradek> it's just us
[04:55:06] <cradek> there is no anon cvs for axis
[04:55:11] <cradek> you have to use the snapshot.
[04:56:45] <cradek> for incremental updates, there are patches
[05:45:48] <zwisk> ahh... thanks...
[06:26:25] <CIA-6> 03paul_c * 10emc2-auto/wiki/ (18 files in 11 dirs): "Auto update wiki from a cron job. Sat Oct 29 05:30:01 BST 2005 "
[08:18:28] <ValarQ> what? people are using my crap?
[08:22:53] <ValarQ> fenn: those pygtk segfaults are a bit tricky... :/
[10:35:23] <anonimasu> morning
[11:56:04] <Jacky^afk> Jacky^afk is now known as Jacky^
[11:56:31] <Jacky^> G morning
[11:59:35] <anonimasu> what's up?
[12:00:34] <Jacky^> hey anonimasu , replyng to some email
[12:00:50] <anonimasu> ok
[12:01:04] <Jacky^> and looking some catalogue for servomotors :(
[12:22:02] <anonimasu> ok
[12:30:12] <anonimasu> I am doing some code for a avr
[12:30:23] <anonimasu> for decoding a jog wheel
[12:30:24] <Jacky^> nice :P
[12:30:48] <anonimasu> it's too bad I cant get thoose encoder chips..
[12:31:24] <anonimasu> but since I'll be limited to how much resolution I want it's not a big deal..
[12:33:57] <anonimasu> I'll sove it with some neat calcs instead
[14:32:03] <Jacky^> looking at this website for dc motors,
http://siboni.it/it/p_SM_CC_MP.htm , it have not inertia specifications..
[14:32:26] <Jacky^> is it possible to claculate it in some way by the other params ?
[14:58:23] <les_w> hi jacky
[14:58:34] <les_w> no, you really need the specs
[14:58:49] <Jacky^> hi les_w
[14:59:01] <les_w> just built first fire in new wood stove. Warm!
[14:59:04] <les_w> and
[14:59:18] <Jacky^> les_w: i know.. i remember your words
[14:59:26] <les_w> looking at helicopters.
[14:59:32] <Jacky^> nice :)
[14:59:37] <les_w> I kinda want one
[14:59:46] <les_w> silly
[14:59:54] <Jacky^> hehe cool
[15:00:55] <les_w> http://www.barnstormers.com/Helicopter,%20Robinson%20Classifieds.htm
[15:01:38] <les_w> would look neat parked in the yard?
[15:01:42] <les_w> haha
[15:01:52] <Jacky^> :P
[15:02:15] <Jacky^> very nice
[15:03:10] <les_w> I cannot fly them, but I am a fixed wing pilot. I could get a heli rating
[15:04:41] <anonimasu_> les_w: didnt you complain about not having anything to spend money on ;)
[15:05:32] <les_w> uh...never mind.
[15:05:37] <les_w> hahaha
[15:05:38] <anonimasu_> haha :D
[15:05:51] <anonimasu_> les_w: there's always larger/better airplanes/heli's
[15:06:13] <les_w> they are expensive, but not as much as I thought
[15:06:42] <les_w> I think it would take another 20 hrs of flight school to get the heli rating
[15:06:44] <les_w> not sure
[15:06:53] <Jacky^> this is nice:
http://www.barnstormers.com/uploads/adphotos/a85834p2092951191orig.jpg
[15:06:54] <anonimasu_> dosent seem that horrid
[15:07:10] <Jacky^> and cheaper.. maybe
[15:08:08] <les_w> that is a nice picture. It would look very nice in the front yard.
[15:08:50] <Jacky^> yeah
[15:09:13] <les_w> but gas turbine motor=too expensive
[15:13:05] <dmess> chk out the bb 609
[15:17:43] <les_w> ok
[15:18:56] <les_w> nice. yeah i'll run out and pick one of those up right away.....
[15:34:32] <anonimasu_> les_w: nice ;)
[15:41:10] <domenique> hello
[15:41:20] <domenique> wow Jacky^
[15:41:20] <Jacky^> :)
[15:41:25] <Jacky^> ciao domenique
[16:36:53] <dmess> allo
[16:52:05] <Jacky^> servo
[16:52:10] <Jacky^> ops
[16:54:52] <domenique> hello
[18:57:24] <Jacky^> hello
[18:58:17] <Jacky^> how seem to you this motor i've here?:
http://digilander.libero.it/jackydgl0/pics/lab1.jpg
[18:58:38] <Jacky^> no datasheet found around
[19:01:44] <Jacky^> here some detail:
http://digilander.libero.it/jackydgl0/pics/lab2.jpg
[19:04:56] <Jacky^> :(
[19:36:33] <etla> hi
[21:02:41] <Jacky^> hi alex_joni
[21:04:59] <alex_joni> hello
[21:05:46] <Jacky^> hey, stay to home this evening ?
[21:05:56] <Jacky^> its saturday :P
[21:06:17] <alex_joni> I'm away from home ;)
[21:06:20] <alex_joni> up in the mountains
[21:06:35] <Jacky^> ah, nice :)
[21:08:07] <Jacky^> i'm uploading some photos
[21:09:00] <Jacky^> already have 2 big DC motors here, but can't find specs or datasheet :/
[21:09:20] <Jacky^> http://digilander.libero.it/jackydgl0/pics/lab1.jpg
[21:09:45] <Jacky^> surplus motor ..
[21:11:02] <Jacky^> no clue about voltage,torque,inertia
[21:11:36] <alex_joni> what's written on the motor?
[21:11:49] <Jacky^> http://digilander.libero.it/jackydgl0/pics/lab2.jpg
[21:12:01] <Jacky^> my cousin have 2 of these ..
[21:12:41] <Jacky^> data code is 086
[21:12:47] <alex_joni> looks brushless DC to me
[21:12:49] <Jacky^> i suppose is the year ..
[21:13:12] <Jacky^> brushless ? no idea..
[21:13:21] <alex_joni> permanent magnet
[21:13:31] <Jacky^> yeah
[21:13:47] <Jacky^> if so, G340 cant drive it ..
[21:13:51] <Jacky^> right ?
[21:14:11] <alex_joni> I think so.. looking now
[21:14:38] <Jacky^> ta
[21:14:42] <alex_joni> hmmm. . this says it can:
http://www.geckodrive.com/product.cfm?pid=14
[21:15:07] <Jacky^> would be nice
[21:15:23] <alex_joni> * alex_joni was mistaken
[21:17:44] <Jacky^> found one similar here:
http://www.servorepair.com/stock_servomotors.htm
[21:18:13] <Jacky^> but just similar as brand
[21:18:44] <Jacky^> this ive has no tach
[21:18:55] <alex_joni> * alex_joni remembers seeing some EC motors on older robots
[21:18:55] <Jacky^> one
[21:19:59] <Jacky^> it turn with a good torque using just 9V battery ..
[21:24:29] <Jacky^> id like to try it with the gecko and this screw
[21:24:34] <Jacky^> http://digilander.libero.it/jackydgl0/pics/lab3.jpg
[21:25:10] <Jacky^> but i dont know how to get encoder work up
[21:25:27] <alex_joni> what do you mean?
[21:25:31] <alex_joni> you got some encoders?
[21:25:36] <Jacky^> yeah ..
[21:25:40] <Jacky^> a moment
[21:25:52] <alex_joni> apply voltage to them, and look with a scope at the signals
[21:26:01] <Jacky^> not bought yet.. id like just to test this motor
[21:26:03] <alex_joni> you should get quadrature for them to work with the gecko's
[21:26:12] <alex_joni> you can't without
[21:26:17] <alex_joni> the gecko's won't run
[21:26:27] <alex_joni> or they will move the motor out of control
[21:26:42] <alex_joni> start moving slowly, then faster... but without any control
[21:27:20] <Jacky^> i jeus get this from an old printer :
http://digilander.libero.it/jackydgl0/pics/lab5.jpg
[21:27:39] <Jacky^> got no datasheet online about the agilent component
[21:27:58] <Jacky^> but i found + - 5V and the 2 phases
[21:28:17] <Jacky^> not sure if it can work ..
[21:28:32] <alex_joni> should
[21:29:34] <Jacky^> ill try ..
[21:39:57] <alex_joni> hi john
[21:40:46] <Imperator_> Hi Alex, Hi John
[21:40:56] <alex_joni> Hello Martin
[21:42:18] <Imperator_> how are you
[21:42:57] <alex_joni> cold :D
[21:43:04] <alex_joni> it's -2 outside :))
[21:43:19] <Imperator_> ups
[21:43:40] <Imperator_> here we have 20 � at daytime and about 6 at night
[21:43:56] <alex_joni> I had about 5 at noon today (up in the mountains)
[21:43:57] <alex_joni> :D
[21:44:07] <Imperator_> extremly warm here at the moment, i know even colder summers :-)
[21:44:35] <Imperator_> ok in the mountains its always colder
[21:45:12] <Imperator_> on which altitude are you
[21:49:20] <alex_joni> about 1000m (I think 1005 or so)
[21:51:19] <Imperator_> ok, that something you can more or less call a mountain :-)
[21:53:25] <alex_joni> probably you need to add my bed right now (so 1005.7 should be accurate enough)
[21:55:32] <Imperator_> :-)
[21:58:05] <jmkasunich> does anybody know who Yabo Sukz is?
[21:58:23] <alex_joni> you asked that already
[21:58:28] <alex_joni> about half a year ago
[21:58:30] <alex_joni> :P
[21:58:31] <jmkasunich> when?
[21:58:38] <jmkasunich> well he's at it again
[21:58:42] <alex_joni> IF my memory serves me right
[21:58:48] <alex_joni> yup... seems like it
[21:58:48] <jmkasunich> this time I think his commit busts things
[21:59:01] <alex_joni> it did? didn't have the chance to test
[21:59:03] <jmkasunich> he seems to have changed the way you config the hal stepgen module
[21:59:48] <jmkasunich> from ' cfg="0 0 1" ' to 'step_type[0]=0 step_type[1]=0 step_type[2]=1'
[21:59:56] <jmkasunich> his way might actually be better
[22:00:21] <jmkasunich> but not when committed under a heading of "fixed bug, clean code", and not when he didn't change the comments or other docs to match
[22:00:27] <alex_joni> 2005-07-09.txt:18:10:42 <jmkasunich> do you know who "yabo sukz" is?
[22:00:49] <alex_joni> so .. only 4 months ago (my memory still is kinda intact)
[22:00:53] <jmkasunich> and the answer back then was "nobody knows", right?
[22:01:26] <cradek> I wondered about that too...
[22:02:31] <alex_joni> jmkasunich: yup
[22:04:06] <jmkasunich> I'm writing an email to his SF addy asking him to contact me
[22:04:18] <jmkasunich> if I don't get some kind of explanation I will revert the commit
[22:04:33] <alex_joni> google turns up pretty empty
[22:04:57] <alex_joni> jmkasunich: good that I catch you.. :)
[22:05:16] <cradek> he has not sent mail to either emc list since Apr 2003
[22:05:27] <alex_joni> wondered about my last mail to the list.. do you think we should put an emc2 release on SF?
[22:05:45] <jmkasunich> dunno
[22:06:10] <jmkasunich> I'm perfectly happy "distributing" it using CVS
[22:06:30] <alex_joni> ok.. maybe we should wait for the new board to decide
[22:06:31] <jmkasunich> not ready to start supporting every Tom, Dick, and Harry that downloads it
[22:06:39] <alex_joni> right
[22:07:32] <jmkasunich> meanwhile I gotta get this stepgen mess cleaned up
[22:07:43] <icee> Even if distribution uses cvs to keep things obscure.. IMO you guys should periodically have stable branches
[22:07:50] <icee> so stuff like this stepgen stuff doesn't happen in them
[22:08:07] <jmkasunich> EMC2 by definition is not stable
[22:08:26] <jmkasunich> I understand what you are saying
[22:08:26] <icee> Is there a roadmap or series of releases heading towards stability?
[22:08:43] <icee> You need to bunch up things by risk. If I were to start hacking on the trajectory planner, that would be higher risk than most of the things happening in emc2 now
[22:08:45] <jmkasunich> but IMHO, this stepgen problem is a case of a careless release,
[22:08:47] <alex_joni> icee: it's pretty much like a ship sailing on it's own
[22:08:48] <alex_joni> :)
[22:09:04] <icee> and it would be unfair to burden the bulk of emc2 users with that
[22:09:10] <alex_joni> jmkasunich: no offence, but it sure feels like that
[22:09:17] <jmkasunich> the roadmap is a good subject for discussion
[22:09:30] <jmkasunich> my approach to date has been: HEAD is the current working copy
[22:09:49] <alex_joni> maybe tags inside HEAD for releases
[22:09:51] <jmkasunich> non-trivial expirements (like TP stuff) go in branches, and merge into head when known to work
[22:10:05] <icee> that's very different from the way most software projects use CVS, not that it's unworkable
[22:10:17] <icee> usually HEAD is bleeding-edge new stuff, and then branches correspond to releases of varying states of stability
[22:10:34] <icee> changes get made in HEAD, and new branches get formed off HEAD to head for stability; or changes get merged down from HEAD to existing branches
[22:10:44] <cradek> icee: with jmk's strategy, two people can work on different breakage projects simultaneously
[22:11:07] <icee> cradek: well, you can still have 'high risk' branches off the HEAD in addition to the release branches
[22:11:22] <cradek> icee: I see
[22:11:30] <icee> then they get merged down into the HEAD, and then are part of the next release branched off the hEAD
[22:11:36] <jmkasunich> icee: we might be forced to have releases or release branches sooner or later
[22:11:42] <jmkasunich> but I dread that day
[22:12:01] <cradek> jmkasunich: emc1 is already like that; there's breakage on HEAD and then there's my stable branch
[22:12:20] <icee> jmkasunich: well, it can be as informal if you like
[22:12:27] <icee> if things are mostly working one day, you branch there.
[22:12:37] <icee> Then you tell people to use that branch. high importance fixes can be manually put there
[22:12:38] <jmkasunich> I see a broken HEAD as an intolerable thing - HEAD breakage should be FIXED, not worked around with a release
[22:13:07] <icee> HEAD breakage should get fixed and then become a release.
[22:13:30] <icee> You control the amount of breakage coming into HEAD until it's a sane sized chunk to reconverge and get working
[22:13:59] <jmkasunich> different strokes for different folks I guess
[22:14:03] <icee> where the reconvergence happens-- in HEAD or a branch, doesn't really matter.. as long as the fixes make it into HEAD
[22:14:11] <jmkasunich> I personally don't commit anything I know is broken
[22:14:27] <icee> that's always a good thing jmka.. broken code should never get committed
[22:14:32] <icee> But 'young' code tends to always be broken
[22:14:51] <icee> passing unit test and trivial integration test doesn't equal 'mature'
[22:14:52] <jmkasunich> and I expect to be able to test using HEAD, which means can't have other folks committing breakage either
[22:14:58] <jmkasunich> true
[22:15:06] <jmkasunich> and those bugs need to be found and fixed
[22:15:21] <jmkasunich> but "doesn't compile" isn't something subtle
[22:15:33] <jmkasunich> nor is "changes syntax of ini files"
[22:15:35] <icee> yah, exactly. Things in CVS should always build (with the possible exception of 1-2 weeks after a release when there's major change.. but even then probably)
[22:16:11] <icee> just throwing it out there.. this is the way large companies use revision control and most open source projects execute.
[22:16:22] <icee> emc doesn't have to do it, but I think you guys could use more process
[22:16:26] <jmkasunich> I understand
[22:16:33] <jmkasunich> and perhaps it is the right way
[22:16:42] <icee> I'm afraid to start hacking on emc to be honest.
[22:17:01] <jmkasunich> I just dread having N users on branch X, and others on branch Y, and others on HEAD, and trying to support them all
[22:17:02] <alex_joni> why is that?
[22:17:24] <alex_joni> icee: why is that?
[22:17:34] <jmkasunich> * jmkasunich wants to know too
[22:17:48] <icee> alex: Well, the stuff that it seems like my time would be best spent on-- performance and trajectory planner stuff
[22:18:00] <alex_joni> jmkasunich: I know why you do.. and I agree it's not the best choice (at least not when having under a handfull of people doing that)
[22:18:06] <icee> are both very high risk and potentially unforgiving if handed to users that don't expect them
[22:18:17] <cradek> icee: so make a branch
[22:18:21] <alex_joni> icee: so use an own branch
[22:18:34] <alex_joni> darn, can't beat cradek to quick replies
[22:18:40] <alex_joni> :)
[22:18:40] <icee> ;)
[22:18:52] <cradek> you were not even close
[22:19:16] <alex_joni> cradek: depends on the lag you're seeing
[22:19:21] <icee> and the only problem with that is that I have to hope there's small enough movement underneath that i can eventually get merged down
[22:19:46] <alex_joni> cradek: but I know that you got buttons prepared for common answers :D
[22:19:46] <icee> and it's unclear to me how to best converge to that point-- merge up to my branch repeatedly and then merge down, or do one big merge
[22:19:47] <cradek> if you make a branch and check in your work, you let others test it too
[22:19:48] <jmkasunich> that of course depends on where you are working with respect to where others are
[22:20:20] <alex_joni> icee: I don't think that's an area others will change very often
[22:20:27] <cradek> icee: if you're working on TP, you will only touch a couple files in one directory. Merging isn't going to be a big problem.
[22:20:33] <jmkasunich> to be honest, I expect you could go on a branch for TP work for a month or more and nobody would even touch those files in HEAD
[22:20:45] <cradek> s/month/year/
[22:20:46] <jmkasunich> damn, cradek is quick
[22:20:49] <icee> well, that's a good sign.
[22:20:50] <alex_joni> a month? :)
[22:20:55] <alex_joni> darn.. yes he is
[22:20:58] <icee> I need to actually read the code to see how bad it is.
[22:21:10] <alex_joni> it's not bad.. not very readable otoh
[22:21:11] <icee> If it's disentangled, that's at least a good sign
[22:21:12] <jmkasunich> you might not want to work on it after you do ;-/
[22:21:37] <icee> how hard would it be to implement an interface for 'pluggable' trajectory planners?
[22:21:44] <jmkasunich> dunno
[22:21:51] <icee> Because that might be a nice middle ground
[22:22:00] <jmkasunich> that would require groking the existing interface more fully than I do now
[22:22:10] <icee> * icee will look at it
[22:22:27] <jmkasunich> I'm all for pluggable stuff (see HAL for proof)
[22:22:27] <icee> because that could allow you to have an 'old generation' TP and a 'new generation' one, and let users choose their level of risk
[22:22:48] <icee> (and eventually, there could be jerk-limited TP, etc)
[22:22:50] <alex_joni> icee: at the worst we can make that a compile option
[22:23:04] <alex_joni> limit it to ./configure or smthg like that
[22:23:13] <alex_joni> ./configure --with-tp=old-style
[22:23:26] <cradek> in emc1 you could pick the TP in the ini
[22:23:32] <cradek> is that no longer possible?
[22:23:41] <alex_joni> you could? never heard that
[22:24:00] <jmkasunich> me neither
[22:24:08] <jmkasunich> cradek: are you sure?
[22:24:20] <alex_joni> the TP? or how it should behave?
[22:24:24] <cradek> ummm
[22:24:44] <cradek> you could change EMCMOT=
[22:24:45] <jmkasunich> I think ini selection of one of N TPs is a nice idea
[22:24:59] <alex_joni> that's the motion controller (with TP inside)
[22:25:04] <cradek> right
[22:25:13] <jmkasunich> there were things like freqmot, stgmot, steppermot, etc, but they all used the same TP
[22:25:19] <cradek> all the rest of the code was .... copied
[22:25:22] <alex_joni> that can be done in emc2 too.. but you'd need to compile the new motion controller with a new TP
[22:25:33] <cradek> jmkasunich: no they didn't; there was for instance steppermod and steppersegmod
[22:25:36] <alex_joni> might be doable, pretty easily
[22:25:46] <alex_joni> yup, the SQ stuff
[22:25:52] <jmkasunich> oh, that's right, forgot about seqmentqueue
[22:26:18] <jmkasunich> mostly because it is something only it's creator has any chance of understanding
[22:26:26] <cradek> bah
[22:26:39] <cradek> I pretty much understand it - I read the paper
[22:26:54] <jmkasunich> reading the paper and understanding the code are two different things
[22:27:01] <jmkasunich> but if you get it, that's great
[22:27:14] <alex_joni> cradek: any idea why it's "known" to be busted then?
[22:27:19] <alex_joni> * alex_joni is not even sure it is busted
[22:27:27] <cradek> alex_joni: it has some bugs, but I'm not sure at all that it's busted
[22:27:32] <icee> what exactly was segmentqueue?
[22:27:39] <cradek> alex_joni: last I heard, paul declared it busted, and nobody asked him why.
[22:27:40] <jmkasunich> what I want is a clearly defined (and documented) interface between TP and the code that calls it
[22:27:56] <alex_joni> icee: an evil thing
[22:27:59] <alex_joni> just kidding
[22:28:00] <cradek> alex_joni: I can successfully make parts with it. The bugs I identified are in the tracker.
[22:28:01] <jmkasunich> segmentqueue was an attempt to do more sophisticated lookahead
[22:28:12] <icee> is it what it sounds like? a FIFO of trajectory segments?
[22:28:13] <alex_joni> and more sophisticated blending
[22:28:27] <alex_joni> icee: with blending applied to certain groups of them
[22:28:40] <alex_joni> given some conditions, if I understand it corectly
[22:28:43] <cradek> icee: it fits a high-degree polynomial to several (many) upcoming points
[22:28:45] <jmkasunich> les did much testing on it
[22:28:51] <jmkasunich> sometimes it worked nicely
[22:29:05] <jmkasunich> but some pathological G-code programs could mess it up good
[22:29:13] <cradek> yeah, that's my experience too
[22:29:17] <jmkasunich> (like lock it up)
[22:29:27] <cradek> no, I never saw that after my fixes.
[22:29:30] <etla> what does the output of the TP look like ?
[22:29:34] <alex_joni> or at least make it stutter from what I've heard
[22:29:48] <jmkasunich> thats a good question... part of the interface thing I was talking about
[22:29:54] <cradek> yes, I think it would start exact-stopping if more than queuelen segments required joining
[22:29:56] <alex_joni> etla: some pinkish elements
[22:30:12] <jmkasunich> there is no doc that says; "a TP must accept the following commands and produce the following outputs"
[22:30:51] <alex_joni> etla: mixed with purple lines at the corners
[22:30:56] <etla> one more stupid Q: in EMC2, is all of EMCMOT implemented using HAL ?
[22:30:57] <jmkasunich> in general tho, a TP should accept commands like "arc" and "line", and produce a series of position commands that are samples on the desired path
[22:31:17] <jmkasunich> etla: nope - the core of the motion controller is similar to what it was
[22:31:24] <alex_joni> etla: depends on what you understand under emcmot
[22:31:31] <jmkasunich> but all interactions with drivers, etc, use HAL
[22:31:38] <jmkasunich> and the PID loops have been moved into HAL
[22:31:40] <alex_joni> if you mean the output from the motion controller to the real world, then yes it's HAL
[22:31:46] <icee> are there any shape primitives other than arc and line?
[22:32:01] <etla> not in normal G-code i think
[22:32:02] <jmkasunich> not really
[22:32:17] <alex_joni> but the actual code (inside the motion control) is still like the old one (c-code kernel-module)
[22:32:18] <icee> not in gcode, but not anywhere else lurking in emc or anything? no bezier silliness or anything, right?
[22:32:25] <jmkasunich> there are a crapload of motion controller commands, but only those two are used for paths
[22:32:26] <alex_joni> icee: not really
[22:32:35] <icee> OK.. that greatly constrains things
[22:32:38] <jmkasunich> (others are things like jog, home, config commands, etc)
[22:32:38] <cradek> icee: helixes are allowed
[22:32:48] <jmkasunich> helix is an arc
[22:32:58] <etla> cradek but that is circle for xy and linear for z, right
[22:33:04] <cradek> yes
[22:33:23] <cradek> but it has a different length than the projected arc, so it must be handled differently (I fixed this in emc1)
[22:33:24] <jmkasunich> except you can use any two axis, not always xy
[22:33:29] <alex_joni> icee: the interface from motion controlelr to TP goes through these 2 functions basicly (tpAddLine and tpAddCircle)
[22:33:35] <icee> hm.. that shouldn't be too bad. trajectory planning for arc and linear primitives isn't exactly rocket science
[22:34:00] <jmkasunich> I think the TP treats everything like a helix, "plain" arcs are just a special case where dZ = 0, and don't need any special code
[22:34:03] <alex_joni> from there... not much clue what happens..
[22:34:17] <jmkasunich> alex: that's only half of it
[22:34:25] <alex_joni> one direction of course
[22:34:30] <alex_joni> not the return of the data
[22:34:34] <jmkasunich> AddLine and AddCircle tell it what moves it needs to make
[22:34:47] <jmkasunich> there are other calls that request the next position in the path
[22:34:48] <icee> well, I can read the code to determine the exact interfaces
[22:34:52] <jmkasunich> * jmkasunich greps the code
[22:35:11] <alex_joni> extern int tpAbort(TP_STRUCT * tp);
[22:35:12] <alex_joni> extern int tpAddCircle(TP_STRUCT * tp, EmcPose end, PmCartesian center,
[22:35:12] <alex_joni> PmCartesian normal, int turn);
[22:35:12] <alex_joni> extern int tpAddLine(TP_STRUCT * tp, EmcPose end);
[22:35:12] <alex_joni> extern int tpClear(TP_STRUCT * tp);
[22:35:12] <alex_joni> extern int tpCreate(TP_STRUCT * tp, int _queueSize, TC_STRUCT * tcSpace);
[22:35:22] <alex_joni> extern int tpGetExecId(TP_STRUCT * tp);
[22:35:23] <alex_joni> extern EmcPose tpGetPos(TP_STRUCT * tp);
[22:35:23] <alex_joni> extern int tpInit(TP_STRUCT * tp);
[22:35:23] <alex_joni> extern int tpIsDone(TP_STRUCT * tp);
[22:35:23] <alex_joni> extern int tpPause(TP_STRUCT * tp);
[22:35:23] <alex_joni> extern int tpResume(TP_STRUCT * tp);
[22:35:25] <alex_joni> extern int tpRunCycle(TP_STRUCT * tp);
[22:35:27] <alex_joni> and a few others
[22:36:27] <jmkasunich> RunCycle and GetPos are the key ones on the output side
[22:36:32] <etla> if the output is a series of positions (input for the PID), then time is somehow discretized ?
[22:36:45] <jmkasunich> control.c:1547 and nearby
[22:36:51] <alex_joni> yes, it runs at trajectory rate
[22:36:55] <alex_joni> and outputs points
[22:36:55] <jmkasunich> yes
[22:37:05] <jmkasunich> that is a big part of what the TP is all about
[22:37:31] <etla> so could/should it be implemented using HAL ?
[22:37:46] <alex_joni> I've seen paul started some work on TP, and commited some math to src/emc/kinematics/trajectory.h (not part of current TP)
[22:37:50] <jmkasunich> not really
[22:37:54] <alex_joni> etla: don't see why?
[22:38:10] <alex_joni> what would be the benefit of HAL for TP?
[22:38:31] <alex_joni> it would make passing data more complicated
[22:38:32] <jmkasunich> the output of the TP is a sampled signal (positions), but the input is discrete commands, HAL doesn't handle that well
[22:38:36] <etla> ok I don't know... but it talks to a HAL position pin ?
[22:38:48] <jmkasunich> eventually yes
[22:38:58] <jmkasunich> but there are other motion controller parts between TP and the output to HAL
[22:39:02] <alex_joni> it's linked in the motion controller code.. so it can talk standard c-functions
[22:39:18] <jmkasunich> things like homing and jogs are not part of the TP, they are handled in other motion control code
[22:39:23] <etla> and the circle/arc commands come in as NML messages from the interpreter ?
[22:39:26] <alex_joni> you still need to do some checking on the outputs before releasing them to the outer world
[22:39:36] <jmkasunich> etla: sort of
[22:39:36] <domenique> hello alex_joni
[22:39:49] <jmkasunich> they arrive as NML to something called usrmotintf
[22:39:50] <alex_joni> hello
[22:40:02] <jmkasunich> that converts them into shared memory commands to the motion controller
[22:40:13] <jmkasunich> because NML itself can't cross the realtime boundary
[22:40:39] <etla> ok...
[22:40:40] <alex_joni> actually they arrive as g-code to the interpreter, which converts them to canonicals, and sends them to task, which passes them on to usrmotintf
[22:40:43] <jmkasunich> the EMCMOT command set corresponds approximately 1-to-1 with NML messages, but only approximately
[22:41:03] <etla> is the overall structure docuemnted somewhere ?
[22:41:10] <jmkasunich> yes, but poorly
[22:41:13] <alex_joni> etla: all over :)
[22:41:25] <etla> thats the problem.
[22:41:59] <etla> very hard to just jump in and work on a single problem...
[22:42:15] <alex_joni> etla: you just need to ask what you need
[22:42:31] <etla> a new brain, more spare time
[22:42:41] <icee> well, it sounds like the TP is nicely decoupled
[22:42:48] <alex_joni> ok.. sign me up for that too
[22:42:49] <icee> so it's not too bad of a contained problem
[22:43:14] <alex_joni> icee: I don't think it would be that hard to exchange the TP with another working one
[22:43:36] <icee> and it doesn't look like it would be too bad to make it pluggable at runtime, either
[22:43:47] <alex_joni> that's harder
[22:44:00] <alex_joni> because we are talking about parts of a kernel module
[22:44:16] <alex_joni> so either build a few modules, and chose which to use at runtime
[22:44:23] <icee> still not bad. function pointers in the TP_STRUCT are your friend
[22:44:32] <alex_joni> or use some mechanism like HAL? or udev or whatever
[22:45:09] <jmkasunich> actually, the TP could be a module of its ownb
[22:45:34] <jmkasunich> as long as all TP's export the same list of functions, and have the same prototypes
[22:45:43] <jmkasunich> you can insmod whichever one you want
[22:45:51] <jmkasunich> you can't have reverse links tho
[22:45:57] <alex_joni> right, that would be fairly easy to do
[22:46:13] <jmkasunich> IOW, if you load the TP module first, then the motion controller module can call it, but it can't call the motion controll module
[22:46:18] <icee> well, you can register callbacks for reverse links if you need them
[22:46:18] <alex_joni> icee: get that new TP in here, and we'll hook it up :)
[22:46:42] <icee> well, first things first. need to get my servo driver working first.
[22:46:47] <icee> So I have a meaningful test case
[22:46:50] <alex_joni> jmkasunich: afaik, the TP doesn't call the motion code
[22:46:57] <jmkasunich> not directly
[22:46:59] <alex_joni> it's only the other way around
[22:47:12] <jmkasunich> I don't know if it calls anything from posemath ahd such tho
[22:47:48] <alex_joni> so? that's not part of the motion controller.. could get linked into the TP module
[22:47:48] <jmkasunich> and there are also global variables
[22:48:10] <jmkasunich> I know its not an unsolvable problem
[22:48:21] <jmkasunich> but remember that kins call posemath too
[22:48:27] <icee> well, i'll look at it. I'm not so interested in the exact interface particulars
[22:48:31] <icee> but the knowledge and rationale behind them.
[22:48:38] <jmkasunich> so you need to load posemath before the TP, and the motion controller after
[22:48:44] <icee> I can read the code to figure out how things are; just I can't determine all of 'why' from that
[22:49:06] <alex_joni> icee: afaik there is no paper on the TP :/
[22:49:08] <jmkasunich> first excercise is to determine if the function calls are the only connection between TP and motion controller
[22:49:22] <jmkasunich> I seriously doubt it - there are a bunch of globals too
[22:49:27] <alex_joni> at least not on the standard one, there are some papers on the SQ TP
[22:49:33] <icee> a_j: yah, but developing a trapezoidal velocity TP borders on trivial
[22:49:36] <alex_joni> jmkasunich: point me to them
[22:49:46] <jmkasunich> the globals?
[22:50:00] <alex_joni> icee: that's what it does, along with some cubic subinterpolation
[22:50:03] <alex_joni> jmkasunich: yes
[22:50:45] <jmkasunich> * jmkasunich looks
[22:51:54] <icee> well, being efficient with interpolation can be hard.
[22:51:57] <alex_joni> I see that it include ../motion/motion_priv.h , but I don't think it accesses hal data..
[22:52:01] <icee> well, harder.
[22:52:08] <jmkasunich> * jmkasunich may have to eat his words about globals
[22:52:27] <alex_joni> I see only 2, and those are for debug purposes.. can go away any time
[22:52:45] <jmkasunich> icee: the blending is where it gets non-trivial
[22:53:04] <alex_joni> icee: especially blending lines to arcs
[22:53:27] <jmkasunich> imagine a case where you are moving along in a long line (several inches long), and your speed is such that you need to begin to decel 0.50 inches before the end of the line
[22:53:51] <jmkasunich> now suppose the next 250 commands are tiny line segments, each 0.001 long
[22:54:08] <jmkasunich> the first 249 are parallel to the original line, so there is no need to slow down for them
[22:54:13] <jmkasunich> but the last one is at right angles
[22:54:41] <jmkasunich> you need to know about that last one before you finish the first line, because you need to begin slowing 0.250 before the end of the first line
[22:54:48] <icee> jmka: yah, I know.
[22:54:56] <etla> so you need to have smart lookahead - and not geometrical blending like G64 is now
[22:55:02] <jmkasunich> exactly
[22:55:05] <icee> though in a real world one you might have a limited number of segments of lookahead to keep things sane
[22:55:29] <alex_joni> icee: usually limited by the tp queue
[22:55:30] <icee> so you have to be pessimistic and assume that you have to be ready to stop after 200 segments, because that's how far you look
[22:55:32] <jmkasunich> yeah, variable length buffers in kernel space aren't a nice thing
[22:55:58] <jmkasunich> you also need a user->rt channel that can keep your lookahead buffer full
[22:56:13] <jmkasunich> the existing channel isn't so good IMHO
[22:56:26] <icee> though when they're actually parallel within a desired precision you can just stitch them together, i guess
[22:56:34] <icee> and dequeue them
[22:56:38] <jmkasunich> there is a buffer, but it lives entirely on the RT side, it doesn't cross the barrier
[22:56:43] <alex_joni> jmkasunich: got 5 mins for my question?
[22:56:49] <jmkasunich> shoot
[22:57:04] <alex_joni> http://sourceforge.net/tracker/index.php?func=detail&aid=1238816&group_id=6744&atid=106744
[22:57:29] <alex_joni> I dropped you an email on that one.. not sure you got it
[22:57:38] <jmkasunich> icee: what about aren't quite parallel, but still make up a smooth curve that should be blended (like a spline or elipse)
[22:57:59] <alex_joni> or even an arc
[22:58:12] <alex_joni> a lot of CAM software outputs crap g-code (lines instead of arcs)
[22:58:16] <etla> there needs to be a blending tolerance
[22:58:23] <icee> well, it might make sense to blend them into bezier curves with a specific accumulated tolerance
[22:58:55] <jmkasunich> alex: I don't recall an email
[22:58:57] <alex_joni> bezier or b-spline
[22:59:15] <alex_joni> 24.10
[22:59:15] <icee> yah.
[22:59:21] <jmkasunich> that isn't something I'd even get involved in though (especially if it was last week while I was up to my elbows in Mazak)
[22:59:24] <alex_joni> jmkasunich: want me to resend?
[22:59:33] <jmkasunich> if you want
[22:59:40] <icee> still easy to do the math and velocity planning on a b-spline, including jerk limiting
[22:59:41] <jmkasunich> but to be honest, that's the part of the program that I avoid
[23:00:06] <jmkasunich> anything above usermotintf is scary to me
[23:00:08] <jmkasunich> ;-)
[23:00:09] <alex_joni> icee: you'll see people limiting themselves to areas they know
[23:00:21] <alex_joni> * alex_joni wouldn't touch the interpreter :)
[23:00:25] <jmkasunich> ditto
[23:00:34] <alex_joni> jmkasunich: just had a nasty fight with NML messages
[23:00:34] <icee> well, that's fine; the part that scares me is everyone seems to be scared of the TP
[23:00:42] <icee> and it uh, seems to have problems
[23:00:46] <alex_joni> spend half a night to write abotu 20 lines of code
[23:01:14] <alex_joni> icee: probably most are scared because it's not their field of expertise..
[23:01:22] <jmkasunich> that's why I'm such a strong proponent of interfaces, so people can work in their own areas of expertise with a well-defined "contract" that says what they must and must not do
[23:01:29] <alex_joni> or maybe because so much math is involved :)
[23:01:53] <icee> the code is scarier than the math ;)
[23:01:59] <etla> the physics and math is not a problem ! jkmasunich: YES for interfaces
[23:02:41] <alex_joni> icee: maybe not for you, for others it's just the other way around
[23:03:08] <etla> and documentation seems to be all over the place - but maybe thats true for all opensource stuff
[23:05:12] <alex_joni> etla: right
[23:14:56] <fenn> * fenn has deja vu
[23:15:48] <alex_joni_> alex_joni_ is now known as alex_joni
[23:17:27] <alex_joni> * alex_joni should learn how to drive
[23:17:33] <alex_joni> getting collisions :D
[23:17:34] <etla> ok, have to sleep now, bye.
[23:17:53] <jmkasunich> night
[23:19:32] <Imperator_> what i don't understand is why TP is running on kernel side
[23:19:51] <alex_joni> because it needs to run realtime
[23:19:58] <alex_joni> to produce the paths
[23:22:00] <Imperator_> don't think so Alex
[23:22:13] <jmkasunich> depends
[23:22:29] <Imperator_> you only have to take care that there are always some ponts in the que
[23:22:49] <jmkasunich> things like feedrate override complicate things tho
[23:22:51] <Imperator_> queue
[23:22:57] <Imperator_> jep
[23:23:12] <jmkasunich> with the TP in realtime, it can adapt to feedrate changes immediately
[23:23:34] <jmkasunich> if you queued points, then the machine would run at the old rate until the queue emptied
[23:26:15] <Imperator_> have worked a long time with a NUM controller. NUM is now owend by Schneider electronik i think. I have transfered the G-Code by a serial line from a computer to the controller. If i head only short segments it runs empty then the machine stops and starts all the time, so it begans to vibrate.
[23:26:42] <Imperator_> so the profesional controllers are also not aware of that problem
[23:27:07] <alex_joni> oh.. they are aware..
[23:27:13] <alex_joni> they just didn't fix it :P
[23:27:21] <Imperator_> i think that if TP runs in userspace it would be much faster !!
[23:27:41] <jmkasunich> I don't think so
[23:27:57] <jmkasunich> you just move the buffering issue
[23:28:07] <jmkasunich> today we buffer commands, you are talking about buffering points
[23:28:34] <Imperator_> jep
[23:28:40] <alex_joni> and speeds
[23:28:49] <Imperator_> exactly
[23:28:50] <alex_joni> vectors to be more precise
[23:29:12] <alex_joni> how many points?
[23:29:24] <alex_joni> trajectory outputs one point each cycle
[23:29:27] <alex_joni> that's a LOT
[23:29:50] <jmkasunich> yeah, 1 second of buffer = 1000 points
[23:29:54] <Imperator_> and if the motion controler sees that the queue runs empty it can reduce feed override
[23:30:08] <alex_joni> on it's own?
[23:30:15] <alex_joni> don't think I would EVER want that
[23:30:30] <alex_joni> crap out .. yes, but do smthg like that on it's own is bad
[23:30:33] <jmkasunich> same here
[23:30:43] <jmkasunich> I strongly believe the TP should be in RT
[23:30:57] <Imperator_> can we do floating point calculations on the RT side ???
[23:31:04] <jmkasunich> yes
[23:31:06] <alex_joni> posemath does it
[23:31:26] <Imperator_> posemath implements that ?
[23:32:03] <jmkasunich> posemath does FP math
[23:32:05] <alex_joni> "* Data types comprise various representations of translation and
[23:32:06] <alex_joni> * rotation quantities, and a 'pose' for representing the location
[23:32:06] <alex_joni> * and orientation of a frame in space relative to a base frame.
[23:32:06] <alex_joni> * Translation representations include cartesian, spherical, and
[23:32:06] <alex_joni> * cylindrical coordinates. All of these contain 3 elements. Rotation
[23:32:06] <alex_joni> * representations include rotation vectors, quaternions, rotation
[23:32:08] <alex_joni> * matrices, Euler angles, and roll-pitch-yaw. These contain at least
[23:32:10] <alex_joni> * 3 elements, and may contain more. Only 3 are necessary for the 3
[23:32:12] <alex_joni> * degrees of freedom for either translation or rotation, but some
[23:32:14] <alex_joni> * data representations use more for computational efficiency or
[23:32:14] <anonimasu_> hello
[23:32:16] <alex_joni> * intuition at the expense of storage space.
[23:32:30] <alex_joni> hi anders
[23:34:11] <Imperator_> what i think is that our TP is to complicated
[23:34:38] <Imperator_> i think that Haidenhain controllers are doing the same much easyer
[23:34:45] <alex_joni> nope.. it's too simple as it is now :)
[23:34:48] <anonimasu_> the difference is in the manpower..
[23:35:06] <anonimasu_> heidenhain has maybe 10 professors employed to write the algorithm
[23:35:17] <anonimasu_> then somone else to implement it.
[23:35:39] <Imperator_> Siemens makes it complicated and it don't work, there are cases where it calculates the wrong path
[23:35:57] <anonimasu_> Imperator_: how do you know that?
[23:36:11] <anonimasu_> how do you make out that it's complicated
[23:36:28] <Imperator_> we have a Siemns 840D on a Digma machine in our lab
[23:36:30] <anonimasu_> icee: the tp is nothing to be afraid of ;) just a horrid mess..
[23:37:15] <Imperator_> i think that aidenhain calculates the waypoints and the speed for each point, and then they apply some filters to that !!!
[23:37:27] <anonimasu_> you dont know in reality then.,,�
[23:37:36] <Imperator_> jep
[23:37:56] <anonimasu_> :)
[23:38:08] <Imperator_> they do thinks much easyer than the others and they are the best
[23:38:18] <anonimasu_> how do you know that it's easier?
[23:38:31] <anonimasu_> have you got the sourcecode so you can study their tp?
[23:38:45] <Imperator_> Haidenhain controllers make the best surfaces if you want to produse freeform surfaces
[23:39:12] <Imperator_> or how do you call them in english ?
[23:39:18] <anonimasu_> ah that's just fine
[23:39:41] <anonimasu_> but that dosent imply that their algorithms are simple..
[23:39:46] <Imperator_> don't have some sourecode :-(
[23:40:52] <Imperator_> the people from Digma who make the machines said that
[23:41:45] <Imperator_> ok they don't made the controller, but they know a lot. also a lot about the internals of the controlers
[23:43:52] <anonimasu_> anonimasu_ is now known as anonimasu
[23:45:22] <alex_joni> LOL: anonimasu has quit IRC ("aieeee")
[23:48:10] <Jymmm> ouuuuuuuuuuuuuuuuuuuu
[23:48:42] <alex_joni> hey Jymmm, woken up already?
[23:48:47] <Jymmm> no
[23:49:13] <alex_joni> oh.. then you might even say some sensible things.. not the usual blabber
[23:49:55] <Jymmm> doubtful
[23:50:18] <alex_joni> agreed
[23:55:18] <alex_joni_> alex_joni_ is now known as alex_joni
