Back
[00:00:14] <jmk-solo> but I'm not very good at reading patches
[00:00:26] <cradek> what am I looking for in the table?
[00:00:35] <jmk-solo> "coretemp"
[00:01:13] <jmk-solo> #1 applies against 2.6.21-rc4
[00:01:28] <jmk-solo> #2 against 2.6.21-git
[00:01:35] <cradek> second one makes a new file
[00:01:45] <cradek> third one is documentation
[00:01:58] <cradek> first one is the only that might cause you trouble
[00:02:16] <cradek> just see if it applies
[00:02:21] <cradek> patch --dry-run ...
[00:02:31] <jmk-solo> 3rd one does some other stuff too
[00:02:41] <jmk-solo> adds lines to Kconfig, etc
[00:02:54] <cradek> not that I see
[00:03:05] <cradek> oh, 2nd
[00:03:13] <jmk-solo> sorry, typo
[00:03:29] <jmk-solo> those adds seem innocuous though
[00:03:33] <cradek> yes
[00:03:37] <jmk-solo> I have a couple options
[00:03:55] <jmk-solo> I could download 2.6.21.1 (the latest stable) from kernel.org and apply the patches to that
[00:04:06] <jmk-solo> or I could try applying them to 2.6.20.11
[00:04:45] <jmk-solo> this morning with I started this whole mess, I was talking to alex and he mentioned that 20.11 might be a better choice than 21.1
[00:04:55] <cradek> it's harmless to try on the one you already have working
[00:05:39] <cradek> patch --dry-run will tell you how well it applies
[00:05:56] <jmk-solo> * jmk-solo humbly admits to never having used patch
[00:05:57] <cradek> hmm, setup time is 1usec, probably not a problem
[00:06:00] <jmk-solo> man page here I cum
[00:06:04] <jmk-solo> come
[00:06:30] <cradek> in your source tree toplevel dir: patch -p1 --dry-run </the/patch/file
[00:06:38] <jmk-solo> I download those three, remove the various cruft from the front of the last two (from, subject, and such)
[00:07:04] <jmk-solo> should I concatenate the three into one patchfile?
[00:07:34] <cradek> no, just try them one at a time
[00:08:37] <jmk-solo> I do need to strip out the header crap tho, right?
[00:08:56] <cradek> I think patch might be smart enough to skip over it, but it sure won't hurt
[00:09:25] <cradek> patch tries to skip any leading garbage, apply the diff, and then skip any trailing garbage. Thus you could feed an article or message con taining a diff listing to patch, and it should work.
[00:09:42] <cradek> "tries" ... "should"
[00:12:28] <jmk-solo> the first one fails
[00:12:33] <jmk-solo> the other two work
[00:12:43] <cradek> fails how bad?
[00:12:47] <jmk-solo> root@solo:/usr/src/linux# patch -p1 --dry-run </home/jmkasunich/Desktop/hwmon-coretemp-first.patch
[00:12:47] <jmk-solo> can't find file to patch at input line 3
[00:12:47] <jmk-solo> Perhaps you used the wrong -p or --strip option?
[00:12:47] <jmk-solo> The text leading up to this was:
[00:12:47] <jmk-solo> --------------------------
[00:12:48] <jmk-solo> |--- linux-2.6.21-rc4.orig/arch/i386/lib/msr-on-cpu.c 2007-02-28 09:48:18.000000000 +0100
[00:13:07] <cradek> oh don't you have the file arch/i386/lib/msr-on-cpu.c at all?
[00:13:18] <jmk-solo> guess not, lemme see
[00:13:56] <jmk-solo> nope
[00:13:58] <cradek> then yer stuffed for sure
[00:14:16] <jmk-solo> * jmk-solo downloads 2.6.21.1 from kernel.org
[00:14:23] <jmk-solo> nothing like living on the edge ;-)
[00:14:48] <jmk-solo> I wish it was dot-<something-more-than-one>
[00:17:33] <jmk-solo> gonna get some food while that downloads
[00:46:12] <cradek> lerman: I like (debug,) and (print,)
[00:46:58] <lerman> It seemed like a good idea at the time. I'm glad to hear that someone is actually using it.
[00:49:45] <cradek> did you see I made a bug report about O-call?
[00:50:25] <cradek> it's easy to work around but still a bit surprising
[00:51:14] <lerman> Yes. I suspect that at the time I wrote it I didn't think about comments. Since the o word must be at the beginning of the line, owords are handled by a separate parser (at the top level).
[00:51:42] <cradek> ah I see
[00:51:50] <SWPadnos> can an O word come after an N-word?
[00:51:54] <lerman> I suspect that I just forgot about handling comments. Also, you cannot have parameter assignments within an oword line.
[00:52:17] <lerman> Honestly, I don't remember.
[00:52:40] <lerman> When I get a chance, I'll take a look at the code.
[00:53:21] <cradek> no hurry on my account. I just wanted to make sure you saw the report
[01:07:02] <jmk-solo> root@solo:/usr/src/linux# patch -p1 --dry-run <../hwmon-coretemp-new-driver.patch
[01:07:02] <jmk-solo> patching file drivers/hwmon/coretemp.c
[01:07:02] <jmk-solo> patching file drivers/hwmon/Kconfig
[01:07:02] <jmk-solo> patching file drivers/hwmon/Makefile
[01:07:02] <jmk-solo> patching file MAINTAINERS
[01:07:03] <jmk-solo> Hunk #1 succeeded at 967 with fuzz 1 (offset -26 lines).
[01:07:16] <jmk-solo> that last line isn't something to worry about I don't think?
[01:07:18] <SWPadnos> nope
[01:07:34] <SWPadnos> it means that patchj found the same context 26 lines above where it expected it
[01:07:38] <SWPadnos> -j
[01:07:59] <SWPadnos> I'm not sure exactly what fuzz means though
[01:08:17] <jmk-solo> maybe its a measure of uncertainty?
[01:09:10] <SWPadnos> I'm not exactly sure what they mean, but the fact that they say the hunk succeeded tells me that it shouldn't be a problem
[01:10:07] <SWPadnos> ah - fuzz 1 means that it needed to ignore the first and last lines of context to find a matching location in the file
[01:10:59] <SWPadnos> so you may want to look at that file on lxr (if they have the next revision back, to see what the changes are
[01:11:10] <SWPadnos> oh wait a minute - that's the MAINTAINERS file - I wouldn't worry about it ;)
[01:11:15] <jmk-solo> right
[01:11:19] <jmk-solo> I was typing that...
[01:33:26] <jepler> I think that a "fuzz" is a line of context that doesn't match the file
[01:36:39] <cradek> looks like I may have messed up "fixing" probing
[01:39:18] <jepler> oh no
[01:46:26] <jepler> something besides gene's message?
[01:51:02] <jmk-solo> wow.... doesn't 213 megabytes seem high for a kernel-image package?
[02:04:19] <jmk-solo> woot!
[02:04:20] <jmk-solo> jmkasunich@solo:~$ sensors -A
[02:04:20] <jmk-solo> coretemp-isa-0000
[02:04:20] <jmk-solo> temp1: +41°C (high = +85°C)
[02:04:20] <jmk-solo> coretemp-isa-0001
[02:04:21] <jmk-solo> temp1: +44°C (high = +85°C)
[02:04:59] <SWPadnos> cool
[02:05:06] <SWPadnos> I wonder if my MB is now supported
[02:05:52] <jmk-solo> I had to patch the kernel to get that to work
[02:06:06] <SWPadnos> right
[02:06:17] <jmk-solo> and the other mobo monitoring chip (fan control, and 3-4 other temperatures) still doesn't work
[02:06:59] <SWPadnos> hmmm - theoretically, it should already work, as of 2.6.12 or thereabouts
[02:07:12] <jmk-solo> yours?
[02:07:16] <SWPadnos> yep
[02:07:29] <SWPadnos> though that's not quite the exact chip (nforce4)
[02:07:29] <jmk-solo> try it
[02:07:47] <jmk-solo> install lm-sensors (if you haven't already) then do "sensors-detect"
[02:07:51] <SWPadnos> oops - I guess I should look at the right list ;)
[02:14:44] <petev> jmk-solo, I was working on an auto tune for PID and have some questions
[02:14:55] <cradek> jepler: no, just gene
[02:14:56] <petev> are all the float calcs in emc using float?
[02:15:04] <petev> I thought double was used?
[02:15:21] <SWPadnos> internal calcs may be double, all HAL pins/params are float
[02:15:23] <jmk-solo> internal calcs are double mostly, but hal pins and signals are float
[02:15:43] <petev> would there be any gain to carry double through hal?
[02:15:52] <jmk-solo> I had/have concerns about atomic access to anything bigger than 32 bits
[02:16:01] <petev> hmm
[02:16:13] <jmk-solo> hal signals cross between different threads, and between kernel and user space
[02:16:31] <petev> ok, I can we can revisit it later
[02:16:38] <jmk-solo> so in theory a process could be interrupted while writing to a pin/signal, and the interrupting code might read that pin
[02:16:38] <petev> not sure there would be any gain anyhow
[02:16:54] <jmk-solo> it would be good to have full double precision
[02:17:21] <petev> what about the way deadband is treated? I'm not sure it should be subtracted off from the error
[02:17:41] <SWPadnos> error shuold be clipped to 0 if it's within DEADBAND
[02:17:45] <petev> maybe just ignore error within the deadband, but don't modify error if it is greater
[02:17:49] <SWPadnos> is that not what happens?
[02:17:55] <petev> SWP, I know that
[02:18:08] <petev> but it's be adjusted when it's greater than the deadband
[02:18:30] <jmk-solo> the goal there was to avoid a step at the edge of the deadband
[02:18:34] <SWPadnos> hmmm - that does sound wrong, bit it also gives you a smooth error change, so D won't jump at the DEADBAND limit
[02:18:36] <jmk-solo> steps + D-gain = a problem
[02:19:06] <petev> ok, I can experiment with that later
[02:19:47] <petev> I'm going to add a simple limit cycle to characterise the process and get Pu, Tu
[02:20:05] <petev> then we can use one of the various formulas to get PID from that
[02:21:29] <SWPadnos> I had thought about doing a PID tuner, but (of course) got bogged down in the complexity of doing a generic one
[02:21:56] <SWPadnos> with a UI that lets you choose some limits, which PID to tune, where it should be connected, etc.
[02:22:08] <petev> I will have that
[02:22:21] <petev> but I'll let cradek or jepler modify the GUI ;-)
[02:22:48] <SWPadnos> heh
[02:23:08] <petev> it's not reall y so feasible to make the auto tune a separate component
[02:23:14] <SWPadnos> my original inclination was to try pyvcp, but I think I needed more (like a list of possible places to connect output ...)
[02:23:17] <petev> you have to disable PID when tuning
[02:23:22] <petev> and it's not much code
[02:23:32] <petev> I think it's best to be in the PID component
[02:23:43] <petev> then have a tune mode and a PID mode
[02:23:53] <petev> then you don't even have to mess with your HAL config
[02:23:57] <SWPadnos> are you doing overshoot / ring detection? (ie, how are you getting the PID parameters)
[02:24:07] <petev> just have the GUI set tune mode and start a tune cycle
[02:24:15] <petev> from a limit cycle
[02:24:24] <petev> will find the resonance of the process
[02:24:29] <petev> and calc PID from that
[02:26:16] <SWPadnos> you know, it's amazing how annoying it is to have a large lump of semi-solid hit you in the face from the bottom of your drink
[02:26:31] <jmk-solo> especially if its a worm
[02:26:56] <SWPadnos> no, just a big blob of "grape recharge" solids, I hope
[02:27:03] <SWPadnos> the liquid part tasted OK ...
[02:27:28] <jmk-solo> I was thinking of that tequila with the worm in the bottom
[02:27:37] <SWPadnos> indeed
[02:27:43] <SWPadnos> but that's not my kind of drink
[02:27:46] <SWPadnos> though it could be soon
[02:27:48] <jmk-solo> nor mine
[02:44:25] <skunkworks> I found out tonight brandy and coke tastes just as good as rum and coke..
[02:44:46] <SWPadnos> or just as bad, as the case may be ;)
[02:44:54] <skunkworks> :)
[02:49:38] <petev> what is the emctuning.tcl script?
[02:50:13] <SWPadnos> that's a PID tuning script, but I think it just has the user enter new values (and updates the ini when you're done if you like)
[02:50:28] <petev> I thought that was the emccalib.tcl script?
[02:50:42] <SWPadnos> oh, I could be totally wrong then :)
[02:50:54] <cradek> this is very old, I don't know what it is
[02:50:57] <cradek> scan [exec -- /usr/local/nist/emc/system $string] %s%s%s pgain igain dgain
[02:52:07] <cradek> emc_axis_set_output $activeAxis $stepvolts
[02:52:24] <cradek> looks like it wrote to the (stg?) dac directly somehow
[02:52:27] <petev> yeah, it looks like some effort at a tuning algorithm
[02:52:34] <petev> but it looks hopeless
[02:52:53] <cradek> not a useful start for something new
[02:52:55] <petev> did Ray do the emccalib script or did Jepler do it from something Ray started?
[02:53:10] <cradek> I think ray did most of it
[02:53:17] <petev> I was actually looking to see what it would take to modify the GUI to support the auto tune
[02:53:25] <petev> but my tcl sux anyhow
[02:53:54] <cradek> I recommend doing the gui last (or letting someone else do it) then
[02:54:08] <petev> I agree ;-)
[03:47:31] <SWPLinux> ok, time to check the latest rebuild of 2.6.20-11-ipipe
[05:59:13] <jmkasunich> crap.
[06:00:33] <jmkasunich> on Tuesday I committed the index changes, and asked Jon to test them
[06:00:37] <petev> jons checkin?
[06:00:42] <jmkasunich> I even pointed out that I was unsure of the polarity
[06:00:59] <jmkasunich> 5 days later, Chris releases a package with the changes
[06:01:10] <jmkasunich> only then does Jon get around to testing, and finds a mistake
[06:01:10] <petev> oh, not good
[06:01:29] <petev> I just finished the auto-tune pid, time to test (without belts first) ;-)
[06:17:27] <petev> hey, he corrected it twice, maybe it was correct?
[06:20:13] <alex_joni> petev: no, he corrected it on TRUNK and on the 2.1 branch
[06:20:28] <alex_joni> but as jmk said.. crap
[06:20:39] <petev> wishfull thinking
[06:29:48] <petev> jmkasunich, you still up?
[11:44:36] <jepler> jmkasunich: argh, I am the one who suggested backporting it--I didn't know it was wrong.
[12:58:11] <jepler> or that it wasn't through being tested, I should say
[13:16:55] <alex_joni> well.. it was only close to a week
[13:39:34] <cradek> I never fail to screw up each release in some minor but irritating way
[13:40:03] <SWPadnos> 100% success - we should have a party ;)
[13:54:19] <cradek> if ppmc index works now, I'll make another release - if it's only broken differently, I suppose there's no hurry
[14:05:36] <SWPLinux> hmmm. I seem to be having trouble getting RTAI to compile correctly
[14:05:46] <jepler> you're not the only one
[14:06:24] <SWPLinux> heh
[14:06:46] <SWPLinux> it compiled OK (apparently), but I can't run the testsuite
[14:07:41] <SWPLinux> it seems there's some cruft from a different compile sitting around, and make clean didn't get rid of it. I get several of this kind of error in dmesg:
[14:07:51] <SWPLinux> [ 1507.726469] rtai_hal: version magic '2.6.19.7-ipipe SMP preempt mod_unload ' should be '2.6.20.11-ipipe SMP mod_unload '
[14:08:27] <SWPLinux> nevermind - I found the problem
[14:08:52] <SWPLinux> duh. it helps to use the actual Linux source directory instead of /usr/src/linux, which doesn't always point to the right place
[14:09:10] <alex_joni> :-)
[14:09:36] <SWPLinux> argh!
[14:09:58] <SWPLinux> now I find that somehow, modversions is on in this kernel (even though the main reason for me rebuilding was to get rid of it!)
[14:42:21] <SWPadnos> well, isn't that a bummer
[14:42:37] <SWPadnos> I rebuilt the kernel without MODVERSIONS, and now it doesn't boot
[18:40:35] <SWPadnos> hey pete - I had a thought on that error plot you sent
[18:41:07] <petev> did you see something in the code?
[18:41:21] <SWPadnos> no, but I do have a question that I didn't spend enough time to answer
[18:41:29] <petev> ok, what?
[18:41:49] <SWPadnos> the pid.error isn't useful for ferror, since it's dependent on the new position output from motion
[18:42:26] <petev> I don't follow, both PID and motion calc error independently, but I think they should be the same
[18:42:26] <SWPadnos> it also occurred to me that the PID isn't all that useful when it's in the same thread as motion, unless motion is commanding a steady state
[18:42:33] <SWPadnos> no, they won't be
[18:42:39] <petev> why?
[18:43:00] <SWPadnos> at the end of the thread, the PID now has a new position command for input, so the error will be new_command-current
[18:43:33] <SWPadnos> rather than old_command-current, as the motion controller should be checking (that's the question I didn't find the answer to)
[18:43:59] <petev> why do you think motion is using old command and not new?
[18:44:15] <petev> I'm going to add the motion params and see if I can get another capture
[18:44:21] <SWPadnos> if it's possible to move more than ferror in a single traj cycle, then the motion controller has to use the old position for error checking, because it jus added more than ferror to the new position command
[18:44:57] <petev> hmm
[18:45:01] <SWPadnos> which is also why it isn't all that useful to have PID unless the position command remains the same for several PID calculation cycles
[18:45:19] <SWPadnos> it can't keep up, until the command pos steadies
[18:46:14] <petev> hmm, but PID is alwasy subtracting fb from cmd, so even if it's delayed a cycle, I would think you would have to see the large error
[18:46:52] <SWPadnos> it isn't delayed a cycle, it's delayed until later in the same cycle (for the purposes of computing PID output)
[18:46:54] <petev> if PID doesn't see the same error as motion, how can it be expected to use fb to reduce it?
[18:47:06] <SWPadnos> well, there's the problem ;)
[18:47:48] <SWPadnos> motion doesn't control the motor, it only asks "whtever it's connected to" to go to some position during the time between motion thread execution
[18:48:28] <SWPadnos> and it should only compare actual position "now" to the position is requested at time "now", which was actually requested the previous motion cycle
[18:48:40] <petev> I really don't like the idea or ferror being done in more than one place, but I assumed it had something to do with stepper setups
[18:49:11] <SWPadnos> since PID is in the same thread as motion, it has only the new commanded pos to work with (position expected next cycle), plus the current feedback
[18:49:50] <SWPadnos> which is good for getting the motor to the target, but should probably cause some extra overshoot (I think)
[18:50:06] <petev> I hear what your saying, but it seems like the PID error should always be greater in this case
[18:50:14] <petev> I really need to get the motion params on the trace
[18:50:19] <SWPadnos> in any case, that's why plotting pid.n.error ins't useful in finding out what the ferror limits are
[18:50:32] <SWPadnos> the PID error will be higher, until there's a reversal
[18:50:38] <petev> well I was testing PID auto tuning
[18:50:39] <SWPadnos> yep
[18:50:45] <petev> just happened to see it again
[18:50:46] <SWPadnos> how is that going, by the way?
[18:51:09] <petev> It looks good, but I'm not fully sure I understand all the behavior yet
[18:51:16] <petev> let's talk about a few things
[18:51:33] <petev> first, the period of the limit cycle is effected by the control effort
[18:51:57] <petev> this seems intuitive, as larger control efforts cause larger overshoot and a slower period
[18:51:59] <SWPadnos> I understood those words, but not in that sequence ;)
[18:52:11] <petev> control effort is the PID output
[18:52:38] <petev> the limit cycle is the oscillation that the auto-tune sets up to characterize the process (drives & motors)
[18:52:46] <SWPadnos> it was "period of the limit cycle" that didn't make sense to me :)
[18:52:49] <SWPadnos> ah - thanks
[18:53:27] <petev> so it seems like the PID can be tuned differently for different control efforts
[18:53:41] <petev> maybe this makes sense as it's optimized for a different step size
[18:53:50] <petev> but it seems a bit counter intuitive
[18:54:08] <SWPadnos> can you control the step size and/or frequency of the test signal?
[18:54:12] <petev> the step response from the auto-tune params looked pretty nice on hal scope
[18:54:13] <SWPadnos> externally
[18:54:24] <petev> the freq is always determined by the process
[18:54:33] <petev> you stimulate it, then see how it reacts
[18:54:58] <petev> the limit cycle keeps the stimulus 180 degree out of phase with the process response
[18:55:08] <SWPadnos> ah, ok
[18:55:12] <petev> you can set the control effort param for tuning
[18:55:49] <petev> at any rate, I think some more thought needs to be given to the whole algorithm as I'm not sure I understand the behavior totally
[18:55:55] <petev> next issue
[18:56:12] <petev> how can you do an auto-tune without making a special hal setup?
[18:56:14] <SWPadnos> I hardly understand the algorithm ;)
[18:56:24] <petev> this almost works as the auto-tune is built into the PID
[18:56:35] <petev> the problem comes with the fb to motion
[18:56:44] <petev> and getting back into PID mode after a tune
[18:56:53] <SWPadnos> well, if you have the tuning parameter/pin decide whether to take input from the "normal" pins or the tuning params, that could do it
[18:57:08] <petev> there is a tune-mode pin
[18:57:11] <SWPadnos> but you still want to disable output if a limit or other error occurs
[18:57:25] <petev> so you could use the signal to that to select a mux to motion
[18:57:30] <petev> but that seems ugle
[18:57:38] <petev> ugly
[18:58:06] <petev> also, you need to get back to cmd-pos before going back to PID mode, or there would be a pos step
[18:58:15] <petev> I'm not sure how to handle this gracefully
[18:58:29] <SWPadnos> actually, you don't need to deal with motion, except to tell it that the feedback is correct, so I think you'd need to run feedback through the PID (which gets circular and ugly due to thread execution order)
[18:58:50] <petev> the PID can switch back and forth no problem right now, but it's more of a question of how to keep motion happy
[18:59:28] <SWPadnos> hmmm. actually, all you need to do is disconnect the feedback from motion, then reconnect it once tuning is done (and the position has been restored)
[18:59:28] <petev> you could mux cmd-pos to fb for motion when tuning
[18:59:42] <petev> but how do you get back to PID mode gracefully?
[19:00:19] <SWPadnos> in the PID, when you go into tuning mode, save the accumulators (or just use a different set of them altogether)
[19:00:21] <petev> the pos after a tune may not be the same as before it started, it most likely won't be
[19:00:33] <petev> that's not the problem
[19:00:36] <SWPadnos> PID can make it be, since it controls where it gets its command from
[19:00:37] <petev> the PID can switch
[19:01:01] <SWPadnos> right, so you disconnect before tuning, and at the end you move back to the original position and reconnect the feedback
[19:01:04] <petev> it's that there is going to be a huge error (cmd-fb) after the tune finishes
[19:01:05] <SWPadnos> to motion
[19:01:18] <petev> yeah, that move part is the key word
[19:01:24] <petev> how do you do that gracefully?
[19:01:43] <petev> you can't just apply PID to it, as the error may be huge
[19:01:52] <petev> it's like having traj put out a huge step
[19:02:30] <SWPadnos> within the PID, you should be able to calculate some reasonable accel ramp, and apply that
[19:02:53] <petev> that is really putting a lot of junk in PID that doesn't belong there
[19:02:58] <jepler> make emc go into "machine off" state -- then it copies feedback into command\
[19:03:15] <petev> It would be nicer if you could just get motion to change the cmd-pos to the current pos
[19:03:21] <SWPadnos> in machine off, wouldn't servo amps be disabled?
[19:03:58] <SWPadnos> oops - gotta run. bbiab
[19:04:15] <petev> jepler, do you think it's safe to do that in from the GUI as part of the auto-tune, or would it be better to do it in hal?
[19:04:54] <petev> BTW, you want to add the GUI support for auto-tune? I don't think it's much, but my tcl sux
[19:04:56] <jepler> petev: I'm not sure how to make the emc go to "machine off" from HAL, except through halui
[19:05:14] <petev> right, or add some new pins to motion
[19:06:02] <petev> basically the at_pid has two new pins to control auto-tune
[19:06:08] <jepler> I can probably write a small GUI program to do it, and add it to the tkemc and axis menus.
[19:06:13] <petev> tune-mode to enter tuning mode
[19:06:21] <petev> and start-tune to start a tune cycle
[19:06:30] <petev> start-tune gets cleared when the cycle is done
[19:06:41] <petev> then the PID params need to be read back from PID
[19:07:08] <petev> the current emccalib script already sees the tuning params, but it doesn't re-read the PID params
[19:07:11] <jepler> does pid lie about its feedback position during the tune cycle?
[19:07:17] <petev> no
[19:07:26] <jepler> so emc will ferror pretty quickly
[19:07:30] <petev> I can add that, but I thought it a bad idea
[19:07:46] <petev> yes, but I use the tune-mode to bypass motion fb
[19:08:00] <petev> as motion doesn't take fb or error from PID
[19:08:09] <petev> it takes fb directly from the encoder
[19:08:21] <petev> so you have to mux cmd-pos to fb for motion
[19:08:32] <petev> during tune mode
[19:08:48] <jepler> er, ok
[19:08:52] <petev> this still seems a bit bad without hard limit switches
[19:08:54] <jepler> my question didn't make much sense then
[19:09:13] <petev> but I'm not sure how to fix it other than making motion aware of tuning operations
[19:09:58] <alex_joni> petev: how about running it completely separated from emc?
[19:10:23] <alex_joni> separate GUI and hal file
[19:10:37] <petev> I though about that, but it seems nicer to be able to use one hal setup, tune when you want, and have all the amp-enable control, limit checking, etc
[19:10:53] <alex_joni> it seems to me it's complicating things unneededly
[19:11:01] <cradek> I'm with alex
[19:11:10] <alex_joni> you don't tune from time to time just for fun..
[19:11:10] <petev> so what do you suggest?
[19:11:24] <alex_joni> separate GUI & HAL file just for tuning
[19:11:25] <jepler> does the problem get any simpler if it's not necessary to return from tuning mode to regular mode without restarting emc?
[19:11:37] <jepler> that way the tuning UI can also make changes to the HAL configuration that it doesn't necessarily undo
[19:11:46] <jepler> (the running HAL configuration, not .hal files)
[19:12:11] <petev> I thought it would be nice to tune, then back to emc, run some test g-code, track ferror, etc.
[19:12:25] <petev> it seems like a paing to have to keep switching configs to test results
[19:12:28] <petev> pain
[19:12:42] <alex_joni> jepler: I think it gets messy if emc needs to be aware of the tuning in progress
[19:13:09] <petev> alex_joni, how would you handle all the limits, etc. when tuning if totally separate?
[19:13:09] <alex_joni> petev: having 2 icons and running them in parallel.. doesn't seem like a big pain to me
[19:13:25] <petev> how would you run them in parallel?
[19:13:32] <alex_joni> I mean one after the other
[19:13:35] <petev> you would have to exit/restart emc a lot
[19:13:51] <alex_joni> petev: depending how well the autotuning works, yeah
[19:14:11] <alex_joni> ideally you do it only once..
[19:14:24] <alex_joni> is there any reason a new autotuning will bear different results?
[19:14:28] <petev> from what I have seen so far, it's pretty good, but it seems like you can optimize for different conditions
[19:14:44] <alex_joni> * alex_joni listens
[19:14:49] <petev> and it may not be clear what's best without itterative testing
[19:15:09] <petev> yes, if you change the control effor for the limit cycle
[19:15:21] <petev> and I'm not sure what the optimal control effort would be
[19:15:24] <jepler> seems like the autotuning UI can take care of setting emc to "machine off" mode before changing the feedback muxes back
[19:15:39] <petev> it's like tuning the PID for a different size step input
[19:16:14] <jepler> then the only "special" thing you need is these feedback muxes which I assume you've already worked out, petev
[19:16:33] <petev> jepler, that was straight forward, but ugly
[19:16:40] <petev> I just added hal muxes
[19:16:46] <petev> and used the tune-mode signal for control
[19:17:55] <petev> what about the case where a machine doesn't have limit switches?
[19:17:59] <jepler> tell me again why auto-tune can't be written so that the motor position is the same at the end
[19:18:26] <petev> the auto-tune sets up a limit cycle, basically oscillates the process (drive & motor)
[19:18:48] <petev> when the PID output goes back to 0, there is not gaurantee what the position is
[19:18:56] <petev> it's most likely not what you started with
[19:19:20] <petev> switching back to PID mode in that state is like a huge pos step from traj
[19:19:35] <petev> it may result is a saturated PID output
[19:19:40] <petev> and seems a bit ugly
[19:20:40] <petev> SWP suggested adding some code to move back to the cmd-pos, but that's like putting tp code in the PID
[19:20:54] <petev> I don't think it belongs there and it bloats the PID
[19:21:22] <petev> you could just let the PID deal with the large step, but it may abuse the machine a bit
[19:21:37] <petev> and you would have to keep emc from generating FE until the PID caught up
[19:24:16] <jepler> besides the amps turning off when you go into "machine off" state, what else makes running auto-tune in "machine off" problematic?
[19:24:33] <jepler> in "machine off" the command position will track feedback position, and you won't get a following-error message
[19:24:40] <petev> nothing other than the lack of limit input checking, etc.
[19:25:09] <petev> I was trying to get some of the protection motion provides by havning it active
[19:25:15] <petev> but maybe that was a bad idea
[19:25:31] <petev> maybe using machine off and adding amp-enable logic is a better choice
[19:25:56] <jepler> oh -- you want emc to stop the tuning if it walks onto a *soft* limit
[19:26:24] <petev> yeah, but the soft limits won;t work without making motion tuning aware
[19:26:35] <petev> but hard limits would at least still work in the current state
[19:27:19] <petev> I could add an amp-enable logic to the PID and route the enable from motion through the PID block, then PID could enable the amp when tuning
[19:27:38] <petev> maybe that's the best approach, but the operator needs to be VERY carefull
[19:30:34] <jepler> it won't be the only part of emc where the operator needs to be careful
[19:31:15] <petev> true, but he may not be aware that there are no limits in effect, maybe a huge waring in the GUI would suffice ;-)
[19:32:15] <jepler> another option is to have the tuning UI set the permitted following error to be very large
[19:32:21] <jepler> and reset it when done
[19:32:31] <jepler> (I think there are NML messages for that but I'm not certain)
[19:33:02] <petev> that might not be too bad, assuming the FE could be specifed from the GUI
[19:33:57] <petev> the cycles that I have run here seem to only require about 0.1" for good results, but I don't have the belts on yet
[19:34:01] <jepler> I just checked, there are EMC_AXIS_SET_FERROR and EMC_AXIS_SET_MIN_FERROR messages
[19:34:50] <jepler> and the current values are also in the stat buffer, so a program can set them back to the original value as well
[19:35:12] <petev> ok, I'm going to do some clean-up on the at_pid, then I'll make a special hal file for testing
[19:35:37] <petev> I'll add some safety checks and then I'll be ready to test with your new GUI ;-)
[19:35:46] <jepler> hah
[19:35:48] <jepler> it's not written yet
[19:35:57] <jepler> and I really should be doing the job I get paid to do right now
[19:36:02] <petev> can you just modify the ecmcalib.tcl?
[19:36:15] <petev> I don't think it's far off
[19:36:21] <petev> it already picks up the tuning params
[19:36:26] <petev> just needs the other logic
[19:36:35] <jepler> maybe, I'll sure consider that option when I get around to looking at it
[19:36:36] <petev> I hear you, I should be doing real work too
[21:51:51] <_petev> jmkasunich, u there?
[21:56:22] <_petev> I got a capture of PID vs mot FE and they are not even close to the same.
[21:56:24] <_petev> http://imagebin.org/8512
[21:56:54] <SWPadnos> same scope scaling on the two channels?
[21:57:03] <_petev> so something non-obvious is happening here and I don't see how PID can possibly correct for an error it doesn't see
[21:57:08] <_petev> yes, same scale
[21:58:06] <SWPadnos> I assume the order of operations is correct in the thread -inputs, motion, PID, outputs, with scope sampling done next to outputs?
[21:58:13] <_petev> they both have 0 offset as well
[21:58:17] <SWPadnos> ok
[21:58:51] <_petev> let me revied thread order, I have no idea where scope is as I launch it from the GUI
[21:59:03] <SWPadnos> I think it gets put at the end by default
[21:59:12] <SWPadnos> since it has no HAL outputs, that makes sense
[22:01:06] <_petev> does the -1/1 still work when using addf ?
[22:01:17] <SWPadnos> I believe so
[22:02:08] <_petev> even if it doesn't, the order should be fine for the funcs of concern
[22:02:30] <SWPadnos> I bet it is - all you need to show you is halcmd show thread
[22:02:46] <_petev> let me check it
[22:03:53] <_petev> its enc read, motion, pid, dac write, scope
[22:04:45] <SWPadnos> ok, that's good :)
[22:09:27] <_petev> I'm really starting to think we need to calc error in one place period
[22:09:32] <SWPadnos> hmmm. in that plot, the axis.2.f-error should go to 0 immediately once the ferror is triggered
[22:10:02] <_petev> yeah, I noticed that, but wasn't sure about it
[22:10:15] <SWPadnos> I don't think so, due to time granularity. PID moves the machine because motion creates a position error with the new command
[22:10:59] <_petev> yes, but the machine only moves based on the cmd pid sees, and FE should only be determined by the FE pid sees
[22:11:11] <SWPadnos> so, unless you restrict the machine to moving < FERROR per traj/PID cycle, you can't calc error in the PID (and use that for following error detection)
[22:11:26] <_petev> some other command somewhere else is just irrelavent to machine motion
[22:11:46] <_petev> hmm, that's a good point
[22:12:01] <_petev> and I think that case is definitely common
[22:12:11] <SWPadnos> I would hope so :)
[22:12:34] <SWPadnos> though it's interesting to note that the error can be greater between motion samples, and wouldn't be noticed ...
[22:12:55] <SWPadnos> you almost need a peak hold if you have faster PID than traj cycles
[22:13:09] <_petev> but something is certainly wrong with what I captured, as I don't see how PID can be expected to correct an error it doesn't even see
[22:14:20] <SWPadnos> well, I think there's a problem with what you captured because AFAIK f-error should immediately snap to 0 as soon as the machine errors out
[22:14:50] <_petev> well that is a param straight from axis
[22:14:55] <SWPadnos> since pos-cmd is set to pos-fb when the machine is not on (I think)
[22:15:21] <SWPadnos> you should be able to hit F2, crank a handwheel, then hit F2 again and not get a following error
[22:16:06] <_petev> I'm trying to think how any hal config issue could cause that, but I don't see how
[22:16:29] <_petev> the f-error param from axis should do as you say if cmd is set to fb
[22:16:37] <_petev> even if hal is foobar
[22:17:00] <SWPadnos> I don't know either, since I believe all the machine on/off is in motion (at least in that module), and so is all the feedback/command position stuff
[22:17:26] <_petev> BTW, this is latest head as of a little while age
[22:17:31] <_petev> ago
[22:17:32] <SWPadnos> ok
[22:17:45] <_petev> I have wifi now ;-)
[22:17:50] <SWPadnos> out of curiosity, is this pid or at_pid?
[22:17:51] <SWPadnos> nice :)
[22:18:31] <_petev> it was at_pid, but the PID part is the same. I'll make a capture with normal PID as I was getting the same thing
[22:18:31] <SWPadnos> you don't happen to have any Yaskawa SGDH-02B... AC servo drives kicking around, do you?
[22:18:50] <_petev> I think I have one, but it's a A model, not B
[22:18:53] <SWPadnos> ok - just curious. I figured the actual calcs / HAL outputs are the same
[22:18:58] <SWPadnos> bummer -A is 200V
[22:19:09] <_petev> what do you need, 100V ?
[22:19:13] <SWPadnos> yep
[22:19:17] <_petev> why?
[22:19:16] <SWPadnos> 100V, 200W
[22:19:25] <_petev> for the fest?
[22:19:26] <SWPadnos> I have the matching motor, and I want to make it spin ;)
[22:19:30] <SWPadnos> no, sooner
[22:19:40] <_petev> you can still use the 200V
[22:19:41] <SWPadnos> I haven't been able to find them too easily
[22:19:53] <_petev> you just set the V/rpm by motor type
[22:19:57] <SWPadnos> true, I guess the 200V / 400W one would be OK
[22:19:59] <_petev> I have a matching motor too
[22:20:09] <SWPadnos> hmmm - what power?
[22:20:33] <_petev> and most of the 200V will run off of 120V too, just like a 100V model
[22:20:41] <SWPadnos> cool
[22:20:58] <_petev> I have 1 200W and a few 400W motors I think
[22:21:03] <_petev> the 200W has a brake
[22:21:03] <SWPadnos> do you know off hand what protocol their absolute encoder talks?
[22:21:10] <_petev> the 400s don't
[22:21:14] <SWPadnos> ok, that's what I've got here
[22:21:17] <SWPadnos> the brake
[22:21:23] <_petev> it's proprietary onthe newer stuff
[22:21:27] <SWPadnos> figures
[22:21:35] <SWPadnos> it's a sigma II
[22:21:38] <_petev> the comm tracks are some serial stream on one channel
[22:21:44] <SWPadnos> with a firewire connector for the encoder
[22:21:56] <_petev> firewire?
[22:22:06] <SWPadnos> firewire connector, I don't think it's that protocol
[22:22:06] <_petev> mine have high density D-shells
[22:22:24] <SWPadnos> it's a great idea actually - high speed data, shielded 6-conductor cable
[22:22:35] <_petev> you can get the mating connectors from 3M from digikey, mouser, etc
[22:22:59] <_petev> yeah, and it means you have to use both their drives and motors
[22:23:08] <SWPadnos> hmmm. I'll keep looking around, but I may go for the -04A (400W 200V) model that's on eBay
[22:23:09] <SWPadnos> of course
[22:23:23] <_petev> what are they going for?
[22:23:26] <SWPadnos> and getting something equivalent new (motor + drive) is expensive as hell
[22:23:31] <_petev> how many do you need?
[22:23:36] <SWPadnos> a few hundred bucks each
[22:23:50] <_petev> the 400W setups I have are brand new, and I have encoder cables too
[22:23:53] <SWPadnos> I think 2 for now. (one smaller - like 50W)
[22:24:10] <SWPadnos> I'm trying to make a robot, and I have access to another robot for parts, but no drivers
[22:24:17] <_petev> I could sell you the 400W setups for $350/axis with the encoder cables
[22:24:27] <SWPadnos> and they work on 120AC?
[22:24:43] <_petev> I'll give you the 200W setup for less and connectors/pins so you can make anencoder cable for it
[22:24:59] <SWPadnos> is that 200W with motor + drive?
[22:25:00] <_petev> yes, they will work on 120V, but your motor rpm will be limited
[22:25:09] <_petev> yes
[22:25:09] <SWPadnos> I'm not too worried about RPM, I think
[22:25:26] <SWPadnos> cool. I'll let you know pretty soon (by the end of the week, I think)
[22:25:29] <_petev> I think they are 3500 rpm on 200V, so you should be able to get 1/2 that
[22:25:33] <_petev> ok
[22:25:43] <_petev> I'll email you specs later
[22:25:50] <SWPadnos> I think performance won't be critical for the demo, so no biggie on speed
[22:25:52] <SWPadnos> ok, great
[22:26:14] <_petev> I got a whole pile of stuff I collected for project ideas and haven;t had time or space to build
[22:26:18] <SWPadnos> I should probably ask JonE and Rayh also, they may have the exact model I need ;)
[22:26:19] <SWPadnos> heh
[22:26:31] <_petev> it's been sitting for too long, so I guess I don't really need them right now
[22:26:36] <SWPadnos> one thing - do your motors have the absolute encoders (with backup battery connection)?
[22:26:51] <_petev> the 200W does, the 400W don't
[22:27:01] <SWPadnos> the one I have has a 16-bit absolute encoder O_O
[22:27:16] <_petev> yeah, but do you really need that?
[22:27:22] <SWPadnos> gotta run for a conference call - see you later
[22:27:24] <SWPadnos> yes
[22:27:29] <_petev> ok