Back
[09:13:06] <seb_kuzminsky> good morning
[09:13:44] <Tom_itx> morning, gonna be a hot one
[09:14:47] <seb_kuzminsky> "gaah the moon is incredibly bright tonight!?"
[10:00:43] <skunkworks_> zlog
[10:17:20] <mozmck> If I want to set a gcode parameter to the analog value returned be M66, is this a correct way? #<var> = M66 E0 L0 Q0
[10:18:27] <jepler> no
[10:18:40] <jepler> I think M66 and then on the next line #<var>=[#5399]
[10:21:44] <mozmck> Ah, I see that now in the documentation - I missed that. Thanks!
[10:24:50] <seb_kuzminsky> mozmck:
http://img03.deviantart.net/3722/i/2007/356/0/4/mao_rtfm_vectorize_by_cmenghi.png
[10:26:00] <mozmck> read the manual or you'll sic Mao on me?
[10:27:27] <seb_kuzminsky> read the manual or we'll sic laogai on you
[10:27:36] <pcw_home> freeby.mesanet.com/encoder-no-dpll.png
[10:27:37] <seb_kuzminsky> oh wait, you already volunteered for it
[10:27:37] <pcw_home> freeby.mesanet.com/encoder-dpll.png
[10:27:39] <pcw_home> encoder dpll patch works for me
[10:28:14] <seb_kuzminsky> ooh, that looks really good
[10:29:45] <archivist> what noise?...that seems rather good
[10:31:45] <pcw_home> its those are count diffs of a 4 MHz count rate sampled at 3 KHZ so a bit odd scaling
[10:32:10] <pcw_home> (ac coupled)
[10:36:10] <skunkworks_> wow
[10:42:48] <jepler> seb_kuzminsky: ok for 2.7? I think it's an item you were waiting on..
[10:43:04] <jepler> branch name jepler/hm2-encoder-dpll
[10:48:15] <seb_kuzminsky> is that the branch pcw just tested & reported working?
[10:49:26] <jepler> seb_kuzminsky: yes
[10:50:25] <seb_kuzminsky> cool
[10:50:46] <seb_kuzminsky> i'm not a fan of the ternary operator but i know that's a personal problem of mine and not a problem with your code
[10:50:54] <jepler> hah
[10:51:23] <jepler> comments on the doc changes are welcome too
[10:52:30] <seb_kuzminsky> the "hm2_something_force_write_something()" functions generally actually write out the thing htey say they will force-write, but the new hm2_encoder_force_write_dpll_timer() skips the write if it thinks the fpga is in sync with the driver
[10:52:58] <jepler> I'm a little dissatisfied at how I end up testing dpll_timer_num for equality with written_dpll_timer_num twice
[10:53:24] <jepler> so you think I should just unconditionally write it in the inner function?
[10:55:16] <seb_kuzminsky> at one point the norm was two write functions, one forcing and one not forcing
[10:55:25] <seb_kuzminsky> the force-write function just writes, without thinking about it
[10:55:39] <seb_kuzminsky> the non-force checks if the fpga is in sync, and if not it calls the force-write funtion
[10:56:12] <seb_kuzminsky> this was so the force-write function can be called to resync, for example after a failed write due to epp timeout or watchdog bite
[10:57:39] <seb_kuzminsky> then you'd call the non-forcing write in the inner loop, and it usually just returns without writing
[10:58:46] <seb_kuzminsky> ... but i see that's not how hm2_encoder_write() works, so i'm misremembering & ignore me
[10:59:44] <seb_kuzminsky> the top-level hm2_something_write() checks if *anything* needs writing, and if so it writes *everything*
[10:59:48] * seb_kuzminsky shrugs
[11:00:04] <seb_kuzminsky> it should almost never happen after hal startup, so it's probably fine
[11:00:10] <jepler> yes
[11:00:30] <jepler> OK, I'll respin with hm2_encoder_force_write_dpll_timer writing unconditionally
[11:00:44] <jepler> .. this evening if I have time
[11:00:58] <seb_kuzminsky> i think that would be preferable/safer, thanks
[11:06:44] <jepler> pcw_home: is it possible in theory for the number of dplls to be != 4 ?
[11:06:56] <jepler> .. or I guess it's all one dpll with different offsets, but the question is the same
[11:15:05] <pcw_home> Sure 4 seemed like enough though
[11:17:44] <jepler> I notice that 4 has ended up coded as a constant in a number of places. a real count comes from idrom?
[11:24:32] <pcw_home> No its just a constant (theres no real module description in the IDROM, just the base address and number of global/instance registers)
[11:25:48] <pcw_home> If I did it again there would be some more description (so a generic driver would work at least in a a basic way with any hardware)
[11:32:09] <pcw_home> 2 timers probably adequate for most things (pre-read and post-write)
[16:41:01] <mozmck> jepler: I'm testing with your hm2_eth patch
http://pastie.org/pastes/10250567/text
[16:41:34] <mozmck> Seems to work with my 7i92 - how all should I test it?
[16:54:44] <skunksleep> http://www.ebay.com/itm/Mesa-Electronics-CNC-PCB-6M20-Circuit-Board-GM20-6M2O-off-Bryant-Grinder-/390111208735?pt=LH_DefaultDomain_0&hash=item5ad470a51f
[17:01:38] <seb_kuzminsky> ooh, free shipping
[17:13:35] <PCW> Sure makes me feel old...
[17:14:12] <seb_kuzminsky> matured, like a fine scotch
[17:22:14] <Tom_itx> no spartan 6 on that one
[17:37:01] <jepler> mozmck: by default it will not use the dpll feature
[17:37:39] <jepler> mozmck: you have to add something like
[17:37:40] <jepler> halcmd: setp hm2_7i80.0.encoder.timer-number 1
[17:37:55] <jepler> halcmd: setp hm2_7i80.0.dpll.01.timer-us -100
[17:38:27] <jepler> and after you do this, your encoder-based system should have better following because timing variations in reading the encoder positions will be removed by the magic of dpll
[17:40:07] <jepler> -100 means that the encoder counts will be latched 100us before the hostmot2 "write" function, pcw seemed to indicate that -100 is a number that should work even on a mediocre system, and that fast systems can use closer to -50 .. but I don't know how to tune this number
[17:40:49] <PCW> actually its 100 usec before the _read_ function
[17:41:21] <jepler> pcw_home: OK, noted. let me make sure I didn't put something inaccurate in the docs...
[17:41:45] <jepler> hm our existing docs (not added by me) had this:
[17:41:46] <jepler> > Negative numbers indicate that the trigger
[17:41:46] <jepler> should occur prior to the main hostmot2 write.
[17:42:24] <jepler> PCW: there's a particular read that serves to trigger/train the dpll?
[17:42:50] <PCW> I have not found a system so bad that computer busy-ness can cause a 100 usec baseline shift in the read time
[17:43:25] <jepler> also I see that the default is 100, not -100 :-/
[17:43:29] <PCW> Yes the DPLL read or the sync regeister is the first read
[17:43:42] <PCW> of the sync register
[17:44:33] <PCW> yeah a 100 usec default is rather useless
[17:44:36] <jepler> hm and dpll is in 2.6 so we don't have a free hand here
[17:44:45] <jepler> -100 has got to be better than 100 as a default, hasn't it?
[17:44:53] <PCW> yep
[17:45:20] <PCW> well for reads, writes are going to be positive
[17:46:11] <PCW> (since they need to happen after the last register has been updated)
[17:46:14] <jepler> there are dpll-triggered writes?
[17:46:21] <PCW> Not yet
[17:46:22] <jepler> this is a thing we have now, or a hypothetical thing?
[17:46:24] <jepler> ah
[17:47:08] <jepler> I also don't quite get this in our docs either:
[17:47:09] <jepler> > It is anticipated that this value will
[17:47:09] <jepler> be calculated from the known bit-count and data-rate of the functions to be
[17:47:12] <jepler> triggered. Alternatively you can just keep making the number more negative
[17:47:15] <jepler> until the over-run error bit in the encoder goes false.
[17:47:30] <jepler> this is referring to the initial use of the dpll to trigger reads in one of the serial modules?
[17:47:47] <PCW> The residual errors for stepgens and servo systems were so small it did not seem worth the trouble
[17:48:10] <PCW> I have trouble parsing that...
[17:48:13] <jepler> me too
[17:50:45] <PCW> Oh... for serial encoders you need to set the pretrigger time so the transfer is complete at read time
[17:52:46] <PCW> stuff about bit counts is too much detail probably
[17:56:45] <PCW> the specific serial encoder doc should probably say that the overrun pin is set if you attempt to read old data,
[17:56:46] <PCW> which likely indicates that not enough time has been allotted for the data transfer
[17:57:05] <jepler> I wish I were better at writing documentation
[17:57:10] <jepler> here's what I've come up with at the moment:
http://paste.debian.net/plain/257670
[17:58:09] <PCW> Yeah thats much better
[17:59:06] <jepler> thanks
[17:59:46] <PCW> a technoquibble: the time is actually not the maximum difference between read times ( a delay spike of 250 usec is harmless at 1 KHz )
[18:04:05] <PCW> late is ok early is bad, only way to be early is a DPLL baseline shift (computer gets busy for 0.1 seconds, shifting the DPLL baseline (which tracks average delay) later 50 usec and so you just lost your 50 usec margin)
[18:04:25] <jepler> I see.
[18:05:07] <PCW> you can see this in the phase error signal (50 usec is very big though)
[18:05:51] <PCW> on an atom d525 you can get 10 usec baseline shift by moving the mouse
[18:05:58] <jepler> > For stepgen and quadrature encoders, the value needs to be more than the
[18:06:01] <jepler> maximum phase-error-us.
[18:06:45] <PCW> well not really because late is OK
[18:09:54] <jepler> less than the most negative phase-error-us ?
[18:10:03] <jepler> or is the relationship not even as simple as that?
[18:10:22] <PCW> In other words say I have a poor Preempt-RT system and it has latencies of 200 usec occasionally. this does not mean that read latching needs to be 200 usec early
[18:10:52] <jepler> because the dpll only shifts by a small amount, not 200us
[18:11:19] <PCW> less than the most negative is very close to right
[18:11:37] <jepler> what does phase-error-us show in that situation of a single 200us latency? something like 0, +200, -1?
[18:11:51] <jepler> ..., 0, 0, 0, +200, -1, -.5, ...
[18:12:52] <jepler> > For stepgen and quadrature encoders, the value needs to be less than the most
[18:12:55] <jepler> negative phase-error-us seen after the dpll initially settles. -100 will
[18:12:59] <jepler> suffice for most systems, and -50 will work on systems with good performance
[18:13:01] <PCW> a single sample make very little change (the time constant is in the 1 second region)
[18:13:02] <jepler> and latency.
[18:14:52] <PCW> yeah it is subtle because it depends on the latency statistics (you can have systems with large latency peaks but good average latency statistics
[18:15:09] <PCW> and vice versa)
[18:16:49] <jepler> I sure can see what you're talking about in phase-error-us vs system load
[18:17:31] <jepler> and it "rings" for a good long while after I take away the extra system load (while true; do md5sum *; done)
[18:17:45] <PCW> in general my experience is that latency tends to be quite "spikey" and then has a low frequency component thats load dependent
[18:18:27] <PCW> Yeah I need to tune the DPLL a bit so it has better damping
[18:18:27] <jepler> and with system load the overall variability is much higher
[18:19:24] <jepler> tuning in the firmware? I see there are a couple of knobs to turn in hal
[18:19:27] <jepler> (u32, in) hm2_\fI<BoardType>\fR.\fI<BoardNum>\fR.dpll.time-const"
[18:19:30] <jepler> (u32, in) hm2_\fI<BoardType>\fR.\fI<BoardNum>\fR.dpll.plimit"
[18:20:14] <jepler> plimit Default 4194304 (0x400000) Units not known...
[18:20:35] <PCW> Yeah unfortunately the things that control damping factor are in firmware constants
[18:22:08] <PCW> (the ratio of first to second order feedback)
[18:22:37] <jepler> halscope really needs a peak capture mode
[18:22:38] <jepler> built in
[18:22:49] <jepler> every 5 years I say I'm going to write halscope2 and then I get bored
[18:23:45] <PCW> yeah and a ddt value that doesn't disappear when the number gets big
[18:26:35] <jepler> -50 and -100 seem pretty conservative numbers
[18:27:02] <jepler> I haven't seen a dpll offset less than -8 in several minutes of testing, going from high-load to low-load
[18:27:15] <jepler> "several minutes" is not a very good sample size I know
[18:27:21] <jepler> (at 1kHz fwiw)
[18:28:12] <jepler> -4 happens readily on a transition from idle to busy
[18:28:48] <jepler> idle/busy last 5+s each which was empirically long enough for the dpll to settle
[18:29:32] <jepler> and also on the first 'ring' of the busy->idle transition
[18:30:26] <jepler> PCW: I assume there's a good reason that the other firmware constants aren't runtime tunable (gate counts and whatnot)?
[18:34:08] <PCW> Probably just not terribly necessary
[18:34:42] <jepler> bbl
[18:34:49] <PCW> I think I had trouble with a Atom at 50 Usec and 75 fixed it
[18:36:11] <jepler> this is a core2 something, probably a lot faster than the atom
[18:36:21] <jepler> and I'm not using X at the console either
[18:36:28] <PCW> Yeah the Atom is pretty slow
[18:42:39] <PCW> DPLLCorrection <= FilteredPhaseErr + resize(BoundedPhaseErr(23 downto 4),24);
[18:42:40] <PCW> damping is dependent on this fixed divide by 16...
[20:23:43] <skunkworks> zlog
[20:52:22] <mozmck> jepler: sorry, I was talking about the patch that makes hm2_eth do more of the iptables setup
[20:52:51] <mozmck> I'm working with stepper systems, so I presume the dpll fixes won't help that?
[21:16:06] <skunksleep> They do. Dpll
[21:16:48] <skunksleep> I think you need to run the steppers in velocity mode
[21:16:56] <skunksleep> Pid
[21:17:23] <skunksleep> (Which you should anyway)
[21:45:17] <mozmck> Ok, I do use dpll, but all this discussion was about encoder dpll?
[21:46:34] <mozmck> I have setp hm2_7i92.0.dpll.01.timer-us -50
[21:46:55] <mozmck> and setp hm2_7i92.0.stepgen.timer-number 1
[22:30:22] <pcw_home> Yeah stepgen was first (after serial encoders) with DPLL support
[23:03:33] <mozmck> So does that mean that stepgen will also be improved by the fix?
[23:05:57] <skunksleep> I think the fix was adding dpll for encoders
[23:06:12] <mozmck> ok
[23:24:53] <pcw_home> Yeah the stepgen was already fixed
[23:26:00] <pcw_home> only further improvement I can see is adding accel to the hardware
[23:28:45] <pcw_home> which is not much of an improvement unless you need high accuracy at low thread rates
