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