Back
[00:41:19] <jmkasunich> petev: I believe part of what you are seeing is transport delay
[00:42:00] <jmkasunich> when its not faulted, motion compares the position feedback (just sampled) with the command that it issued last time
[00:42:35] <jmkasunich> that makes perfect sense, it is testing how well the external control (PID, stepgen, whatever) did at making the actual match the command
[00:42:38] <petev> well how can pid be expected to correct an error it never sees?
[00:43:03] <petev> PID always compares the current cmd to current fb and never sees an error that large
[00:43:10] <petev> so pid seems to be doing it's job
[00:43:16] <petev> but motion has other ideas
[00:43:28] <jmkasunich> I disagree
[00:43:37] <petev> why?
[00:43:43] <jmkasunich> forget about PID for now
[00:43:46] <jmkasunich> read what I just wrote
[00:43:56] <jmkasunich> motion issues a command
[00:44:10] <jmkasunich> a millisecond later, it reads the feedback, and tests it against the old command
[00:44:35] <jmkasunich> that means PID or whatever has had 1mS to try to match the command
[00:44:48] <jmkasunich> for motion to do anything else would be wrong
[00:45:15] <jmkasunich> unless and until we can agree that motion is doing the ferror calc right, I don't want to talk about PID, it just muddies the issue
[00:45:21] <petev> so in the case I captured, PID is actually ahead of where it should be and closer to the current command?
[00:45:38] <jmkasunich> I have no clue, because I don't know what motion was happening
[00:45:56] <petev> the PID error was less than the motion error
[00:46:00] <jmkasunich> in general, PID will show a larger error than ferror
[00:46:08] <petev> that's what I would expect
[00:46:12] <jmkasunich> but you aren't listening to me
[00:46:17] <petev> but here it was reversed
[00:46:26] <jmkasunich> I DO NOT not want to talk about what you saw, or about PID
[00:46:40] <petev> I am listening, I'm just having a hard time understanding how what I saw happened
[00:46:42] <jmkasunich> I want to come to an agreement that the ferror calc IN MOTION is correct, or not
[00:47:05] <petev> I think that depends on the exact thread order, so lets review that first
[00:47:53] <petev> what thread order did you intend? enc, mot, pid, dac?
[00:48:01] <jmkasunich> read encoders (or whatever feedback), run motion, which does the ferror calc early on, and later issues a new pos cmd, then run PID (or whatever motor control), then write the result of that to hardware
[00:48:08] <jmkasunich> yes
[00:49:30] <jmkasunich> lets go on an talk about the pid error
[00:49:35] <petev> in that case the mot behavior seems like it should be reasonable to compare fb to last cmd
[00:49:59] <jmkasunich> assume the machine has been sitting for a while with constant command, and PID has managed to do its job perfectly
[00:50:06] <petev> ok
[00:50:12] <jmkasunich> fb = cmd, both ferror and piderror = 0.00000
[00:50:30] <jmkasunich> now motion commands a position change of 0.001
[00:50:48] <jmkasunich> in the same cycle, PID sees that command, and calcs a pid error of 0.001
[00:50:54] <petev> right
[00:51:04] <jmkasunich> it starts doing its thing, and it may or may not (probably not) correct that error
[00:51:24] <jmkasunich> only in the next run does motion check the feedback against the new command
[00:51:37] <jmkasunich> pid sees the error first
[00:51:41] <petev> against the prev cmd?
[00:51:45] <jmkasunich> right
[00:51:53] <petev> ok, I follow that
[00:52:09] <jmkasunich> now you have this screwy waveform
[00:52:14] <jmkasunich> and we gotta figure it out
[00:52:14] <petev> right
[00:52:29] <petev> BTW, I think it happened on a decel
[00:52:38] <jmkasunich> I hope this is reproducable, because you almost certainly don't have the right stuff on halscope
[00:52:52] <petev> yes, I can get more traces
[00:52:58] <jmkasunich> do you know which way it was moving?
[00:53:02] <jmkasunich> positive or negative?
[00:53:05] <petev> the f-error limit in motion looked good
[00:53:18] <jmkasunich> I sure hope so, that code is trivial
[00:53:21] <petev> why does that matter?
[00:53:31] <petev> I'm pretty sure it was a decel
[00:53:35] <jmkasunich> we're trying to understand this scope trace
[00:53:39] <petev> and was moving neg
[00:53:42] <petev> but not sure on the dir
[00:53:53] <jmkasunich> huh?
[00:54:02] <jmkasunich> "was moving neg", that is the direction
[00:54:05] <petev> not sure whether the dir was pos or neg
[00:54:10] <petev> right
[00:54:23] <petev> I'm prety sure it was a decel, but not sure the dir
[00:54:29] <jmkasunich> ok
[00:54:32] <petev> it was part of a home sequence
[00:54:34] <jmkasunich> that makes things harder
[00:54:49] <jmkasunich> initially the pid error is negative
[00:55:16] <jmkasunich> we don't know if that means you were moving negative, and PID was ahead of the command (overshoot maybe?) or if you were moving positive and PID was lagging
[00:55:31] <jmkasunich> its really hard to reconstruct what was happening without such fundamental info
[00:55:35] <petev> let me look at the ini and see if I can determine
[00:56:16] <jmkasunich> the ferror lim signal is offscale, right?
[00:56:25] <petev> ok, HOME_OFFSET is 0.050 and HOME is 0
[00:56:44] <jmkasunich> unless you know what phase of homing it was in, not sure that helps
[00:56:51] <petev> SEARCH_VEL is 0.5 and LATCH_VEL is -0.05
[00:56:59] <jmkasunich> using index?
[00:57:07] <petev> I'm almost positive it was the last move after finding the index
[00:57:20] <petev> but I didn't have the home state on the trace
[00:57:24] <jmkasunich> so its only moving 0.050 inches?
[00:57:29] <jmkasunich> that won't take long
[00:57:30] <petev> yes
[00:57:56] <jmkasunich> lets assume it was the last move
[00:58:02] <petev> ok
[00:58:21] <petev> so it should be a neg move
[00:58:33] <jmkasunich> I gotta look at the home pic, I always get home and home-offset mixed up
[00:58:50] <petev> I think home_offset is the position of the switch
[00:58:56] <petev> home is where you want to end up
[00:59:06] <jmkasunich> sounds right, and thats what I was thinking
[00:59:12] <jmkasunich> but I want to check, won't take long
[00:59:17] <petev> ok
[00:59:38] <jmkasunich> yes, thats it
[00:59:52] <jmkasunich> so, its moving negative
[00:59:56] <petev> right
[01:00:28] <jmkasunich> error is cmd - fb
[01:00:35] <petev> that makes sense as pid error is neg
[01:00:45] <jmkasunich> so a lag would produce negative error
[01:00:46] <petev> then swings pos on the decel
[01:00:52] <petev> right
[01:01:26] <jmkasunich> do you have non-zero FF1 ?
[01:01:33] <petev> FF1 = 1
[01:02:13] <jmkasunich> are you at the EMC machine now? or elsewhere?
[01:02:28] <petev> no, in the house, it's onver 100 degree in the shop right now
[01:02:34] <petev> it was hot today
[01:02:35] <jmkasunich> we're speculating based on too little data, when the right thing to do is gather more data
[01:02:50] <petev> ok, what more info do you want to see?
[01:03:09] <jmkasunich> do you still have ddt blocks looking at the command?
[01:03:15] <petev> yes
[01:03:38] <jmkasunich> commanded velocity would be a good one, so we know which way its moving, whether its acceling, cruising, or decelling
[01:03:55] <petev> ok, what else>
[01:03:57] <petev> ?
[01:04:09] <jmkasunich> also set the trigger position near the end of the screen, rather than the beginning
[01:04:24] <petev> sure
[01:04:49] <jmkasunich> ideally motor-pos-cmd and motor-pos-fb feedback, but they may be large numbers, hard to see small changes
[01:05:21] <jmkasunich> there is also some math between motor-pos-cmd/fb and joint-pos-cmd/fb
[01:05:31] <petev> yeah, they are very large compared to the error signals and the offsets are a pain to setup
[01:05:42] <jmkasunich> although I believe it just adds an offset to command and subtracts the same offset from fb
[01:06:20] <petev> I will try and capture them
[01:06:28] <petev> it should cool down in a couple hours
[01:06:32] <jmkasunich> the joint-pos values should be close to zero, maybe they would be a better choice
[01:06:56] <jmkasunich> in a couple of hours I'm gonna be in bed - business trip tomorrow, gotta get up at 5ish
[01:07:01] <jmkasunich> 2 hours is 11pm here
[01:07:08] <petev> that's early
[01:07:20] <jmkasunich> not when I have to get up at 5 its not
[01:07:32] <petev> I meant 5ish ;-)
[01:07:37] <jmkasunich> oh
[01:07:40] <petev> but so is 11 pm ;-)
[01:07:47] <jmkasunich> yeah, it is... I don't like travel
[01:08:15] <petev> will you have email access on the road?
[01:08:20] <jmkasunich> I think my hotel will have internet, and I have an ubuntu VM on my laptop, so I _might_ be online tomorrow evening
[01:08:29] <petev> ok
[01:08:41] <petev> I'll capture some more data in the mean time
[01:08:45] <jmkasunich> during the day, no - I might be jacked into the corporate net, but I'll be occupied in meetings all day
[01:08:56] <petev> ok
[01:09:02] <petev> let's talk about the auto-tune
[01:09:23] <jmkasunich> I saw that discussion from eariler
[01:09:27] <petev> did you read any of the earlier discussion on the algo?
[01:09:29] <jmkasunich> and I wanted to scream
[01:09:43] <petev> forget the EMC part, we can discuss that later
[01:09:53] <jmkasunich> why in gods name do you want to have EMC running while tuning?
[01:09:55] <petev> which part did you object to?
[01:10:10] <petev> just wanted the limit checking of motion
[01:10:24] <petev> and to be able to quickly test results, etc.
[01:10:46] <jmkasunich> how is EMC at all usefull for checking results?
[01:10:51] <petev> without it, you would have to re-do all the limit checking, amp faults, e-stop, etc.
[01:11:07] <petev> so after you tune you could run some g-code test and check FE
[01:11:37] <jmkasunich> using g-code to provide a test stimulus seems rather awkward to me, but to each his own I guess
[01:11:58] <petev> ok, let's talk about the algo
[01:12:16] <petev> it sets up a limit cycle osc in the process
[01:12:23] <petev> then checks the amp and period
[01:12:27] <jmkasunich> maybe its because I'm a drives guy, but I can't imagine having a higher level control system active and enabled until the low level (drive+motor combo) works right
[01:12:40] <petev> from that it calcs PID
[01:12:47] <jmkasunich> please clarify "limit cycle", you've used that term a lot
[01:13:03] <petev> basically you apply a control effort to the process
[01:13:24] <petev> every time the process crosses the set point, the control effort is flipped 180 degree
[01:13:31] <jmkasunich> does that mean you command some positive DAC value until position crosses a threshold, then go to a negative DAC value until it crosses going the other way?
[01:13:33] <petev> so it's always out of phase with the process
[01:13:45] <jmkasunich> control effort is a fancy word for DAC?
[01:13:53] <jmkasunich> IOW, the PID is not active during this?
[01:13:55] <petev> yes, so the period is determined by the process as well as the amplitude
[01:13:59] <petev> correct
[01:14:22] <petev> no, control effort is what the process control guys call the input to the process
[01:14:30] <petev> in our case it's the DAC output
[01:14:37] <jmkasunich> so a fast system will have a fast and low amplitude oscillation, a laggy high inertia one will have a large slow oscillation
[01:14:44] <petev> yes
[01:15:02] <petev> and there are several formulas for coverting this to PID
[01:15:17] <petev> I just used the way old and simple zeigler-nichols
[01:15:30] <petev> but here's where it seems a bit non intuitive
[01:15:43] <petev> the ultimtimate gain and period are used to calc PID
[01:15:47] <jmkasunich> I'm not a mathematically competent control guy, I'm more seat of the pants, so please have patience with me as I put this into what is basically laymans terms
[01:16:00] <petev> ok
[01:16:04] <jmkasunich> your drive is in velocity mode
[01:16:21] <petev> yes, but I think it's somewhat irrelavant
[01:16:34] <jmkasunich> so if you send "0.1 ips" to the dac, you expect the drive to go to 0.1 ips, and the position to ramp at that rate
[01:16:58] <petev> yes, at least as fast as the motor can get to 0.1 ips
[01:17:07] <petev> and then it may overshoot too
[01:17:12] <jmkasunich> what is relavant here isn't the distance that it moves, but how long it takes to get to 0.1 ips
[01:17:27] <petev> the two are realated
[01:17:34] <petev> I think you have to think higher level
[01:17:38] <petev> you have a set point
[01:17:42] <petev> you have a process
[01:17:45] <jmkasunich> stop
[01:17:55] <jmkasunich> you are not being precise enough
[01:18:04] <petev> why?
[01:18:05] <jmkasunich> position setpoint? velocity setpoint?
[01:18:26] <petev> in our case the setpoint is pos as is the fb
[01:18:38] <jmkasunich> this would be much easier face to face where we could draw pictures, you gotta take into account the limitation of the communication channel (IRC)
[01:19:07] <jmkasunich> for the PID, the cmd and fb are position, yes
[01:19:13] <petev> so PID has a pos setpoint and pos fb and applies some control effort to the process
[01:19:19] <jmkasunich> for the "plant", the cmd and fb are velocity
[01:19:34] <petev> the plant?
[01:19:35] <jmkasunich> (because the drive is part of the plant)
[01:19:38] <jmkasunich> the process
[01:19:42] <petev> right
[01:19:52] <jmkasunich> our control guys often use "plant"
[01:19:56] <petev> but I don't think it really matter what the input to the plant is
[01:20:06] <petev> all that matters is how the plant reacts to it
[01:20:20] <petev> so it could be vel, pos, torque or whatever
[01:20:37] <petev> maybe I'm wrong here, but that's what I'm thinking
[01:20:59] <petev> so before I ran the algo and got results
[01:21:04] <jmkasunich> the tuning (and maybe even the approach) will be different if its vel vs torque
[01:21:42] <jmkasunich> it changes the order of the system
[01:22:03] <petev> I don't realy follow what you mean
[01:22:26] <petev> as long as the setpoint and fb are the same metric, why does the control effor matter?
[01:22:42] <jmkasunich> if the command is torque, then accel will be proportional to dac output, velocity will be the integral of dac, and pos will be the double integral of dac
[01:22:54] <petev> sure
[01:22:55] <jmkasunich> if its velocity, then pos will be the single integral of dac
[01:23:04] <petev> but all that matters is the pos response to the dac output
[01:23:19] <jmkasunich> one is first order, one is second, drastically different phase shifts, etc
[01:23:39] <petev> yes, but all that matter is the response
[01:24:12] <jmkasunich> pos = dac*t^2, vs pos = dac*t - different responses
[01:24:23] <petev> right
[01:24:48] <petev> so if you just look at the response, why do you have to be concerned with what the control effor is?
[01:25:19] <jmkasunich> my gut tells me that an algorithm that works when response = cmd * t^2 isn't going to be appropriate when response = command * t
[01:25:42] <petev> why not look at it as a black box
[01:25:51] <petev> and you just want to determine the xfer func
[01:25:58] <petev> you don't care what's inside
[01:26:13] <jmkasunich> ok
[01:26:18] <petev> I did look at severl commercial PID controllers and didn't see any special modes for different types of effort
[01:26:33] <petev> I could be wrong, so don't rule it out, but lets proceed
[01:26:46] <jmkasunich> you looked at autotuning ones?
[01:26:50] <petev> yes
[01:26:59] <jmkasunich> ok, lets proceed
[01:27:05] <petev> ok
[01:27:32] <petev> so before I got any data, I expected the period to pretty much be the same with different control effort
[01:27:40] <jmkasunich> you are basically applying a square wave stimulus
[01:27:49] <petev> the PID is calc from ultimate gain/period
[01:27:55] <jmkasunich> amplitude determined by you? and frequency by the system
[01:28:01] <petev> the ultimate period is just the measured period
[01:28:21] <petev> the ultimate gain is a ratio of control effor to measured amp
[01:28:36] <petev> the amp is also somewhat dtermined by the system
[01:28:39] <jmkasunich> what are ultimate gain and ultimate period?
[01:28:49] <petev> those are the inputs to calc PID
[01:29:09] <petev> they are basically related to per and amp as I just described
[01:29:24] <jmkasunich> lets back up
[01:29:29] <petev> ok
[01:29:37] <jmkasunich> you said amplitude was also somewhat determined by the system
[01:29:38] <jmkasunich> how?
[01:29:58] <jmkasunich> I mean stimulus amplitude, aka control effort, not result amplitude
[01:30:05] <petev> the controll effor is flipped every time the process crosses the setpoint
[01:30:25] <petev> so the ampltitude of the response is also process dependent
[01:30:26] <jmkasunich> its flipped from +youpickedit to -youpickedit
[01:30:32] <jmkasunich> how is that amplitude system dependent?
[01:30:55] <SWPadnos> the feedback swing amplitude is system dependent
[01:30:57] <jmkasunich> that amplitude of the RESPONSE is system dependent, yes
[01:31:01] <petev> a slow process will not get as far, before the control effor is flipped
[01:31:05] <jmkasunich> I HATE IRC
[01:31:08] <SWPadnos> heh
[01:31:14] <jmkasunich> thats what I've been saying for the past 5 minutes
[01:31:19] <petev> yes, the amp of the the response (the process)
[01:31:27] <jmkasunich> stimulus amplitude is set by you
[01:31:36] <petev> the amp of the control effor (the auto tune) is picked by the user
[01:32:02] <jmkasunich> and I bet you get different resulting frequency for different effort
[01:32:04] <petev> both the process and the control effort effect the response amp
[01:32:08] <petev> yes
[01:32:28] <petev> so the ultimate gain is a ration of control effor and response amp
[01:32:32] <petev> so that make some sense
[01:32:47] <petev> but the I and D are completely determined from the response period alone
[01:32:58] <jmkasunich> except that the period isn't constant
[01:33:04] <petev> so depending on the control effort you get different results
[01:33:09] <jmkasunich> exactly
[01:33:17] <petev> here's the interesting part
[01:33:28] <jmkasunich> therefore I can't see how you can get the right I and D from this
[01:33:31] <petev> it may be that I'm just using raw motors so the response changes a lot
[01:33:54] <petev> but I get numbers quite far apart but they all seem to work very well
[01:34:15] <jmkasunich> you mean when you change the tuning effort?
[01:34:37] <petev> changing the tuning effort creates different PID values
[01:34:46] <petev> I can take the resulting PID and stimulate with a fixed square wave and the respone is very good
[01:34:53] <petev> it's almost time optimal
[01:34:54] <jmkasunich> how far apart? 2:1?, 4:1? 10:1?
[01:35:00] <petev> with one overshoot and no ringing
[01:35:09] <petev> so far about 2:1
[01:35:11] <petev> on P
[01:35:23] <jmkasunich> what about I & D?
[01:35:45] <petev> I and D are coming out small, so I have to look to see the ratio, I can't remember off the top of my head
[01:35:57] <petev> but I can tell you the period seems to vary quite a bit
[01:36:14] <petev> the larger control effort results in a slower oscillation of larger amp
[01:36:16] <jmkasunich> I is much smaller than P? like 10 times smaller or less?
[01:36:31] <petev> much smaller than that
[01:36:39] <petev> hang on and I'll get a set of numbers
[01:37:28] <petev> here's approx values P=100, I=0.0128, D=0.0032
[01:37:37] <jmkasunich> zoiks
[01:37:42] <petev> yes
[01:37:53] <jmkasunich> this is with dac scaled to ips, and commands in inches?
[01:38:13] <petev> but the system response is only slightly slower than the manual values and it has none of the hig freq oscillations that the manual values had
[01:38:19] <petev> yes
[01:38:29] <jmkasunich> do you have FF?
[01:38:42] <petev> FF1=1, but not during tuning
[01:38:48] <petev> PID is off during tuning
[01:39:01] <petev> and when I test with the square wave
[01:39:08] <jmkasunich> when you say "the system response is only slightly slower than the manual values" do you have FF on or off?
[01:39:12] <petev> test the PID result that is
[01:39:24] <petev> FF is off for testing results
[01:39:31] <jmkasunich> thats remarkable
[01:39:40] <petev> yes, very strange
[01:39:42] <jmkasunich> what happens when you grab the shaft and try to turn it?
[01:39:54] <petev> as I had much larger I and D was about 0.45
[01:40:07] <petev> I think P was in the same range
[01:40:16] <SWPadnos> hmmm. I'd think that a tuning effort equal to the max change in position in one period (based on the max vel) would be a good number to pick
[01:40:22] <petev> the noticable diff was in the overshoot
[01:40:26] <jmkasunich> what happens when you grab the shaft and try to turn it?
[01:40:29] <petev> I manaully tuned for no overshoot
[01:40:36] <jmkasunich> what happens when you grab the shaft and try to turn it?
[01:40:43] <SWPadnos> echo echo response
[01:40:43] <petev> it's very stiff
[01:41:03] <SWPadnos> that's going to be almost entirely P, so if P is close, they should be the same
[01:41:12] <petev> the tune cycle actually runs for several oscillations and takes an average for accuracy
[01:41:14] <SWPadnos> (aut vs manual tuning)
[01:41:54] <jmkasunich> maybe the reason this isn't matching my intuitition is the presence of a digital drive with encoder feedback and a velocity loop
[01:42:02] <petev> so my whole point was this did not seem intuitive to me, it was not what I expected
[01:42:12] <jmkasunich> if you force the DAC to zero, I bet its _still_ stiff when you try to turn the shaft by hand
[01:42:14] <SWPadnos> heh -matching intuitions, it seems
[01:42:22] <petev> could be, or maybe having no load on the motors is also a factor
[01:42:26] <SWPadnos> petev, have you tried tuning with the drive in torque mode?
[01:42:32] <petev> hell no
[01:42:35] <jmkasunich> well, the "grab it and turn" is a load on the motor
[01:42:40] <SWPadnos> well, what are you waiting for?
[01:42:52] <jmkasunich> the temperature to drop
[01:42:53] <petev> yes, but I wasn't holding it while tuning ;-)
[01:43:00] <SWPadnos> heh - chicken
[01:43:10] <petev> it's over 100 deg in the shopt right now
[01:43:18] <petev> was about 103 earlier today
[01:43:21] <petev> I was melting
[01:43:24] <SWPadnos> ouch
[01:43:34] <SWPadnos> only got to ~75 here, very nice (for a change)
[01:43:48] <jmkasunich> bout the same here
[01:43:55] <jmkasunich> anyway, back to PID
[01:43:56] <petev> one of you guys want to try the auto tune on your system and see what kind of results you get?
[01:44:04] <jmkasunich> I don't have servos
[01:44:16] <petev> you need to get some ;-)
[01:44:52] <jmkasunich> too many projects, too little time
[01:44:57] <jmkasunich> I do have some small motors with encoders
[01:44:58] <petev> I hear you
[01:45:08] <jmkasunich> they need '298 class drivers
[01:45:09] <SWPadnos> if only I had a motor (*any* motor) connected to a PC ...
[01:45:32] <petev> what's wrong with your baldors?
[01:45:46] <SWPadnos> they aren't connectable to a PC ;)
[01:45:55] <jmkasunich> however, even if I had drivers for my motors, they would be so far different from your case it would be meaningless
[01:45:59] <petev> why not? what have you been doing?
[01:46:08] <SWPadnos> I probably could with the USC relatively soon
[01:46:25] <jmkasunich> you have a digital speed loop, I would have an H bridge, not even torque control, just voltage control
[01:46:29] <SWPadnos> I dunno - trying to drum up business, traveling ...
[01:46:51] <SWPadnos> actually, having totally different hardware would be very menaingful
[01:46:56] <petev> yeah, all I have is digital drives
[01:47:08] <SWPadnos> the idea is to check the algorithm in as many situations as possible to be sure it works
[01:47:13] <petev> I would really like to see the results on another system
[01:47:29] <jmkasunich> are you coming to the workshop?
[01:47:37] <cradek> when I get my lathe back together I can try it there. I'm actively working on it so it will be one of these days.
[01:47:38] <petev> no, not going to be able to make it
[01:47:42] <petev> got plans with the kids
[01:47:58] <jmkasunich> bummer
[01:48:05] <jmkasunich> cradek will have his servo lathe there
[01:48:10] <petev> nice
[01:48:15] <cradek> assuming it's working...
[01:48:23] <jmkasunich> what happened?
[01:48:33] <cradek> I decided to improve it, now it doesn't work at all
[01:48:40] <jmkasunich> oops
[01:48:46] <jmkasunich> what did you break
[01:48:46] <cradek> you know how it goes
[01:48:57] <cradek> I want to use the pluto for pwm and counting
[01:49:10] <cradek> instead of the dumb divider scheme (which worked ok)
[01:49:27] <SWPadnos> hmmm. does jepler still have the etch-servo together? :)
[01:49:53] <SWPadnos> that would be about as different from pete's hardware as you can get
[01:49:57] <cradek> I could hook it back up with the dumb driver too. I'll try to keep it together in case we want to try it
[01:51:18] <petev> jmkasunich, I was thinking of adding a second order IIR filter block to HAL, do you think it would be usefull?
[01:51:32] <jmkasunich> sure
[01:51:38] <jmkasunich> I've thought about that before
[01:51:39] <petev> I can write some code to calc filter coeff too for various notch, low pass, etc.
[01:51:51] <petev> but I'll need someone to put it in a GUI
[01:52:03] <jmkasunich> 2nd order isn't very high is it?
[01:52:16] <petev> it can produce quite steep notches
[01:52:28] <petev> I don't think any higer order would be needed
[01:52:44] <jmkasunich> maybe I'm thinking of FIR as needing much higher order to be usefull
[01:52:47] <petev> it's easy enough to cascade if necessary
[01:53:31] <jmkasunich> do you have EMC installed on the pc you are typing on right now?
[01:53:44] <petev> no, on a doze box
[01:53:47] <jmkasunich> (I want you to see a manpage, if not I'll find it online)
[01:53:50] <petev> but I have another test box
[01:54:56] <jmkasunich> http://www.linuxcnc.org/docs/devel/html/man/man9/lowpass.9.html
[01:55:09] <jmkasunich> what order is that? (I believe it is an IIR)
[01:55:33] <jmkasunich> the equation is right there....
[01:55:45] <petev> you could get approx 12db/octave out of a 2nd order low pass, but it depends on the filter response
[01:56:05] <jmkasunich> lowpass.9 is a first order?
[01:56:11] <petev> like an elliptical would have steep initial roll off, but oscillations in the stop band
[01:56:28] <jmkasunich> oh, now he's talking about poles and zeros...
[01:56:34] <petev> right
[01:56:38] <jmkasunich> bessel!
[01:56:41] <petev> yes
[01:56:46] <jmkasunich> phase linear, nice for control
[01:56:54] <jmkasunich> shitty rolloff tho
[01:56:55] <petev> you can do all the same in digital as analog ;-)
[01:57:09] <petev> phase linear would be FIR
[01:57:09] <jmkasunich> I've never been good with the math in either realm
[01:57:21] <petev> can't do it with IIR
[01:57:32] <jmkasunich> bessel is pretty close (at least in the passband)
[01:57:36] <petev> but it will introduce group delay
[01:57:35] <jepler> the etch cnc is not "put together" right now
[01:57:58] <SWPadnos> jepler, do you have any servos and things to drive them with (controlled from a PC, of course)?
[01:59:59] <jepler> I'll take a look at the etch cnc stuff .. but I think I had ruined some of the poorly-soldered encoder wires after the last fest, and never fixed it
[02:00:10] <SWPadnos> ah, ok
[02:00:32] <SWPadnos> I'm digging around to see how much needs to be done to connecta motor to a gecko here. I should know in a little bit
[02:00:36] <petev> crap, it's still 90 deg outside
[02:01:05] <SWPadnos> on a somewhat separate note, anyone have any idea why disabling module versioning would cause a kernel to not be able to boot?
[02:01:19] <SWPadnos> leaving everything else the same with that config
[02:02:58] <cradek> SWPadnos: what exactly is "not be able to boot"
[02:03:12] <SWPadnos> Kernel Panic: tried to kill init!
[02:03:15] <SWPadnos> or similar
[02:03:31] <cradek> hmm, so not the usual thing about not finding the root fs
[02:03:38] <SWPadnos> I can (not) boot it up and see the exact message
[02:04:10] <SWPadnos> well, there was another message before that about not being able to find /dev/console
[02:04:16] <cradek> did you package it, or install it and make an initrd yourself?
[02:05:03] <SWPadnos> self made initrd (just like the modversions one that worked, but a separate initrd, of course)
[02:05:28] <jmkasunich> I have these servos, but nothing to drive them with:
http://jmkasunich.dyndns.org/pics/tapelibservos.jpg
[02:05:31] <SWPadnos> I found a page that mentioned some ACPI / APIC things to try, and tried ne of the three with no success
[02:05:32] <cradek> so make modules_install; make install; mkinitramfs ... 2.6.that.version
[02:05:47] <jmkasunich> is anybody gonna have a spare 298 board?
[02:05:52] <SWPadnos> mkinitrd that_version, but yes otherwise
[02:06:08] <SWPadnos> no make install - manually copied bzImage and System.map to /boot
[02:06:39] <cradek> you told grub about the initrd?
[02:07:08] <SWPadnos> yes, I cleverly overwrote the modversions one that had worked ;)
[02:07:10] <cradek> jmkasunich: with what for reading encoders?
[02:07:24] <jmkasunich> I dunno
[02:07:35] <jmkasunich> I'll be bringing my 5i20s and breakouts
[02:07:36] <cradek> jmkasunich: I could make you one - I think I offered way back when, but you said you were too busy to build it and didn't want me to waste my time
[02:07:46] <jmkasunich> that could read encoders and make PWM
[02:08:02] <cradek> I have a 7iXX minus which is all you'd need to play except obscure connectors
[02:08:04] <jmkasunich> (using the old driver if I don't get off my ass and get the new one finished by then)
[02:08:07] <cradek> -minus
[02:08:14] <petev> what is it?
[02:08:21] <SWPadnos> this is the thread that had the APIC/ACPI suggestions:
https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/70774
[02:08:23] <cradek> the quad H bridge and encoder receivers
[02:08:29] <jmkasunich> petev: what is what?
[02:08:40] <petev> the machine you linked pic too
[02:08:51] <SWPadnos> tape library robot?
[02:08:53] <jmkasunich> its the mechanism from an old tape library
[02:09:01] <jmkasunich> held about 10 tapes and one drive
[02:09:16] <petev> so you aren't making it into anything yet?
[02:09:34] <jmkasunich> no, its a toy
[02:09:49] <jmkasunich> its only about 12" on the long axis, less than 4 on the short, and rated to hold maybe a half-pound
[02:09:58] <cradek> it's a plotter!
[02:10:06] <petev> how did it run servos without encoders?
[02:10:13] <jmkasunich> there are encoders there
[02:10:19] <jmkasunich> on the backs of the motors
[02:10:25] <jmkasunich> 512 CPR I believe
[02:10:39] <petev> ac or dc motors?
[02:10:43] <jmkasunich> DC brush
[02:10:53] <petev> so why not get the mesa H bridge?
[02:11:10] <jmkasunich> you gotta be kidding, do you really think a tape library would use AC servos?
[02:11:16] <SWPadnos> didn't you get a Mesa H-bridge?
[02:11:19] <jmkasunich> because I'm cheap
[02:11:20] <jmkasunich> no,
[02:11:27] <petev> I didn't see any brushes
[02:11:29] <SWPadnos> because you're cheap
[02:11:31] <SWPadnos> :)
[02:11:32] <jmkasunich> at least I don't think so
[02:11:42] <petev> I bet you could get one free for all the driver work
[02:11:48] <petev> they aren't that much retail
[02:11:51] <jmkasunich> heh, actually, I did get the H bridge
[02:11:55] <SWPadnos> 7iheh
[02:12:04] <jmkasunich> 7I30-4
[02:12:14] <petev> so hook it up
[02:12:18] <petev> all you need is a supply
[02:12:19] <SWPadnos> only 1 though
[02:12:22] <petev> maybe a lab supply?
[02:12:51] <jmkasunich> I have a bench supply, and a pile of various lambda's and such (open frame supplies)
[02:13:15] <jmkasunich> I'll try to get it working by fest time
[02:14:19] <jmkasunich> I think that thing should be good for some pretty nice rapids
[02:14:51] <petev> nice to have something to play with that you don't care if it breaks
[02:15:14] <jmkasunich> nice to have something to play with thats small enough that its hard to break it
[02:15:23] <petev> that too
[02:15:32] <petev> and probably won't hurt you ;-)
[02:15:34] <jmkasunich> I certainly care if I let the smoke out of either the motors or the H bridge
[02:16:02] <jmkasunich> just cause I pulled the motors out of the dumpster doesn't mean I can go there tomorrow and get more
[02:18:32] <jmkasunich> there was something I was gonna do, and now I forgot what it was
[02:23:03] <jmkasunich> I remember!
[02:23:19] <jmkasunich> configs/servo_sim has PID and simulated motors
[02:23:34] <petev> going to sim an auto tune?
[02:23:44] <jmkasunich> no, just look at ferror and such
[02:23:49] <petev> ahh
[02:23:51] <jmkasunich> (for now)
[02:24:16] <SWPadnos> actually, you should be able to sim autotuning of differnet order systems (though I'm not sure exactly what the setups would be atm)
[02:24:44] <jmkasunich> right now, PID output goes thru a scale block (ips to revs/sec), then a lowpass, then to a sim-encoder's speed input
[02:25:04] <jmkasunich> so it kinda simulates a drive with a velocity loop, and with some inertia or other lag in that loop
[02:25:14] <SWPadnos> right - you could stick an integrator in there somewhere to roughly simulate torque mode
[02:25:28] <petev> a motor is an integrator
[02:25:49] <SWPadnos> maybe with a decay or offset value or something so you still need nonzero output to get motion
[02:25:52] <jmkasunich> motor integrates speed to make position, sim-servo has that already
[02:26:16] <SWPadnos> the sim-encoder is an integrator as well, but for torque mode sim, you need two of them
[02:27:04] <jepler> can't find all the parts of etch servo .. oh well
[02:27:17] <SWPadnos> oh well - thanks for looking
[02:43:42] <jmkasunich> I'm jealous of Dean
[02:44:03] <jmkasunich> I get old tape libraries, he gets a PC board router
[02:44:13] <petev> in the dumpster?
[02:44:19] <jmkasunich> yep
[02:44:24] <petev> nice score
[02:44:24] <jmkasunich> (mail on users list)
[02:44:32] <jmkasunich> 60000 rpm spindle
[02:44:36] <petev> wow
[02:44:43] <petev> at least you got something
[02:44:53] <petev> I have never found anything decent out here
[02:45:06] <jmkasunich> you don't work for a big company do you?
[02:45:11] <SWPadnos> I can usually find rotting food and worms
[02:45:12] <petev> I think it all ends up at triangle ;-)
[02:45:32] <jmkasunich> SWPadnos: you don't work at a big company either
[02:45:43] <SWPadnos> no, definitely not :)
[02:46:07] <SWPadnos> I think my best find was an 8-foot or so section of 200-pair (or so) telephone cable
[02:46:32] <jmkasunich> lifetime supply of 24AWG solid hookup wire, eh?
[02:46:38] <SWPadnos> indeed
[02:46:42] <SWPadnos> I think it got thrown out though :(
[02:46:47] <SWPadnos> again
[02:47:35] <jmkasunich> hmm, you bport guys might be interested in the cables I snagged
[02:47:51] <SWPadnos> mic connectors?
[02:47:52] <jmkasunich> 6 conductor, 16 AWG, nice crud-proof connectors
[02:47:52] <SWPadnos> mil
[02:48:02] <jmkasunich> pic coming soon
[02:48:07] <SWPadnos> cool. what kind of conn - err, thanks :)
[02:49:29] <SWPadnos> I know my motors have a single MS connector for motor, tach, and encoder
[02:49:37] <SWPadnos> the servo cables are expensive as hell
[02:50:00] <SWPadnos> the connectors are also expensive as hell (more than I paid for the motors)
[02:50:04] <jmkasunich> if your motor already has connectors, its a safe bet these won't fit
[02:50:14] <SWPadnos> I know they won't, if they're 6-pin
[02:50:36] <SWPadnos> they aren't firewire-shape, are they?
[02:50:56] <jmkasunich> no, they're industrial duty
[02:51:10] <jmkasunich> sensor cables I think, but I don't know why so heavy
[02:51:13] <SWPadnos> ok. the Yaskawas motor I have has a firewire-shaped clocking connector for the encoder
[02:51:16] <jmkasunich> 16AWG is fat wire
[02:51:24] <SWPadnos> yeah, that's big for sensors
[02:52:44] <jmkasunich> http://jmkasunich.dyndns.org/pics/P1010001.JPG
[02:52:48] <jmkasunich> I'm too lazy to rename
[02:53:51] <jmkasunich> http://jmkasunich.dyndns.org/pics/P1010002.JPG
[02:53:55] <SWPadnos> interesting
[02:54:54] <jmkasunich> http://jmkasunich.dyndns.org/pics/P1010003.JPG
[02:55:24] <jmkasunich> the bad news is that each half is only about two feet long
[02:55:45] <jmkasunich> the good news is that if you can use 4ft from point A to point B, they are nice cables
[02:55:50] <SWPadnos> heh
[02:56:22] <jmkasunich> very flexible, uv, water, and oil resistant, 600V rated
[02:56:29] <jmkasunich> and I have about 50 mated pairs
[02:56:40] <SWPadnos> wow - that's great
[02:56:56] <jmkasunich> I'll be bringing a bunch to the fest I think
[02:56:57] <SWPadnos> I wonder where to get the matching connector though, in case an extension is needed
[02:57:20] <jmkasunich> not sure
[02:59:29] <jmkasunich> I'm gonna use a few pairs on my machine, to connect things that I want to be able to remove
[02:59:47] <jmkasunich> millhead to main part of machine, saddle to control, that kind of thing
[03:00:01] <jmkasunich> color code them so I don't plug them wrong
[03:00:16] <jmkasunich> they'll be nice for my 6A steppers
[03:00:49] <jmkasunich> you could use 3 conductors in parallel for LARGE DC servos
[03:00:59] <SWPadnos> those connectors look familiar, but I can't quite place them
[03:01:00] <jmkasunich> and the connector makes it easy to remove the motor if you have to
[03:01:14] <SWPadnos> they're almost like lockable AT keyboard connectors
[03:01:19] <SWPadnos> with an extra pin
[03:01:50] <jmkasunich> except heavier (pin size, and general construction) and sealed
[03:02:16] <SWPadnos> right, heavy duty sealed lockable high current 6-pin AT keyboard connectors ;)
[03:03:16] <jmkasunich> it doesn't jump out at you in pic2, but one pin is longer than the others, probably for grounding
[03:05:30] <jmkasunich> hmm, looks a lot like this, but with one more pin: tp://www.amci.com/rotary-encoders/images/devicenet-connector.gif
[03:12:03] <jmkasunich> getting closer:
http://literature.rockwellautomation.com/idc/groups/literature/documents/ca/889n-ca503_-en-p.pdf
[03:13:27] <SWPadnos> hmmm
[03:15:35] <SWPadnos> similar:
http://rocky.digikey.com/WebLib/Switchcraft/Web%20Photos/EN3C6M.jpg
[03:16:06] <SWPadnos> http://rocky.digikey.com/WebLib/Switchcraft/Web%20Photos/EN3C6F.jpg
[03:16:26] <jmkasunich> similar, but no cigar
[03:16:29] <jmkasunich> the pins are too thin
[03:16:56] <SWPadnos> ah - right
[03:17:01] <jmkasunich> and the polarization rib on these is more squared off
[03:17:13] <SWPadnos> there were several other kinds, but I was too lazy to look at all of them
[03:17:37] <jmkasunich> I'm certain its the device net family
[03:18:08] <jmkasunich> it seems the network cables use one 5 pin config, and the power cables use another, but both are based on the same 6 pin connector with one missing pin
[03:18:30] <SWPadnos> http://www.tpcwire.com/tpc/TOfnetBODY.html
[03:20:17] <jmkasunich> yep
[03:20:58] <jmkasunich> you could mate those 5 pins plugs with these 6 pin sockets, but not vice-versa (obviously)
[03:21:20] <jmkasunich> http://www.tpcwire.com/tpc/pdf/12_TrOxDevicenet_6.pdf#page=9
[03:21:33] <jmkasunich> the pic matches, pin diameter, even the one long pin
[03:21:38] <SWPadnos> yep - I just didn't want to link the PDF :)
[03:21:53] <jmkasunich> why not?
[03:25:06] <SWPadnos> no particular reason
[03:25:29] <SWPadnos> ok, I can finally boot and use gnome again on the Opteron. I think it's bedtime
[03:25:41] <SWPadnos> see you later
[03:26:10] <jmkasunich> I need to sleep too, catching a plane in the morning
[03:26:19] <SWPadnos> yep - early :)
[07:22:11] <alex_joni> oki :">
[07:22:33] <alex_joni> hrmm.. wrong window
[12:41:57] <SWPadnos> hi folks
[12:42:19] <rayh> Hi Steven
[12:42:49] <SWPadnos> hi Ray
[12:45:38] <skunkworks> so you guys have the auto-tuning all figured out then ;)
[12:46:27] <SWPadnos> of course
[12:46:31] <SWPadnos> pete does :)
[12:47:00] <SWPadnos> hey Ray - do you have any servos around (that you can drive with EMC)?
[12:47:13] <skunkworks> I can throw this out.. In my situation - I think I have to use emc as the current limiting.. As there is none in the amps.. yet. So I don't know what will happen sending it a square wave. if that made sense.
[12:47:15] <rayh> sure.
[12:47:28] <rayh> full servo feedback, gecko, rutex
[12:47:48] <SWPadnos> skunkworks, you can't current limit with EMC, since you have no current feedback (and it's a Bad Thing anyway)
[12:48:30] <SWPadnos> rayh, ok. if you can read back through the conversation on auto-tuning PID, it may be a good thing for you to do some testing
[12:48:38] <SWPadnos> (in your copious spare time :) )
[12:48:40] <skunkworks> never said it was good.. I am limiting it by accelleration and top speed. I know it isn't going to be the best solution.
[12:49:31] <rayh> I'm a real skeptic when it comes to autotune.
[12:49:32] <SWPadnos> skunkworks, you *may* be able to do something that approaches current limiting within EMC, if you set the maximum PDM pulse width based on speed
[12:49:58] <SWPadnos> rayh, apparently it was working pretty well. the only tester so far has been pete though, with a smart drive from AB
[12:50:15] <rayh> So I probably should test it, eh.
[12:50:35] <SWPadnos> jmk was wondering if the method would work for torque mode as well as vel mode (which is what pete used)
[12:50:45] <SWPadnos> yes, the more the merrier
[12:51:21] <alex_joni> skunkworks: you won't be sending a square wave to the motor
[12:51:34] <alex_joni> you're sending a square wave to the pwmgen
[12:51:38] <skunkworks> right
[12:51:43] <alex_joni> and it's a small square wave
[12:51:50] <skunkworks> ah - ok
[12:52:18] <skunkworks> It should have pretty good peak current ability.. so maybe it isn't a problem
[12:53:37] <skunkworks> I probably should read back. I dipped out early while you guys where talking.
[12:55:35] <SWPadnos> rayh, I thought one of the more interesting comments pete made was that the PID numbers he got were dependent on the "effort
[12:55:53] <SWPadnos> he used to tune, but that all the results worked very wel
[12:55:58] <SWPadnos> l
[13:00:20] <rayh> Okay. Sounds like something I'll have to do someday.
[13:01:12] <rayh> Perhaps it's something we'll have to try on the Mazak at fest.
[13:01:21] <rayh> That should be a pretty good test.
[13:29:01] <SWPadnos> indeed it should
[13:29:20] <SWPadnos> rayh, one more question: do you have any Yaskawa AC servo drives around?
[13:39:07] <rayh> No I don't.
[13:39:17] <SWPadnos> ok. thanks (that makes two of us :) )
[13:40:10] <rayh> I saw their name on something very recently but I can't remember what.
[13:40:19] <SWPadnos> IRC logs? ;)
[13:41:10] <rayh> Nah. A device laying around one of the places I visited.
[13:41:17] <SWPadnos> heh - ok
[13:41:38] <rayh> Oh. Beijing machine tool show.
[13:41:46] <SWPadnos> I have a motor from a Yaskawa robot, and I'd like to make it spin. too bad it's an AC motor with a special type of absolute encoder
[13:43:11] <rayh> that's an odd combination.
[13:43:34] <rayh> I could see absolute on an axis but on a motor?
[13:43:40] <SWPadnos> I actuall yneed the absolute encoder for my application (and the brake), but it makes sense that Yaskawa would use their own motors in their robots
[13:43:43] <rayh> That is really a single use thing.
[13:44:21] <SWPadnos> the main thing is that it needs to track position during power-off (or at least know where it is when powered up)
[13:47:52] <SWPadnos> gotta run - bbl
[13:47:58] <rayh> Sure. That is a good use for absolute positioning devices..
[13:48:02] <rayh> see you.
[18:27:32] <skunkworks> this dual processor seems to have ovl-max of around 30000
[18:28:13] <skunkworks> 33000
[18:28:32] <skunkworks> dual pentium III 1ghz
[18:29:44] <cradek> huh, mine is about 12000
[18:29:57] <skunkworks> yexk
[18:29:57] <cradek> (5000 with a cpu isolated)
[18:30:10] <skunkworks> odd
[18:30:27] <skunkworks> my dual 800 at home does better.. but not that good.
[18:31:35] <cradek> wow look at that entry move
http://imagebin.org/8507
[18:31:53] <cradek> I guess it's calculated "automatically"
[18:32:35] <jepler> the dotted green is the path taken, and the blue/magenta is the path given?
[18:32:42] <cradek> yes I think so
[18:33:10] <skunkworks> this is the motherboard
http://www.msicomputer.com/product/detail_spec/694D_Pro2.htm
[18:33:12] <jepler> I'm having trouble convincing myself it's right
[18:33:46] <jepler> this is part of the "why don't you just change it so concave corners are OK" discussion?
[18:33:59] <cradek> it crosses the programmed path about perpendicular, hard to see how that could be "right"
[18:34:02] <cradek> yeah
[18:34:16] <cradek> mach apparently allows it in some cases
[18:34:35] <cradek> although to me it looks like it curves in inappropriately - hard to tell from the one dot though.
[18:34:59] <SWPadnos> it sure looks like there's an inward curve on the second to last move
[18:46:17] <cradek> this wouldn't be so hard if we didn't have Z moves with comp on
[18:51:18] <SWPadnos> what about Z moves complicates things?
[18:51:46] <cradek> it takes more than adjacent segments to see the concavity of the corner
[18:52:00] <SWPadnos> hmmm
[18:52:39] <SWPadnos> why is that? if comp only affects XY offsets, then Z moves are (should be) immaterial
[18:52:57] <cradek> to cut up to a concave corner, you have to calculate that endpoint
[18:53:09] <cradek> without Z moves in the corner, you can do that by considering just the adjacent segments
[18:53:12] <SWPadnos> ah - unless you're talking about moving in XY, then in Z, then in XY again
[18:53:16] <cradek> right
[18:53:29] <cradek> into the corner, up and down a hundred times, then into the next corner
[18:53:41] <SWPadnos> I think that's just part of the generic problem of needing more than one segment of lokoahead
[18:53:50] <SWPadnos> lookahead too
[18:54:54] <cradek> heh this reminds me - I found the manual for the old maxnc software
[18:55:13] <cradek> for cutter comp, it says "you must be very careful to not confuse the software when using cutter comp"
[18:55:31] <SWPadnos> heh
[18:55:40] <cradek> it says if you confuse it, it can do wildly wrong things
[18:55:52] <cradek> (paraphrase)
[18:56:04] <cradek> at least we have error checking for the cases we can't handle
[19:08:34] <skunkworks> cradek: nice machine limits in axis :)
[19:08:54] <cradek> glad you like it
[19:09:33] <skunkworks> Now I can't think outside the box ;)
[19:10:03] <cradek> well you sure can't cut outside the box
[19:10:21] <skunkworks> * skunkworks wonders what it does for pumakins..
[19:10:40] <cradek> something wildly wrong
[19:10:49] <cradek> limits are all screwy in general
[19:10:53] <skunkworks> ;)
[19:17:59] <SWPadnos> it would be cool to run joint linits through kins to get an accurate boundary set
[19:18:02] <SWPadnos> limits
[19:19:01] <cradek> I don't see at first how you could do that
[19:19:03] <SWPadnos> but for 8 possible joints, you have 3^8 combinations to check (at minumum - endpoints + midpoint on each axis)
[19:19:51] <SWPadnos> I don't know how to get the a priori knowledge of what poses are invalid though
[19:19:53] <cradek> if you could do it, you could end up with a very complex shape
[19:19:57] <SWPadnos> indeed
[19:24:38] <skunkworks> we need to be able to model tombstones in the axis preview :)
[19:24:41] <jepler> you need to check more than endpoints and midpoint
[19:25:08] <jepler> imagine that i have a scara-type robot but I set the limit for joint 0 (the rotary joint at the base) to -360, 360.
[19:25:37] <jepler> with your method you'd check for J[0] = -360, 0, 360 -- but those lead to the same cartesian coordinates
[19:26:21] <SWPadnos> sure - that's an absolute minimum
[19:26:41] <SWPadnos> you could use some other logic for rotary joints - like using 4 quadrants
[19:26:46] <SWPadnos> (within limits)
[19:26:57] <SWPadnos> or 8 octants, actually
