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