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