Back
[12:37:35] <alex_joni> skunkworks: thanks for mentioning it
[12:37:38] <skunkworks> Thank you ;)
[12:37:43] <skunkworks> Thanks ales
[12:38:13] <skunkworks> alex.
[12:38:20] <skunkworks> Last time you could not get in :)
[12:38:21] <alex_joni> [dinero]$ uptime
[12:38:22] <alex_joni> 05:38:14 up 1 day, 3:06, 3 users, load average: 12.29, 8.50, 9.01
[12:38:22] <jepler> did anyone find a Z-N formula table that they trusted?
[12:38:59] <skunkworks> jepler: no - I tried a few of the formulas with mass added to the servo and none seemed to work.
[12:39:06] <skunkworks> (but it could have been me)
[12:39:31] <skunkworks> I was hoping to try the auto-tune pid. I think petev checked in a fix so I may try it agian tonight.
[12:42:19] <skunkworks> I did do 'ok' manually tuning. but I still don't know what I am doing.
[13:18:34] <skunkworks> -Modified PID calculations to calculate PID values appropriate for EMCs
[13:18:48] <skunkworks> PID equation. The PID equation they were intended for is slightly different.
[13:19:47] <skunkworks> This is a comment in petev at_pid
[13:20:19] <skunkworks> I wonder what he used..
[13:27:09] <skunkworks> looking at the code - looks like I is still calculated by period/2 and and D is calculated by period / 8
[13:28:19] <skunkworks> hmm - looks like is it just ultimate gain * .6
[13:29:31] <skunkworks> * skunkworks muddling thru the code
[13:30:36] <skunkworks> although - ultimate gain is calculated by (4*effort)/(PI*avgaplitude)
[13:30:49] <skunkworks> interesting.
[13:44:51] <skunkworks> sure seems like not much code for all it does ;)
[13:45:00] <skunkworks> (pid in general)
[13:45:06] <jepler> yeah it is pretty magical
[13:45:07] <cradek> does it work after his fix last night?
[13:45:18] <skunkworks> I have not tried it - tonight
[13:47:06] <jepler> the "ultimate gain" is the P where the oscillation has gain=1 over successive cycles (does not grow out of control or die out) -- so if you don't find exactly this gain, you have to use some method to find it based on the oscillation amplitude at the second peak. sounds like petev's using some kind of average to do this..
[13:49:35] <skunkworks> Spookyness at a distance
[14:07:19] <alex_joni> bbl
[18:43:29] <SWPadnos> cool. the 5i22 is out now
[18:43:40] <SWPadnos> or it will be at the end of the week, anyway
[18:44:30] <SWPadnos> unfortunately, it'll be >2x the cost of a 5i20 ($439, I think)
[20:03:46] <jepler> 1 more header worth of I/Os?
[20:07:22] <SWPadnos> + 1.5M gates in the FPGA
[20:07:34] <SWPadnos> and it'sa faster FPGA afmily as well
[20:07:38] <SWPadnos> family, that was
[20:11:14] <jepler> until I hear from jmkasunich that he's feeling a pinch, I'm not worried about that
[20:12:35] <SWPadnos> heh
[20:13:49] <SWPadnos> didn't he say that 12 stepgens used ~70% of the 5i20?
[20:14:04] <SWPadnos> or was that 16 stepgens
[20:15:50] <cradek> what use is 12 (or 16) stepgens?
[20:16:20] <SWPadnos> err - for testing how big the FPGA is?
[20:16:41] <SWPadnos> he did that to see how constrained the FPGA would be
[20:17:18] <SWPadnos> the 5i22 could likely handle a fully generic PWM+stepgen model: every pin could be an I/O or any pair could be a stepgen or PWMgen
[20:17:39] <cradek> that would definitely be cool
[20:17:39] <SWPadnos> that could be 48 of each (actually, that probably wouldn't fit)
[20:22:31] <SWPadnos> heh. actually, it might :)
[20:23:01] <SWPadnos> the larger FPGA has 7.5x the number of gates, but only 6x the number of "modules" are needed (and the PWMs are smaller than the stepgens, I think)
[20:24:19] <jepler> what I think would be interesting is to put classicladder inside the fpga
[20:24:48] <SWPadnos> yep. I'd love that too
[20:24:56] <jepler> or any small microcontroller
[20:25:06] <SWPadnos> and possibly a lightweight CPU for ... right
[20:25:53] <SWPadnos> the 1.5M FPGA could actually hold a pretty good size CPU, though I'm not sure there are any free/Free ones
[20:26:20] <jepler> http://www.opencores.org/browse.cgi/filter/category_microprocessor
[20:26:28] <SWPadnos> looking ther enow :)
[20:26:58] <SWPadnos> I know the NIOS and MicroBlaze will fit in that many gates, with some pretty good features (32-128 registers, 32-bit, cache ...)
[20:29:44] <jepler> have one CPU core for each I/O connector, something you can target with gcc but with a few choice instruction set additions that make fast encoder / pwm / step generation possible
[20:29:57] <jepler> (I should just keep my mouth shut since I'm not going to work on anything of the sort)
[20:30:11] <SWPadnos> heh
[20:30:27] <SWPadnos> a 24-bit CPU should fit nicely
[23:18:09] <skunkworks> I have a question.. I just did a cvs update and make... Now the lathe_pluto.ini file shows this
[23:18:11] <skunkworks> <<<<<<< lathe-pluto.ini
[23:18:11] <skunkworks> MAX_VELOCITY = 1.66
[23:18:11] <skunkworks> MAX_ACCELERATION = 20
[23:18:11] <skunkworks> BACKLASH = 0.000
[23:18:11] <skunkworks> =======
[23:18:12] <skunkworks> MAX_VELOCITY = 23
[23:18:13] <skunkworks> MAX_ACCELERATION = 500
[23:18:16] <skunkworks> BACKLASH = 0.06
[23:18:18] <skunkworks> >>>>>>> 1.6
[23:18:20] <skunkworks> all over
[23:18:40] <skunkworks> that was a recent change? I guess I could look my self couldn't I ;)
[23:20:50] <skunkworks> also got an error saying that the axis_toolchange.hal didn't exist. I ended up copying the file from one of the sim configurations.
[23:24:16] <cradek> your copy must have been really old - I don't remember it being in inches
[23:24:30] <cradek> but yes I did update cvs to match what I was running at workshop
[23:26:09] <skunkworks> I had initially got it at the workshop. I changed it to inches.. That was my copy.
[23:26:32] <cradek> ah