just got back
did you see my mail to the board list about "board business"?
(been having mail probs, it hasn't appeared here yet)
it's not you
sf mails were taking over an hour earlier today
well, I guess it could also be you :-)
I sent that one a lunchtime I think, and its still not here
switch to the board chan?
SWP_Away is now known as SWPadnos_
did you see the change I committed to core_servo.hal?
I think so
pid.n.maxoutput = [AXIS_n]MAX_VELOCITY
fixed the following errors I was getting
damn... my att mail is slow, I saw it on my yahoo acct, but don't have that window open right now
it was a real pisser to search for 6 hours to find a configuration change "bug" ;)
jmkasunich: still around?
two questions for you
first, I was thinking about the PID parameter problem (default output limit of 1, but max_velocity default to 1.2), and thought about overshoot
does it make sense to allow the pid block to overshoot the axis max_velocity, to give it a chance to "catch up" to a requested step change in velocity?
that whole topic is a mess
I thought the people with problems were running steppers anyway?
well - you still need PID with steppers (and the USC), becuase the actual step rate (quantized) won't necessarily match the (float) requested rate
the usc isn't steppers ;-)
neither is stepgen
stepgen uses core-stepper.hal
no PID loop
but there should still be some ability to dither between the two closest attainable rates, to get the requested rate as an average
so it is distinct from USC steppers and all others that use core-servo.hal
with core-servo, the pid loop does the dithering as it constantly corrects for errors
stepgen just does it internally, since it already knows how many steps it has output
with core-stepper, there is an internal loop that is part of stepgen, and it does whatever dithering is needed
(using a non-pid method, I know)
kind of an artifact of DDS, actually
I was assuming the problems people were reporting were with stepgen
and assumed some problem with that internal loop
right - I was thinking the same thing with the PPMC stepgen
it's non-trivial, basically a little trapezoidal TP of its own
that's why it took so long to find where the (damned) limit of 1 IPS came from
skunkworks over on the other channel is talking about one of those bugs
I want to go over there and see if I can replicate it
it may well be related to this conversation
sorry - was afk for a mo - I'll read back
hey petev - trying to not pollute that channel
they aren't called that, but the construction of a stepper is basically what you would have with a 2-phase AC motor
microsteppers try to approximate a sinewave (or triangle / trapezoid) into the two phases, 90 degrees apart (instead of 120, like 3-phase AC)
hey cradek - got a sec, or are you fixing a dead computer? :)
swp: I don't realy understand what a 2 phase system is. 2 wires is one phase, 3 wires is 3 phases
2-phase is two sets of 2 wires (each pair gets one phase)
actually, you could do two phase with 3 wires
you can do 3-phase that way as well - 3 separate coils, each with 2 wires (rather than the delta or wye connections usually used)
sure - common, phase A, phase B
the real difference is the phase relationships
2 phase has 90 degrees between phases
3-phase has 120
right, and you get the other two 90-degree "corners" by reversing current direction
which is unnecessary once you have 3 or more phases
3 phase systems almost always reverse current too
so you really have more phases with 4 wire, but some are just 0 volts so you are ignoring them?
yes, swp says two separete coils
you mean 3phase with neutral distribution, or 4 wire steppers?
that's 4 wires
steppers have two coils, 90 degrees apart
a 4 wire stepper has two windings oriented 90 degrees to each other (90 electrical degrees)
each winding at some point in the cycle has positive and negative current
hence H bridges in the drive
however, if you don
to me, the phase we are talking about is the potentials between each pair of wires
and is essentially the same construction (brushless, "manual" commutation, sequenced activation) as a BLDC servo
don't want H bridges, then you can center tap each winding, and power one half at a time
so with 4 wires, you get 6 phase relationships, correct?
the number of wires is irrlevant
its the number and orientation of the coils
so when you say phase, you are talking about the coils in the motor then?
sorry - this is a big tangent to my (mostly accurate, but not absolute) statement that people use fake encoders with steppers all the time ;)
you can have a two phase motor with 3, 4, 6, or 8 leads
jmkasunich: can I ask you my halcmd wuestion now? (there seems to be a lull in #emc)
ok - remember that I was going to add filtering and/ or owner name printing in show?
but you said that you were going to makesome changes, so I should hold off
I'm assuming that you haven't made those changes (the multiple long mights with a hot USC getting in the way)
what are you planning, in a nutshell?
long term (weeks, maybe months, but hopefully in an incremental way....)
move metadata out of shmem
ah right - and make userspace calls that can ask for the data using a library
extend the api to support listing, without halcmd actually knowing about and traversing the lists
jmk: did you try out that ngc parser I emailed?
me either - sorry
what do you think about the expressions it allows?
sorry, but I can't even keep up with the motion control parts of emc
should we limit their use?
I'm really out of my depth talking about the interp in any but the most general terms
yeah, there's a lot to be done
this is pretty general
like skunkworks following errors.... :-(
it's about what's valid in the g-code
cradek: you still listening?
the grammar kramer gives seems a bit crazy
I recognize his grammar to the best of my understanding of it right now
but I'm not sure its the best
it supports logical OR, XOR, and AND
but there is not logical invert
also there are no relational ops
I thought all the variables are floating point
how can you do logical operations on them?
and it allows the use of expressions just about anywhere you would expect a number
you can do logical on floating point
true is non-zero
oh, they're logical, not bitwise
so what do we all think about the g-code that should be accepted?
are we going to include all the ngc grammar plus lermman stuff?
anything that may be in the field today must be accepted
I'm dead serious pete, I'm not qualified to discuss it
or should we keep it simple?
I ran 3D_chips no prob, but it's basic
I think some of the stuff in Kramer's grammar is not even implemented
what do you get out of the program?
then there is the M100 stuff
wo where does that leave it?
if there are errors, it reports them
it doesn't do anything else yet
otherwise nothing- got it
can I see the source?
sure, you guys all want a copy?
heh - deafening silence ;)
yeah, I guess that means no
ok, just sent you a tarball, including my slickEdit project file ;-)
ooooohh - slickedit
too bad I don't have that ;)
yeah, I like it in vi mode
ok - it didn't spit out any errors on a 1.6M NC file I have
if you want to build the source, you will need to apt-get antlr and libantlr-dev
you can also use it command line to test stuff
(though it is significantly slower on the 500 MHz celeron than on the 1.4GHz Opteron
1.6GHz, that is
It's compiled with debug for testing
maybe optimization will make a difference
how does the current EMC compare between the two machines?
unknown - I only have it in VMWare on the big machine
it's a top down LL(1) parser and top down LL(2) scanner
and it uses bit sets for lexing and parsing
should be pretty decent
pardon me while I go get all my textbooks ;)
and the code really follows the grammar since it's top down
I haven't used any of this stuff in ages
you can pretty much jump in at any rule
yeah, I had to brush up a bit too
did you get the source?
ok - so the version of rs274ngc with the source is a debug compile, and the other isn't?
if you install the antlr packages and run make, you will see the cpp code
no, the one I sent you was debug too
I added the ngc to indicate which flavor of 274 it was
hm - they're different sizes, by over 1M
that's what NIST called it
the first was 879K, the second is 2M
maybe the one didn't have symbols
neither were optimized
hm - why is the Makefile executable?
oh, it's a samba/windows thing
ah - OK
any time I write a file from doze, it's +x
I need to fix that
ok - I didn't realize that you had done it on a windows machine
my IDE (slickEdit) is doze based
I thought they had a Linux version
I'm compiling on the linux box
they might, but I don't have it
I should try eclipse
just too used to slickEdit
I talked to them at Embedded Systems in SF
was it good?
maybe, but their website java just crashed my other machine
can't ecen ping it
OK - it was them - they have versions for win, lin, irix, aix, solaris, mac, and HP-UX
dang, I changed the samba umask and sent HUP to daemons, but still setting +x
oh well, maybe it will work after a reboot
well - that was exciting
I clicked on a menu item onthe slickedit website, and the machine locked up hard
didn't even respond to pings
ooh, that's not good
that shouldn't happen from just the browser
maybe you need to do a clean install of 4.30 as well
starting to sound like my old install
nope - I think there's a problem with the Java installation on this machine - possibly a 32/64 bit interaction
this isn't a BDI at all
I hate java
it's a dual-processor opteron
too many non-compatible options for linux
the problem is with the website - too much crap
that too, but I agree that the crap shouldn't crash the OS
so, did you look at the grammar?
no - the machine crashed ;)
so I rebooted, and decided to take a shit :)
what is the goal for lines/sec on what speed machine?
I feel better
well - there are some pathological cases that I think would be good to use for setting goals
on my 1GHz C3 (which is about a 600MHz celeron), I get about 4700/sec with debug code
what's the typical rate for the TP in EMC now?
is there any point to sending down more than one canonical motion command per TP cycle?
that's not a me question - I can never keep straight what's at the servo rate vs. the task rate vs. the (etc etc) rate
jmk, you there?
no, but Les has had problems with high speed planning, and he's not even at "HSM" speeds
what is high speed?
one sec - I'll send you a link
[03:45:21] <SWPadnos_> http://www.datrondynamics.com/products.htm
watch the videos of the MiniRaptor
or the VelociRaptor
where are you looking?
there's a table about a screen down
where are the videos?
[03:47:27] <SWPadnos_> http://www.datrondynamics.com/VideoZone/Videos340kb/HighSpeedH.wmv
the velociRapto is 1,000"/min
yes - cutting speed
can it rapid faster?
I think so
but nonetheless, 1000 in/min is pretty fast for machining
I like the way the coolant is going on/off
what kind of cutter it that, looks tapered
it's a pretty damned slick $35k machine
the spindle speed is crazy
the whole machine is a bit crazy
is it mostly for Al and softer?
the thing about HSM is that at some high speed, the chips start taking the heat away for you - they become the coolant
I think that's true even at low speed
I don't think so
the cutters are designed to heat the material, not themselves
well - at low speed, they hang onto the work or the tool long enough to transfer heat away
at least that's what the cutter mfgs claim
yes - well, they would say that ;)
so is this what les was trying to acheive?
not that fast, but yes
how many TP cycles/sec to you think are needed for 1000ipm?
he has a big machine with a lot of mass and power, and wants to machine at 400-600 IPM, I think he said
that's about 17 "/sec
well - again being pathological, consider a CAM post that outputs line segments instead of arcs
sure, that's worst case
and you want .003 max deviation (or even better)
you're at around 300-350 * 17 lines/sec
how do you get that?
what's the min radius a machine could run at that speed?
well - 17 inches/sec / 0.003 arc segments (though that's not necessarily the max deviation)
the segments may be longer
1/0.003 is 333
seems like you need the min radius, then figure the coord for 0.003 error
I'm just getting an approximation
yeah, but it seems way off
heh - approximate ;)
your radius would be tiny for a move that small to have 0.003
approximate would be nice if it wasn't a few orders of mag off ;-)
but 4700l/sec is definitely fast enough anyway, since it's in the ballpark of the worst -case incorrect approximation ;)
yeah, but the machine has to run the TP and servo too
that was just for the interp
I can get it faster with optimized code
but it's a good start
well - that's what the extra orders of magnitude are for ;)
so, does it make any sense to send more than one canonical motion per TP cycle?
out of my league at the moment, I'm afraid
ok, I don't think it does, as how would it get processed?
but yes, I think so
can the TP process mulitple points per iteration?
I guess that's what we need to know
I don't think so now, but it should
put it on the list for jmk ;-)
there was discussion of sending splines to the planner as well, so there could be more information transferred per cycle
yeah, did you follow any of the eliptical motion stuff?
how would that be ot help? would it get implemented at the servo rate?
sounds ugly to me
I was following, and I think ellipses are an excellent idea
so how would they work?
that's the hard part
I can see it at a high level, but not in motion
to get axis-aligned ones is easy, but off-axis would be a pain
oh - ellipses are easy, even in integer math
I don't think it makes sense at the low level
you would have to put it in the servo thread for it to help
just calculate a circle, and scale the minor axis down by b/a
right now the servo gets all lines, doesn't it?
no - the planner gets circles
yeah, but PID, and everything else don't understand that
actually - the call is an ellipse in the emc source
right, the TP gets it
and makes a list of points for servo
PID only understands commanded position, and it doesn't matter how the command is calculated
so at the motion level, it's all small lines
yes - it will end up being that way, but only because of discrete time quantization
so the only gain is if there it a bottleneck to the TP
if you could get the servo or TP rate to 1 microsecond, you'd have a smoother circle
yes, but I think doing more than lines at servo is a bad idea
well - maybe
I don't think so
consider what happens if a line needs to end in the middle of a servo period
you want PID positions to be adjusted by the servo thread?
PID has nothing to do with it
they're at different levels
I think that's ugly, if you want stuff to end in the middle of a period, run it faster
motion gives PID the position command
(and I don't fully understand how they're put together, so I think I shouldn't try to explain it ;) )
if it doesn't adjust at servo rate, then it's just a line
we need jmk
no - if I command a move of 0.0035 inches, and the speed is 60 IPM, I shouldn't have to double the servo rate to get it
can you explain why you would want eliptical motion if there is no bottle neck to TP
(60IPM = 1 IPS = 0.001/ms)
if you command a move of 0.0035 inches, what you get depends on the moves that precede and follow it
it blends 3 points, no?
do moves have to start and end on a TP cycle?
(ie, at the edge of a cycle)
no, servo cycle I would think
no, they shouldn't
shouldn't on servo or TP?
let me throw out a thought experiment, ok?
first assume absolutely no time quantization
if the velocity is updated on servo, then they have to send on servo, correct?
let me finish - this is a thought experiment
think math - continuous time
with no time quantizaiton, you can calculate exactly when each segment should start and end, and you could also have closed form functions for position as a function of time
those functions would have discontinuous slopes (velocities) if you don't do blending, but we don't care yet
now, take that position(t), and call it a signal (just use one axis, say X)
still continuous time, pass that signal thru a lowpass filter
make the bandwidth of the filter be 500Hz
now you can sample the signal at 1KHz (nyquist) and do whatever you want with it in discrete time
the filter got rid of the high frequency stuff
well, are you saying the bandwidth of the machine is much lower than of the control?
this I see
because as soon as you go to sampling, you simply cannot pass high frequency stuff
yes, that too
but machine dependent
let's assume the machine is infinite bandwidth
I don't see that
if PID is converting position error to velocity
don't see what?
how can velocity go to 0 in between a servo period
the VelociRaptor has higher bandwidth than a Bridgeport with 20 oz-in steppers
if velocity only changes on servo period, how can it go to 0 at other times?
it can't, at the moment
so then motion has to end on a servo period, unless we consider machine bandwidth
motion has to end on a servo period because of machine bandwidth
well, real motion must start/emd on a servo period
no, assume the machine bandwidth is infinite, with infinite acceleration
but remember, real motion is a low-pass filtered version of the ideal path
emc machine == pc
no, I meant machine == iron
the ideal path can have bends at any time, not just servo time
right - the fact that emc can't make changes to motion inside a servo period is what makes it a low pass filter
quite an assumption, but OK
jmk: with infinite machine bandwidth?
so what have we agreed to?
I don't know
that it's the low pass of the iron, motors, etc.?
that is one lowpass
if that weren't the case, could motion end between a servo period?
yo uhave an ideal signal with infinite bandwidth, you pass it through the controller (emc) which has a finite bandwidth, and then on to the machine, which should have even lower bandwidth
the iron "filter" is the dominant pole in the system
if the iron hads more bandwidth than the controller, then you need a faster controller
if the pole caused by the servo rate is lower than the iron pole, then you should raise the servo rate until it isnt
woohoo - we agree (I think)
but for any but the most exotic machines, the iron bandwidth is in the 10s of Hz
so, that being the case, why do we want to deal with more than linear moves at the servo rate?
why not just up the TP rate so we can keep division of labor clean?
I must of missed something
we started with the request for eliptical commands
I never suggested that you would want more than linear moves at the servo rate
and I didn't see any value unless there was a bottle neck to the TP
I did, but it's probably my lack of understanding / mental block on al lthe different <X> rates in emc
swp: suggested eliptical moves at servo rate
at TP rate, I think I meant
well part of the value has absolutely nothing to do with rates
I see value in the GUI
but not at the lower levels
but not by calculating 100 short moves every TP cucle
its also lookahead
take skunkworks machine
he has a maxV of 300ipm, 5ips
if the TP gets fixed so that it can process multiple point per period, then arent arcs and lines enough?
and a max accel of 1 ips
that's the thing - the path shape is calculated at the servo rate, but the shape is decided at the TP rate (more or less)
so if he's scooting along at 5ips, he needs to start slowing down 5 seconds before a right angle turn
if he does a 40 inch straight line as a single move, no problem
but what if he does it as 1000 moves that are .040 long each
I don't follow
(all parallel to each other, followed by another line off at right angles to the rest)
wont the TP just blend them and get the same result?
how far ahead can the TP look?
ah, so there is the look ahead issue
today, it blends adjacent moves only
ok, that sucks
if it sees 500 parallel lines, it doesn't know that number 501 is a right angle turn and it needs to slow down when it gets to number 150 in order to make the turn
so what are some of the proposed solutions?
that's partly due to the fact that it can only accept one move per cycle though, isn't it?
obviously some form of deep lookahead
fwiw, that's already written but buggy
I take that back
I think paul started that at Fest or at Les' place, right?
the "accept one move per cycle" is a different issue
I'm not sure which one paul attacked
that's the buffer prob, right?
or how successfull he was
"the" buffer problem - an optimist ;)
right now I thought we couldn't send more than one motion command per TP cycle
I just gave you the "lookahead" pathological case
now heres the buffer one:
the only way it gets more points is from an arc, no?
straight parallel moves, no right angle turn at the end, no need for lookahead
but the programmer decided to programm 0.0005" segments
well, that's just plain stupid
at 5ips, you gotta feed 10,000 of them to the interp
I said patholocgal
that's CAM - great, but sometimes stupid
now assume he's milling a smooth curve
they're not quite collinear
but still close enough that there is no need to slow down at the junctions
so he programs a lot of em, cause he wants to track that curve really well
well should depend on the radius of the curve
petev: you'd be surprised at the crap paths that come out of cam software
not mine ;-)
just look at a DXF where they used lines instead of curves (or text)
heh, mine's pretty bad
another way of looking at this goes back to my "signals and bandwidth" approach
DXF is not CAM
another thought experiment:
no, but the idea of linear approximations of curves is similar
suppose you have a 1" diameter circle
assume a milling speed of 6.28" per second
so you mill the circle in 1 second
and assume you want to just keep going around and around, no entry or exit
so X and Y position are 1Hz sinewaves
not a lot of bandwidth needed there, is there?
now approximate the circle as a square
now X and Y positions are flat, then linear down, then flat, then linear up
infinite bandwidth needed
now what is the bandwidth?
infinite bandwidth needed
adding more segments reduces the magnitude of the high frequency componets (because there is a smaller change in velocity at each point) but increases the frequency (more per circle)
I'm still stuck back on the 1" diameter circle with 6.28" circumference
petev: not where I come from!
oops, my bad
sorry, it's irrelevant but I thought it was funny that you all let it past
I did that on purpose, to see if you were awake!
it was just an experiment
if tested, we would have revised the theory
I forgot where I was going with that (if I ever knew)
I think you did it to see if you were awake ;)
it keeps coming down to bandwidth
suppose you actually wanted to make an octagon, not a circle
as you decrease the number of samples, you increase the amount of information you need to convey per sample
ok, so relate this to the eliptical motion, I'm not seeing it
what is the ideal number of segments to break an elipse or other smooth curve into?
hmm, trade of error for bw
any time you have a non-linear motion, you would need (servo_rate) lines of G-code per second to get the same precision that just sending an ellipse to the servo controller would do
or the appropriate curve
ideally, you have a mathematical representation of the path, and you sample it at the servo rate
swp: but you are mixing division of work
essentially, the "ideal number of segments" is one per servo period
no - the servo controller already does the sampling
the PID is also done at the same rate, though it could be different
so, why not just have the TP give a queue of points to the servo thread?
we're trying to make a signal called Xposition
it can calcualte them in batches
because you'd have to send 1000 commands per second, every second, if you aren't doing straight lines
we need to bandwidth limit that signal, so the PID (and the machine) can follow it
yes, queues of pose for servo
pete: what you are talking about is the essence of trajectory planning
taking a continuous path and sampling it
but why not change the position command to PID on each cycle it needed?
follow an arbutray shape
PID and position command are two different things
but you are talking about sending that "continuous" path to the trajectory planner as a series of segments
IE, already sampled
PID takes position command
could handle the sample part by sayinng what servo cycle to update on for lines
that would save queue mem
right - and also takes feedback, and mixes it all up to get a velocity command (or torque, etc)
but the sampling in the g-code file is almost certainly wrong for the servo rate
hold on a sec - consider this:
swp: forget about PID, and velocity, and torque, and all that
no, TP busts it up and makes a queue for servo
that is trivial signal processing, it can be characterized with a bode plot or whatever
that was my point - it has nothing to do with position commands from the planner or the servo loop
swp: assume the PID is perfect
(except that it's calculated at the same rate, in the servo loop)
the position commands out of the planner are the signal we care about
roght - so - think about this:
we need a new position each servo cycle for optimum performance
we need a new position each servo cycle, period
given an elliptical path (or circular or whatever), emc will need to calculate N line segments
N is the servo rate * the total time for the move
yes, but now it's the same position until the TP runs again
you mean because the TP runs slower than the servo rate?
why is it better to calculate a million of them at once, and transfer a million commands, rather than calculating them on the fly from a single command?
I'm saying let the TP calc poses for the servo rate in batches
first, I consider that a distraction... nowhere is it written in stone that the TP needs to run slower than servo
that was a NIST decision, driven in part by CPU horsepower limits
but CPU limits are real
we need a real solution
I'll ask again - given that there will *always* be a new position command every servo period (even if it's the same as the last one),
second, there is an interpolater that does cubic splines between the TP output points, generating intermediate positions at the servo rate
why is it better to calculate a million of them at once, and transfer a million commands, rather than calculating them on the fly from a single command?
swp: first, why limit the shape with formulas in the servo thread
second, the servo thread needs to be tight to limit jitter
to avoid "resampling"
I'd ask that the other way around - why limit the formulas that the servo thread can handle?
breaking a shape up into short segments is a form of sampling
sure - it all depends on having an efficient calculator, but you need that anyway
aren't we always sampled at the servo rate?
but that sampling rate is almost never gonna match the sampling rate that you need at the servo stage
somebody calcs the position
I don't follow, TP knows the servo rate, why can't it calculate pionts for each servo period based on whatever blending and Q them
pete: if you tell me to do a circle by drawing 500 straight lines, you have sampled that circle
yes - you need blending as well, and that shouldn't be in the servo calc
pete: the cubic interpolator does what you are talking about
the TP generates points at the TP rate
if your CAM program outputs a series of line segments that take 1.3 servo periods each, there's a problem
jmk: I don't see how motion is changed between servo periods, so it's always sampled
jmk: I know, I was considering a change to get better performance
I think we're having at least three conversations at the same time
heh - one each ;)
ok, you lead
that won't help
not if I'm not talking about the same subject you are
(and I think I'm not)
the original (ish) question was about having ellipse commands in the interp, and how the ellipses get doen to the motors
ok, I'm still on the value of eliptical commands
command as in G-code, or command as in TP->servo?
ok, lets try this tack...
the guy wants an elipse
one approach is to tell his cam program he wants an elipse
(if he has one)
and let the program generate a bunch of straight lines
ok, we all agree that sucks, correct?
that's one way, yes
at that point, he has sampled that elipse
yes, at the wrong rate
thats why an elipse command is good - you can send it to the trajectory planner and let the TP sample it at the right rate
so when you run that program, you'll get a machine that jerks all over the place, and gives you an approximation of the approximation of an ellipse
yes, but we were debating how far down it had to go
heh, exactly swo
the command that is
ok - so command = TP->servo
not G6 or whatever
swp: thinks elipse goes to servo
I think to TP with poses for servo
I'm asking what you mean by "an ellipse command"
we might be using the term servo loosly
swp: a new g-code or whatever
ok - I think the value of that is obvious, from the sampling point of view that jmk brought up
to me, "servo" is the block(s) that are responsible for making the machine follow a sampled position command (a signal)
it's also a hell of a lot easier for one-offs at the machine
servo never sees "commands", it only sees signals
jmk: i think of servo as the PID rate
yes - that's the hardware view of servo ;)
it sees a position to go to
servo period and servo are two differnet things
not formulas to calc the position
ok by me, so servo should be totally out of this discussion
ok, so servo period
servo period is the sample rate of the position stream
right - except that the shape sampler also runs at the servo rate
do you mean TP?
to me, "TP" is the blocks that turn a mathematical path into a sampled stream of positions
it runs slower now
that is for historical reasons only
no - I mean the thing that quantizes the expected path into straight lines for the servo loop to follow
or consecutive positions, if you prefer
swp: that's the TP AFAIK
and I prefer to think of the EMC "TP" and consisting of both the slow planner (TP rate) and the interpolator (servo rate)
the input to that overall TP is commands, and the output is sampled position
ok I thought the TP in emc was the part that blends successive paths
the EMC one happens to accomplish that in two stages, first the main TP samples at a low rate, then the interplator resamples faster
no, that's the interpolator
opposite, I think - interpolator goes faster (jmk?)
I agree with JMK
TP is slower
what the EMC folks call blending is done by the slow TP
ok - interpolator is at servo rate, planner / blender goes slower (so far)
although the effect of the interpolator is to blend some more
ok, now I'm confused
since it uses cubic splines
also dependent on the machine mode
exact stop etc
actually no, the interpolator isn't
thats the main TP
yes - sorry - we were typing at the same time, I think
I'll shut up - jmk knows what he';s talking about (more than me, at any rate ;) )
anyway, the output of the main TP is not a series of straight lines...
it is a series of points, but they get connected not by lines, but by splines
the interpolator does the splines part
ok, so where is the blending in the TP then?
on a longer time scale
lets do a simple examppe
G1 is rapid, right?
ok, so G1 uses feed
blending has to do with G-codes or canonical commands, interpolating is sampling the blended path
I'm awake ;-)
heres our program
start at 0,0,0
G1 F60 X1
G1 F30 X2
y and z never move
X must accel to 60ipm, then when it gets close to 1.0, it decels to 30ipm, then continues to 2.0 and decels to a stop
without blending, it does this:
accel to 60, cruise at 60, decel to 0 at 1.0, accel to 30, cruise at 30, decel to 0 at 2.0
with blending it does this:
accel to 60, cruise at 60, decel to 30, cruise at 30, decel to 0 at 2.0
the decel from 60 to 30 is split, so half happens before reaching 1.0, and the other half after
and interpolation does nothing here
speed at 1.0 is 45
if the accel limits are low, the actual ramping may take many servo (in fact many TP) cycles
ok, so the TP is blending velocity, and the interpolator is blending position?
the tp is blending commands (lines and arcs)
and the interpolator is blending between subsequent TP positions
lines and arcs at a given path speed
but it's blending the velocity of the commands, or the position too?
they aren't independent
velocity = dP/dt
you could draw the ideal path on paper as velocities, then integrate to get position
ok, one sec
to clarify, what is the output of the TP?
is it a position and velocity?
poses (postions) at the TP rate
does a pose include velocity or not?
velocity is implied, by the differnece between successive samples
so how does the TP blend the velocity in your example?
the interpolator did it then?
the commands into the TP did include velocity
damn, I need paper again
ahh, so velocity at the TP sample rate
I got it
heh - we need to get you a smartboard
that would be cool
isn't there some website where you can sketch?
didn't MS net meeting have that?
there are probably collaboration programs that would let you
yes it did
ok, so many TP cycles per g-code, blends both position and velocity
velocity implied by position at TP rate
velocity coming out of the TP is implied by the distance between successive samples
velocity going in is embedded in the commands
"line from here, to there, this fast"
going in, there is no knowledge about how long it will take
the part I wasn't clear on was that the pose out of the TP were assumes to be at each TP period
I got it now
(and in fact, that can change on the fly, thanks to feedrate override)
right - I knew ther ewas a problem with precalculation - I just couldn't remember it
hmm, so what if the TP gets too far ahead?
and the op changes feed override
right - it gets messy
the TP needs to redo all those queued poses
there are actually ways to precalc it
is that what it does now?
it's the same problem as the CAM program sampling an ellipse for you at the G-code level
no, because now it doesn't do lookahead
heres a concept (no idea if the math is tractable)
given a mathematical representation of a path (either a smooth curve, or a series of straight lines)
you can work backwards from the end to compute the maximum velocity at any point
if the TP does not look ahead, how does the interpolator get multiple points to blend?
is there a lag?
so that interpolator Q can have the wrong feed rate for a bit then
the lag is only one TP period
so if you hit feedrate overrride, the actual feed might take 10mS to change
you ain't gonna notice
or start to change if the interpolator is blending many points, no?
the interpolator blends between 2 points, using in addition to those 2, the one that precedes them, and the one that follows
it'll start after one TP period, but take as many as necessary, determined by the machine accel parameters
so at any time there are four points of TP output in storage
call them 0, 1, 2, 3
3 is the newest
the interpolator is moving between 1 and 2
when it hits 2, it asks the TP for 4
then it discards 0, and begins moving between 2 and 3
so it can take several TP cycles for the new velocity to be commanded
but not too many
that lag is probably less than the lag in userspace when you hit the feedrate control
right - those will typically be servo periods, right?
the interp is generating a point (between 2 and 3 for instance) every servo period
according to the cubic
ok, but 0-2 , 1-2 etc are every TP cycle?
it evaluates a spline formule
ok, so where does the eliptical move fit in then? still seems like TP to me
the t in spline(t) goes from 0.0 at 1, to 1.0 at 2, then new spline coeffs are computed for the 2 to 3 spline, and t resets to 0.0 again
yes, has nothing to do with the interp
interpolator, not interpreter ;-)
ok - and 0,1,2 are issued at the TP rate, or as necessary (ie, there's a parameter that tells the increment for T every servo period)?
so that would happen at the same place as arcs now
the interpolator increments it's t by the ratio between servo period and TP period
ok - so the poses are issued at exactly one per TP period
for instance, if servo is 1mS, and TP is 10mS, then the interpolator incrementes its t by 0.1
jmk: you lost me
what do you know about splines?
are you saying the cubic is normalized?
servo is the rate the interp(olator) runs
it is normalized in time
so the interpolator uses up one per TP cycle
one pose, that is
the spline is a set of coefficients
sure, I understand if it's normalized
you put 0.0 into it, you get point1
put 1.0 into it, get point 2
for 6 axes
put 0.3 into it, get a point that is 0.3 of the way, along a smooth path between 1 and 2
along a smooth cubic path
so it can already describe an arbitrary quadratic (circle or ellipse), given the right coefficients
when the interpolator gets to 1.0, it generates a new set of cofficients using the next TP pose
a segment on one anyway
you can't describe a complete circle with a spline
no, but a TP portion of one should be easy ;)
one approach to trajectory planning is to describe everything in terms of splines
it seems that a high enough order spline should do fine for TP period moves and give flexibity to arbitrary move commands
then the RT code is easy
should have put a s in front
the problem is that no spline, no matter how high order, can describe a sharp corner
right, but the machine can't follow that anyhow
so you have to decide how much the spline can deviate from the ideal path
which is speed dependent, so you are right back at not being able to precompute the splines
If you think about it, you see that there is exactly one pose per servo period
if you could precompute splines in user space, that would be wonderfull
but still seems like TP look ahead has value, it just can't generate ahead
and it doesn't matter where that pose is calculated, it still needs to be calculated
swp: but servo rate stuff needs to be tight to reduce sample error
swp: exactly, thats why I consider the "TP" to be the composite of the main TP and the interpolator
so, unless you plan to precalculate the entire program (not practical), you need to have a computer that is capable of calculating at the servo rate
none of the HW can support captures position until we get HAL IRQ threads
swp: you do simple math (spline interpolation) at the servo rate
you do more complex math (main TP and especially kinematics calcs) at the TP rate
yeah, don't forget about kins ;-)
jmk: how much do you think sample jitter is effecting EMC performance now?
that is done on the main TP output, to reduce the CPU load
but there's still exactly one pose per servo period
not enough to matter
so, what improvements can be made then?
yeah - you get 20 us jitter (worst case) on a 1ms period
remember, most noise introduced by jitter is at the servo rate, and it gets filtered out by the frequency response of the PID and iron
swp, servo period is less than 1ms
improve how you tell the lower levels what to do, by reducing the amount of communication overhead (to allow moretime for calculations)
setvo period is typically 1ms
petev: default EMC servo rate is 1mS
I thought that was TP rate, seems slow for servo
can be faster, but I haven't heard of anyone going faster than 5KHz
TP is 10ms
so what's the point of 5K lines/sec of g-code
well - nobody's doing HSM with emc yet - it can't keep up
how about when you restart and need to fast-forward to line 1000000
it would need to be faster for that
that too ;)
jmk: good point, but I like the checkpointing better
how about when you load the file in AXIs, and it runs it in sim mode for the preview plot?
fyi: I'm getting 4700 lines/sec on the 1GHz C3 (which is about 600 MHz celeron) with un-optimized code
what does the standard interp do?
what does axis do when you load it?
it "runs" the entire file to generate the preview toolpath
jmk: not sure
would have to build something to test it
axis runs it through what?
there are million line G-code programs, at 4700 lines/sec, that is 200 seconds to load and display the plot
thru the interp, I think.... it doesn't send the commands to the machine, just notes the position and discards the command
so axis asks the interp to read it, but no exec, then reads back current position?
it runs the planner, but with output disabled (the mode is there for restarting without moving, I think)
if that's the case, the current interp is 4 x slower than what I have now, but all the code isn't in yet
right - they pipe the canonical commands back into their program, and make the plot that way
petev: how do you know its 4 times slower?
that includes communication overhead
I load the same program in axis and it takes at least 4x as long
yes, NML overhead too
overhead for comm/NML, and generating the 3D GL objects
and putting them into the display list
true, and right now, I'm reading from the file direct
later, I will read into a buffer for each line
should be much faster
well - it runs a 66000 line file in 4.348 seconds on this machine
no - your interp
the 879k one
your machine is faster than mine I think
I hope so ;)
I just spent $4000 on it
that beats my $400
(2x opteron, 4G ram, 300G hd, dvd+-rw-DL, Nvidia 7800GT, dual 24" LCDs)
jmk: so what do you see as the major areas to improve?
hm - a little faster for the 2M one (but within the error margin, I bet)
in the area that we've been discussing?
yes, from interp to dac out
I'd like to build a collection of all the pathological cases
short parallel lines
curves made of short lines
then try to architect a TP that doesn't barf all over them
3-D lofted surfaces ...
jmk: what ideas do you have? lookahead?
the idea of computing splines in user space and using those as the RT primitive instead of lines and arcs is attractive
BTW, why can't cubic coeff be calced in the TP each period?
but I haven't studied it deeply enough to know whether it can work
today, the TP takes lines and arcs and generates a series of points
ok, so maybe NURBs to the TP?
then generates the cubic coeffs to interpolate between the points
there was dscussion of NURBS
I'm talking about giving the TP its commands in the form of splines in the first place
also quintics, and others
what about the usr/RT queue for the TP?
I guess if we can pass a whole spline, one per period is ok
that goes pack to lookahead
yes, forgot that
that's also stuff that can be precalculated
even if you are passing splines, you still need lookahead of some sort...
precalc in user space is nicer than trying to do it in RT
so we should fix that too so lookahead can be avialbe immediately then?
emc is a bit unique here because it actually uses feedback
not relevant to the TO
I assume a spline will take several TP though, so lookadhead should be available soon
its too late for me to think straight
the other controller programs (DeskCNC, Mach, etc) don't, so they can do 500-point lookahead, and show nice smooth paths
jmk, swp has a good point, what about adaptive control in the TP?
if one axis is getting behind, why not have the TP slow down?
I don't see the connection
but they can't correct for anything on the fly
like feed override, etc
use the position error feedback at the TP level
they can do feed override
that's too late
why not have the TP do auto feed override based on error?
I don't even want to think about how nasty that would be to tune
sorry - feedback was a red herring - I'm not thining straight either
especially if you have non-trivial kins
just put a pid loop on it
the thing is, the mentality with the other programs is "set it and forget it"
emc is "set it, then check it"
it would be slick
other programs assume that the motor control section will do what its told
I think our TP should do the same
what about torque/force control on the spindle?
your thinking in the box, let's go outside the box
let's build something better
but you can't precalculate, and retain the ability to do things like feed override (or pause/resume) - you have to recalculate (resample) the segments involved
I can see a slower outer loop that modulates feedrate override (in RT) based on following error (vector sum of all axis probalby) or based on spindle load or something
yep - that's the unstallable stepper thing Mariss has been working on
it's got to be a little faster though
SWP: I would never precalc to the point of sampling
not familiar with what mariss is doing
ok - good :)
ok, one other thing
what about feed based on spindle RPM? we need this for rigid tapping and lathe
what are your thoughts?
Mariss is making a mode in the G-Rex that will sense when a stepper isn't able to keep up, and slow down all axes proportionally until it can maintain speed
petev: that topic is good for at least an hour or too
I gotta crash
I'd love to make something (a feed wizard) that takes material properties (select Aluminum, 6061-T5), and sets feeds / speeds for that material / tool combination
honestly though, that topic is probably the most important we could discuss
and me too I think
swp: my CAM already does that and there are plenty of feed/speed calcs on the net
threading has been on our to-do list for at least 3 years, probably longer
damn - how'd it get to be 2:00 again?
you guys need to move west ;-)
petev: your CAM is more than either $0 or $75, I'd wager
next time we're chatting, lets put our minds on the issue of threading and see what we can come up with
yes, but the calcs from the net are free
threading - hmmm - my sheets have threads
ok, we have a lot to think about
I understand the motion in EMC better now
yes, and they should be available from within emc - "this is my tool, this is my material, this is the path I want - cut"
yeah - me, too.
I've had a hard time "getting it" for a long time
that should relaly be done in CAM, but could be nice for conversational
I'll probably forget 90% by tomorrow
let's put it on cradeks feature list ;-)
conversational is where Ken Lerman wants to go - wizards for lots of things
yeah, but I think he's taking the wrong approach
why save g-code space
who cares, HD are cheap
just put a conversational fron end
well - people can use the codes as well
yeah, but it make interp stuff ugly
look at the recovery issue with loop
plus the interp will be slower
and there's no standard to boot
sure - but is it easier for somebody to look at a 600 line file to make a dozen holes, or a 50-line subroutine, and a couple dozen commented calls to that sub?
I'm just not convinced
we can support subs as programs
I don't think that's too bad
I think we need to look at as many G-code references as possible, and make a "master reference" for the language and its major variants
but I'm not sold on the loops and conditionals
from that, we can choose what to implement or to not implement
yeah, it's hard to get good data
the most I could find are discussions on forums
no manuals to download
Gene Heskett mentioned that there's a reference in Machinery's Handbook - I'll look through that
eBay, but some of those manuals are expensive
(starts on page 1217, I think)
of the 27th edition
or was it 1279?
I don't have machinery handbook
oh - you should get it - has all the info your CAM hides from you ;)
I have some other books by moltrecht
I look for a copy cheap
I've got to get to bed. we can talk more tomorrow
SWPadnos_ is now known as SWP_Away
IMO this next line in core_servo is just wrong. setp pid.0.maxoutput [AXIS_0]MAX_VELOCITY
Using the variable names from emc it should refer to [AXIS_0]MAX_OUTPUT
hi alex phone
Feeling any better?
a bit worse I think :/
Oh. That's not good.
but I'm sweating a lot, so I think it's getting out
Is this a stuffy head or just a brain ache?
that was pretty american. let me try again
stuffy head, muscle ache, a bit fever ;) the whole package
running nose, caughing..
I could go on ..
I get the feeling
I'll not bug you much today.
oh.. but you can
that's nice for a change :)
IMO even if we get only a half dozen sample configurations, I'd like to see them packaged in their own subdirectories.
but the stuff I had to do to support one single emc.nml was nasty, I don't really like it
fixing default HAL files in configs/ and further .hal files in configs/foo/ is easy
but configs/foo/ needs to hold a .var & .tbl files aswell
In the past, the ini file has been key to finding all of the other files.
Could the ini file use something like ../emc.nml
yes that is one possibility
and it makes a lot of difference in the code needed to support that ;)
rayh: are you still around?
SWP_Away is now known as SWPadnos_
Working on another pc this morning.
SWPadnos_: how you doing
I noticed your comment about [AXIS_0]MAX_OUTPUT
you're probably right, but the values would be different than for emc1, so the users would still need to look at it
default for emc1 was +10
right - it's a "virtual 10V servo driver max output"
in emc2, it's user units / second
that's a direct velocity command to the hardware drvier
max velocity which it is set to now used to default to 1.2
I agree - it's a good idea to have this setting be separate from max_vel
we've been trying to figure out how to make it do that in a clean way
(expressions, fudgefactor parameters, etc)
this is clean, but it isn't directly compatible with the emc1 way of doing things
multitasking cause the phone is slow
I don't see the difference between max output on emc1
and this thing that we are trying to set on emc2
I'm between runnables right now but let me try to find it.
04 float -W 1.20000e+00 pid.0.maxoutput
This is not max velocity is it?
it should be how much output do we need to achieve max vel
It's the range of the output variable?
ok - I'm back (until the phone rings again)
yes - pid.0.maxoutput is the maximum commanded speed that will be output to the hardware, in user units / second
I thought that was what we had to change to 10 in order to make stuff run
nope - it just needs to be a little higher than the axis max_velocity
equal almost works, but a little headroom helps the PID
10 was necessary in emc1 because it was assumed that this was the voltage to output to a servo drive
So how do we tell HAL that we want +- 10 volts
or +- 7
or 0-10 volts
ah - that's where the scale parameter (in the driver) comes into play
note that HAL uses user units for everything, for as long as possible - this is different from emc1, which uses "volts" everywhere for servo output levels
Okay. And this we have to configure in each specific xxx.hal
it's machine specific
But what is the user unit for range of output signals
We don't have volts.
user units per second
No that is not at all right
it's a velocity command to the servo or stepper, so it's a velocity unit
we are way wrong here.
in what way?
You are telling me that hal can command usc in velocity
yes - that's what it does
Tries to fucking do.
no - does (when properly configured ;) )
That isn't JonEs work at all
nope - that's JohnK and SWP's work
Jon is expecting a signal that runs from -10 to +10
in emc1, that was true. in emc2, it's not
It is a firmware thing not a version of emc thing
that's why I mentioned that the parameters from emc1 ini files wouldn't be directly compatible
no - it's a driver thing
I don't think so.
the hardware / firmware just gets a rate or pulse width setting from the (software) driver
all scaling is done at the ppmc.x parameter level
I can tell you exactly what units and scale factors are used, starting at the motion controller, and going to the outputs on the USC
then I guess I'll go for a walk and when I get back call my customer and tell them not to use ppmc
Cause it ain't gonna tune the way they need.
Sorry not meaning to take this out on you.
the only thing missing is asymmetric limits - going faster in one direction than the other
no trouble - I'm trying to understand why there's a problem
(which I don't yet :( )
can you explain it to me?
after I recover from this shock maybe.
well - there may not need to be any shock - I think that ppmc is perfectly tunable - just not in the same units as for emc1
(I could say silly psychiatrist things like "explain it to me - let me help you", but that would be silly ;) )
seen a very long talk about TP last night...
heh - yep
nice.. any conclusions?
yeah - nobody understands the TP ;)
petev was wondering why you sould ever want anything other than line segments for the TP, since you can approximate any shape with them
yeah.. but that makes blending a problem
not a problem, but you need to be able to do that properly
and segments might be very short
it started with a discussion about whether or not ellipse commands should be there (prompted from the user list discussion)
yeah.. seen that
yeah - and feed override means you have to recalculate all of them
right.. feed override is a pita ;)
itwas on of those "the CAM program should do that for you, so why sorry about it" things
only some people's CAM program is notepad
yeah.. or mc ;)
sure - or maybe gedit, or kate ;)
rayh_m5i20 is now known as rayh_ppmc_usc
heh - change of hardware ;)
05 float -W 0.00000e+00 ppmc.0.stepgen.00.max-vel
0 means no user-defined limit
is the only thing that looks to be settable on the ppmc card.
cause scale is pulses per unit
ok - hold on a sec, I'm getting to the code
yes - that's the only limiting thing that gets set at the USC driver level
that should probably be split into two settings - one for forward, one for reverse
And what are the units associated with it
ipm or mmpm
user units per second (velocity)
internally, the input velocity is multiplied by the scale to get the nimber of steps /second to output
right. I'm okay with that.
the tuning gets done at the PID block though - this is just a "hard" limit on the maximum pulse rate the driver will allow
I see that.
and it ought to be set to Max_Vel * Scale
what ought to be set to that? the max-vel parameter?
max-vel should be Max_vel
not multiplied with Scale
So we have no way of handling max ppr
internally, the max-vel parameter is multiplied by scale to get the max pps
rayh: what do you plan to do with pps?
hold off a sec alex - this is a continuation of a prior discussion
Right and that is the logical thing to use when you look at stepper motor characteristics
ok - yes, you need to calculate the max velocity from the max step rate
I don't look at velocity when I consider stepper motor and drive characteristics.
how about something in between?
but you need to do that anyway, because at some point, you're going to set the [AXIS_0]MAX_VELOCITY number
having either MAX_VEL or MAX_STEPS in the ini, and the run-script? or hal? takes care of converting one to the other
Well I guess I'll just have to rethink how I tell folk to design a stepper system.
are you thinking of stepper systems that aren't for machininn?
I'm thinking of motion
I can do that. It just starts at the other end of the design problem.
yeah - with this method, you have to know your final drive ratio and all to get the limit value
but the max step rate (or velocity) will also depend on that anyway
No you have to know all of that before you can begin to look at the stepper motor velocity/torque plots.
what's the design / setup process you want to use?
(or - used to use ;) )
maybe O meed a ;pmger wa;l.
um - in english? :)
I tend to tell folk you can expect to get about 12 k pps
from a parport
Now go design your axis so that it moves as fast as you want.
ok - with the USC, the motor and drive system will be the limiting factor
how far can the USC go? as in pulse rate?
depends on the version, but mine can do 2.5 MHz
jmk's is limited to 2 MHz
you can't get encoders that fast, and I'd be really surprised to see any stepper that can keep up, even with pretty fine microstepping
It is not a matter of how fast the usc works
nope - was just answering alex's question
* alex_joni goes back to lurking mode
it sort of is, because the step rate is no longer the limiting factor in designing a stepper system
The problem is that we have a motor that has so much torque at so many pps
and we design from that.
Not from the final velocity of the system.
right - you get teh final velocity by choosing drive ratios etc, based on the performance of the stepper you've chosen
We just have to write the paper that explains this stuff different than we did.
at its simplest, this method only requires one extra divisoin (max-vel = max_pps / scale)
that calculation would have to be done anyway, so you can set the axis max_velocity in emc.ini
Now at the pid box
there are no percentages?
we just shove commanded vel in
yes, in user units / sec
and get xxx out.
and xxx can not be thought of as +-10 volt
yes, also in velocity (I'm not sure how this magically turns into a torque number, for those kinds of systems)
right - velocity (or magically torque)
hold on a sec - the input to the PID is a position
in user units
the output is a velocity, to correct the current position to match the commanded position
(again - I'm not sure how this works with torque mode, so I'll just leave that out)
hmmm.. this is new :/
No difference in that case.
I guess my Centrino just overheated and shut down :(
might be the fever and the fact that it's sitting in my lap ;)
I've done that.
alex_joni_ is now known as alex_joni
I was just going to comment on how lucky you are that your balls didn't get fried
SWPadnos_: it was the other way around :D
I don't want to know ;)
alex has a fever today
he thinks his balls are frying his processor.
yeah - I don't want to know ;)
SWPadnos_: 'image go away'
try that as a mantra
Well at least I can understand why I am having issues with tuning.
heh - that's a good start
oopsy... just came in a mail from ebo
on the devel list
* alex_joni reads now
so, do you have concerns about the PID tuning?
wow that lag was huge
so input to pid is position and output is vel in user units.
* rayh hits his head on the table a few times to pound it in.
rayh: write it on the table first, that does all the difference
Good plan. I've got a permanent marker (sharpie) right here.
sure - did I help?
gotta run for a bit
ok - see ya around
understanding yes approval for the approach no.
heh - OK
rayh_ppmc_usc is now known as rayh_away
hm - I don't see any ebo mails...
just one.. on the devel list
strange - when did it arrive?
20 mins ago
odd - maybe the .ro mail service is vaster than .us
my .ro is in texas :P
just traceroute it ;)
well - I'm looking at the archives on sf (logged in), and it's not there. and I haven't gotten any mail on the devlist sonce Ray's comment in the config thread
SF has been odd with emails lately
rayh_away is now known as rayh_ppmc_usc
yesterday ray's mail took 2 hours before it got to me
the one that went through SF
that was fast ;)
rayh_ppmc_usc: talking about bad mailings at SF
They had some real troubles yesterday.
yup, and SWP still reports some
something to do with their server farm
said they'd get the whole new system on line in a few days.
well - we'll see what happens. I think the default retry period is 4 hours
One of the reasons that "we" want computation in halcmd
oh - I think you can drop the quotes there ;)
everyone I've talked to has agreed that they would be good ;)
yeah.. you're safe ...
is so that we can do stuff like (max-vel * 1.1)
exactly -check the logs from last night to see just how much in agreement jmk and I are
Now we know that we always want that so why not in the code itself
in the PID?
Wherever that ceiling is placed on pulserate or pulse read rate
I guess that is max vel again
ok - there are several limits, at different places in the command chain
one is the motion controller - it has a maximum position that it can ask for
next is the PID
then the driver
the driver limit needs to be from the actual machine constraints
(minus some safety factor)
the motion controller should also be clamped to this max safe limit
Well max pos is irrelevant for this kind of thing
sure - motion also uses the max_vel in the TP
so, we have essentially the same number being used in 3 places
SWPadnos_: but sometimes the axis might fall back a bit
motion, PID, and driver limits
all we need is a bit of overhead so that we can return any buildup in following error
then to keep up it will need to go faster
yes, and that has to be in the PID limit, and the driver limit
but not the motion controller limit
and then it might hit the limit.. so maybe the TP limit needs to be a bit lower than PID limit
(so motion limit < driver / pid limit)
actual_motion > driver > pid > tp (in terms of speed)
and since this is IMO always the case, why not allow for it in the pid code.
for testing purposes, you have the flexibility of using just the driver (no PID), and setting the output rate manually
well - the headroom needed is machine-dependent
for testing I can make that allowance
so add a headroom variable
on a closely engineered system, you wouldn't want to go beyond maybe 3-5% headroom
on a deafult install for a hobbyist, you may need 10%
yes - the headroom variable is the pid.0.max-output (though we can't use formulas yet)
Lag is usually caused by accel so I'd think that it would be the other way round.
No pid.0.max-output is exactly that
the headroom is a fudge factor that you want to put in by computation at the hal
well - right now, we can't see the motion limit in HAL
that's directly loaded from the ini
yeah but it could be ([AXIS_0]MAX_VEL * 0.9)
if calculations were supported ;)
yes - if we had formulas
it seems to me that it would be more consistent to make a param named pid.0.headroom
we eventually will have
it may be possible for HAL to compute the proper headroom, but it still needs to know the limit in motion
Then we don't have to edit formulas in hal
it still needs the limit that motion has
so you'd need two pins still
It already has pid.0.max-output
yeah... but that would be a particular fix, not a general one for different situations
yes it does
you'd have to add another pin though
IT is simply one additional pin for the pid loop
I'm not sure that it's better to have two pins (max-output and headroom)
when one pin can suffice, assuming that it can be set with a formula
it would be ideal to have access to the internal parameters of motion
So you gotta tell the integrator, okay open up this hal file and find line 2689 and change the ([AXIS_0]MAX_VEL 0.9) to a ([AXIS_0]MAX_VEL 1.1)
you realize that i'm being the devils advocate here.
no - just the devil ;)
it might be aswell ([AXIS_0]MAXVEL * [AXIS_0]HEADROOM)
it NEEDS to be in the ini afterall
because probably you don't want a constant in the -hal file going to the pid.0.headroom pin
there needs to be a setting, so the integrator has to open *some* file and go to line 2689 and change something
I'll repeat my mantra: "sane defaults, but user configurable"
SWPadnos_: probably an integrator might beconfortable with editing the INI
or use a Configurator to do that ;)
sure - I have no problem with that
it might be aswell ([AXIS_0]MAXVEL * [AXIS_0]HEADROOM)
could as easily be
actually - [AXIS_0]MAX_VELOCITY * (1+ [AXIS_0]HEADROOM)
so if you leave it out, you still egt a max vel ;)
internally to HAL, it doesn't really matter what the setting is
as long as it can be set
or something like 1.5
for default so that no one will ever run out of headroom.
sure - but is that percent, or a multiplication factor?
I would do something similar for the default following error settings also.
but then that's the devil talking
you realize that making PID slower, it will make the overall machine run slower
well - how do you mean? setting them as a fraction of max_vel?
I'd make all of these things percent.
we haven't talked about PIDFF parameters at all. how would it be slower?
not PIDFF, the limiting of PID
this is a final output limit we're talking about - not a slew rate limit
it shouldn't be able to command anything faster than the machine can do anyway
yeah.. but G0 should go at that rate
It it doesn't, then you can not feed following error back in during a rapid.
that's why it's set to [AXIS_0]MAX_VELOCITY
and why we were discussing how to get some extra headroom in there
I got the email, btw
2 of em in fact.
spaced about 10 minutes apart but carrying the same time stamp.
probably had to go through NRO
or whomever it is that keeps track of my email these days.
incidentally, there's nothing that stops an integrator from making up their own ini settings, like MAXPIDOUT
then making the hal file use [AXIS_0]MAXPIDOUT
yeah if they know that ;)
I only used max_vel because it was there in the default emc.ini
we can add emc2-related stuff to the ini file too
I didn't want to commit any changes to the ini file, just because of thing I had changed that are specific to my machine
Right. I fear for this also
I'm thinking though at we need at least a stock stepper and servo configs
yep - Alex and I were discussing that
we were all discussing that
I was thinking of making an emc_servo.ini, and changing the core_servo.hal file to match
I think that's clear to all..
way ahead of me. I only saw the dust
I can add something like PID_MAX_OUTPUT to the AXIS_n sections
problem is what hardware do we use
okay that handles the problem
the core settings are hardware independent (in terms of the units)
that's why the units are the way they are ;)
and we just have to explain to integrators that headroom is PID_MAX_OUTPUT - Max_Vel
it's gotta be explained one way or the other
I'd change the driver output limit to be equal to the PID limit as well
so effectively, we're adding a HAL_MAX_VEL to the ini file
That'll get those stray pulses rounded up and put back in.
heh - yep :)
speaking of texas.
it would be ideal to remove anything that doesn't pertain to emc2 from the ini file, but unfortunately, some of it will be put back on exit
do you know what those things are or is there a way to test
edit the ini file, and align all the settings
run emc and exit
when you look at the file, any rewritten settings will be NAME = VALUE - not aligned
SWPadnos_: except the hal ones
no - anything that gets rewritten will have changed alignment - the HAL data won't be written at all
I meant ini values used from HAL
Huh. I thought the read/write that emc did was a diff
the diff is for the settings file, right?
parameter file , I mean
I know that for emc if you edit the file and add or remove comments or put in tickle type variables they will stay
in the ini that is.
right - there are some things that get rewrittten (OUTPUT_SCALE, for example)
I think that it only touches the lines that it recognizes as variables that are changed
actually - that one is a pisser, because it doesn't get read, and then getw rewritten to default every time
but it ignores anything else you add to it
That's my impression
SWPadnos_: exactly.. because it's used by HAL not by emc (that's what I wanted to point out above)
I'm checking (call me paranoid)
yep - MAX_PID_OUTPUT was left untouched
alex - looking at your changes, is there a reason for only checking the first 10 chars of the nmlfile name?
oh.. that was a paranoid check
had some segfaults I fought with
and that wasn't the cause, just made it 10 to be sure
forgot to put it back afterwards
does that include the path, or just the name?
I emptied ppmc.ini and shutdown and nothing came back.
i had a backup
rayh_ppmc_usc: I think the shutdown procedure looks at the file and changes the stuff there
so if we don't need a variable and leave it out then it should not come back.
only the variables that emc uses, and which have changed. are written
unless there are some trip wires in that write routine that we don't know about
I suspect that it does an inifind on any variable, and if it isn't found, it doesn't write it
otherwise you'd end up with a pretty big file after the first run
(plus, if the var isn't there, it must be at default, and you can't check for differences)
I used to make them read only but I think nowadays they change the file permissions
gotta get to town.
there's an interesting (related) feature of KDE that I was reading about recently
also related to the ebo mail
they have the ability to read a series of config files, and overwrite settings from successive files (like ebo suggested)
but you can also put a [$i] in any of the earlier files, to make parameters (or whole sections, or entire files) "immutable" - so the user can't override those parts
it's pretty slick
it's a little elss applicable here, but still a useful concept
the integrator can make emc.ini have some sane defaults, and mark some as unchangeable (like max_velocity ;) )
but there can be other setups that override other things
yeah = usefull concept
(user foo is an idiot, so use the simplest GUI available)
you know that it will be a pita to look for the .nml and .var files ;)
would only work if you use absolute pathnames
say you have a default ini / system
hm - for the config subdir thing?
for the multiple configs stuff
like ebo said
and like you said
Catch you guys later. Thanks for the fun. Signed user foo.
sure - there's a config file "search path"
see ya foo-bar ;)
bar != baz
fubar != pebcak
proven my case ;)
if bar!=baz then bar-baz exists
bar - baz always exists
given that bar and baz exist
ok.. back to configs
I could write that in logic notation if you like ;)
you write - I'll make some oatmeal and read in a minute :)
wanted to ask you about the mail I sent you..
(hm - 3 minutes - I must be getting old)
for the oatmail
bathroom / coffee / oatmeal
hope you don't mix those ... ROFL
nope - separate process spaces
make a list for when you're older
so - back to the email ... :)
I'd say that the need for separate NML file directories is small (basically nonexistent)
would the scenario described there be ok?
having a few nml files in one directory is sufficient
SWPadnos_: yeah, and the subdirs might just reference as ../emc.nml
then all those changes are not needed
yep - as long as relative paths are allowed in the ini file, I think we're covered
they are, and work ok
the path can be expanded, so that an absolute name is handed to the NML code
one of the changes for make install was running from the dir where the config file is
if relative paths work for the HALFILE entries, then that's covered as well
yeah.. but look at the changes of emc.run
I look in the dir where the ini is for .hal files, but also in the original config dir
so common stuff (core_servo , core_stepper , classicladder , etc) can stay in emc2/configs/
I'm not sure if I like the "automagic" nature of that - all it saves you is ../core_servo.hal in the ini file
I think it's the thing that cradek was talking about
just lt you specify all those files relative to the location of the ini, and it's all good
that works as it is now ;)
then your work is done ;)
there is still need to move the configs around
for the nmlfile, I'd use the default dir, unless the person specifies ./yaddayadda.nml
actually - that would work for the others as well - assume default dir unless a path is specified
with ./ being a valid path
say again please
well - the nml file is unlikely to change
right.. that's why I wanted that to be in the configs/ topdir
so I thought that it should be takes from the default config dir
yes.. but that can be done in 2 ways:
but, you still should be able to specify a different one
1. use ../emc.nml in your ini
2. take over the changes I did
ahh.. you want to hardcode it inside emc2?
the default value?
so only change it if needed?
I think we're saying the same thing, it 's just a question of how the decision is made to take the file from a different dir
and the easiest way would be just like bash does it
the problem is that you've got 3 or 4 software components that do that
if you type "foo" - bash searches the path for foo
taking the nml file out of the ini
if you type ./foo, it doesn't
so you can explicitly override default behavior very easily
GUI (aka emcsh, or AXIS, or xemc..), IO (aka ioControl.cc), TASK (aka emctaskmain.cc)
I guess the question is just what the "search order" is
you're not hearing me ;)
bear with me for a while
lets take IO
IO needs to talk to task, right?
therefor it needs to open some NML channels (or listen to some)
sure -I understand that all processes need to be looking at the same NML file
ok.. now how is this done:
1. there is a function emcGetArgs() that's called, and looks for args to the program
searches for -ini & the like
next there is a function called iniLoad() usually, which reads the ini for values it needs
if it finds a NML_FILE reference it replaces the DEFAULT_NML_FILENAME with it
then tries to read it
but the programs get executed from the directory where the ini is
yep - and all of those programs have to either (a) have the same complete file path specified, or (b) use the identical default behavior
(or (c) have an environment var)
c is bad
a is bad too, because you can't have absolute paths in the ini
hmmm - well that leaves ...
ok.. how do you mean b?
say you have emc.nml in the ini
you try to open in the same dir, and that fails
what will you do?
all programs that use the nmlfile have to search the same paths, in the same order, to find the nml file
that's what we're trying to decide ;)
you don't know where you are..
probably should issue a pwd first, then try to see
but that's just as bad :(
sure you do - $0 is the executable name with full path, no
in ioControl.cc ?
yep - it should be the first arg
humm.. with full path? don't think so
I'm not sure about that either
but a pwd is also workable
ok - scripts don't get the full path - bummer
scripts don't need it
they know it
or better said they decide it based on where the ini is
$0/argv is the name the program was invoked as
ok - thanks (saves me from writing a "hello argv program")
so it should have the full path
only if you ran /the/full/path/program
emc.run executes everything with full paths
;-) (at least it does now)
SWPadnos_: I am thinking this is complicating it too much
how about we have (by agreement) the default nml in configs/emc.nml
and all ini's are in configs/foo/ dirs
yeah - as long as the system works from emc.run, and you can specify both absolute and relative paths, I think that's enough
and reference that nml file by ../emc.nml
I think the config should work from configs/ as well
actually you don't need to do that, we could have DEFAULT_EMC_NMLFILE = "../emc.nml"
config would work, if you have a NML_FILE=emc.nml in it
unless there's a "configs/sample" or "configs/default" dir
in there you would either have a). no NML_FILE at all
or b). one that reads ../emc.nml
ah - OK. DEFAULT_NML_FILE (../nmlfile) is in scripts.run, and is overridden by an ini setting NMLFILE, if present
well not in scripts.run, actually inside emc (emc2/src/emc/nml_intf/emccfg.h) but you get the picture
right now the NML_FILE in the ini might be missing
components using that will try the default value before giving up
emc.run I meant. I'd think that the same thing would be needed in both the run script and the header file
so that programs use the same defaults as the script
the script doesn't use the nml file
it does specify it though, right?
the changes you've seen to the script are only to pass the nml file as an argument to the files
to be able to find them easier
ah - OK.
so I did the NML search in the emc.run script, then passed the absolute path to it as a -nml parameter to all parties involved
except AXIS.. didn't touch that
ET phone.. swampy
ok - back
missed that :(
heh - it's midnight - you should go to sleep ;)
passing the nml file seemed like a good way
yep - I agree
the only thing that happens is that you can't run the programs "manually" and expect them to find the same file (but I can live with that)
well.. seems afterall you agree with my changes ;)
I think so
I just didn't understand them at first (I'm not so used to the cvs diff format, or shell scripting in general ;) )
well.. I was a bit worried about changing functionality without talking to others ;)
that is a concern
I agree partly because I have no stake in how it works now ;)
well.. functionality isn't changed
mostly the way things get passed
anyways.. guess I'll bring it up on sunday
probably a good plan
or maybe on the dev list
yeah - that would give people a chance to look over the changes before discussing them on Sunday
guess I'll do that tomorrow
gone to bed now
ok - night
hey there, jmk
(i get to sleep in tomorrow ;-)
woohoo - you can stay up as late as you want!! ;)
not really, I have to sleep in just to catch up from all the other staying up late
you and pete are terrible when it comes to keeping me up late
we try ;)
pete especially - he has an unfair advantage
check the logs on this channel for a nice discussion I had with Ray today ;)
we overlooked the obvious in our discussions with skunkworks re: pid headroom
what is that?
all we have to do is make a new [AXIS_n] var, called PID_MAXOUTPUT
just because emc1 dodn't have it doesn't mean that emc2 can't
do you mean the axix.<number>.whatever HAL pins from the motion module?
no - since PID needs a little extra room (over the MAX_VELOCITY), make a new var in the ini
and assign that to pid.maxoutput and stepgen.maxoutput
could do that
why not use MAX_OUTPUT
(I think that's what Ray suggested, just starting to read the log)
because then we'd have to have formulas, or PID won't be able to catch up to step inputs
so you lower max_output a little, or add a little to PID_MAX
I don't think anybody is using MAX_OUTUT right now
well - I added it to the core_servo.hal file, and I thought that motion used it
motion doesn't (I don't think)
the path from ini file to motion is convoluted... would take some checking to confirm that
I was probably looking at it like an emc1 parameter ;)
I kjnow it used to be used there
it used to limit the PID output, back when the PID was integrated with the motion module
now I'm almost certain the motion module doesn't use it at all
easy test: hack the hal file so the PID limits are fixed at whatever works
then change the ini MAX_OUTPUT to 0
ok - I'm thinking of max_velocity, not max_output - that's what I made core_servo use
also, the PID (and possibly the various output drivers) should be able to have asymmetric limits
perhaps, but that is rather specialized
note: there is a HAL limit block, that lets you independently set min and max
though a Z axis could easily have different parameters going down vs. up
PIDFF, limits, accel, etc.
the emc1 PID had a bias parameter for that kind of thing
I don't recall if the HAL PID has the same
could certainly be added if not
I think it does, come to think of it
yep - it's there
wow, alex seems to be making this ini file thing a lot harder than it has to be
use the directory that contains the ini file as the current directory, paths contained within the ini file are relative to that
you want to use the generic .nml file, say ../emc.nml in the ini
it's a matter of making all of the programs that use the NML file do that as well
(which includes all of the UIs)
don't all the various binaries get the path to the ini from a command line arg?
yes, and also the location of the NML file, in a patch that Alex is testing
but he had to change emcsh.cc, emctaskmain.cc, ... to do it
I know what to do!
get rid of NML ;-)
and he left out axis
hey - that's a good idea
and you can sleep in tomorrow! ;)
actually, I'm planning on throwing together a preliminary version of halvcp tonight
(if pete doesn't show up ;-)
maybe you should just leave the two emc channels ;)
three actually, I'm also on the board channel
well - there you go ;)
its only 4:30 out there
at least it would make it slightly harder to distract you from coding all night
but I've enjoyed the distractions
there are few folks who really talk about these kind of details
it's nice to have conversations where people aren't saying "this is how it's done, you have to make it the same"
that's probably a big part of it
* jmkasunich hides
u don't want to eal with threading?
actually I do...
just not until 2am ;-)
I have any idea to do it easy in the HAL
I think we could mod the HAL gearing comp and add a few pins to motion
if the gearing would take a start count value for lock up, it should be pretty straight forward
take z out of coordinated mode, hit the lock pin
what do you think?
it might work for rigid tapping
do u think TP or HAL for starters?
single point threading is more complex
I was thinking inside EMC proper, not in hal
single piont threading doesn't nead gearing
how else do you get the pitch you want?
it's just a helical move
doesn't have to be geared to spindle speed
only if you have a servomotor on the spindle and treat it as a position controlled axis
circle in x,y, linear in z
that is not the norm
now I'm saying huh
I'm talking about single point threading on a lathe
threadmilling works that way - with helical moves
with single point, the cutter only has a little point, it spins much faster than a tap would
oh, I was still on a mill
no, with single point, the cutter is mounted in the lathe toolpost and spins not at all ;-)
single point on a lathe is the same as rigid tappin on the mill
multiple passes, for one thing
but each pass is the same
tapping doesn;t need an index pulse on the spindle encoder
multipass threading does
actually, the passes are slightly different
also, threading might involve more than just moving Z
u don't need an index, just the start count like I mentioned
you offset by a little to increase the depth of cut
tapered threads for instance
so u want to gear multiple axis to spindle speed on the lathe then?
and if you are threading to a shoulder, you want to pull the tool out as you finish the pass
NPT threads are tapered, for example
each axis could have a gear module
what are the trade offs for TP vs HAL?
it seems pretty specialized for HAL
I see HAL as keeping things tighter, but probably limited to linear gearing
the TP still has to be aware of what is going on...
shouldn't it just be happy with the position feedback it see?
the way I see it, a threading (or tapping) pass is an ordinary coordinated move, but instead of using time as the independent variable, it uses spindle position
does the TP even look at the following error, or is that servo only?
do u think the error will be acceptable that way?
the TP always uses position feedback
certainly won't be good enough for gear hobbing stuff
it just gets it as steps generated for stepper machines
swp: I thought from yesterday, the TP was just assumeing things went where it said to?
yes and no :-/
right - sorry ;)
jmk: what's the no part?
(I told you I'd forget 90% by today)
emc looks at the feedback, for purposes of following error detection
it also uses feedback when stopped, to set the command when it starts again
right, but that's just for error, correct?
rihgt - the TP is too slow to be able to use it
"stopped" = motion disabled
yes, not for control
so if gearing works, the TP should be happy with no error
I guess I don't get what you are porposing
I was just thinking about putting gearing modules on the axis in HAL
if we mod the gear module to take a start count, we can start the same relative to the spindle each time
so you essentially disconnect an axis from the motmod axis.0.position-cmd output, and drive it from the gearing module instead
and motion gives the start count and lock gear pin
the trouble is that there are sometimes lead-in and trail-out moves
once its disconnected, TP has no idea what is going on
you would have to blend the lead-in with the "geared" output over time
(note: I proposed this idea at Fest, and was met with these concerns ;) )
you can almost do gearing just by using a PID module
what are the various lead in going to look like?
I don't have concrete facts yet, but I feel that threading/tapping is a machine tool operation, and should be handled by the machine tool oriented part of the SW, not the generic part
(or the scale block)
for ridgid tapping, lead in could be handled by adjusting spidle speed
It probably needs to be part of the interpolator
for a lathe, I'm not sure what it looks like
I think rigid tapping doesn't use leadin
I always start from a groove
and finish in one too?
jmk: I don't use it on my machine
for the reason that John mentioned - it changes the independent variable away from "time"
jmk: finish in groove or off end of part
off end of part usually only happens with left-hand threads (unless you run the spindle backwards and put the tool either upside down or behind the work)
but both lead-in and lead-out are issues
yes, and right hand start off end and end in groove
the issue is, how does the TP handle that - there's no longer a 1:1 (or 10:1) ratio of poses vs servo cycles, since the completion rate of successive poses is locked to the spindle
so what do the lead in/out moves look like?
depends on the shape of the thread
does your lathe have a threaded spindle nose?
for a normal thread, I'm having trouble seeing how leadin is anything but slower speed
my lathe is d1-4 cam lock
ok, that won't help...
I can thread either way
lathe spindle nose threads don't end in a groove
hm - what if motion had an input that could change the increment to the spline independent variable (away from servo period / TP period)?
they just smoothly retract the tool, the thread gets shallower and disappears over perhaps half a turn
that is lead out
oh, so you are saying the thread fades out at the beginning or end?
ok, got it
its a right angles to the centerline of the part
sure, but that seems like a coordinated move on x with gearing on Z
you probably don't need lead in and lead out on the same part, but they are kinda equivalent
the X move has to be synced with the spindle too
not as much as Z
yes it does
I think more error in X is acceptable
say X pulls out over half a revolution
if you are nearly done (last few passes) and you start the pullout a few degrees of spindle rotation late, that pass is gonna dig in
yeah, but that seems like TP speed stuff and it will only take a little heavy or light cut
if Z messes up, your threads are wavy
they're both important
anyway, lets think about the toolpath
assume for now, a right hand thread, normal rotation, starting off in the air past the end of the part, and finishing near a shoulder
initially, part is spinning, tool is sitting still, a little past the end of the part
at some point (probably based on index pulse) we say GO!
or some count
but I think we say go and the gear comp syncs to the count if we use HAL
the position command for Z immediately begins to go left, at a rate dependent on spindle speed
first problem is that the commanded speed just went from zero to something without any accel
so the axis is gonna fall behind and take some time to catch up and settle out
there are limit in PID, no?
but we're still in air
so the initial position needs to be far enough out in the air to allow for that
could be a problem if we were doing left hand and starting at the shoulder
anyway, lets keep going
Z stabilises, tracking the spindle, the cut begins
if the cutting load slows down the spindle, Z tracks it
say we're cutting a 1" long thread
after 1", now what?
we keep Z moving, and retract X
if you want lead out, you start a coordinated move on X
when out enough, motion dissables the gearing
changes Z back to coordinated
and carries on
if you have a groove, no problems
so you're gearing Z to spindle but not X
just stop gearing and switch to coordinated
yes, Z, not X
true, as long as the groove is wide enough for the decel of Z
X can be geared, but only if the ratio is 0 for the bulk of the threading move
that always is the case
you can always slow the spindle near the end
no you can't - you don't necessarily have control of spindle speed
swp: I think you gear x for tapered threads
well - you can leave X geared to the spindle, but change the gear ratio during the threading pass
if you don't have spindle control, then there is nothing u can do regardless if the groove is too small
yes - if you have spindle feedback, then you're all set
no, jmk says groove is too small for decel of machine
that's why you do gearing, rather than a coordinated move that includes the spindle
then you have a problem if you cant change spindle speed
swp: the assumpting was acel/decel too high with small groove
you may be able to change the spindle speed, but the time constant will be huge, I think
ok, let's go on
jmk: how do you compare this to TP gearing?
sorry, was answering a call of nature ;-)
* jmkasunich reads back
don't foget the oatmeal
I wasn't saying the groove was too narrow, I was saying it better not be to narrow
but lets not talk about the groove case, lets talk about the pullout case
the tool path isn't straight
that's OK, if something (motion) can change the gear ratios on the fly
first it moves parallel to the part, then it turns - simplest approach would be a 45 degree bend to pull out
but realistically it would be an arc, that starts tangent to Z and does a hard left
(as viewed from the tailstock)
now why can't we just program that toolpath (line followed by arc) and then follow it at a rate determined by spindle speed instead of clock time?
that concept allows you to do all kind of things
but this will be at TP rate, no?
like tapered threads, (just program an angled line for the first part)
ignore rates for the moment
see my previous suggestion regarding changing the rate that the independent variable is incremented in the interpolator
hard to do as that was the motivation for HAL
right to swp, what? to pete about hal motivation ;-)
the only difficulty being that some axes may not want to be geared (most notably the spindle, if it's an axis)
I see gearing on a per axis basis, not all or none
in fact I thought only on Z would work
I don't like the idea of gearing
I want to be able to program an arbitrary toolpath
then run that path at a speed determined by the spindle
instead of by the clock
ok, so how do we run the interpolator at various times based on spindle count?
that's actually useful for non-threading apps, such as removing material at a constant rate
but I don't see the implementation
yeah, where you change spindle speed as the diameter changes, but maintain constant feed per rev
there are two things that have to be done
(at least ;) )
one: make the spline calculation rate variable - that's pretty easy
it goes back to the TP (the overall thing, not just the slow thread that EMC calls the TP)
swp: I would think that spindle count would take the place of time
TP input, a path, defined in mathematical terms
TP output, samples on that path
two: make sure that there aren't any nasty problems if the interpolator isn't executing TP poses at the expected rate of exactly one per TP cycle
yes - spindle speed would take the place of time, but that means that there needs to be a way of dynamically changing this value
SWP: can we pretend for an evening that there is no interpolator, and that the TP runs at the servo rate?
since you don't *always* want to use that
but then you have a different can of worms
ok, what does the TP do? it evaluates X(t), Y(t), Z(t), etc for various values of t
usually t does 0.001, 0.002, 0.003, 0.004
but it could do 0.0013, 0.0025, 0.0032, 0.0041, 0.0044, 0.0045, 0.0045
IOW, motion would slow down and stop, if you slow down and stop t
I see the TP sampling the desired path and making pose
if that's at servo rate, I don't see an issue
hey - we're supposed to forget that it's two pieces right now ;)
if not, it's the interpolation between these points that seems to be tricky
swp: I know
[20:28] jmkasunichSWP: can we pretend for an evening that there is no interpolator, and that the TP runs at the servo rate?
given the CPU power we have today, I'd like it to be one piece
that may actually help, due to no overhead between the parts
I think the real reason for the slower TP wasn't because the TP couldn't keep up
it was because they were doing kinematics on the TP output
and for some machines, the kinematics are an iterative thing, very slow
so kinematis for a robot are slow?
for a mill/lathe, who cares
depends on the geometry
you may need successive approximations for something like a hexapod
if there is a closed form solution, not bad at all, even if the math is comples
for a standard mill/lathe
a hexapod may be a mill/lathe
SWP: don't be a brat
you know what he's talking about ;-)
swp: if axis=joint
NIST had a really cool hexapod milling machine - they made the titanium case for the Declaration of Independence with it
I didn't know that
I like the robocrane
I want to build one of those that hangs from my basement ceiling
yeah - the one for ship fixing?
yeah, although that one is too slow because people need to stand on it
anyway - back to lathes
I saw a video of a robocrane holding a welding torch
(you have to watch NOVA to see the hexapod)
* jmkasunich doesn't watch much TV, but NOVA is good, I should watch that
anyway, I would like to move toward a TP where t can come from either the clock or the spindle interchangably
but TP period is still constant?
sampling period is constant, yes
ok, I guess that would work if spindle variation wasnt too great
it would work regardless
other wise it seems like some pose could be close and others far
seems like error could increase for pose far apart
poses are always 1mS apart
or whatever the servo rate is
probably not an issue with any decent spindle
yes, I was looking at distance between pose, not time
even at 300ipm, 1mS = 0.005
granted, you want a lot better than 0.005 when threading
but you aren't likely to thread at 300ipm
that doesn't sound all that fast for coarse threads
lemme see.... 20tpi
but let's continue
5 inches/sec, = 100 turns/sec = 6000 rpm spindle
yes, not unreasonable for 20 TPI on AL
have you seen a Hardinge thread?
they thread unbeleivably fast
to do that, you don't just need 300ipm, you need mondo accel and decel too
IOW, a high bandwidth machine overall
so maybe you ip the servo rate to match
but even the manual HLV threads scary fast
it has some built in stop mechanism
throws out the halfnuts without the machinist sweating bullets?
there is also a cam on the compound to move X quickly
heh, IOW, they program the toolpath (including pull out) with steel
ok, so you think that jitter on the distance between pose is not a problem for a normal spindle?
spindles have huge inertia compared to axis drives
the challenge is probalby the accel/decel at start and finish, during the threading pass any change in spindle speed over a period of 0.001 seconds will be negligable
even if there is significant slowdown over the complete pass
of course, rigid tapping has the opposite problem
ok, so some minimal spindle inertia is an assumption then
everything has inertia ;-)
I just think about a sherline and it seems it has almost none
relative to the size of cut it takes, it has enough
you only make shallow cuts
never used one, looks like a toy
sizewise, it is a toy
I've made chips bigger than some of the parts folks make on sherlines
so it doesn't seem that hard to take T from the spindle count instead of time
the problem is getting the TP to accept T as a variable, instead of a constant stairstep
why? how is the code done?
isnt it just a var down there?
(including when T goes backwards - getting the tap back out after a rigid tapping pass)
I don't think that should be a big issue
nothing is that simple
now we have to admit that there are two parts to the TP again (bummer)
the second part of the rigid tapping pass should be a move in the opposite direction
the tapping pass is a single move, from outside the work to finished depth
Z is syncd to the spindle
don't you have to reverse the spindle?
and you need to stop the spindle when you reach finish depth
then you reverse it, T goes backwards, and you "reverse time" and do the toolpath backwards
but you never unsync from the spindle
or, you remain synced, but make a "reverse path" move, so you're still going forward in pseudo-time
I knew I shouldn't have said "pseudo-time ;)
it's two moves, with a synchronized IO operation in the middle
change spindle speed (off / reverse)
move up, still in sync
it can't be two moves with a spindle change in the middle - there is no middle
t never needs to go backwards
if you are tapping fast, you may already be slowing down the spindle before the tap even enters the work
is the spindle under emc control?
the move needs to slow down, stop, and accel backwards at the same rate as the spindle
whats wrong with running T backwards?
for rigid tapping, it would need to be under at least loose control of EMC
and EMC needs to know its accel limitations to it can make it stop a the right spot
running t backwards isn't a problem, until you need t he previous pose that you were working from
running T backwards has other advantages - backing up in wire edm's when the wire shorts to the work, for instance
heres where I want to get radical
new TP time!
input to TP is still a mathematical expression of the desired path
but instead of line or arc, it is splines
not one spline per TP period
each spline would be as long as possible
limited only by the fact that you can't perfectly fit a spline, so eventually you need to break it up into shorter ones to get a better fit
splines are calculated in user space
sent to RT
and all the RT does is evaluate the spline polys for various values of T
when you reach the end of one spline, start the next
but save the old one
so if you need to back up, you decrement time, when it goes below 0, you switch to the previous coefficients
an interseting question is how many to save
so where are the canned cycles implemented then? not in canonical, but in the TP?
it would be nice to be able to save them all
yep - but you run into similar buffer length problems as before
if the splines come from user space, why not just have canonical play them back?
even if you were issuing hundreds of splines per second, modern PCs could easily queue several thousand, and keep several thousand old ones around after they are "used"
it knows if it's a canned cycle
canned cycles have always been in the cannonical/interp side, not the TP
I wouldn't change that
yes, so canonical knows how many splines to save
for rigid tapping, etc.
why save them in the TP?
well the TP needs to be able to access them without waiting for user space code
so you can go backwards
no, cannonical sends them down and they Q
here is a far-fetched concept (just a concept, not what I want to do)
canoical repeates them in reverse for the back up part
suppose you run the interp on an entire g-code program, and generate a file (on disk) that consists of thousands of splines, that mathematically represent the desired toolpath
load that file into memory
and just work your way thru it...
you can go as slow or fast as you want
you can even back up
all the way to the beginning if you want
you can use a jog wheel to move along the toolpath ...
so maybe we need a two way between the TP and user space
in practice, there would be a couple levels of cachine - first from disk to user space, then from user space to RT
but if we think of the "queue" as actually being a pointer into a very long sequence...
and you need a way of dealing with I/O and other things in there as well
insert I/O commands between the splines, or in a parallel array
hey - there's that synchronized queue again ;)
why not just have a file on canonicals, one of which is a spline
I want everything as splines
it's probably better if the fast RT code only has to deal with one type of calculation
ok, so get rid on arc and line
anyway, this is just a thought experiment right now
you can optimize the hell out of it
but you still need other canonicals
right - resolve arcs and lines into splines in user space
a spline can describe an arc or line
I might be able to do this in the new interp if we want to
however, consider this
notice that feedrate override is easy now, just change your T
what about cutter compensation?
this will be tougher with splines
not if it's in the G-code to begin with
g-code will (at least for now) issue only lines and arcs
you just make a compensated path
ok, well that's different
cutter comp is applied first, you now have corrected lines and arcs, then you spline it up
if g-code is still arc/line no prob
I'm thinking nurbs from CAM
though you're right - it would be ideal to be able to replace a broken tool with a different diameter, and keep on trucking
or a sharpened tool that's undersized
(after backing up a little to actually cut the part you missed ;) )
I was really liking the idea of precomputing the entire path
although I glossed over something....
I think we still need to do it on the fly
this concept handles feedrate override nicely, however
not that big a deal though
it also handles jog / pause / resume nicely
if your path consists of lines and arcs that are co-linear at the joints (arcs tangent to the adjacent line or arc) then you can spline it up easily
but if it contains a line followed by a non-parallel line, that is an infinitely sharp corner
and no spline can track it, only approximate it
no machine can cut it either, unless you are in exact stop mode
you need to take a cue from a program like Corel Draw
you can do arbitrary splines, but a node can also be considered a "corner"
you mean between splines?
you would have the option of either doing a stop, then accel at a corner, or rounding it somewhat
EMC defines three modes (but only implements 2 I think)
exact stop stops between each segment, even if they are tangent
yep - you can decide what to do at a disjoint based on the mode
exact path stops when needed, but for colinear lines or tangent arcs it keeps going
continuous contour keeps going at the commanded speed and deviates as needed from the ideal path
is there an error limit for continuous?
I don't think so - the error is a function of the speed you commanded with an F word
well - the simple but stupid way of doing that would be to generate three different sets of splines around any disjoint. one for each of those modes
its really only 2 modes
you either stop at a joint, or you make the tightest turn possible given the commanded speed
no - I think it's three - in exact stop, you emit 4 control points per segment
only two choices
in exact stop, you stop even when you don't have to
that guarantees a stop at every point
in exact path, you stop only when you have to
in continuous, you don't stop
but the math only has to deal with stop, and not-stop
ok, so something else dawns on me
in exact path, any change from exactly collinear moves would generate a stop, no?
how does gcode specify the lead in lead out on a lathe and have it geared to spindle?
it's not a canned cycle
note another thing - any path can be made non-disjoint
sure - if you don't mind some rounding or stopping ;)
what I mean is that you can compute arcs that will join the non-tangent lines
yes, that gives you rounding
I think I would approach the rounding thing by doing exactly that
for any given tangential speed and lateral accel limit, you can easily compute the minimum radius
so when you have two lines that join at an angle, you can calculate the radius of the arc that blends them
sure, but that changes with feedrate override
or jog mode
then it is geometry to calculate where the lines should be cut off and the arc spliced in
shhhh, you weren;t supposed to say that!
ok, but how does gcode specify the lead in/out on a lathe and have it geared to spindle?
jogging is single axis (or you talking about using a jogwheel to control "time")?
jogwheel = time
pete: you keep changing the subject
I'm not sure, but I think there are g-codes that change the sync mode
yes, but this seems like a big issues we forgot about
so you would have:
g1 F1 Xsomething Ysomething (last normal move)
G33 (I think that is the sync g-code, it actually also takes arguments)
G1 F1 X something Y something (first part of toolpth
ok, I never saw anything like that, I'll search
G1 more tooplath
G2 more toolpath, doesn't ahve to be all lines
G33 sync mode off
G1 non-sync toolpath
I think Paul added G33 to the interp in the lathe fork,and I think that was merged into HEAD
but it might be ifdefed out
hm - that's not quite what Machinery's Handbook says
what I just told you I got second or third hand
swp: what does the book say?
ok - lemme type in what the Book says ;)
it's ot definitive for threading
scan and ocr, cut /paste
here are the G-codes:
G33 = thread with constant lead
G34 = thread with increasing lead
grep interp source for G33
G35 = thread with decreasing lead
I'm looking through the text for desciptions of threading commands
#define NCE_G33_NOT_SUPPORTED 200
so it is parsed, but then does nothing
pete: you've been reading Kramer, is there a canonical for threading?
no, there's a canonical to sync with spindle
that would be the one I think
no threading found, except for G84
there are also some for spindle force/torque
I see some references on the net to G33, G34, G35
interesting - G94 / G95 are supposed to be for feedrate as a function of time vs. spindle rotations
[14:01:03] <petev> http://www.answers.com/topic/g-code-1
pete: you have a URL for the kramer paper? I seem to have lost it
[14:02:02] <petev> http://www.isd.mel.nist.gov/documents/kramer/RS274NGC_3.pdfhang
without the hang ;-)
* jmkasunich saves to disk for next time
[14:02:37] <petev> http://www.isd.mel.nist.gov/documents/kramer/RS274NGC_3.pdf
no prob, I recognised it before I even pasted it
dang doze to X paste stuff
pete needs a linux box
ksirc is running on linux
X to it from doze
oh, but you are sitting in front of the doze box
well those canonical commands are wonderfully vague
u see the canonicals about spindle force/torque?
I think they may have been implemented one time for the K&T retro at GM
I wonder what happened to that code
hmmm, there is an orient spindle canonical
for single point, tool change, etc.
sometimes you use a single point to cut an internal groove
we did spindle orient on the Mazak, but obviously without the canonical
you need to orient so you can move x,y before z retract
or to withdraw a boring head without scratching the bore
yeah, a lot of the canonicals are bypassed with direct NML
I wonder what g-code(s) invoke orient anyway>
I think it's part of canned cycles
my old BP has a bore cycle that uses orient
it stops and you have to orient in manually, then continue ;-)
so I guess all this stuff is non-standard again and kramers doc doesn't define enough detail on how g-codes or canonicals should work
do you see the elipse feed? that one's not implemented either
cutter comp is bein done in the interp now too
I think it belongs in canonical
I'm much happier talking about how to implement threading in the TP than about how to specify it in g-code or canonicals
I think we can just use the canonical for spindle sync, not sure about the g-code
we have to define in more detail exactly what the canonical means
there is no scale factor there, it is strictly on/off
so how is thread pitch specified
I think paul's interpreter G33 stuff expects an argument to G33 that is the pitch
probably why it's not implemented ;-)
since I want to be able to sync arbitrary toolpaths to the spindle, I'd favor using F words
when sync is off, F words set speed in ipm, or inches/sec, or mm/sec, or whatever
the standard is to use a K word for the thread pitch
when sync is on, F words set speed in inches per rev, or mm per rev, or something
so if we have F and S, what else do we need? just counts per rev from INI or something
G33 Z-1 K0.0625
where did you find that?
swp: how does the lead in/out work?
yep - G94 means units/sec, G95 means hundredths of a unit per revolution
it doesn't ;)
swp: are these fanuc conventions that are described?
they seem to assume that the "geared" axes will by synched to a particular spindle orientation as well
yes, must be
not sure - they have a combination of EIA nad ISO specs
the orientation is needed for multi-pass threading
and some non-standard codes, but no names mentioned
yep - I remember some discussion of this at Fest
they don't say much more about threading.
well, my interest is in the implementation of the TP
the job of getting threading working is gonna need to be split up
interpreter, canonicals, task, RT, etc all are involved
ok, I'll take a shot at the canonicals when I get there
I look at the cutter comp stuff too
gotta give the kids a bath, be back in a few
* jmkasunich needs to do some coding
this is probably a good point to stop talking ;-)
(stopping early :) )
I can probably help with the halcmd stuff, if you can check in or email (or dcc) a header file or something
I was talking about halvcp (the virtual control panel stuff)
nevermind - you said vcp eariler - that's the HAL-ified control panel stuff
you have some time and want to do something with halcmd? I have a suggestion...
totally up to you...
newthread <name> <period> [nofp]
hm - rather than load threads blah blah
the problem with this is that you need to be in kernel space to actually start a thread
you guys gave me some ideas about how to do that (helper kernel thread) but I'm not thinking anything so complicated right now
you can also do it with the threads components
do you know what's involved with the obvious corollary function - delthread?
loadrt threads name1=<name> period1=<period>
at least for now, you won't be able to delete a thread
ok - I know it's like that now - was wondering what the expected complexity of making it possible is
that will require work at the HAL API level to make it happen, its at least as complex as the newsig
needs to be done in kernel space
but the hack using loadrt threads can probably be coded in one evening
that's why I brought it up
sure - just loadrt threads / unloadrt threads (like linkpp)
once we have newthread (even if its a hack) we can chop the thread creation code and "period" parameters that are in nearly every HAL componnent
get rid of a lot of duplicate code
I'll take a look, and see if it fits with my "style meter" :)
(I don't like hacks, when the right thing might not be too much harder)
in this case, the right thing is much more complex (and actually the leading edge of a major rewrite)
then itll probably pass the style check
once there is a helper thread running in kernel space, I want most of the HAL API to use that thread, and all the internal metadata can live in ordinary kmalloc kernel memory instead of shared memory
the long term plan is to use a proper implementation of newthread to get the kinks out of the helper thread idea
then move over the rest of the API
the finally move the metadata
OK - I was thinking about a module that sets up a "hidden" slow thread, looking at shmem for commands every once in a while
slow poll - it's for userspace control anyway
that would be slow when you are executing a .hal file with a crapload of lines in it
and a waste of CPU the rest of the time
the CPU isn't an issue - poll every 100 ms or so, and it takes almost nothing
I thought we were talking about having the kernel thread block on a semaphore
also, allow a queue of functions to be placed by userspace
sure - that can be done as well
that way reaction to a userspace request is instant, and it wastes no time at all the rest of the time
one minor point - you do realize that a semaphore is also polling, it's just the task executive that does the poll
so you save the context switches
src/rtapi/rtapi,h describes semaphores as implemented in rtapi
I don't think so
but it's still polled
I think it is tied to the scheduler
I'll take a look there to make sure
when the user task releases the sem, the scheduler is told: suspend the current task (user process) and re-evaluate priorities, run the highest runnable task (which will now be the helper thread)
looks like sems are RT only
ah - OK.
I bet that is a RTLinux limitation, I think RTAI has symmetrical user/RT sems
I can look at that stuff - you are hereby released from "Steve Support" for the evening - have fun coding vcp ;)
just caught up here, I thought the RTAI sems worked from user space too
so jmk mentioned - he said that it may be an RTLinux limitation
not necessarily RTAI
right - RTAPI is designed to hide the differences between the two
as such, it is the least common featureset
out of curiosity, do we still need that?
damn I hate snow
just took the dog outside, we must have 16"
I thikn we have .017" now
it was funny watching him try to take a dump in snow that is belly deep on him
back to RT...
like pissing in the wind
RTLinux is basically BDI-2.xx
so if we go to RTAI only, we abandon that BDI-2.xx users
(could be that user -you never know ;) )
I think cradek said the other night (when he tried emc2 for the first time) that he was running RTLinux
yes, he did
I don't think he had BDI-2, I think he might have done his own install
but with a newer kernel he built
ok - if it's not acceptable to drop RTLinux suport, that's fine - I just thought the question should be asked
I agree it should be asked, and in a wider forum than this
let's find out for sure if it's an RTLinux issue
I don't really care for RTLInux myself
my knowledge of RTLinux is at least 2+ years old, from when I was writing RTAPI
I don't use it
but I doubt I put that note in rtapi.h for nothing
I thought that it was also proprietary (from Timesys or someone)
they patented some of the underlying tricks
right - OK
that's what prompted adeos
there is a GPL version, but the patent flap is why most free SW folks use RTAI
the patent issue
ok - and we're also considering (way in the future) using stock 2.6 with Ingo's RT patches
that certainly would limit the number of distros that could be used (since all the BDI 2.xx were kernel 2.4 afaik)
and many of the BDI 4.xx as well
BDI-2.xx were 2.2 I think
BDI-TNG and Live were 2.4
ok - even more out of date, and difficult to upgrade
BDI-4.xx were all 2.6, differnet minor versions and different RTAIs
I thought that BDI4 before 4.16 or so were 2.4 as well
I don't think so
I think the whole purpose of the 4.xx series was to move to a modern kernel
I use the free rtlinux
jmk: just to close things on the TP, you're thinking to just run it at servo rate and avoid the interpolator issues?
I never was able to figure out how to build an rtai kernel and have it work right
although I only tried once
how would you like to switch to Adeos / RTAI?
cradek: does today's free RTLinux support userspace/RT semaphores, or only RT/RT?
because I installed it a year ago and it was easy and works perfectly
I have no clue
figured I'd ask...
cradek: for RTAI, you only need the adeos patch
RTAI is not part of the kernel path
at least for the newer versions
what's the hal patch then?
I think it may be more compiler version sensitive
that's old, adeos is the new way
petev: on the TP issue, I don't know... depends on kins and other issues
I can't believe they still recommend 2.95
RTHAL is gone
don't want to go there now
cradek: I think more recent versions of RTAI work with later compilers
I did try to use rtai once; I got a system that didn't work right and then I installed rtlinux since I had done it before once
the recommendation is one of those "so-and-so got bit by this 3 years ago, so lets play it safe" things
jmkasunich: jepler found it on their web site a week ago when we were talking about this
I'll switch if I have to, but I'll probably bitch some
paul compiled the most recent BDI-4.30 with gcc 3.something
I think that Paul got Adeos to compile using 3.3 or 3.4 for BDI 4.30 (though I could be wrong)
maybe it works fine
I have 3.5 on mine
I'm pretty sure I used 3.2.2 for everything on my systems
I have no intention of dropping support for RTLinux - it came up because we'd like to use user/RT semaphores, and it seems that the verison of RTLinux I wrote RTAPI for doesn't do that
jmkasunich: I see
yep - 3.3.5 on BDI 4.30, though I haven't compiled any kernels or anything with it
if it turned out that nobody was using RTLinux, we might consider it
jmkasunich: it's just that I trust my rt machine now, and I can run emc1 and emc2, which is more than most of the developers can say!
jmk: we could always have a thread kludge module for RTLinux, although it would suck to maintain the code
any kluging should be done in rtlinux_rtapi.c, or not done at all
agreed, but that would be tough
then we don't use user/RT semaphores
hard to do the helper thread properly without it
there are other approaches
just none as nice
what I really want is a system call, not a helper thread
if it wasn't for the hassles of /dev nodes, I'd use an ioctl
yeah, but that probably means a kernel compile
just a driver module, I think
/dev/hal ioctl doesn't need a kernel compile
swp: I meant for sys calls
[15:16:54] <petev> http://piglet.uccs.edu/~chow/pub/rtl/doc/html/MAN/rtl_index.4.html
ah - yes, you do need to add to the syscall table
those RTL docs seem to indicate that the sem calls are still realtime only
where do you see that?
click on sem_init, there is (REALTIME) in bold first line
[15:19:40] <petev> http://piglet.uccs.edu/~chow/pub/rtl/doc/html/susv2/xsh/pthread_mutex_init.html
whats the difference between a mutex and a semaphore
a mutex is a sem with count of 1 max
may also have priority inheritance
it's all we need for this if it will work
I wonder if that is supported by the version of RTL that is on BDI-2.xx
if so, rtl_rtapi.c should be re-written to use it
if not, we might consider a rtl<version>_rtapi.c that works with newer versions
* jmkasunich looks at the ./configure output from the 2.2 farm slot
well - you need to have the support in all versions that you want to maintain compatibility with
that slot runs BDI-2.18, kernel 2.2.18-rtl3.0
so if there's one version of RTLinux that won't give you the functionality you need, you can't use it for halcmd
I note that the mutex page says nothing about realtime or kernel - it's a userspace thing only (from my perusal of the page)
that page is straight from the posix specs
swp: then why is it in the RTLinux docs?
it's under a rtl directory tree, but...
because it's supported in userspace
look at the top of the page
Single Unix Spec
so the question is does RTL let you create one in userspace and then block a RT task on it
I'm looking for that answer
the title of hte page is RTLinux man page index
I don't know why they would discuss Posix stuff if it weren't related to the RTLinux
that site isn't even officially related to RTLinux
no, I'm looking on fsmlabs now
oh, but the URL you posted was elsewhere
[15:30:11] <petev> http://www.fsmlabs.com/fsmlabs-lean-posix-for-rtlinux.html
if either of you wants to hack rtl_rtapi.c to use mutexes, I'm willing to try to compile it on the compile farm that is running BDI-2
there is a semaphore example in src/rtapi/examples/sem, that could be hacked to test user/RT sems
I'll look it over before agreeing to that ;)
the docs of fsm suck
remember, I was just asking about the quick and dirty hack, not the helper thread approach
yep - they fail to mention that RTLinuxFree is available for kernel 2.6
I remember. I'd still like to pursue the "correct" approach
they probably fail to mention anything good about the free version
In order for the realtime system to be able to use Linux, we provide three three standard interfaces between realtime tasks and Linux. The first is a device interface called RTfifos (illustrated below),r the second is shared memory, and the third uses the pthread signal mechanism to allow realtime threads to generate soft interrupts for Linux. A simple A/D application might consist of a single periodic thread that collects data from a A/
doesn't sound like it has usr/RT sems or mutext
that doc is ancient
that's RT <-> kernel, not RT <-> userspace
it also talks about 66MHz boxes as being fairly fast
yeah, there is nothing newer on there
maybe in a download somewhere
most support and docs for the free version are hosted by the comminuty
the company abandoned it
someday I'll learn to spell
hey cradek: where did you get your RTLinux, and the docs to install it?
I thought fsm still sells RTLinux, what was abandoned?
the version that you don't have to pay for
they do sell it, it's the free version they're not too hot on
they do link to RTLinuxFree.com though
thre is a version for 2.6 kernel
yep, but it's hard to find that out from FSM ;)
u can't even see the files if u don't register, what a crock
that's why a lot of people aren't happy with Victor Yodaiken
yep, they probably stick the sales guys on you after u register
(unless the mail you a registration key or something)
I have nothing against a guy making money, but it burns me when a project is started open source and everyone contributes code, ideas, etc. then someone takes it commercial
I was using some doze HTPC code and everyone was contribution ideas and plugins and waiting for version 2
and even worse, patanted
then the guys starts a company and takes it commercial
thatnks for all the free ideas and dev work
the ADEOS people were very careful to implement something other than what Yodaiken did
my buddy is having the sudo gethostbyname() problem
he says his /etc/hosts is ok
any other ideas?