jepler: how about the lathe tool comp picture that is floating around somewhere
i'm back .. got called away earlier
I don't know for sure whether it's just for g-code, or for emc in general
I don't even know what you have in mind, but I guessed "handouts for the workshop"
last year we had those ubuntu CDs to give away .. this year I am thinking about 1 laminated page + burned emc2 live CDs as the giveaway
so yes, a 1-page "setting up emc2 for parport steppers" might be a good 2nd side, if that document existed
I dunno about that
the kind of people who need a cheatsheet for a simple stepper machine probably need more than one page
me either -- I don't think there *is* a 1-sheet document for that
and it will become useless after the setup is done, unlike the other reference info
AXIS key reference .. gcode-related diagrams .. some hal quickref ..
thats sounds about right
if its gonna be laminated, it should be stuff that you use after the machine is set up
I Have no clue what lamination costs, I assume a lot more than the basic copying?
I suspect so. but shops need it.
I assume you're already planning to have a few URLs on there
linuxcnc, a few key wiki pages, and/or manuals
at least linuxcnc and wiki.linuxcnc
maybe a line of prose to say how to open the pdf manuals on the installed system
jepler: did you play daisy when you were here?
cradek: no, I forgot about it
trust me, it's a hoot
perhaps the listing of daisy.ngc should go on the second side of the quick reference
it's obviously one of the most useful things that can be done with emc
darn, I knew that was too good to be true
jepler: if I trip on the cable and the pluto stops getting updates, does it turn off the pwms?
jmkasunich: what is?
updating 16 stepgens in 5800 clocks
I forgot the loop, its only doing 1
cradek: unfortunately, no -- they stay at their last commanded duty cycle.
I'm getting to that stage here
I shut down the software last night, and this evening the leds were still blinkin' away
no -- that got left for the end, and I am running low enough on resources that I don't think there's room (I didn't try to add it)
what is the PWM frequency?
cradek: actually a hardware mod would solve the "trip on the cable" problem (a pull up or down on the parport reset line) but still not the "emc crashes" problem
jmkasunich: 40MHz clock, 12-bit counter
so about 10KHz
20kHz I think
maybe it's a 11-bit counter then
a 5 bit counter clocked by the MSB of the pwm counter would overflow every 3mS or so
6 bits then
that doesn't seem terribly resource hungry
6 bit counter, reset whenever the PC updates, and shut down if it ever hits 3F
I think that I need an extra LE for each output pin though, to combine the value with the watchdog "all OK" signal
I should try and see what I get
what happens if you reset the PWM counter on watchdog timeout? will that kill everything from one place?
I guess I could also use the watchdog to trigger the chip reset
but then you can't recover without restarting emc (the pluto-servo component)
thats not nice
maybe but that leaves the general purpose I/Os as well
good point, one i was overlooking
GPIOs are a pita, because you can't be sure what the proper state is
IMO a proper hardware setup ignores the GPIO until you are out of estop, and getting out of estop requires some kind of watchdog-ish thing
like a charge pump
hmm -- actually there may be a per-pin output enable, so that 'assign real_pin = watchdog_ok ? pin : 1'hZ' doesn't take any extra LEs
for instance, on the mazak there is a master 24V estop relay (physical relay), and unless its energized, you can twiddle the GP outs until you are blue in the face and nothing on the machine reacts
File "/home/chris/emc2.trunk/bin/axis", line 2383, in open_file_name
x = (o.g.min_extents + o.g.max_extents)/2
AttributeError: 'NoneType' object has no attribute 'min_extents'
^^ when opening a filter that generates nothing useful
cradek: you mean 'no motions'?
or maybe a single g0
is it specific to a filtered file, or does it apply to the same gcode if it's just in an ngc?
an empty ngc file gives different errors
a file containing only "m2" gives no error
well thats unexpected....
stepgen.read takes ~20000 clocks, stepgen.write (more complex) takes ~6000
the original one was a python file with a syntax error
I bet its time spend waiting for the PCI read cycles
how long is 20000 clocks?
jepler: if I turn the spindle very slowly, I reliably see counts to -4095
or 780nS per stepgen
so with 100 joints run by your stepgens, you could only get a 3kHz update rate!
the FPGA only holds 16 stepgens
ok you can get 80kHz then
you know what they say about premature optimization...
the other night pete was giving me grief about the time checking params to see if anything changed
the stepgen write code is checking 5 params for changes (at least, maybe 6, I'm too lazy to check)
it runs in 235nS per stepgen
I have a feeling that once you've touched a cache line you might as well do all the arithmetic you want on the values in it without making your program appreciably slower
thats probalby true
unless you decide to do numerical double integration or something ;-)
OK -- the watchdog logic is probably all wrong, but the additional 6-bit counter and output enables still leaves me with 20 LEs to spare, so I can probably fix it up to be "right" as well
if I understand the code I wrote, this will tristate all the output pins doutXX, upX and downX when the watchdog expires
that's anice line
"if I understand the code I wrote" ... :)
usually it takes at least a few weeks to lose the ability to understand my code
pluto is at least that old
I've done little enough verilog that I'm not confident I understand what any of it mean
that's not bad
assign real_dout = watchok ? dout : 10'bZZZZZZZZZZ;
petev: it seems like I'm not getting any autotune behavior
what happens when you run it?
ah, nothing, but when I poked the pulley, it oscillated and then I got some changed values
(and an immediate following error)
should I have to poke it to start it oscillating?
you need to take motion out of the loop, the PID cmd input cannot be changin during auto tune
cradek: I get "Exit code 1 [OK]" when I run a Python program with a syntax error. I don't get your error. This is in emc 2.1.5
I used a mux to feedback the cmd pos to pos fb during tunning
cradek: are you using a lathe config? It may be something that happens when no gcode is originally loaded .. ?
you should not have to poke it
jepler: this is trunk - I did not check 2.1
jepler: yes a lathe config
maybe the tune effort is not enough to overcome friction
ok I tried .1 first, then .5 (the default)
it also depends on your DAC scalling
my max PID output is 3.333333
cradek: aha, that got me your error, after the "Exit code 1" message.
petev: I don't know what the scaling should be or how to set it
if yours is 10, 0.5 may be too little
I set my scaling so the PID output is in user units per second
but it's up to you how you want to set your machine up
you should also take care of any DAC offsets before auto tuning
do you know what voltages create what RPM?
no but I should be able to measure it
you mean dist/sec, not rpm right?
first you need to figure out the rpm, then use the reduction and thread TPI to get dist
on my machine its 10 turns per inch
but the number I eventually want is dist/sec?
and the drives are setup so 10 V = 2000 rpm
at the PID output it's vel, so dist/sec
assuming you are running vel mode in your drives
his drives are straight PWM to the motor
my kingdom for a mm ruler
hmm, so what would the PID output be, accel?
its actually sort of velocity
since duty cycle determines voltage, and the motor will accel or decel until the CEMF matches the applied voltage
at any rate, it should be pretty safe to just start increasing tune-effort until you get a decent oscillation
less the IR drop and other strays
I didn't know I could change that after I "start"
you can, but it will obviously not give accurate numbers so you should run another cycle again after that
hey pete - remember our discussion about the time needed in RT to see if a parameter has changed and "stuff" needs to be recalculated?
you can also abort a cycle by setting the enable false, or tune-mode false
what about it?
I'm running a 16 channel stepgen driver right now
it checks 10 parameters (per channel) for changes
and is taking less than 250nS to do each channel
on what machine, your new dual core?
no, sempron 2800+ (1.6GHz)
I'm running a 1GHz C3 which is probably about a 500 MHz celeron
the stepgen read function takes longer than the write function, about 800nS per channel
and the filter stuff would probably be running at some multiple of the servo rate, so it's a little more sensitive than most compnents
its only checking one parameter (scale), but it has to wait for the PCI read
have you looked at the biquad?
I'm a little lost here
SWP and I talked about it ad decided to compromise
my main effort right now is getting the 5i20 working, I just noticed this result during my testing
we put in some basic filter coeff calcs
and a direct mode
* jmkasunich updates
and the coeffs are only calced on enable
so you can't change them on the fly?
if I set my pid output so 1.0 is 1mm/sec, the pid output will have to go to ~ 25 to get the velocity I want. That means pid maxoutput is 25. am I right so far?
so only one input needs checking and atomic coeff updates are gauranteed
but you have to make sure the update is atomic anyhow, or the filter could become unstable and oscillate with positive feedback
cradek: pretty much
what do I do to get that into the pwm that takes 0..1 then?
currently pid.output => pwm.input
remember yesterday we talked about limiting the duty cycle to 19/26?
you should set the PID based on that
so maxoutput should be 19/26 and the scaling isn't what I need for autotune?
does PWM have any scaling like the DAC does?
auto tune doesn't care about the scaling
it will work with any scaling
petev: getting ahead of things
the manpage says it needs a certain scaling to get auto FF
it may work with any, but it makes sense to choose a decent scaling, not something random
that's only if you want to use PI FF1
for PID, scaling doesn't matter and it only matters for FF1 in the PI FF1 mode
understood, but a non-random scale is still nice to have, for testing, troubleshooting, and to allow use of FF terms
so, how to do that....
I found D was less than helpfull with FF1, which made sense intuitively
right now, a pwm of .3 moves the axis about 4.6mm/sec
ok, so 30% duty cycle = 4.6mm/sec
so you want 4.6 into the PWM block to result in 30% out
the desired scale is either 4.6/0.3, or 0.3/4.6
how's that for unambiguous information
cradek, does the pluto have any tpype of control loop?
it counts encoders and generates pwm - that's all
does .3 -> 4.6 mean that 1.0 -> 15.33 mm/sec
I don't know if that answers your question though
I thought your machine was faster than that
thats only 36ipm
jmkasunich: well it is -- 1.0 gives > 25mm/sec
so its non-linear
or my measurement skills suck
jmk, if the pluto has no loop, isn't the result going to change a bit with load, etc.?
I said a while back that it was only approximately velocity
I don't think I can safely run it at 1.0
I mean, to see how fast it goes
(not much travel)
the safe way to check speed is a bit of a pain
you do a hal config with siggen->pwmgen
so assuming I don't care if the scaling is pretty, I can still autotune PID but not FF1?
start with a square wave, 1Hz at an amplitude of 0.05 and increase it
you can measure velocity by looking at slope of position on the scope
since pluto pwm doesn't have an input scale, it seems like what I have already is the straightforward setup
and you can still tune PI FF1, then manually adjust FF1
oh, pluto has no scale?
didn't know that
in that case, scaling is a non-issue
oh yes it does
anyway, whether you scale or not, you want to set the PID limits so it won't exceed your max safe volts
(19/26 = 0.73 duty cycle)
its better to set the limit in the PID block
that way, it know when it saturates, and it can hold the integrator to prevent winduo
if you limit it in the pwm block only, then the PID has no clue that its saturated the PWM
ok so my max vel is 25.4
pid maxoutput = 25.4
pluto.pwmscale = 33 (25.4 * 26V/20V)
assuming I have 26V supply and want about 20V at the motor max
is this right?
give or take a reciprocal in the pluto :-)
that means you'll have truly arbitrary units for the signal going from PID to Pluto
if you can't scale that signal to mm/sec, how bout scaling it to volts
seems like a lot of 25.4, why not use inch? is your leadscrew metric?
I think that means pluto scale = 26
what are your machine units (ini file units)?
petev: I could use 25, doesn't matter to me
let's call it 25
cradek: make the pwm scale factor 26, and pid-max-output 20
I think PID output in volts would probably be a decent choice since pluto has no loop anyhow
a scale factor of 26 means 26 = 100% = 26V to the motor, 19 = 19/26 = 73% = 19V to the motor, etc
I verified that pluto does divide by the scale, so this seems right
on the sw pwmgen, I divided specifically so you could use the supply voltage as the scale and have the command = output voltage
so ideally I'd measure what pwm=20/26 gives me, and that would be my max vel
or, once tuned, jog faster and faster, with a halmeter on the PID output
when it hits 20, whatever jog vel you are at is that vel you get from 20V
ok now with that scaling, it's really loose, but still working
once you have vel limits set that limit steady state motor volts to 20ish, and have the PID tuned, I'd open the PID limits up a bit, to 24 or so
a little extra voltage will help for accel and such
seems dificult to run a setup like this near limits when you get a cutting load on it, etc.
cradek: what were your old PID gains?
~ 50, 3, .15
and what was the old pwm scale? 1.0?
so they will have to be much higher now
no FF1 or FF2?
before getting into autotune, try multiplying your previous gains by 26, I bet they work ok
all those (26/20) should probably be (20/26)
since you want to go down below 100%
I didn't see him write 26/20 anywhere
err - or not
pluto.pwmscale = 33 (25.4 * 26V/20V)
he's using a different value now anyway
but I guess it could be the inverse ...
heh - right. I'll go back to server assembly now
pwmscale = 26, so the signal from PID to PWM is in volts
* SWPadnos wonders where his 39160 card is
yes multiplying by 20 makes it work fine again
I'm going to try auto now
(I could do 20 in my head...)
try PID mode
* jmkasunich ducks
petev: in hal, it's .start-tune; in the manpage it's .tune-start
ok, Ill fix it
I assume .tune-start is what you meant (the rest are all .tune-*)
man I should have use comp ;-)
I still don't have any motion at tune-effort=4
is this in pid output units?
what does your pid output normally go to to get motion started?
so you will probably have to go at least that high then
so still nothing at effort=20
(which is maxoutput)
what is coming out of PID?
* jmkasunich states the obvious
is the output of the PID loop going to +/- 20?
pid output is .5
the output should stay pegged until themachine moves
pegged = effort?
what does hal show for tune-effort?
oh I have to start-tune after I set tune-effort
I got the impression I could adjust it after starting
you should be able to
it doesn't seem to work that way
it takes it directly fromthe param
check if the tune finished
but does it only take it when the polarity switches?
maybe the osc were so small you didn't notice them
if you get no movement, it never switches
no I can easily see them
jmk, that's correct
6 float RW 16180.71 pid.1.Igain
6 float RW 344.3257 pid.1.Pgain
6 float RW 1.831813 pid.1.Dgain
so it's probably stuck there
that's with effort 20 (= maxoutput)
the code should probably read the param 'effort' every time thru, instead of just when it switches polarity
ok, I can look at that
it's fairly sure about those values, I doubled 'cycles'
with effort that big, was the tuning movement rather violent?
cradek, how large were the oscillations?
small - 1/8 turn of the main pulley maybe (1/8 mm axis motion)
maybe .25mm, something like that
how does the machine behave with those values?
I think you should try a smaller effort as things may be getting saturated
seems to overshoot and ring
but it feels stiff and does damp out
try a smaller effor, I bet something saturated
I got smaller P and a little higher D than what I manually tuned
your x20 values were P= 1000, I = 60, and D = 3, right?
sure, try 1/2
so the auto-tune has craploads more I
yeah, and less P
1/3 the P, and ~1/2 the D
much smaller oscillations this time
axis is VERY stiff
still rings I think, let me plot it
when I visually looked at the step response between my auto tune and manual tune, the auto-tune had one over shoot and no osc
you used effort = 10 this time?
the manual tune had no overshoot as that's what I was going for
what were the PID values?
you mean "are" as in this time?
yes, with TE=10
[03:24:08] <cradek> http://timeguy.com/cradek-files/emc/autotune1.png
those are just short medium-speed jogs
yeah, and it rings like a bell
can you zoom in and see what the ring frequency is?
how is the error compared to the manual values?
looks like maybe 50mS = 20Hz
petev: the ringing is visible on the blue trace, which is at 1/div
I'd guess its about 0.01ish
I see that, looks pretty bad
the pluto is non-linear - does that affect how well PID works?
I bet the tuning algorithm isn't designed for 2nd order systems
it uses zeigler-nichols to calc PID from the process characterization
motor torque + load inertia is one "stage", which both you and cradek have
I did read that the ZN values tended to ring under some circumstances, but were fast to get to final value
but applied voltage + motor armature inductance is another "stage" which was handled by your drive
and some commercial PIDs had other eqs for slower tuning
[03:29:50] <cradek> http://timeguy.com/cradek-files/emc/manualtune1.png
accel looks too high, now that the output is limited
but these are my old settings multiplied by 20 (should have been 26)
what PID values is this?
1000 60 3
yeah, might want to lower it until tuning is done
last auto was 1096 86600 3.5
what happens if you use auto-tune values with less I?
the bouncing during the steady state part of the move is disturbing, but it might be a response to real things
like cogging in the motor
too much I reduces phase margin
well I notice P,D are very close to the same
jmkasunich: it could very well be the belt teeth
if you do a jog at half the speed, does the bouncing drop to half the frequency?
if so, its almost guaranteed to be mechanical - some cogging somewhere, whether belt, or magnetic in the motor, or brushes, or...
[03:32:54] <cradek> http://timeguy.com/cradek-files/emc/manualtune-halfspeed-jog.png
cradek, what is the servo rate?
the ring frequency remains the same, but the steady state bobbles slowed down
a higher servo rate will make the period measurement more accurate if the period is short
so you can ignore them
petev: 1 mS
did u turn on the debug module param?
if so, it will export a coupld more params
one being the period
no, but I can if you want them
sure, let's see what the period is
ok let me multiply the values in my ini file so it works sanely to home
I and D both have a dependancy on the period
[03:35:51] <tomp2> http://www.httrack.com/page/21/fr/index.html?patart
[03:38:58] <cradek> http://timeguy.com/cradek-files/emc/manual2.png
reduced accel a bit - now I get this very nice output
throw pid.error up there, and gain it up a bit
tha's with the manual values?
pid error, or ferror?
either one, they should be the same
I guess I'd use PID error
I'd also be tempted to use incremental jogs, so you can make them shorter
you really only need to get up to cruise phase, have a little time to settle, and then start decel
[03:41:43] <cradek> http://timeguy.com/cradek-files/emc/manual3.png
the shorter the move, the faster you can set the sweep
hmm, steady state error during the move
I bet the scale changed messed up the ff1
I think I agree with the auto-tune, you need more I
this is still with no FF1, correct?
there is some - I'm trying without now
ok anyway I was going to try auto again...
60 is nowhere near enough I
6 float RO 698.9418 pid.1.ultimate-gain
6 float RO 0.03408 pid.1.ultimate-period
you have 0.020 of more-or-less steady state error, times 60, means you'll get an I term of 1.2 after 1 second
ok, so your period is pretty long, 1KHz shouldbe good enough
ideally the I term would have meaningfull effect in much less than a second
yes, that is very slow
hold on - is PID running in the same thread as "servo" from motion?
if so, then the PID error is expected to be near the motion per servo cycle
PID gets the new position
not the current position
the error is there for the move, then goes to 0 after the move ...
still, if you have enough I gain, you can't have a steady state error
right, I effect low freq behavior
it should wind up and eliminate steady state error
yes you can, because every cycle, even if you get perfectly into position, motion moves the target on you
ok - I see
as long as the PID isn't saturated, it should try to go even faster
the integrator starts anticipation that motion is gonna move the target,and it "leads" it
hmmm - pid.error is an absolute value, isn't it?
the fact that the PID output looks like a scaled version of the pid error points out that Pgain is by far the dominant factor here
the axis must be inverted - the output should go negative for a positive error
no, it's the way error is calced
they both got the same way
I believe error = cmd - fb
so if cmd is going up, error will be positive
shouldn't the PID sum be subtracted from the output though?
* jmkasunich waits patiently for the next scope grab
tuning by committee ;-)
I think it helps us all learn
BTW, I don't think I told u this, but one of my problems was that the drives were too quick without the filter and too slow with it on
when I tuned for a step input without filter, the PID corrections for steady state caused too much movement between servo cycles
tuning for steps has problems
so I couldn't get good response to both large and small error
I upped the servo rate to 5KHz and it was great
by its very nature it guarantees that something will saturate, but with proper commands (ones that obey vel and accel limits) it won't saturate
BTW, I had to drop the accel on my machine after I ran some moves with a loaded table
it was wobbling a bit too much ;-)
jmkasunich: what am I supposed to be grabbing for you?
yeah, it's needs a bigger base
I dunno, what have you been doing? changing gains? using auto-gains?
back to playing with the numbers manually, I can get a lot of improvement
post pics as you improve, so the peanut gallery can chime in
(and see the effect of your changes)
what are the best manual numbers?
he probably isn't at "best" yet
best so far
more like "better, but still tweaking"
you're too literal
[03:58:30] <cradek> http://timeguy.com/cradek-files/emc/manual4.png
I is starting to do something
yeah it's very high
yes, what is I there?
that is 900 12500 8
so more D is stopping the osc from I ?
did you find that increasing D damped some of the ringing?
to both of you
I remember that from the Mazak
D will cause a phase shift back the other way and improve phase margin
interesting that the PID output doesn't go to 0 - it sticks to some low value that probably doesn't overcome friction
there didn't seem to be a limit to that, except that D amplifies the quantization noise from the encoder, so you can't go too high
there is probably also a lower limit in the PWM gen, at which you get no output
SWPLinux: I've never seen pid output go to zero in any of my tuning
ah - could be. but then again, when the motor is on station, there doesn't need to be any output ...
I bet the fuzz on the green trace, especially at the tail when it is stopping, is encoder quant noise * Dgain
yeah eventually D makes it worse
what's the encoder resolution?
there's a delicate sweet spot
jmk, I was seeing some of that, but it was not noise
the drives were actually responind to it, and I could hear the motors ring
petev: you have very high encoder resolution, hence low quantization noise
unless you had lots of D, you wouldn't see that fuzz
6000/mm is pretty high too isn't it?
might see different fuzz...
I'll end up with 40000/inch on my BP
you've got ~150000
cradek: you really have 1/6 micron resolution?
cradek has ~150k
err - nm
yeah - 6000/mm
well according to the encoders, yes - according to the axis motion - not so much
500 line, 3:1 pulleys, 1mm screws
oh, its the screw
that means you can use lots of D-gain
yes definitely the screws
yeah - 20 TPI ballscrews would be hard to come by for a larger machine ;)
or 25, even
so why does friction seem to be so high? is it a combo of the screw and ways?
sweet spot is D=7 or 8
why kind of ways do you have?
petev: why do you say friction is high?
is seemed to take a large PID output to start any motion
much higher in percentage terms than anything I have seen before
you mean when he said it took 30% duty cycle?
well I got reliable measurable motion at 30%
I didn't test for the slowest motion possible
brush friction, magnetic cogging, and simple armature resistance I bet
cradek, can you hear the motor ring after it's stopped in that last trace?
true, I'm used to ball screws and AC motors
no, it is silent and I don't feel anything
petev: stone knives and bear skins
with the 3:1 ratio and the fine pitch screw, way friction is probably a non-issue
so how far are the auto-tune values from the manual ones at this point?
the dominate factors are motor friction, and motor inertia
in fact I bet you could remove the belt and see not-too-different results
but they screw is probably not even an acme, correct?
no I think they are some kind of triangular
too small to see :-)
right, so efficency is probably pretty low on them
does this have the plastic anti-backlash nuts?
no the nuts are metal and a bit sloppy
petev: I think the autotune values with about 5x the given D gives pretty stable operation
and that's still without FF1?
you might want to experiment with ff2 actually
since the biggest spikes of ferror are during accel and decel
yes I think that'll really help
I had some before
from what I read, Z & N determined their tuning experimentatlly
then they derived formulas to come up with the values
I wonder how Z&N calcs dgain?
it wasn't any rigorus scientific model or anything
everything is related to ultimate period
in practice, its limited by encoder quantization, but I bet that doesn't go into the formulas
which is a ration of control effort to response amplitude
then I and D use a ratio of the period as well
and cradek's finding that significantly higher dgain than calculated stabilizes things
yes, seems like I was a bit high for the D in his system
what I found on the mazak is that after a while, I had a P-to-I ratio that it liked
but I could keep raising both P and I to improve performance
yes, I noticed that too
but too much made my machine unstable
but keeping the ration the same was pretty good
cradek, with that encoder resolution, I wonder what a higher servo rate would do?
I had to add D to stabilize it, and ultimately the limit was quantization noise limited the amount of D, which in turn limited the amount of P & I
if you think about bode plots, P+I means \__
if I autotune and then multiply D by 4, I get pretty stable response, except I need FF2
and the ratio of P&I determines the break point
and add D and ger \_/
each of those breakpoints provides 90 degrees of positive phase shift
which counters the negative phase shift due to poles in the actual system, thus adding stability
I didn't try FF2 on my system
I bet the I->P break is aligned with the main mechanical resonance, and the P->D break is aligned with an electrical/magnetic resonance
I 'm not sure what the motor model looks like, other than the basic integration effect
its got poles
everything has poles
cradek, so what were the final manual values vs auto tune values?
if you apply a voltage step to the motor, first current and torque ramp up, based on motor inductance
then velocity ramps up, based on motor inertia
then position is the integral of velocity
the first is the electrical time constant, the second is the mechanical time constant
ok, I can see that
man, andy holcomb is in deep trouble
something on the user list?
when the guy who owns the machine has absolutely no clue as to how much I/O he needs, and is asking people who never saw the machine how much I/O he needs, it means he is without clue, and in over his head
that is bad
cradek, did auto-tune at least provide a starting point or did you find it not much help?
I think he said he wound up with close to the auto tune values, but with 4x the D
but he said something about FF2 needed as well
he's probably playing with FF2 right now, instead of talking to us
FF2 .03 helps a lot
P 331 (AT) I 17400 (AT), D 6, FF2 .03
I'm going to have to try FF2 on my machine now
cradek: I'd do runs with different speeds and accels, to make sure you haven't tuned into a sweet-spot that is specific to this particular stimulus
probably handled by the drive vel loop, but I'm curious
petev: it may be less usefull for you, because
right, the vel loop deals with it
hmm at 25mm/sec it's saturating
the PID output?
is that your expected max vel?
yes - I must have been closer to the limit than I thought
maybe the pluto scaling needs to allow more voltage to the motor for that vel?
now you'll probably have to tune again ;-)
any of these are good enough to make parts
as long as he didn't saturate during tuning, he's operating in the small-signal, linear region, and the same tuning params should apply
once you know what vel limit = 20V, and set that in EMC, I'd open up the PID limits to allow momentary application of more voltage during accel
24V for some milliseconds isn't gonna hurt the motors
but if he changed pluto gain, that will effect the total loop
don't change gain
just raise the pid max-output
cradek: you gotta post a "final" or close to final plot of ferror
[04:36:31] <cradek> http://timeguy.com/cradek-files/emc/manual-final.png
so less than 10 microns of error
you get similar results for longer moves?
(I notice the cruise phase is very short on that one)
why did the error flat line a bit there before going back to 0?
petev: overshoot and a delay before I kicks in?
but I see PID output changning and the error is dead flat
a bit of deadband, note that output is passing thru zero
is it the scale?
oh, maybe backlash?
the PWM has a minimum duty cycle it can make, and the motor has a minimum duty cycle to overcome friction
unless I saturate, it stays under .01
lash isn't in the picture, the encoder is on the motor
ok, so deadband in the amp/motor combo
[04:39:52] <cradek> http://timeguy.com/cradek-files/emc/manual-final-longjog.png
0.0004 inches if I did the translation right
cradek, so is the new setup better than the old one?
its overshooting at the end, which is kind of annoying
petev: yes, but I don't think I ended up keeping any of the autotune values...
not sure what can be done about that though
I was actually refering to the machine setup
ah, yeah the pluto is great, much smoother motion
much better resolution
cradek, what is D and FF2 in that plot?
I had only 8? steps of pwm before
oh, that's not so good
D 8, FF2 0.03
you've tried larger FF2 values?
it worked surprisingly well actually
I bet less D would have less overshoot on the decel
yes FF2 is very picky and that's the "right" value
have you tried any FF1?
no, steady state looks perfect
oh, it's relying on I for the steady state, which causes the overshoot at the end
FF1 would fix it wouldn't it
if FF1/2 are perfect, then the integrator doesn't need to do anything
I think I-gain is a curse
I found FF1 and D did not work too well together on my machine. Intuitively, it seems like D shouldn't be needed with the right FF1
but you definitely need it to reach the final value
thats why I tune without them, to get the proper gains, then try to make the gains irrelevant with FF
cradek, maybe you need to set I limit
petev: I would avoid limits
the wind up limit in the PID?
they cause non-linearities, and make it respond differently to different kinds of moves
crap, I better get to bed
its not even midnight where you are!
goodnight guys, thanks for the interesting/useful evening
try FF1 first ;-)
wish I could report AT worked great - but ZN just seems wrong for this setup
(when I tried ZN manually, I found the same thing - it didn't work at all)
it did point out that you needed lots more I gain
how did you try it manaully?
jmkasunich: nah, I'd play with it for another hour then
you need the period and gain
petev: increase P until it barely sustains oscillation, measure the oscillation period
I see, but the Z&N formulas in the EMC manual are wrong if those are what u used
that's sure possible :-)
as I said, it didn't work
ok, goodnight for real this time
we need more data on auto-tune
lerman_ is now known as lerman
cradek_ is now known as cradek
SWPadnos_ is now known as SWPadnos