Back
[00:26:00] <skunkworks> this is just tuning pid -
http://www.electronicsam.com/images/KandT/servostart/followingmore.png
[00:26:41] <skunkworks> 100ipm the steady state folloing error is around .0008
[00:29:59] <skunkworks> berry is now home - the drained the abases and also pulled a few teeth.
[00:30:05] <skunkworks> he is a bit out of it.
[00:31:48] <skunkworks> abscess
[00:56:17] <skunkworks> This is strait out of the at_pid with an effort of 30. less effort makes it a bit more squirely.
[00:56:21] <skunkworks> http://www.electronicsam.com/images/KandT/servostart/followingatpid.png
[01:37:43] <skunkworks> and this is what happens when I add -25 ff0
http://www.electronicsam.com/images/KandT/servostart/ferrorff0.png
[01:39:52] <skunkworks> and it is correct both directions. (ferror looks the same both directions)
[01:39:55] <skunkworks> go figure
[02:11:14] <jmkasunich> hi guys
[02:11:23] <jmkasunich> cradek: why not just reduce the jog-scale by a factor of 4?
[02:11:59] <jmkasunich> skunkworks: hope berry wakes up feeling better
[02:17:41] <jtr> skunkworks: sorry to hear about berry, hope he gets better soon. Once we brought missy home on the day she had surgery - at one point she got paranoid and tried to go after our other cat. We spent the night separated from the rest of the household.
[02:18:28] <jtr> We never brought her home again on the same day of surgery.
[03:16:44] <SWPadnos_> SWPadnos_ is now known as SWPadnos
[04:50:52] <cradek> jmkasunich: because it's coming from axis and matches what's shown on the screen - but you're right, I can use a scale block there
[04:51:29] <cradek> does the canon encoder interface require or suggest (or neither) an x4 switch?
[08:54:50] <dmwaters> {global notice} Good day all, In about 15 minutes to half an hour i'm going to begin maintenence on a few servers. About 5000 total users will be affected by this and this should not take long at all. I will give any further information in wallops, /mode your_nick w if you wish to see any further info.
[12:21:51] <jepler> the good news is that I think I have the watchdog implemented and working -- running the driver on sim, you can see the LED is not perfectly steady
[12:21:53] <jepler> the bad news is that I seem to have broken quadrature
[12:22:02] <jepler> or else my new quadrature test mode doesn't work
[12:23:02] <jepler> * jepler goes to work
[12:28:59] <skunkworks> Barry was in good form this morning. We made a bit of fun about his bald spot. :) He was cruising and rolling around.
[12:29:19] <cradek> yay
[12:29:38] <cradek> you think he had toothaches?
[12:30:18] <skunkworks> The vet was pretty sure.. The teeth they removed had very large holes in them.
[12:30:33] <skunkworks> at the gum line.
[12:31:17] <skunkworks> do you brush your kittys teeth?
[12:31:57] <cradek> are you serious?
[12:32:02] <skunkworks> (vet said it wouldn't have helped)
[12:32:12] <skunkworks> just wondering ;)
[12:35:29] <skunkworks> gave him the pain medicine this morning. also his antibiotic.
[12:36:17] <cradek> ah, everyone is happier with pain medicine
[12:36:32] <skunkworks> exactly :)
[12:36:46] <skunkworks> did you see the halscope pictures I had posted?
[12:36:48] <cradek> nope
[12:37:31] <skunkworks> http://www.electronicsam.com/images/KandT/servostart/followingmore.png
[12:37:37] <skunkworks> manually tuning
[12:37:40] <skunkworks> just pid
[12:38:04] <skunkworks> auto tuned pid
http://www.electronicsam.com/images/KandT/servostart/followingatpid.png
[12:38:38] <skunkworks> adding a -25 ff0
http://www.electronicsam.com/images/KandT/servostart/ferrorff0.png
[12:38:58] <skunkworks> go figure
[12:39:12] <cradek> hmm
[12:39:34] <cradek> if you move a long way from zero I bet ff0 breaks it instead of helping
[12:39:53] <cradek> your first picture looks very workable
[12:40:08] <skunkworks> yah - the at makes it a bit jittery.
[12:40:28] <cradek> first use ff1 to bring the cruise down around zero, then ff2 will balance the accels to zero
[12:40:38] <skunkworks> but what moves the steady state error at 100ipm down? Nothing other than ff0 seems to effect it.
[12:40:47] <cradek> ff1 will
[12:40:52] <skunkworks> ah - so ff1 should do it.
[12:40:56] <cradek> yes
[12:41:10] <skunkworks> I will play some more. (had a sick kitty last night) ;)
[12:41:18] <jepler> excuses excuses
[12:41:23] <skunkworks> Hi jepler
[12:41:23] <cradek> make sure ff* is hooked up to the right things in the hal file...
[12:41:44] <cradek> bbl
[12:41:48] <skunkworks> it looks like it is. I checked it the other day.
[12:46:02] <jepler> for ff1=1 to be the right setting, the output's interpretation must be "user units per second" -- is the scaling on pid and/or pluto set so that this is true?
[12:46:32] <skunkworks> No - That was my next thing to do.
[12:46:58] <skunkworks> I am sure it isn't as I just added my scale to the lathe_pluto
[12:47:02] <skunkworks> config
[12:47:20] <skunkworks> Another project for tonight.
[12:47:51] <skunkworks> So ff1 is just 1 or 0?
[12:48:02] <jepler> no, it can be any number
[12:48:06] <skunkworks> ok
[12:48:15] <jepler> it's a float
[12:48:48] <skunkworks> I thought so - but so far I have only seen it set to 1 or 0 ;)
[12:48:53] <jepler> but the common way to do it is to set up units so that PID output is approximately "user units per second" and FF1=1 (at_pid and lathe-pluto both do this)
[12:49:41] <skunkworks> right - and I changed the ini file a bit to work with inches - so I don't think I changed everything I needed to.
[12:50:08] <skunkworks> I will go thru it again.
[12:51:05] <skunkworks> so for me - it should be setup so the output of the pid should be in inches per second?
[12:52:42] <skunkworks> (I think right now it is set to motor voltage) or that is what I understood.
[12:54:35] <jepler> yeah -- you should set it up so that if the pid output / pluto pwm input is about 1.67 then you get a velocity of 1.67 in/sec = 100 in/min
[12:54:48] <jepler> "pid output or pluto pwm input", not "divided by"
[13:05:28] <skunkworks> one more time - So I get the pid output so it is in inches/sec. Then I assume there is scaling in the pluto pwm so i can adjust it so 1.67 in is aprox whatever pwm out I need to be for 100ipm?
[13:05:57] <skunkworks> * skunkworks goes and looks at the hal file :)
[13:31:04] <jepler> yes
[13:31:27] <jepler> to put it another way, you could just hook 1.67 up to pluto pwm in, and change scale until velocity reads 1.67 as well -- this works fine as long as you can rotate the motor indefinitely
[13:32:32] <skunkworks> which I can right now :)
[13:32:53] <jepler> right
[13:33:36] <skunkworks> did I tell you guys how cool emc is?
[13:39:20] <jepler> maybe once
[14:14:54] <alex_joni> nah.. not really :)
[14:17:45] <skunkworks> ;)
[15:10:48] <skunkworks> so - what units would ff1 be in - I mean if everything is scalled right - should I be able to put in .0008 as ff1 and it should be close to what I want? or is this going to be a trial and error thing?
[15:19:36] <jepler> ff1=1
[15:21:07] <jepler> with all other terms all zero, a change of B/sec on the input gives an output of FF1*B
[15:21:29] <jepler> by making the scale of the output give "1 user unit per second", that makes the value FF1=1 the one you want
[15:26:41] <skunkworks> ok - thanks
[16:01:55] <dmwaters> {global notice} Good day all. It appears we had a bit of routing trouble with one of our european hubs, I've rerouted around it for now, so we'll see how well it behaves.:) Thank you for your patience, and thank you for using freenode!
[19:08:41] <alex_joni> hi guys
[19:09:56] <jepler> hi alex
[19:21:01] <alex_joni> what's up?
[19:25:10] <skunkworks> I am fighting with pid tuning and losing ;)
[19:25:25] <skunkworks> How is your project coming?
[19:27:12] <alex_joni> badly
[19:29:14] <skunkworks> not enough torque?
[19:32:59] <alex_joni> not enot enough time
[19:33:59] <skunkworks> :) know what you mean
[20:04:59] <skunkworks> about 200 views each of the figid tapping videos
[20:09:04] <skunkworks> or rigid
[20:14:40] <alex_joni> good night all
[20:17:05] <skunkworks> night ales
[20:17:07] <skunkworks> alex
[20:54:41] <jepler> hm -- I think that due to the way it's written, missing index pulses can make a pluto encoder go nuts until reset
[20:54:43] <jepler> until restart, I mean
[20:55:05] <jepler> I wonder what to do about it..
[20:56:50] <skunkworks> ah - overruns the counter?
[20:57:28] <jepler> yeah
[20:58:21] <skunkworks> sounds like a 'don't do that' sort of thing ;)
[20:58:48] <jepler> for a 4000-count encoder, index pulses happen at 0, 4000, 8000, ...
[20:58:55] <jepler> but if the one at 4000 is missing, the sequence goes 0, 8000, 12000, ...
[20:59:33] <skunkworks> instead of index, 0, 4000, index, 0, 4000
[20:59:36] <jepler> but the "extension" code fails for a difference of 8000
[20:59:38] <skunkworks> ?
[21:00:30] <jepler> setp pluto-servo.encoder.0.scale 4096
[21:00:35] <jepler> oops
[21:00:38] <jepler> my cat can paste
[21:00:48] <skunkworks> nice. spart cat
[21:00:55] <skunkworks> or smart anyways
[21:01:49] <jepler> what the pluto board sends to emc is a pair of values: [latest # counts, # counts at last index pulse] -- or rather, it sends part of the number, like the last 4 digits
[21:02:41] <jepler> you follow a rule to get the full number based on (A) the last number you had and (B) the low digits of the new number: if the last digit used to be a 9 and now it's a zero, it rolled over so you have to add 10,000; if it was a zero and now it's 9, it rolled over the other way and you have to subtract 10,000
[21:03:07] <jepler> now this works fine if the successive numbers are never more than 1000 apart
[21:03:53] <jepler> but if I tell you 8000 and then 2000, the method I outlined above doesn't work
[21:04:05] <jepler> (they're either 4000 apart or 6000 apart)
[21:04:15] <jepler> is any of this making sense?
[21:04:28] <skunkworks> a bit.
[21:04:31] <jepler> anyway, that's where the rule that there can only be some maximum number of counts between index pulses comes from
[21:06:43] <jepler> actually I think I know what the solution is
[21:07:21] <jepler> I just need to convince myself that it's right
[21:07:23] <skunkworks> I am glad you do.. I wasn't going to be any help. I was wondering how much extra time it takes just to send the whole number.
[21:07:44] <jepler> it's not just extra time -- it takes more FPGA resources to track a 32 bit number than a 16 bit number
[21:07:53] <skunkworks> ah
[21:08:09] <skunkworks> that makes sense
[21:09:24] <jepler> then let me describe my solution in lay terms
[21:10:20] <jepler> like I said earlier, I transmit the last digits of two numbers: last counts, and counts at last index
[21:11:11] <jepler> "counts" are varying slowly enough that you can follow the method given enough to keep track of the high digits by the method I gave above
[21:11:38] <jepler> oh wait I just saw the problem with my suggestion -- forget it
[21:11:53] <jepler> I guess I'll go back to demanding that all index pulses must be successfully seen by pluto
[21:12:20] <skunkworks> I have no problem with that. If you miss an index - you have other problems..
[21:12:31] <jepler> it's just that the behavior is so weird after this problem
[21:12:48] <jepler> e.g., the counts start looping between 72000 and 76000 instead of between 0 and 4000
[21:13:13] <jepler> when index-enable is turned on
[21:13:45] <SWPadnos> hmmm. so the driver is "manually" subtracting a turns count from the overall count when in index-enable mode?
[21:14:43] <jepler> if(encoder_index_enable(i) && index != data.last_index[i]) {
[21:14:43] <jepler> encoder_index_enable(i) = 0;
[21:14:43] <jepler> data.reset_count[i] = index;
[21:14:49] <jepler> yes something like that
[21:15:23] <SWPadnos> and the output is something like data.count-data.reset count ?
[21:15:55] <jepler> it keeps track of "counts since power on" and "counts at last index"; when "counts since last index" changes (index != data.last_index[i]) and index-enable is TRUE, then the new number to subtract is 'index'
[21:16:05] <jepler> encoder_count(i) = count - data.reset_count[i];
[21:17:10] <SWPadnos> I don't know that a change in "count since index" a reliable method of detecting an index pulse
[21:17:37] <jepler> er, when "counts at last index" changes
[21:17:47] <SWPadnos> that's what I meant
[21:17:58] <jepler> oh I see what you're getting at
[21:17:59] <SWPadnos> what if the motor turns at a rate that gives the same value
[21:18:15] <SWPadnos> once in a while ...
[21:18:16] <jepler> that's not what I thought you meant
[21:18:31] <jepler> I thought you meant: turn just past index .. then reverse
[21:18:48] <SWPadnos> that may be a problem as well
[21:19:08] <SWPadnos> though both counters should count up then down in synchrony
[21:20:39] <jepler> when rotating one way, "counts at last index pulse" will always be different: 0, 4000, 8000, 12000, ...
[21:20:44] <jepler> so the first thing you said is not a problem
[21:21:00] <jepler> the second thing is, if the index pulse is so narrow to happen on the same count going both directions
[21:21:16] <SWPadnos> ah - overall counts at last index, I get it
[21:21:17] <jepler> 3999 .. 4000 ... 4001 ... 4000 ... 3999
[21:21:51] <SWPadnos> but you need to transmit the entire number for the counts at last index value
[21:22:33] <SWPadnos> err - hold on. let me reread that
[21:23:20] <jepler> as long as the index pulses are close enough, the same number extension method will work as for counts
[21:24:02] <jepler> .. and as long as no index pulses are lost
[21:24:59] <SWPadnos> or as long as the total count since the last detected index doesn't overflow
[21:25:53] <jepler> yes, if you have a small-count encoder it might be robust against a small number of lost index pulses
[21:27:28] <jepler> huh, the "index track" has a strange appearance -- why isn't it a single black region, instead of having a white (clear?) stripe in the middle?
http://www.usdigital.com/products/em1-heds/graphics/em1-mechanical-alignment-disk-hires.gif
[21:27:59] <skunkworks> so - if it misses and index - (and there is enough count headroom) the driver knows that is has missed an index and acts acordingly?
[21:28:26] <skunkworks> or it doesn't care and resets at the next read index
[21:28:47] <jepler> the driver doesn't treat that case specially, but it just turns out to work
[21:29:52] <skunkworks> I wonder if it has some sort of circutry so that it is less effected by noise. (it sees the double lines as one)
[21:30:54] <skunkworks> circuitry
[21:31:28] <skunkworks> bbl
[21:32:06] <SWPadnos> that is an interesting pattern
[21:32:19] <SWPadnos> one part is a full quadrature phase, the other is half
[21:32:36] <SWPadnos> but I don't know why they do it that way
[21:33:35] <jepler> argh I hate websites that force you into their frameset
[21:33:51] <jepler> http://www.usdigital.com/products/em1-heds/index.shtml click on "Encoding Characteristics" -- any idea what "(degree)E" means?
[21:34:33] <jepler> aha One Electrical Degree (°e): 1/360th of one cycle.
