Back
[03:29:55] <dgarr> jepler: re the [DISPLAY]GEOMETRY -- thanks for the quick work:
[03:29:55] <dgarr> i updated from cvs & make & test with simulator axis_9axis.ini, test different values for Baxis:
[03:29:55] <dgarr> g0 B90, toggle liveplot, cone flips to -90
[03:29:55] <dgarr> g0 Bangle, toggle liveplot, cone flips to -angle
[03:29:55] <dgarr> so it seems (unchanged?) not right to me, my machine is CXYZ, and C rotations are not shown with liveplot off
[03:30:26] <dgarr> i added comment followup to sf
[03:31:32] <jepler> hmmm, you say the cone's angle changes? I was concentrating on the cone's position changing using a 9axis configuration...
[03:31:51] <jepler> I'll look at it again tomorrow
[03:33:36] <dgarr> yes -- i've only noticed problem on the angle when liveplot toggled and GEOMETRY specified
[03:33:40] <dgarr> thanks!
[03:40:03] <jepler> your GEOMETRY = CXYZ
[03:40:04] <jepler> ?
[03:42:34] <dgarr> on my machine, [DISPLAY]GEOMETRY==CXYZAB -- rotary axis along Z, the tests i've reported are with axis_9axis.ini however
[03:42:42] <jepler> ok
[03:43:54] <dgarr> on my machine, rotations are show with liveplot on ok (axis shows the cone moving -- in my real machine the tool is stationary but the display is easy to understand that way)
[03:59:45] <CIA-2> EMC: 03cradek 07TRUNK * 10emc2/src/emc/usr_intf/axis/scripts/axis.py: remove debug print
[13:26:18] <jepler> hmph -- can anybody else take a look at
https://sourceforge.net/tracker/index.php?func=detail&aid=2632523&group_id=6744&atid=106744 and tell me if they can reproduce it?
[13:45:39] <CIA-2> EMC: 03jepler 07TRUNK * 10emc2/share/axis/tcl/axis.tcl: provide an accelerator key to switch inch/mm in DRO
[13:45:40] <CIA-2> EMC: 03jepler 07TRUNK * 10emc2/src/emc/usr_intf/axis/scripts/axis.py: provide an accelerator key to switch inch/mm in DRO
[14:07:25] <cradek> jepler: wfm
[19:40:01] <jepler> hmm, this is a bit ugly. when the pulse frequency is < 1, 1PPR encoder stops interpolating position
[19:40:10] <jepler> when it's <1+epsilon, it slips in and out of its estimating mode
[19:40:17] <jepler> I don't see a tunable to change this, at least in the manpage
[19:44:31] <jepler> http://emergent.unpy.net/files/sandbox/interpolated-encoder-glitch.png
[19:45:25] <alex_joni> ouch
[19:46:04] <alex_joni> why is there a drop in position there?
[19:46:05] <jepler> and when velocity is <1-epsilon, the velocity estimate always shows 0:
http://emergent.unpy.net/files/sandbox/interpolated-encoder-glitch2.png
[19:48:17] <jepler> over the course of several minutes, I didn't get any velocity glitches with a 2Hz pulse
[19:48:34] <jepler> here's my hal file:
http://emergent.unpy.net/files/sandbox/ppr.hal
[19:50:18] <jepler> jmkasunich: when you're around scroll back up here and take a look at this stuff about encoder in 1PPR mode: ^^^
[19:55:04] <jepler> I run it with "halrun -I" then manipulate stepgen.0.velocity-cmd in halcmd
[20:14:15] <SWPadnos_> SWPadnos_ is now known as SWPadnos
[21:12:49] <seb_kuzminsky> taking the buildbot down for a bit to move it to our secret bunker
[21:13:05] <cradek> ooh, where is that? oh wait, secret, right
[21:27:31] <seb_kuzminsky> emc2-buildmaster: version
[21:27:32] <emc2-buildmaster> buildbot-0.7.9 at your service
[21:27:40] <seb_kuzminsky> emc2-buildmaster: upgrade yourself to 0.7.10
[21:27:45] <seb_kuzminsky> ...
[23:30:12] <jmkasunich> jepler at some point the interpolator/estimator has to give up
[23:31:22] <jmkasunich> "its been a week since I saw a pulse - I know I'm somewhere between 'where the last pulse said I was' and 'where the next pulse would put me' but I have no idea where
[23:32:05] <jmkasunich> the give up point should probably be configurable
[23:32:12] <jepler> jmkasunich: hi
[23:32:48] <jepler> I dunno if 60RPM is a speed some people would like to thread at with their 1PPR spindles .. it seems possible that it would be
[23:33:00] <jepler> so +1 for tunable
[23:33:34] <jepler> is there anything to be done about the velocity estimate being a constant 0 below the critical speed, though?
[23:33:53] <jepler> maybe the old behavior (0 most of the time, +big at other times) isn't very desirable either...
[23:33:54] <jmkasunich> well
[23:34:26] <jmkasunich> one approach would be to make the velocity estimate be "the farthest we might have traveled without getting another pulse, divided by the time its been since the last pulse"
[23:34:54] <jmkasunich> the problem with that is that if you integrate it, you will get a distance that is _more_ than "the farthest we could have traveled since the next pulse"
[23:36:53] <jepler> yes
[23:37:29] <jepler> then is it better to integrate to less or more? It seems the current implementation always integrates to less (in absolute value)
[23:37:33] <jmkasunich> #define TIMEOUT 1000000000
[23:37:47] <jmkasunich> less is better
[23:38:12] <jmkasunich> that way when a pulse does come along, you don't have to go backwards to catch up
[23:38:27] <jmkasunich> argh
[23:38:34] <jmkasunich> /* if no edges in 100mS time, force vel to zero */
[23:38:34] <jmkasunich> #define TIMEOUT 1000000000
[23:38:43] <jmkasunich> arg again
[23:38:57] <jmkasunich> I keep falling afoul of the / command prefix in IRC
[23:39:08] <jepler> are you referring to how the comment and the timeout don't match?
[23:39:27] <jmkasunich> /* if no edges in 100mS time, force vel to zero */
[23:39:27] <jmkasunich> /* changed to 1 second - low ppr needs a longer time */
[23:39:27] <jmkasunich> /* FIXME - this shouldn't be a hard coded number */
[23:39:27] <jmkasunich> #define TIMEOUT 1000000000
[23:39:33] <jepler> ah
[23:39:38] <jmkasunich> I was just trying to paste the three lines and the define
[23:39:42] <jepler> it crosses my mind that I should have rtfs
[23:40:28] <jmkasunich> either timeout should be a parameter (or pin), easy to code, maybe confusing to use
[23:41:00] <jmkasunich> or timeout should be calculated from a "min speed" parameter (or pin) that is in terms of counts/sec, counts/min, or RPM
[23:41:36] <jepler> hmm min-speed sounds nice
[23:41:42] <jmkasunich> that would be easier to use, especially in RPM, but RPM can't be used, since the module doesn't know counts/rev
[23:42:05] <jmkasunich> it only knows a scale factor, which might be counts/inch, counts/mm, counts/rev, etc
[23:42:17] <jepler> the only sane way to set it up for a spindle is 1 = 1 rev, and so min-speed would be given in rps
[23:42:37] <jmkasunich> yeah
[23:43:11] <jepler> "units are the same as the velocity output" doesn't burden the integrator much. he has to know what the units of velocity are
[23:43:15] <jmkasunich> have to deal with all the edge cases too - where people don't specify the min scale, etc. if the default is zero, we'll have a divide by zero problem
[23:44:07] <jmkasunich> I have to make dinner - I'll look deeper (and probably fix) later
[23:44:33] <jepler> see you
[23:44:36] <jepler> thanks for taking the time
[23:45:22] <jepler> have you done any benchmarking to see whether it's useful on current machines to do division instead of multiplication?
[23:46:17] <seb_kuzminsky> jepler: in hm2, i have a ".vel-timeout" parameter, if no pulses for that long (in seconds), it gives up and reports 0
[23:46:50] <seb_kuzminsky> if there have been no pulses since the last time through the loop, but we haven't waited vel-timeout seconds yet, it reports the max vel it could have been
[23:58:19] <seb_kuzminsky> see ya's
