Back
[06:31:39] <skunkworks> zlog
[07:22:58] <KGB-linuxcnc> 03Jeff Epler 05jepler/hm2-encoder-dpll c0b64ba 06linuxcnc 10docs/man/man9/hostmot2.9 hm2: improve documentation of timers * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=c0b64ba
[07:22:59] <KGB-linuxcnc> 03Jeff Epler 05jepler/hm2-encoder-dpll e5dd456 06linuxcnc 10src/hal/drivers/mesa-hostmot2/dpll.c hm2: dpll: rename variable to reflect units * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=e5dd456
[07:22:59] <KGB-linuxcnc> 03Jeff Epler 05jepler/hm2-encoder-dpll cffb836 06linuxcnc 10src/hal/drivers/mesa-hostmot2/dpll.c hm2: dpll: fix calculation of period_us * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=cffb836
[07:23:00] <KGB-linuxcnc> 03Jeff Epler 05jepler/hm2-encoder-dpll 357ce42 06linuxcnc 10docs/man/man9/hostmot2.9 10src/hal/drivers/mesa-hostmot2/encoder.c 10src/hal/drivers/mesa-hostmot2/hostmot2.h hm2: encoder: enable dpll when supported by firmware * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=357ce42
[07:23:31] <jepler> PCW, seb_kuzminsky: branch updated based on review notes, and also I figured out why the calculated base-freq-khz was wrong
[07:36:10] <KGB-linuxcnc> 03John Thornton 052.7 f9201c3 06linuxcnc 10docs/src/Submakefile Docs: add missing html directories to make clean * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=f9201c3
[08:56:32] <linuxcnc-build> build #3213 of 1200.rip-lucid-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1200.rip-lucid-i386/builds/3213 blamelist: John Thornton <bjt128@gmail.com>
[09:30:36] <seb_kuzminsky> that test failure is one we see intermittently, a couple of dropped mdi commands somewhere in the shell|nc -> linuxcncrsh -> task stack
[15:59:46] <skunksleep> zlog
[16:16:02] <jepler> skunksleep: it occurs to me to wonder how hard it would be to add maximum path deviation checking to your test setup
[16:16:10] <jepler> with a complex shape like roadrunner it would be hard
[16:17:14] <jepler> but perhaps some simple generated shapes would have feasible path deviation checking but show interesting behavior in the different planners
[16:18:24] <jepler> for instance a path in which Z increases monotonically while it contours in XY makes it pretty easy
[16:18:51] <jepler> Z or A = proportional to XY path length
[16:22:01] <skunksleep> I might not understand what you are explaining...
[16:27:24] <jepler> I might not be explaining it well
[16:27:47] <jepler> you are testing velocity and acceleration
[16:27:56] <jepler> but it would be nice to test if the path is actually followed
[16:28:06] <skunksleep> Agreed
[16:28:10] <jepler> instead of sort of eyeballing it on the backplot
[16:28:58] <seb_kuzminsky> i've thought some about path following testing, as part of the standalone-motion stuff i'm working on
[16:29:51] <jepler> determining the maximum distance between two curves is a lot harder than determining the distance between two points
[16:30:25] <seb_kuzminsky> the way i've imagined doing it is to have a test program that reads a file with a list of emcmot commands (possibly emitted from sai) and emits a list of waypoints (the joint commands from motion at each cycle)
[16:31:00] <seb_kuzminsky> then verification would read the emcmot command file again, and read the list of waypoints, and walk down both files and make sure they agree
[16:31:03] * seb_kuzminsky waves hands
[16:31:13] <jepler> but one way to make it a simpler problem would be: to test 2d contouring, change the program so that Z is increasing
[16:31:27] <jepler> make Z increase uniformly, e.g., for every 1 inch in XY motion, Z increases by .01
[16:31:37] <PCW> Sam problem is harder: how do you match the measured path vs gcode when you have lost any synchronization
[16:31:42] <PCW> Sams
[16:32:12] <jepler> so to determine deviation, you look at Z, compute "correct" XY, and then the distance from feedback XY to correct XY
[16:32:34] <jepler> it's not quite the same as distance-between-curves but it's close
[16:32:42] <seb_kuzminsky> i think you can do it pretty easily if you start on the first emcmot command, and walk along the waypoint list, making sure you stay within the G64P tolerance of the ideal motion, until you come within G64P of the endpoint, then switch to the next emcmot command
[16:32:44] <PCW> Ahh a sync channel
[16:32:57] <jepler> since Z is going uniformly and much slower you don't expect its constraints to be important to the path following
[16:33:54] <skunksleep> Hmmm cool
[16:34:02] <seb_kuzminsky> the checker would also verify soft limits and vel & acc limits
[16:34:18] <jepler> seb_kuzminsky: cool!
[16:34:49] <jepler> seb_kuzminsky: when just testing linuxcnc you could also sample its idea of what the current gcode line is too
[16:35:17] <seb_kuzminsky> this bypasses interp and just tests motion
[16:35:18] <jepler> seb_kuzminsky: did you get a chance to / do you want to review my rerolled encoder dpll branch?
[16:35:29] <seb_kuzminsky> err no i haven't read it yet
[16:35:33] <seb_kuzminsky> i'll read it today
[16:35:35] <seb_kuzminsky> or tonight
[16:35:36] <jepler> seb_kuzminsky: OK but there are still serial numbers or something
[16:35:51] <jepler> but yes you're also right to try to test as small a slice of the software stack as you can
[16:36:32] <jepler> argh the worst thing about being at the mechanic is that they have the TV on to a local TV station
[16:37:13] <jepler> "do you take the medication advertised just before this advertisement? you may be eligible for a class action lawsuit about side effects."
[16:37:22] <seb_kuzminsky> https://learn.adafruit.com/tv-b-gone-kit
[16:37:22] <jepler> "our news program looks like it was recorded on a VHS tape!"
[16:38:30] <jepler> somehow this TV is set to take what appears to be a 4:3 signal and stretch it so it still doesn't fit horizontally on a 16:9 monitor
[16:38:47] <jepler> .. hope you don't want to know the forecast temperature in the western part of the state!
[16:44:18] <PCW> Thanks for adding the encoder DLL support and finding the DPLL frequency setting bug
[16:45:51] <PCW> is x/1000 a integer divide where x/1000. is a float divide?
[17:11:07] <seb_kuzminsky> PCW: in python it is, yes
[17:20:26] <jepler> In C, x/y is integer division if both operands are integers; if one of them is floating-point, it's double-precision.
[17:20:44] <jepler> in python2 the rule is roughly the same
[17:21:21] <jepler> in python3 they decided x/y should always be FP division; x//y is "floor division"
[17:31:13] <mozmck> looks like the // operator works as "floor division" in python 2.7 as well
[17:32:55] <jepler> yes, I was simplifying the story
[17:33:07] <jepler> in python 2.7 you can "from __future__ import division" and get python3's behavior
[17:33:27] <jepler> $ python2.7
[17:33:31] <jepler> >>> 1/3, 1//3
[17:33:31] <jepler> (0, 0)
[17:33:31] <jepler> >>> from __future__ import division
[17:33:31] <jepler> >>> 1/3, 1//3
[17:33:31] <jepler> (0.3333333333333333, 0)
[17:33:32] <mozmck> I just wondered if it would give an error. I didn't do that import...
[17:33:44] <mozmck> oh, I see.
[17:34:15] <mozmck> >>> 3//4.
[17:34:15] <mozmck> 0.0
[17:34:29] <mozmck> :)
[17:37:54] <jepler> $ python3
[17:37:54] <jepler> >>> x = 2**54
[17:37:54] <jepler> >>> (x-1)//x, (x-1)/x
[17:37:55] <jepler> (0, 1.0)
[17:38:45] <jepler> (that second number is exactly the double-precision number 1.0)
[17:49:36] <skunkworks> zlog
[21:09:44] <skunkworks> jepler: so - thinking about what you said earlier..
[21:10:11] <skunkworks> if you has a square
[21:10:22] <skunkworks> g0x0y0z0
[21:10:40] <skunkworks> g1x1y0z.1
[21:11:00] <skunkworks> g1x1y1z.2
[21:11:16] <skunkworks> g1x0y1z.3
[21:11:35] <skunkworks> g1x0y0z.4
[21:12:13] <skunkworks> does this make sense?
[21:12:19] <jepler> yes
[21:13:29] <jepler> so if you sample a position and it's z=2.1 then you know it should be x=.9 y=1
[21:14:21] <jepler> if it's x=.9 y=.99 because this is still the tail-end of the blend, then the error is .01
[21:14:47] <jepler> er something like that
[21:15:01] <skunkworks> so i couldok
[21:17:19] <skunkworks> so i could do more comlicated shapes if i made a table of postitions..
[21:26:17] <Tom_itx> PCW, any idea when you'll have 7i47s in stock? unfortunately it got that board too