Back
[00:31:08] <jepler> there are two things that we might want specifying a maxaccel or maxvel to do: first, it might mean that all profiles that fit inside the maxaccel/maxvel profile are accepted unmodified. second, it might mean that ones outside the profile are modified to stay within the profile
[00:31:30] <jepler> we wish we could have both, but our best programming efforts don't seem to have let us get it
[00:31:45] <jepler> these profiles generated by motion seem to meet the maxaccel and maxvel constraints, and yet stepgen modifies the profile
[00:32:28] <jepler> we could "solve" this by saying that when you set maxaccel=1.00 that you're going to guarantee that any profile which fits inside abs(maxaccel) <= 1.00 will not be modified, even if the consequence is that some just outside it are not modified either
[00:34:33] <jepler> (or else find and fix the bug in the free planner that is making it plan outside the specified envelope; as far as I know, we don't think that bug exists)
[00:43:40] <SWPadnos> I'm not sure, but the stepgen "bug" could be that it introduces a phase lag
[00:44:29] <SWPadnos> PID may also overshoot, but the PID output probably has headroom already, since it's not generally set with the maxaccel/maxvel values
[00:44:57] <SWPadnos> ie, the max_output setting for the PID, which in many cases is effectively maxvel, *is* manually set by the user
[00:45:09] <SWPadnos> separately from maxvel
[01:11:59] <jmkasunich> are we talking about software generated steps, or 5i20 steps?
[01:12:35] <SWPadnos> both
[01:12:39] <SWPadnos> they both need headroom
[01:12:55] <jmkasunich> true
[01:13:02] <SWPadnos> it may not be fair to generalize though, since they now both use the same positioning algorithm
[01:13:07] <jmkasunich> but I believe accel, not vel, is the critical one
[01:13:14] <SWPadnos> the main difference is the frequency generator "underneath"
[01:13:34] <jmkasunich> for some value of "now" - is the person with the problem using the most recent 5i20 with the stepgen algorithm, or the old algorithm
[01:13:49] <SWPadnos> no idea
[01:14:58] <jmkasunich> I doubt a lack of vel headroom will cause the overshoot
[01:15:04] <jmkasunich> but lack of accel headroom might
[01:15:42] <jmkasunich> EMC might ask the axis to slow down a bit faster than it really can, then it overshoots and comes back
[01:16:01] <SWPadnos> lack of accel headroom should result in a constant error during the cruise phase, which is proportional somehow to the val/accel ratio
[01:16:15] <SWPadnos> vel, not val
[01:16:20] <SWPadnos> geez. can't type tpnoght
[01:16:22] <SWPadnos> see
[01:16:42] <jmkasunich> lack of accel hearoom won't cause steady state error
[01:17:06] <SWPadnos> if the move is at max vel, then laco of accel will put the stepgen behind, and it won't be able to catch up
[01:17:10] <SWPadnos> gah. lack
[01:17:25] <SWPadnos> until the decel phase
[01:17:30] <jmkasunich> lack of accel room will make it get behind, but lack of vel room will keep it behind
[01:17:38] <SWPadnos> yes
[01:17:53] <jmkasunich> fixing either would fix the steady state error
[01:17:54] <SWPadnos> by a constant amount during cruise
[01:17:59] <SWPadnos> yes, that's true
[01:18:04] <jmkasunich> however, error on decel can only be fixed by accel hearoom
[01:18:17] <SWPadnos> yep, that's true
[01:19:00] <jmkasunich> in fact, if you are 0.1% short on accel, and have even 0.0001% headroom on vel, the steady state error will be corrected (over time) during cruise
[01:19:07] <jmkasunich> which ensures that you'll overshoot during decel
[01:19:12] <SWPadnos> could it be that the "pseudo-PID" in the stepgen positioning algorithm has a finite usable bandwidth?
[01:19:37] <jmkasunich> the pseudo-pid is "tuned" based (only) on maxaccel
[01:19:37] <SWPadnos> ie, works great for software step rates but not for 5i20 rates
[01:19:47] <SWPadnos> ok
[01:20:13] <SWPadnos> hmmm. ISTR that accel is different in the hm2 code
[01:20:18] <jmkasunich> should work better for higher rates (closer to the ideal continouous output, instead of discrete)
[01:20:39] <SWPadnos> for one thing, there is no accel from step to step within a servo cycle, as there is in make_pulses
[01:20:42] <jmkasunich> I just realised that there are three driver possibilities
[01:21:08] <jmkasunich> the old 5i20 (or did it not do steps?), the less-old hm2, and the new hm2 with the stepgen algorithm
[01:21:15] <SWPadnos> no stepgen in old 5i20
[01:21:22] <jmkasunich> ok, only 2
[01:21:34] <SWPadnos> there should be only hm2old and hm2, I think
[01:21:40] <jmkasunich> you're right about the sub-servo period ramping in software stepgen, vs hm2
[01:22:02] <jmkasunich> I was thinking about that too, but I don't think that would cause overshoots
[01:22:13] <jmkasunich> the ramping actually introduces a lag
[01:22:45] <jmkasunich> with hm2, the average rate over the servo period is exactly what is requested, with stepgen, it is somewhere between the new requested value and the previous one
[01:22:47] <SWPadnos> one possible scenario (not that I think its the problem) is that the accel algorithm doesn't assume that the stepgen will snap to the new frequency for the whole cycle
[01:23:08] <SWPadnos> so you could get a few steps more with constantly higher freq than you would with ramping
[01:23:22] <jmkasunich> higher during accel, lower during decel
[01:23:29] <SWPadnos> oh, right :)
[01:24:02] <jmkasunich> until we have more data (and ideally can reproduce), it's gonna be rather futile to discuss this
[01:24:24] <SWPadnos> yep
[01:26:41] <jmkasunich> * jmkasunich goes back to boring a timing belt pulley
[01:27:18] <SWPadnos> have fun
[01:27:54] <jmkasunich> press fits are finicky
[01:39:03] <jmkasunich> 100 degrees C = 0.0005" on a 10mm diameter in steel
[01:40:48] <jmkasunich> and a little under 2x that in aluminum
[02:35:54] <CIA-2> EMC: 03seb 07TRUNK * 10emc2/docs/man/man9/hostmot2.9: minor documentation fixes for hostmot2
[02:35:55] <CIA-2> EMC: 03seb 07TRUNK * 10emc2/src/hal/drivers/mesa-hostmot2/TODO: minor documentation fixes for hostmot2
[02:38:24] <CIA-2> EMC: 03seb 07v2_3_branch * 10emc2/docs/man/man9/hostmot2.9: minor documentation fixes for hostmot2
[02:38:26] <CIA-2> EMC: 03seb 07v2_3_branch * 10emc2/src/hal/drivers/mesa-hostmot2/TODO: minor documentation fixes for hostmot2
[02:40:57] <fenn_> fenn_ is now known as fenn
[02:43:50] <jepler> cvs server downtime coming shortly. it should not last long
[02:49:20] <cradek> the buildbot canary died
[02:50:02] <jepler> bbiab
[02:50:55] <seb_kuzminsky> my commit borked the CVS repos :-(
[02:51:03] <seb_kuzminsky> * seb_kuzminsky kicks CIA-2
[02:51:04] <CIA-2> ow
[02:52:09] <cradek> I don't think so - I think it's just the downtime jepler announced a few minutes ago
[02:53:10] <SWPadnos> heh. I guess that turned out to be a bad time to take the repo down ;)
[02:53:25] <seb_kuzminsky> oh, maybe i should pay attention to things outside my head...
[02:53:38] <cradek> ha
[02:53:44] <SWPadnos> impossible
[02:53:56] <SWPadnos> you can only pay attention to the copies inside your head ;)
[02:54:13] <SWPadnos> unless I'm the evil genius or something
[02:54:43] <seb_kuzminsky> * seb_kuzminsky is impressed at cradek's fuel pump
[02:55:02] <cradek> it even works!
[02:55:24] <seb_kuzminsky> bonus!
[02:57:07] <seb_kuzminsky> the .005 brass shim stock is cut into strips that act as both hinge and spring, keeping the 1" disks against the fuel pipes?
[02:57:10] <seb_kuzminsky> hi jepler
[02:57:27] <jepler> things should be back to normal in just a bit
[02:58:21] <cradek> yeah the strips just lift up a bit when the flow is up through the hole under them
[02:59:16] <seb_kuzminsky> neat
[03:04:11] <cradek> I bet marginal fuel pumps are an often-overlooked reason why carbureted cars start hard after sitting
[03:41:05] <jmkasunich> grrrrr
[03:41:11] <jmkasunich> bitten by offset
[03:41:12] <jmkasunich> s
[03:45:35] <cradek> oh noooo
[03:48:45] <jmkasunich> didn't ruin the part
[03:49:00] <jmkasunich> in fact, I didn't get bitten as hard as I thought
[03:51:06] <jmkasunich> I switched from G54 to G55 when I changed tools (didn't want to lose the offsets for the boring bar)
[03:51:18] <jmkasunich> forgot the automatic switch back to g54 at end of program
[04:09:18] <garage_seb> the free planner moves differently than the "non-free?" one
[04:10:08] <jmkasunich> garage_seb: not on purpose
[04:10:22] <cradek> differently how?
[04:10:36] <jmkasunich> actually..... the coordinated TP uses only 50% accel I think, because of blending issues
[04:10:42] <jmkasunich> the free TP uses 100% accel
[04:10:45] <cradek> jmkasunich: 'depends'
[04:11:01] <jmkasunich> adult diapers?
[04:11:06] <garage_seb> http://highlab.com/~seb/emc2/stepgen/
[04:11:51] <SWPadnos> non-free == coordinated
[04:12:13] <cradek> so it is accel
[04:12:20] <garage_seb> yeah looks like it
[04:12:28] <cradek> garage_seb: if you program G61 you'll get full accel from coordinated mode too
[04:12:40] <jmkasunich> can you measure the accel in the two cases that you scoped?
[04:12:53] <garage_seb> but i'd expect the fb to lag cmd during accel by as much as it overshoots during decel
[04:13:02] <garage_seb> * garage_seb programs
[04:13:56] <jmkasunich> garage_seb: during accel, the stepgen position loop has a simple task - accel as fast as you can - which is probably 99.995% of how fast it needs to
[04:14:06] <garage_seb> with g61, coord overshoots just like free does
[04:14:29] <jmkasunich> during decel, it is tougher - it doesn't know that the axis is gonna stop at any particular spot
[04:14:32] <SWPadnos_> SWPadnos_ is now known as SWPadnos
[04:14:43] <jmkasunich> it attempts to predict where the axis is going based on the accel limit, etc
[04:15:23] <garage_seb> the stepgen code here is the "new" hm2 stepgen code i <ahem> copied from the sw stepgen
[04:16:37] <jmkasunich> I wouldn't be at all surprised to see the same overshoot with software stepping
[04:16:46] <jmkasunich> you have zero accel headroom
[04:16:53] <garage_seb> yeah... :-(
[04:17:08] <jmkasunich> dang, now I've gone and lost my pulley
[04:17:22] <garage_seb> it might be slightly worse for sw, since it accelerates slightly slower
[04:18:17] <garage_seb> hm2 spends the entire servo loop at the next velocity-step, but the sw stepgen accelerates gradually throughout the servo loop, by changing vel in the base thread
[04:18:52] <jmkasunich> yep
[04:19:09] <jmkasunich> I bet 1% of headroom will fix it
[04:19:34] <jmkasunich> the sticking point is how we go about ensuring the headroom
[04:19:59] <jmkasunich> cradek argues (with reason) that the EMC user shouldn't have to deal with that
[04:20:26] <jmkasunich> I argue (with reason) that components like stepgen should do what they say they do, and the integrator should ensure margin
[04:20:56] <jmkasunich> and its bedtime here
[04:21:08] <garage_seb> ok, thanks jmkasunich
[04:21:10] <cradek> yes, goodnight
[04:21:21] <garage_seb> hope you find your pulley ;-)
[04:21:29] <jmkasunich> I did
[04:22:31] <jmkasunich> I now have a steel spindle, a steel sleeve that (hopefully) is a press/shrink fit on the spindle, and an aluminum timing belt pulley that (hopefully) is a press/shrink fit on the sleeve
[04:22:44] <jmkasunich> tomorrow will tell
[04:22:55] <jmkasunich> night
[04:32:36] <garage_seb> i let the stepgen accelerate 5% more than the .maxaccel param says, and it still overshoots but not as badly
[04:33:07] <garage_seb> my old stepgen code had many problems, but i think it didnt have this one
[04:33:25] <garage_seb> i had misunderstood the contract between the planner and the stepgen driver
[04:34:30] <garage_seb> i thought each position-command was more stand-alone than i think it is now - the old code didnt use history to compute cmd velocity, and it didnt try to do velocity matching like the sw stepgen code (and by extension the hm2 stepgen code) does
[04:35:13] <SWPadnos> the planners just expect whatever they're connected to to move to the position they output
[04:35:22] <garage_seb> the old code had as its goal: accelerate however you have to (up to maxaccel) in order to *stop* at position-cmd
[04:35:36] <garage_seb> SWPadnos, i disagree
[04:35:53] <SWPadnos> well, they also expect it to be done in one servo cycle
[04:36:20] <SWPadnos> and that's where the accel and vel limits come in - the planners won't ask for any more than they're told they can have
[04:37:07] <garage_seb> the ambiguity is this: what velocity does the planner expect the joint to have when pos-fb = pos-cmd at the end of this servo loop?
[04:37:08] <SWPadnos> when you use PID, there's no direct setting for "headroom" - the max_output or limit parameters for the PID or DAC aren't always direcly related to velocity or accel
[04:37:25] <garage_seb> vel is unspecified
[04:37:32] <garage_seb> i had thought it was 0
[04:37:33] <SWPadnos> true, it's not a vector
[04:37:47] <SWPadnos> no, it's possibly something else
[04:38:11] <garage_seb> but that results in large following errors - the stepgen lags far enough behind long moves that it can decelerate to a stop at pos-cmd
[04:38:19] <SWPadnos> are you talking about the end of a servo cycle-length move, or the end of a G-code / jog move
[04:38:49] <garage_seb> i'm talking about the interface between either of the two planners and the stepgen HAL component
[04:39:01] <garage_seb> the current value of stepgen.pos-cmd
[04:39:26] <SWPadnos> ok, so at time t=0 the planner outputs 0, and at time t=0.001 the planner outputs 0.001 (= 1 IPS)
[04:39:53] <garage_seb> yes, that's the interface
[04:39:55] <SWPadnos> there is no specification as to whether that's the first part of a long move or a single 0.001 inch move
[04:40:03] <SWPadnos> so you're right, there is some ambiguity there
[04:40:08] <garage_seb> right, that information is missing
[04:40:46] <garage_seb> okie doke, time for snoozes
[04:40:58] <SWPadnos> but the stepgen is always behind, trying to catch up to the next position
[04:41:06] <SWPadnos> ok, sounds like a good plan
[04:41:17] <garage_seb> logger_dev, bookmark
[04:41:17] <garage_seb> Just this once .. here's the log:
http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2009-04-15.txt
[05:10:47] <CIA-2> EMC: 03seb 07v2_3_branch * 10emc2/src/hal/drivers/mesa-hostmot2/watchdog.c: slightly cleaner sanity checks
[05:13:27] <CIA-2> EMC: 03seb 07TRUNK * 10emc2/src/hal/drivers/mesa-hostmot2/watchdog.c: slightly cleaner sanity checks
[05:31:01] <CIA-2> EMC: 03cmorley 07TRUNK * 10emc2/src/emc/usr_intf/pncconf/pncconf.py:
[05:31:01] <CIA-2> EMC: Fix problem with encoder, pwm, stepgen pins not updating mesa data pins
[05:31:01] <CIA-2> EMC: when using a standard signal name. Work on getting 'test axis' to send
[05:31:01] <CIA-2> EMC: proper HAL names to hal for mesa pins. Noticed parport pins are numbered
[05:31:01] <CIA-2> EMC: wrong pin 1 can not be input and output."
[09:09:18] <micges> good morning
[09:13:05] <micges> I've looked into code and implement additional canon calls for naive cam is the hardest but most functional change
[09:16:05] <micges> jepler: if you will know how to add feature I've asked (add G64.1 for cam on/off or improve G64 with Pn Qn) let me know the I create patch
[09:46:17] <alex_joni> I think G64 Pn Qn is the best idea
[09:46:22] <alex_joni> Q0 to switch it off
[09:47:57] <micges> in interp if I have:
[09:47:58] <micges> save_mode = GET_EXTERNAL_MOTION_CONTROL_MODE();
[09:47:59] <micges> save_tolerance = GET_EXTERNAL_MOTION_CONTROL_TOLERANCE();
[09:48:16] <micges> save cam info in the same way ?
[09:48:53] <micges> naive cam info*
[09:49:21] <micges> or not changing it at all
[09:53:20] <micges> other way: in interp in convert_cycle_xy blended mode is turned off for a short time and restored at end, if we spilt tolerance to rt part and naive_cam part, do they both values must be saved or only rt part ?
[10:03:16] <alex_joni> only RT part I think
[10:03:40] <alex_joni> I would add the GET_EXTERNAL_NAIVECAM_CONTROL_MODE() and TOLERANCE()
[10:03:53] <alex_joni> and the same SET_* functions
[11:58:31] <jepler> I don't think thre's a "mode" for the naive cam detector -- a "tolerance" of 0.0 turns it off.
[11:59:10] <jepler> probably it needs to be GET and SET in the same places as MOTION_CONTROL_TOLERANCE and MOTION_CONTROL_MODE
[12:16:11] <micges> I have problem:
[12:16:12] <micges> Linking milltask
[12:16:12] <micges> ../lib/librs274.so.0: undefined reference to `SET_NAIVE_CAM_TOLERANCE(double)'
[12:17:27] <micges> proto of this function must be added to canon.hh, and anything else?
[12:40:26] <jepler> you have to provide the definition of it
[12:40:46] <jepler> probably in at least 3 places: milltask, sai, gcodemodule
[12:42:08] <CIA-2> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/man/man9/encoder.9: update pins and parameters
[12:45:04] <micges> ok
[14:25:42] <cradek> what problem is micges trying to solve?
[14:28:46] <jepler> cradek: he has an unstated bug with r-f-l and the naive cam detector
[14:29:24] <jepler> cradek: I'd like to see the ability to separately turn on tolerance mode and the naive cam detector. For instance, it has repeatedly tripped up jmkasunich
[14:29:27] <cradek> ok, so you don't know either...
[14:29:55] <cradek> yes, I can see where that would be useful too
[14:30:53] <jepler> I didn't feel like fishing for the real r-f-l bug report, and I wouldn't feel like fixing it anyway
[15:37:54] <jepler> hi seb_kuzminsky
[15:39:24] <cradek> just now, another post about 5i20 stepper
[15:39:36] <cradek> also, hi
[15:40:50] <seb_kuzminsky> hi guys
[15:42:07] <seb_kuzminsky> re: the new email
[15:42:19] <seb_kuzminsky> the humming/hunting thing is fixed in 2.3 branch
[15:42:29] <seb_kuzminsky> not sure about the ferror
[15:44:16] <cradek> headroom?
[15:44:37] <cradek> did you do anything about that after I went to bed?
[16:07:11] <seb_kuzminsky> cradek: yeah, i turned [TRAJ]MAX{VEL,ACCEL} down to about 2% below the [AXIS_0] limits, and then it worked great, as per the prophecy
[16:07:23] <seb_kuzminsky> http://highlab.com/~seb/emc2/stepgen/
[16:07:52] <seb_kuzminsky> the overshoot max error is 0.00625 units, and it corrects to the cmd within about 15 ms
[16:33:06] <alex_joni> seb_kuzminsky: hi
[16:33:17] <alex_joni> I don't think the [TRAJ] change is a viable solution
[16:33:37] <alex_joni> it's good enough for testing, but it limits the system quite a bit
[16:34:05] <alex_joni> (imagine you have a slow Z, and fast X & Y, you would have to set TRAJ slower than Z, so the Z stepgen doesn't fall behind)
[16:36:57] <cradek> I agree -- also, diagonals are limited.
[16:37:05] <alex_joni> yes, that too
[16:38:02] <alex_joni> does [TRAJ]MAX_VEL/ACCEL refer to rotaries aswell, or has that been changed?
[17:20:14] <seb_kuzminsky> alex_joni: hi
[17:21:49] <seb_kuzminsky> it seems like the coordinated planner should know the acceleration limits of the joints its trying to control, not just lump everything together into a "machine accel" limit
[17:24:39] <seb_kuzminsky> alex_joni: any suggestion on how to fix it without limiting TRAJ to less than the slowest axis?
[17:35:03] <seb_kuzminsky> the "stepper" sample config in 2.3 has [TRAJ]MAX_VELOCITY == [AXIS_?]MAX_VELOCITY, and [TRAJ]MAX_ACCELERATION == [AXIS_?]MAX_ACCELERATION / 1.04
[17:35:25] <seb_kuzminsky> i believe this is the best we can currently do
[17:35:40] <seb_kuzminsky> if i dont hear different, i will replicate this pattern in the hm2-stepper sample configs
[17:36:53] <SWPadnos> seb_kuzminsky, that's not the recommended thing to do
[17:37:24] <seb_kuzminsky> what's the recommended thing?
[17:37:30] <SWPadnos> the way the TP works is that for any given move, the most constrained joint or the overall TRAJ constraint will apply
[17:38:03] <SWPadnos> well, aside from the user having to think about it, set the stepgen maxaccel a little higher than the AXIS max accel
[17:38:13] <SWPadnos> that's the technically correct solution, but it is "harder"
[17:38:50] <SWPadnos> TP and TRAJ limits are unrelated to the fact that stepper-driving HAL components can't keep up when they use the same AXIS_N limits as the TP
[17:42:32] <seb_kuzminsky> i think i see
[17:42:42] <seb_kuzminsky> set TRAJ to whatever the max for the whole machine is
[17:43:03] <seb_kuzminsky> set [AXIS]MAX_ACCEL & MAX_VEL for how fast you want the coord planner to try to move this axis
[17:43:07] <SWPadnos> yes, or something very very large if you want the joint limits to control things
[17:43:32] <seb_kuzminsky> set stepgen.maxaccel to something slightly bigger than [AXIS]MAX_ACCEL so it can surely keep up
[17:43:37] <SWPadnos> yep
[17:43:51] <seb_kuzminsky> ok thanks, i'm a bit slow
[17:43:56] <seb_kuzminsky> need more head room
[17:44:02] <SWPadnos> it's icky from the users point of view, because it seems like they're setting two things that the computer should be able to figure out itself
[17:44:04] <SWPadnos> heh
[17:49:29] <cradek> seb_kuzminsky: the coordinated planner does do the things you suggest (know each axis's limits and constrain the total move accordingly)
[17:49:50] <cradek> that's why the traj limit is redundant and considered harmful (e.g. stepconf leaves it out)
[17:49:59] <jepler> (for trivial kinematics, anyway)
[17:50:06] <cradek> yes
[17:50:24] <seb_kuzminsky> i see - i was confused about the meaning of [AXIS]MAX_*, i didnt realize the coord tp used that
[17:50:38] <seb_kuzminsky> i thought it was for the stepgen, but now i see that it's not
[17:51:06] <seb_kuzminsky> so the real fix (i think) is to look at configs/stepper and do basically what that's doing
[17:51:37] <seb_kuzminsky> no [TRAJ] limits, and two limits in [AXIS]: one for the coord tp and one for the stepgen, with the stepgen limits set a few percent higher
[17:51:47] <cradek> yes that's one possible fix - the one that makes the user maintain some numbers a few percent apart
[17:52:03] <SWPadnos> heh. the "icky for the user" one
[17:52:11] <cradek> I think it smells bad, but it's consistent with the smelly way we're currently doing it with software stepgen.
[17:52:23] <seb_kuzminsky> the other way is "icky for the user" too i think
[17:52:30] <seb_kuzminsky> just smelly in a different way
[17:52:32] <SWPadnos> I think all methods we've discussed are smelly somehow
[17:52:52] <SWPadnos> the only clean way would be to figure out how to make stepgens not do this
[17:52:54] <cradek> the fact that all the solutions stink stinks.
[17:52:57] <SWPadnos> but I suspect that's hard
[17:53:04] <SWPadnos> indeed
[17:53:26] <cradek> is there a need for stepgen's max vel? I understand the accel setting helps it slew - is this right?
[17:53:46] <SWPadnos> good question
[17:54:03] <seb_kuzminsky> stepgen maxvel is useful for two reasons i think
[17:54:17] <seb_kuzminsky> one is the limit of steplen+stepspace
[17:54:19] <cradek> my understanding is 5i20 does not slew between servo periods? maybe neither is needed?
[17:54:42] <seb_kuzminsky> the other is the stepper loss-of-torque issue at high speeds
[17:54:57] <cradek> I don't follow
[17:55:04] <seb_kuzminsky> cradek: true, hm2 spends the entire servo period at one particular step rate
[17:55:51] <seb_kuzminsky> cradek: dont follow what?
[17:55:55] <cradek> assuming the input fed to hm2 stepgen's input has max vel of 1 and max accel of 1, does it make any difference in the behavior if stepgen's limits are set to 1,1 or 10,10 or 100,100?
[17:56:20] <seb_kuzminsky> it shouldnt
[17:56:27] <cradek> then don't set them, problem solved
[17:56:39] <SWPadnos> there will be a difference in behavior for the software stepgen
[17:56:49] <SWPadnos> but it may not matter
[17:56:50] <cradek> SWPadnos: yes, it slews with the accel setting.
[17:57:00] <SWPadnos> or not, if you set accel to +INF
[17:57:01] <cradek> SWPadnos: in practice it seems to matter - I think skunkworks tested it
[17:57:29] <cradek> (I wonder if this will turn out to be a problem with hm2 stepgen, but that's an aside)
[17:57:50] <SWPadnos> it depends on the accel, I bet
[17:57:57] <seb_kuzminsky> if it *is* a problem, it should be possible to add controlled-accel slewing to the firmware
[17:58:12] <SWPadnos> at higher speeds, snapping to the next higher rate may not be possible due to reduced available torque
[17:58:14] <cradek> seb_kuzminsky: neat
[17:58:26] <cradek> simply a faster servo cycle might reduce the problem, too
[17:58:36] <SWPadnos> should, it would reduce the steps
[17:58:58] <cradek> but back on topic - why not leave those unset (inf) and let emc handle the limiting
[17:59:06] <SWPadnos> it may be a moot point for the software stepgen anyway since the step lengths vary by jitter (or 2*jitter)
[17:59:18] <seb_kuzminsky> so cradek, do i understand you correctly that you recommend letting the hm2 stepgen accelerate at any rate, and step at any rate, and do all the trajectory control in the coord planner?
[17:59:24] <cradek> yes
[17:59:37] <SWPadnos> that's a great solution if it works :)
[17:59:53] <seb_kuzminsky> i'll try it tonight
[17:59:53] <cradek> then everyone is happy - you don't have to crap up those limits in the driver - people using them get what they ask for - also the user doesn't have to maintain two numbers a few percent apart.
[18:00:18] <SWPadnos> and stepgen is still capable of being used directly in other applications, and will "do what you tell it"
[18:00:29] <seb_kuzminsky> the driver's default maxvel & maxaccel would be "unlimited", for use with the coord tp
[18:00:31] <cradek> our two planners respect their constraints. they are extremely well tested.
[18:00:45] <seb_kuzminsky> users who want to drive the stepgens some other way can specify the stepgen limits explicitly
[18:00:54] <cradek> yes
[18:01:00] <SWPadnos> seb_kuzminsky, coordinated or free, they all respect the TRAJ limits
[18:01:21] <SWPadnos> but the coordinated one may also reduce accel in some cases for other reasons
[18:01:23] <cradek> SWPadnos: no, the AXIS limits
[18:01:32] <SWPadnos> err, yeah :)
[18:01:39] <SWPadnos> that's actually what I meant :)
[18:01:41] <cradek> I don't know whether free respects TRAJ. I don't recommend using TRAJ for trivkins.
[18:01:53] <seb_kuzminsky> TRAJ should be left unspecified
[18:01:58] <cradek> IMO yes
[18:02:02] <seb_kuzminsky> ok thanks for the cluebat guys
[18:02:03] <SWPadnos> ok ok - AXIS_N limits :)
[18:02:04] <seb_kuzminsky> bbl lunch
[18:02:10] <cradek> heh
[18:02:12] <cradek> :-)
[18:04:01] <SWPadnos> OK. it looks like I may be able to go to Fest from the weekend on
[18:04:06] <SWPadnos> yay!
[18:04:14] <SWPadnos> unless something goes wrong in Dallas
[18:05:49] <cradek> cool
[18:26:21] <CIA-2> EMC: 03jepler 07TRUNK * 10emc2/scripts/ (emc-environment.in emc.in): remove mention of EMC2_IOSH, it's not used anywhere in emc2, just defined
[18:42:32] <CIA-2> EMC: 03jepler 07TRUNK * 10emc2/scripts/emc.in: the old formulation is just confusing -- avoid it
[18:44:36] <SWPadnos> hmmm. are the bash completion scripts part of the debian package?
[18:44:58] <jepler> no
[18:45:01] <SWPadnos> ok
[18:45:04] <jepler> they're just a snippet of code in scripts/emc-environment
[18:45:19] <SWPadnos> it looks like you can stick that code into /etc/bash-completion.d/
[18:45:20] <jepler> "someone should do something"
[18:45:22] <SWPadnos> heh
[18:45:36] <SWPadnos> err, bash_completion.d
[18:45:57] <jepler> that would be nice
[18:46:12] <SWPadnos> at least that's how I read this:
http://www.debian-administration.org/users/Steve/weblog/78
[18:46:29] <jepler> I think that's the general intent of that directory
[18:47:44] <CIA-2> EMC: 03jepler 07TRUNK * 10emc2/debian/ (control.in emc2.files.in): this reformulation lets us wildcard the /usr/bin programs to go in the main program
[18:49:47] <SWPadnos> jepler, does that wildcard folmulation work for uninstall also?
[18:50:05] <jepler> yes
[18:50:08] <SWPadnos> ie, is the list of files installed kept around for removal
[18:50:10] <SWPadnos> ok
[18:50:13] <SWPadnos> yay! :)
[18:50:15] <jepler> the wildcard is only used when dh_movefiles decides which files to put in each package directory
[18:50:22] <SWPadnos> ah, ok
[18:50:34] <jepler> it doesn't record "files matching /usr/bin/* come from emc"; that'd be nuts
[18:50:39] <SWPadnos> heh
[18:50:47] <SWPadnos> yeah, but I thought I'd ask anyway ;)
[18:53:16] <CIA-2> EMC: 03jepler 07TRUNK * 10emc2/scripts/ (emc-environment.in emc.in):
[18:53:16] <CIA-2> EMC: Replace emcsh with emc.so, a loadable package.
[18:53:16] <CIA-2> EMC: this is the preferred way to do C extensions to tcl.
[18:53:17] <CIA-2> EMC: 03jepler 07TRUNK * 10emc2/tcl/ (emc.tcl.in mini.tcl tkemc.tcl):
[18:53:17] <CIA-2> EMC: Replace emcsh with emc.so, a loadable package.
[18:53:17] <CIA-2> EMC: this is the preferred way to do C extensions to tcl.
[18:53:20] <CIA-2> EMC: 03jepler 07TRUNK * 10emc2/src/emc/usr_intf/ (Submakefile emcsh.cc):
[18:53:22] <CIA-2> EMC: Replace emcsh with emc.so, a loadable package.
[18:53:24] <CIA-2> EMC: this is the preferred way to do C extensions to tcl.
[18:53:26] <CIA-2> EMC: 03jepler 07TRUNK * 10emc2/tcl/bin/ (5 files):
[18:53:28] <CIA-2> EMC: Replace emcsh with emc.so, a loadable package.
[18:53:30] <CIA-2> EMC: this is the preferred way to do C extensions to tcl.
[18:53:32] <CIA-2> EMC: 03jepler 07TRUNK * 10emc2/tcl/scripts/Set_Coordinates.tcl:
[18:53:34] <CIA-2> EMC: Replace emcsh with emc.so, a loadable package.
[18:53:36] <CIA-2> EMC: this is the preferred way to do C extensions to tcl.
[18:53:49] <cradek> no kidding
[18:54:35] <jepler> (one thing about this is you can now do a windowless tcl program that interacts with emc)
[18:54:47] <jepler> (by invoking tclsh and loading emc.so, rather than invoking wish)
[18:54:54] <cradek> neat
[19:15:30] <jepler> oh look, I'm in the doghouse
[19:16:09] <cradek> bonk
[19:17:43] <jepler> what's the error?
[19:17:59] <jepler> Files exist in debian/tmp, but should not:
[19:18:00] <jepler> uhhhh
[19:18:19] <jepler> but that's all of them!
[19:18:44] <cradek> hm
[19:18:46] <SWPadnos> so much for the asterisk :)
[19:20:25] <jepler> I built a sim deb and it was fine :-P
[19:20:42] <SWPadnos> heh
[19:29:14] <jepler> weird -- for me, sim builds on dapper/i386, sim and rt build on hardy/amd64
[19:29:19] <jepler> and I don't have anything else I can easily try
[19:29:27] <jepler> it builds all the way to a package
[19:41:03] <jepler> ah, here's a hardy/i386/rt system I can build on
[19:41:10] <jepler> er, dapper/i386/rt
[19:49:24] <jepler> oh good, I do get the packaging error on dapper/i386/rt
[19:58:45] <jepler> ah I think I spotted the problem now
[20:00:05] <CIA-2> EMC: 03jepler 07TRUNK * 10emc2/debian/control.in: blank lines are important
[20:00:25] <jepler> (but why did hardy/amd64/rt work for me? or was I mistaken about what I was testing?)
[20:01:07] <cradek> wow, that's obscure
[20:01:58] <jepler> on rt systems, additional Package: blocks for the firmware packages are concatenated
[20:35:31] <cradek> jepler: still 2.3.0 this weekend? seems like changes are still slowly dribbling in, but not any critical ones
[20:37:03] <alex_joni> does any of you remember without looking what pin needs to be linked, so that AXIS displays a coolant button?
[20:37:35] <cradek> flood and mist have their own pins (iocontrol.something?)
[20:37:50] <alex_joni> iocontrol.0.coolant-flood & -mist
[20:38:06] <alex_joni> should linking coolant-flood be enough?
[20:38:55] <jepler> forget(widgets.mist, "iocontrol.0.coolant-mist")
[20:38:55] <jepler> forget(widgets.flood, "iocontrol.0.coolant-flood")
[20:38:55] <jepler> forget(widgets.lubel, "iocontrol.0.coolant-flood", "iocontrol.0.coolant-mist")
[20:39:19] <jepler> the whole frame is forgotten if neither is linked. if one is linked but not the other, only that unlinked one is forgotten
[20:39:21] <alex_joni> jepler: just found that
[20:39:24] <jepler> if you want 2 buttons, link two lins
[20:39:28] <jepler> if you want 1 button, link one pin
[20:39:38] <alex_joni> ok, thx
[20:52:05] <cradek> alex_joni: you get the prize for the most badly-formatted message today
[20:52:15] <CIA-2> EMC: 03jepler 07TRUNK * 10emc2/src/emc/usr_intf/ (Submakefile iosh.cc): as far as I can tell, iosh is not useful for anything anymore
[20:57:06] <alex_joni> cradek: cool, what did I win?
[20:57:22] <alex_joni> wow.. that is bad
[20:57:24] <SWPadnos> a free copy of pine
[20:58:52] <alex_joni> pine is gone
[20:59:06] <alex_joni> I use alpine on hardy
[20:59:20] <alex_joni> but this time my email client (which I will not name) got confused by the paste from the website
[20:59:58] <jepler> hm, wikipedia says linus said in 2008 he uses alpine
[21:00:06] <cradek> X-Mailer: Microsoft Outlook Express 6.00.2900.3138
[21:00:32] <cradek> "here's a nickel, kid, get yourself a real computer"
[21:01:10] <cradek> http://farm1.static.flickr.com/87/240803829_9212773615_o.png
[21:01:17] <cradek> darn, close but not quite
[21:01:45] <skunkworks> no susupenders?
[21:02:09] <jepler> I should get some suspenders to wear to fest
[21:12:00] <CIA-2> EMC: 03jepler 07TRUNK * 10emc2/src/emc/usr_intf/Submakefile: git commit --amend
[21:12:24] <cradek> that can't be what you meant
[21:12:48] <seb_kuzminsky> how are you liking git, jepler?
[21:13:05] <jepler> cradek: it's a joke
[21:13:22] <jepler> cradek: git commit --amend is what you use when you catch your mistake before you push
[21:13:26] <jepler> (since you can still change history then)
[21:13:43] <cradek> ohh, version control humor
[21:13:45] <jepler> seb_kuzminsky: to the extent I've used it, I like it
[21:15:21] <jepler> seb_kuzminsky: I've also been using bzr a bit, and I'm convinced that whichever one you learn second will annoy you more
[21:15:36] <seb_kuzminsky> heh
[21:15:53] <seb_kuzminsky> i learned bzr third, and it annoyed me least (git first, then hg, then bzr)
[21:16:25] <alex_joni> jepler: second after cvs ?
[21:17:25] <alex_joni> anyways.. off to bed for me
[21:18:13] <jepler> seb_kuzminsky: here's one thing about bzr: I was in a "bzr commit", hit ctrl-z in my editor, then "bzr diff". It didn't screw me in the way git does (you have to give an extra argument to see what you're going to commit as a diff), but instead it gave me some error concerning lockfiles
[21:18:25] <jepler> presumably because "bzr commit" holds a repository-wide lock the whole time it is running..?
[21:21:48] <seb_kuzminsky> jepler: bzr *loves* locking everything in sight
[22:33:27] <seb_kuzminsky> i recently found the first (well: second) think i dont like about bzr
[22:33:38] <seb_kuzminsky> it loses merge tracking when you cherrypick :-(
[22:38:51] <jepler> so you have histories A-B-C-D-E and A-G-H-C-J and you want to merge J and E, it can't handle that they have C in common?
[22:39:59] <seb_kuzminsky> no, that scenario works fine
[22:40:45] <seb_kuzminsky> but if you merge H (without G) into the A-B-C... branch, it doesnt record the origin of the H as coming from the other branch
[22:41:10] <seb_kuzminsky> it's just as if you'd applied a patch in your A-B-C... working dir, with no indication that the patch originated in the other branch
[22:41:47] <seb_kuzminsky> oh hm, maybe your scenario would be problematic
[22:41:51] <seb_kuzminsky> i should read before writing
[22:43:54] <seb_kuzminsky> getting C without B into the second branch is a cherrypick
[22:44:11] <jepler> right
[22:44:18] <seb_kuzminsky> merging the second branch into the first would be harder because bzr wouldnt realize that the first branch already had C
[22:46:04] <jepler> I don't think git records any more information than it sounds like bzr does
[22:46:17] <seb_kuzminsky> bummer
[22:49:07] <seb_kuzminsky> darcs is looking better and better to me
[22:50:50] <seb_kuzminsky> http://zooko.com/badmerge/simple.html
[23:12:50] <seb_kuzminsky> later
