Back
[00:07:25] -!- Nick001-shop has quit [Remote host closed the connection]
[00:07:39] -!- Loetmichel has quit [Ping timeout: 244 seconds]
[00:16:26] -!- anarchos has quit [Read error: Connection reset by peer]
[00:18:37] -!- anarchos [anarchos!anarchos@S010600259ce59399.vn.shawcable.net] has joined #linuxcnc-devel
[00:24:25] -!- theorbtwo has quit [Ping timeout: 255 seconds]
[00:25:07] -!- patrickarlt has quit [Quit: Leaving...]
[00:27:40] -!- asdfasd has quit [Ping timeout: 264 seconds]
[00:28:46] -!- sumpfralle1 has quit [Ping timeout: 246 seconds]
[00:49:24] -!- Roguish has quit [Quit: ChatZilla 0.9.91.1 [Firefox 38.0.6/20150605094246]]
[00:52:16] -!- asdfasd1 has quit [Ping timeout: 264 seconds]
[00:57:00] -!- mhaberler has quit [Quit: mhaberler]
[00:57:01] <Tom_itx> pcw_home, will some pins on the 7i90 show logic low by default?
[00:57:30] <Tom_itx> specifically IO 0,1,2,3,18,20 & 21
[00:57:48] <Tom_itx> pretty sure the board is fixed since i get the same result on both boards
[00:58:24] postaL_offline is now known as postaL
[00:58:45] <Tom_itx> i suppose it could depend on the bit file loaded
[00:59:58] -!- Cromaglious has quit [Quit: Page closed]
[01:14:57] -!- Akex_ has quit [Quit: Connection closed for inactivity]
[01:34:52] -!- asdfasd has quit [Ping timeout: 264 seconds]
[01:37:01] -!- Servos4ever has quit [Quit: ChatZilla 0.9.91.1 [SeaMonkey 2.26.1/20140612173529]]
[01:37:28] -!- sector_0 has quit [Quit: Leaving]
[01:41:12] <PCW> all I/O should be high until linuxcnc enables outputs
[01:41:51] <PCW> independent of bit file
[01:42:14] <Tom_itx> it must be the config then or something, both boards show the same IO low
[01:42:36] -!- gyeates has quit [Ping timeout: 252 seconds]
[01:43:15] <PCW> after the driver loads many pins may be low, before, all should be high regardless of config
[01:43:46] <Tom_itx> i was looking at it in hal showconf
[01:44:35] <PCW> once the driver loads many pins may be low (stepgen pins, PWM pins, GPIO set as outpust etc)
[01:44:56] <Tom_itx> i'm pretty sure the board is fixed then
[01:45:41] <PCW> we have a loopback program but its DOS only
[01:45:54] <Tom_itx> hmm
[01:46:08] <Tom_itx> i did make that dos boot thumb drive i could try it
[01:46:34] <Tom_itx> although i feel like it's ok
[01:47:05] <PCW> load a justio config...
[01:47:25] <Tom_itx> i will but i need to strip down a config for it to load
[01:48:26] <PCW> just use halrun
[01:48:28] <PCW> loadrt hostmot2
[01:48:30] <PCW> loadrt hm2_7i90
[01:48:31] <Tom_itx> the 3.3 & 5v look good now
[01:48:39] <PCW> show pins
[01:48:40] <Tom_itx> never tried halrun
[01:48:54] <Tom_itx> from a terminal?
[01:49:00] <PCW> yeah
[01:49:33] <Tom_itx> i put it up for tonight but i'll try it tomorrow
[01:49:52] <PCW> of course I'm not sure anyone has ever tried a GPIO only config
[01:49:54] <PCW> hostmot2 may crash
[01:50:07] <Tom_itx> guess we'll find out
[01:50:46] <Tom_itx> i think i may have done a stripped down config for the justio bit file already, i'll have to look
[01:52:36] <PCW> one of the loopback tests checks the input pullups so I woudl not expect any low pins unless they have been told to be low
[01:52:40] -!- anarchos has quit [Ping timeout: 252 seconds]
[01:53:13] -!- anarchos [anarchos!anarchos@S010600259ce59399.vn.shawcable.net] has joined #linuxcnc-devel
[01:53:42] <PCW> (it drives the outputs low, floats then and the reads the input state)
[01:53:55] <PCW> floats them
[01:54:50] <Tom_itx> what was smflash for? i forgot but it's on the thumbdrive
[01:56:27] -!- adam3999 [adam3999!~adam3999@pool-108-38-17-37.lsanca.fios.verizon.net] has joined #linuxcnc-devel
[02:01:32] <PCW> I think thats a tool for writing 6i25,6i24,7i24 flash from DOS using the bridge GPIO bits (so can boostrap from empty,corrupt flash)
[02:01:53] <PCW> same as mesaflash --recover option
[02:02:02] <Tom_itx> ahh ok
[02:43:27] -!- koo6 has quit [Ping timeout: 248 seconds]
[03:00:04] -!- phantoxeD has quit [Ping timeout: 264 seconds]
[03:07:31] -!- Mr_Sheesh has quit [Remote host closed the connection]
[03:09:36] -!- Mr_Sheesh has quit [Changing host]
[03:11:35] -!- Mr_Sheesh has quit [Remote host closed the connection]
[03:21:57] -!- Mr_Sheesh has quit [Remote host closed the connection]
[03:28:01] -!- AR_ has quit [Ping timeout: 255 seconds]
[03:28:40] -!- ve7it has quit [Remote host closed the connection]
[03:29:31] -!- anarchos has quit [Read error: Connection reset by peer]
[03:30:56] -!- anarchos [anarchos!~anarchos@S010600259ce59399.vn.shawcable.net] has joined #linuxcnc-devel
[03:31:59] -!- Mr_Sheesh has quit [Remote host closed the connection]
[03:41:18] -!- Mr_Sheesh has quit [Excess Flood]
[04:14:01] -!- jvrousseau has quit [Quit: Textual IRC Client: www.textualapp.com]
[04:16:07] -!- zeeshan [zeeshan!~kvirc64@CPE0018e7cea342-CM5039555db2cc.cpe.net.cable.rogers.com] has joined #linuxcnc-devel
[04:17:14] -!- zeeshan|2 [zeeshan|2!~kvirc64@CPE0018e7cea342-CM5039555db2cc.cpe.net.cable.rogers.com] has joined #linuxcnc-devel
[04:21:24] -!- zeeshan has quit [Ping timeout: 277 seconds]
[04:26:33] -!- anarchos has quit [Ping timeout: 276 seconds]
[04:27:34] -!- maximilian_h1 [maximilian_h1!~bonsai@dslb-092-074-048-093.092.074.pools.vodafone-ip.de] has joined #linuxcnc-devel
[04:28:01] -!- anarchos [anarchos!~anarchos@S010600259ce59399.vn.shawcable.net] has joined #linuxcnc-devel
[04:29:13] -!- maximilian_h has quit [Ping timeout: 264 seconds]
[04:39:25] -!- gyeates has quit [Ping timeout: 244 seconds]
[05:10:27] -!- kwallace1 [kwallace1!~kwallace@tmb-228.sonnet.com] has parted #linuxcnc-devel
[05:13:27] -!- Praesmeodymium has quit [Ping timeout: 252 seconds]
[05:13:35] Praesmeodymium|2 is now known as Praesmeodymium
[05:27:40] -!- furrywolf has quit [Ping timeout: 264 seconds]
[05:42:42] -!- mhaberler has quit [Quit: mhaberler]
[06:06:08] -!- anarchos has quit [Ping timeout: 272 seconds]
[07:01:54] -!- zeeshan|2 has quit [Read error: Connection reset by peer]
[07:13:22] -!- mhaberler has quit [Quit: mhaberler]
[07:16:31] -!- syyl has quit [Ping timeout: 246 seconds]
[07:19:23] -!- rob_h [rob_h!~robh@90.220.157.70] has joined #linuxcnc-devel
[07:31:06] -!- Jymmm has quit [Read error: Connection reset by peer]
[07:32:10] -!- PCW_ [PCW_!~chatzilla@99.88.10.65] has joined #linuxcnc-devel
[07:35:35] -!- adam3999 has quit [Ping timeout: 265 seconds]
[07:35:49] -!- PCW has quit [Ping timeout: 264 seconds]
[07:35:50] PCW_ is now known as PCW
[07:51:43] -!- Nutter has quit [Ping timeout: 248 seconds]
[07:51:43] -!- AshKyd has quit [Ping timeout: 248 seconds]
[07:53:19] -!- postaL has quit [Ping timeout: 248 seconds]
[07:53:19] p0staL is now known as postaL
[08:02:17] -!- quiqua has quit [Quit: quiqua]
[08:20:00] Loetmichel2 is now known as Loetmichel
[08:50:59] -!- b_b has quit [Changing host]
[09:04:02] -!- mhaberler has quit [Quit: mhaberler]
[09:19:22] -!- mhaberler has quit [Ping timeout: 246 seconds]
[09:32:21] -!- logger[psha] [logger[psha]!~loggerpsh@195.135.238.205] has joined #linuxcnc-devel
[10:18:44] -!- Tecan has quit [Changing host]
[10:30:45] -!- sumpfralle has quit [Ping timeout: 246 seconds]
[10:43:59] -!- Valen has quit [Remote host closed the connection]
[10:59:29] -!- skunkworks has quit [Ping timeout: 246 seconds]
[11:05:42] -!- remstw has quit [Ping timeout: 272 seconds]
[11:33:21] -!- Tecan has quit [Quit: Live Long And Phosphor!]
[11:36:35] -!- MacGalempsy has quit [Remote host closed the connection]
[11:55:04] -!- skunkworks [skunkworks!~chatzilla@68-115-41-210.static.eucl.wi.charter.com] has joined #linuxcnc-devel
[12:26:09] -!- skunkworks_ [skunkworks_!~skunkwork@68-115-41-210.static.eucl.wi.charter.com] has joined #linuxcnc-devel
[12:28:02] -!- skunkworks has quit [Ping timeout: 244 seconds]
[12:38:34] -!- The_Ball has quit [Quit: Leaving]
[12:58:59] -!- kwallace [kwallace!~kwallace@smb-19.sonnet.com] has joined #linuxcnc-devel
[13:10:07] -!- pingufan has quit [Quit: Konversation terminated!]
[13:12:37] -!- nofxxxx has quit [Ping timeout: 256 seconds]
[13:27:30] -!- dan2k3k4 has quit [Read error: Connection reset by peer]
[13:30:11] -!- ivansanchez has quit []
[13:41:28] -!- wonderr has quit [Ping timeout: 264 seconds]
[13:50:51] <seb_kuzminsky> good morning
[13:51:30] <Tom_itx> morning, gonna be a hot one
[13:52:32] <seb_kuzminsky> "gaah the moon is incredibly bright tonight!?"
[14:16:03] WalterN is now known as tiwake
[14:22:32] -!- Roguish [Roguish!~chatzilla@c-50-143-183-159.hsd1.ca.comcast.net] has joined #linuxcnc-devel
[14:32:14] -!- Thomaxo has quit [Client Quit]
[14:38:28] <skunkworks_> zlog
[14:38:28] <zlog> skunkworks_: Log stored at
http://tom-itx.no-ip.biz:81/~tom-itx/irc/logs/%23linuxcnc-devel/2015-06-23.html
[14:49:38] -!- gyeates has quit [Ping timeout: 252 seconds]
[14:55:05] <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
[14:56:12] <jepler> no
[14:56:26] <jepler> I think M66 and then on the next line #<var>=[#5399]
[14:59:29] <mozmck> Ah, I see that now in the documentation - I missed that. Thanks!
[15:02:35] <seb_kuzminsky> mozmck:
http://img03.deviantart.net/3722/i/2007/356/0/4/mao_rtfm_vectorize_by_cmenghi.png
[15:03:45] <mozmck> read the manual or you'll sic Mao on me?
[15:05:12] <seb_kuzminsky> read the manual or we'll sic laogai on you
[15:05:21] <pcw_home> freeby.mesanet.com/encoder-no-dpll.png
[15:05:22] <seb_kuzminsky> oh wait, you already volunteered for it
[15:05:22] <pcw_home> freeby.mesanet.com/encoder-dpll.png
[15:05:24] <pcw_home> encoder dpll patch works for me
[15:05:59] <seb_kuzminsky> ooh, that looks really good
[15:07:30] <archivist> what noise?...that seems rather good
[15:07:38] -!- choonway has quit [Ping timeout: 246 seconds]
[15:09:30] <pcw_home> its those are count diffs of a 4 MHz count rate sampled at 3 KHZ so a bit odd scaling
[15:09:55] <pcw_home> (ac coupled)
[15:13:55] <skunkworks_> wow
[15:14:46] -!- Demiurge has quit [Ping timeout: 276 seconds]
[15:17:41] -!- zeeshan [zeeshan!~kvirc64@CPE0018e7cea342-CM5039555db2cc.cpe.net.cable.rogers.com] has joined #linuxcnc-devel
[15:20:33] <jepler> seb_kuzminsky: ok for 2.7? I think it's an item you were waiting on..
[15:20:49] <jepler> branch name jepler/hm2-encoder-dpll
[15:21:51] -!- gyeates has quit [Ping timeout: 248 seconds]
[15:26:00] <seb_kuzminsky> is that the branch pcw just tested & reported working?
[15:26:37] -!- dan2k3k4 has quit [Quit: Leaving]
[15:27:11] <jepler> seb_kuzminsky: yes
[15:28:10] <seb_kuzminsky> cool
[15:28:31] <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
[15:28:39] <jepler> hah
[15:29:08] <jepler> comments on the doc changes are welcome too
[15:30:15] <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
[15:30:43] <jepler> I'm a little dissatisfied at how I end up testing dpll_timer_num for equality with written_dpll_timer_num twice
[15:31:10] <jepler> so you think I should just unconditionally write it in the inner function?
[15:33:01] <seb_kuzminsky> at one point the norm was two write functions, one forcing and one not forcing
[15:33:10] <seb_kuzminsky> the force-write function just writes, without thinking about it
[15:33:24] <seb_kuzminsky> the non-force checks if the fpga is in sync, and if not it calls the force-write funtion
[15:33:47] -!- amiri has quit [Ping timeout: 250 seconds]
[15:33:57] <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
[15:35:24] <seb_kuzminsky> then you'd call the non-forcing write in the inner loop, and it usually just returns without writing
[15:35:26] -!- podarok has quit [Remote host closed the connection]
[15:36:31] <seb_kuzminsky> ... but i see that's not how hm2_encoder_write() works, so i'm misremembering & ignore me
[15:37:29] <seb_kuzminsky> the top-level hm2_something_write() checks if *anything* needs writing, and if so it writes *everything*
[15:37:33] * seb_kuzminsky shrugs
[15:37:49] <seb_kuzminsky> it should almost never happen after hal startup, so it's probably fine
[15:37:55] <jepler> yes
[15:38:15] <jepler> OK, I'll respin with hm2_encoder_force_write_dpll_timer writing unconditionally
[15:38:29] <jepler> .. this evening if I have time
[15:38:43] <seb_kuzminsky> i think that would be preferable/safer, thanks
[15:44:29] <jepler> pcw_home: is it possible in theory for the number of dplls to be != 4 ?
[15:44:42] <jepler> .. or I guess it's all one dpll with different offsets, but the question is the same
[15:50:02] amnesic_away is now known as amnesic
[15:52:50] <pcw_home> Sure 4 seemed like enough though
[15:54:09] -!- HSD has quit [Ping timeout: 250 seconds]
[15:55:30] <jepler> I notice that 4 has ended up coded as a constant in a number of places. a real count comes from idrom?
[16:01:47] -!- quiqua has quit [Quit: quiqua]
[16:02:17] <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)
[16:03:33] <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)
[16:09:54] <pcw_home> 2 timers probably adequate for most things (pre-read and post-write)
[16:10:59] -!- HSD has quit [Ping timeout: 246 seconds]
[16:31:54] -!- HSD has quit [Ping timeout: 244 seconds]
[16:40:15] -!- gyeates has quit [Ping timeout: 248 seconds]
[16:48:47] -!- HSD has quit [Remote host closed the connection]
[17:09:09] -!- BellinganRoy has quit [Quit: Konversation terminated!]
[17:29:19] -!- {boboss} has quit [Ping timeout: 248 seconds]
[17:33:36] -!- skunkworks__ [skunkworks__!~skunkwork@68-115-41-210.static.eucl.wi.charter.com] has joined #linuxcnc-devel
[17:36:51] -!- skunkworks_ has quit [Ping timeout: 265 seconds]
[17:39:45] -!- skunkworks__ has quit [Read error: Connection reset by peer]
[17:54:53] -!- skunkworks [skunkworks!~chatzilla@68-115-41-210.static.eucl.wi.charter.com] has joined #linuxcnc-devel
[18:04:29] -!- skunkworks_ [skunkworks_!~skunkwork@68-115-41-210.static.eucl.wi.charter.com] has joined #linuxcnc-devel
[18:05:28] amnesic is now known as amnesic_away
[18:53:46] -!- MrHindsight [MrHindsight!~not_sure@unaffiliated/capthindsight] has joined #linuxcnc-devel
[18:58:46] -!- ve7it [ve7it!~LawrenceG@S01060014d19d0b68.pk.shawcable.net] has joined #linuxcnc-devel
[18:59:59] -!- gyeates has quit [Ping timeout: 248 seconds]
[19:00:25] amnesic_away is now known as amnesic
[19:14:18] -!- patrickarlt has quit [Remote host closed the connection]
[19:18:59] asheppard is now known as sheppard
[19:21:51] -!- SpinniX has quit [Client Quit]
[19:22:32] -!- GJdan has quit [Quit: --upgrade]
[19:30:52] -!- jvrousseau has quit [Ping timeout: 252 seconds]
[19:40:06] -!- dimas_ has quit [Ping timeout: 265 seconds]
[19:48:00] -!- b_b has quit [Remote host closed the connection]
[19:53:47] -!- skunkworks has quit [Ping timeout: 252 seconds]
[19:56:53] -!- skunkworks_ has quit [Read error: Connection reset by peer]
[19:57:06] -!- maurris has quit [Changing host]
[20:14:06] -!- david_____ has quit [Client Quit]
[20:28:19] neiljp__ is now known as neiljp
[20:30:49] -!- skunkworks [skunkworks!~chatzilla@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[20:44:54] -!- Deejay has quit [Quit: bye]
[20:47:40] -!- Roguish has quit [Read error: Connection reset by peer]
[20:48:10] -!- Roguish [Roguish!~chatzilla@c-50-143-183-159.hsd1.ca.comcast.net] has joined #linuxcnc-devel
[20:52:28] -!- skunkworks has quit [Ping timeout: 255 seconds]
[20:53:57] -!- skunkworks [skunkworks!~chatzilla@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[21:00:08] -!- FinboySlick has quit [Quit: Leaving.]
[21:00:25] -!- skunkworks has quit [Ping timeout: 264 seconds]
[21:02:18] -!- HardWall has quit [Read error: Connection reset by peer]
[21:06:56] -!- Pudlo has quit [Quit: Leaving.]
[21:17:59] -!- gonzo_nb has quit [Remote host closed the connection]
[21:18:46] <mozmck> jepler: I'm testing with your hm2_eth patch
http://pastie.org/pastes/10250567/text
[21:18:56] -!- pandeiro has quit [Remote host closed the connection]
[21:19:19] <mozmck> Seems to work with my 7i92 - how all should I test it?
[21:22:53] -!- dimas_ has quit [Ping timeout: 252 seconds]
[21:32:20] -!- skunksleep [skunksleep!~AndChat14@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[21:32:29] <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
[21:34:19] -!- Camaban has quit [Quit: Leaving]
[21:39:22] <seb_kuzminsky> ooh, free shipping
[21:44:59] -!- zeitue has quit [Remote host closed the connection]
[21:47:54] grummund_ is now known as grummund
[21:48:17] -!- maurris has quit []
[21:51:20] <PCW> Sure makes me feel old...
[21:51:57] <seb_kuzminsky> matured, like a fine scotch
[21:59:59] <Tom_itx> no spartan 6 on that one
[22:09:28] -!- koo6 has quit [Ping timeout: 276 seconds]
[22:14:46] <jepler> mozmck: by default it will not use the dpll feature
[22:15:24] <jepler> mozmck: you have to add something like
[22:15:25] <jepler> halcmd: setp hm2_7i80.0.encoder.timer-number 1
[22:15:40] <jepler> halcmd: setp hm2_7i80.0.dpll.01.timer-us -100
[22:15:52] -!- gyeates has quit [Ping timeout: 252 seconds]
[22:16:12] <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
[22:18:15] <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
[22:18:33] <PCW> actually its 100 usec before the _read_ function
[22:19:06] <jepler> pcw_home: OK, noted. let me make sure I didn't put something inaccurate in the docs...
[22:19:11] -!- sumpfralle has quit [Ping timeout: 246 seconds]
[22:19:30] <jepler> hm our existing docs (not added by me) had this:
[22:19:31] <jepler> > Negative numbers indicate that the trigger
[22:19:31] <jepler> should occur prior to the main hostmot2 write.
[22:20:09] <jepler> PCW: there's a particular read that serves to trigger/train the dpll?
[22:20:35] <PCW> I have not found a system so bad that computer busy-ness can cause a 100 usec baseline shift in the read time
[22:21:10] <jepler> also I see that the default is 100, not -100 :-/
[22:21:14] <PCW> Yes the DPLL read or the sync regeister is the first read
[22:21:27] <PCW> of the sync register
[22:22:18] <PCW> yeah a 100 usec default is rather useless
[22:22:20] <jepler> hm and dpll is in 2.6 so we don't have a free hand here
[22:22:30] <jepler> -100 has got to be better than 100 as a default, hasn't it?
[22:22:38] <PCW> yep
[22:23:05] <PCW> well for reads, writes are going to be positive
[22:23:07] -!- furrywolf has quit [Ping timeout: 276 seconds]
[22:23:56] <PCW> (since they need to happen after the last register has been updated)
[22:23:58] <jepler> there are dpll-triggered writes?
[22:24:06] <PCW> Not yet
[22:24:07] <jepler> this is a thing we have now, or a hypothetical thing?
[22:24:09] <jepler> ah
[22:24:52] <jepler> I also don't quite get this in our docs either:
[22:24:53] <jepler> > It is anticipated that this value will
[22:24:54] <jepler> be calculated from the known bit-count and data-rate of the functions to be
[22:24:56] <jepler> triggered. Alternatively you can just keep making the number more negative
[22:25:00] <jepler> until the over-run error bit in the encoder goes false.
[22:25:15] <jepler> this is referring to the initial use of the dpll to trigger reads in one of the serial modules?
[22:25:32] <PCW> The residual errors for stepgens and servo systems were so small it did not seem worth the trouble
[22:25:55] <PCW> I have trouble parsing that...
[22:25:58] <jepler> me too
[22:28:30] <PCW> Oh... for serial encoders you need to set the pretrigger time so the transfer is complete at read time
[22:30:31] <PCW> stuff about bit counts is too much detail probably
[22:34:30] <PCW> the specific serial encoder doc should probably say that the overrun pin is set if you attempt to read old data,
[22:34:31] <PCW> which likely indicates that not enough time has been allotted for the data transfer
[22:34:50] <jepler> I wish I were better at writing documentation
[22:34:55] <jepler> here's what I've come up with at the moment:
http://paste.debian.net/plain/257670
[22:35:54] <PCW> Yeah thats much better
[22:36:51] <jepler> thanks
[22:37:31] <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 )
[22:41:50] <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)
[22:42:10] <jepler> I see.
[22:42:52] <PCW> you can see this in the phase error signal (50 usec is very big though)
[22:43:36] <PCW> on an atom d525 you can get 10 usec baseline shift by moving the mouse
[22:43:43] <jepler> > For stepgen and quadrature encoders, the value needs to be more than the
[22:43:46] <jepler> maximum phase-error-us.
[22:44:29] <PCW> well not really because late is OK
[22:47:39] <jepler> less than the most negative phase-error-us ?
[22:47:48] <jepler> or is the relationship not even as simple as that?
[22:48:07] <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
[22:48:37] <jepler> because the dpll only shifts by a small amount, not 200us
[22:48:54] -!- gyeates has quit [Ping timeout: 246 seconds]
[22:49:04] <PCW> less than the most negative is very close to right
[22:49:22] <jepler> what does phase-error-us show in that situation of a single 200us latency? something like 0, +200, -1?
[22:49:35] <jepler> ..., 0, 0, 0, +200, -1, -.5, ...
[22:50:37] <jepler> > For stepgen and quadrature encoders, the value needs to be less than the most
[22:50:40] <jepler> negative phase-error-us seen after the dpll initially settles. -100 will
[22:50:44] <jepler> suffice for most systems, and -50 will work on systems with good performance
[22:50:46] <PCW> a single sample make very little change (the time constant is in the 1 second region)
[22:50:46] <jepler> and latency.
[22:52:36] <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
[22:52:54] <PCW> and vice versa)
[22:54:34] <jepler> I sure can see what you're talking about in phase-error-us vs system load
[22:55:16] <jepler> and it "rings" for a good long while after I take away the extra system load (while true; do md5sum *; done)
[22:55:30] <PCW> in general my experience is that latency tends to be quite "spikey" and then has a low frequency component thats load dependent
[22:56:12] <PCW> Yeah I need to tune the DPLL a bit so it has better damping
[22:56:12] <jepler> and with system load the overall variability is much higher
[22:57:09] <jepler> tuning in the firmware? I see there are a couple of knobs to turn in hal
[22:57:12] <jepler> (u32, in) hm2_\fI<BoardType>\fR.\fI<BoardNum>\fR.dpll.time-const"
[22:57:15] <jepler> (u32, in) hm2_\fI<BoardType>\fR.\fI<BoardNum>\fR.dpll.plimit"
[22:57:59] <jepler> plimit Default 4194304 (0x400000) Units not known...
[22:58:20] <PCW> Yeah unfortunately the things that control damping factor are in firmware constants
[22:59:52] <PCW> (the ratio of first to second order feedback)
[23:00:22] <jepler> halscope really needs a peak capture mode
[23:00:23] <jepler> built in
[23:00:34] <jepler> every 5 years I say I'm going to write halscope2 and then I get bored
[23:01:30] <PCW> yeah and a ddt value that doesn't disappear when the number gets big
[23:02:39] -!- neiljp has quit [Ping timeout: 248 seconds]
[23:03:07] -!- theorbtwo has quit [Remote host closed the connection]
[23:04:20] <jepler> -50 and -100 seem pretty conservative numbers
[23:04:47] <jepler> I haven't seen a dpll offset less than -8 in several minutes of testing, going from high-load to low-load
[23:05:00] <jepler> "several minutes" is not a very good sample size I know
[23:05:06] <jepler> (at 1kHz fwiw)
[23:05:57] <jepler> -4 happens readily on a transition from idle to busy
[23:06:32] <jepler> idle/busy last 5+s each which was empirically long enough for the dpll to settle
[23:07:17] <jepler> and also on the first 'ring' of the busy->idle transition
[23:07:40] -!- sumpfralle has quit [Ping timeout: 244 seconds]
[23:08:11] <jepler> PCW: I assume there's a good reason that the other firmware constants aren't runtime tunable (gate counts and whatnot)?
[23:11:53] <PCW> Probably just not terribly necessary
[23:12:26] <jepler> bbl
[23:12:34] <PCW> I think I had trouble with a Atom at 50 Usec and 75 fixed it
[23:13:56] <jepler> this is a core2 something, probably a lot faster than the atom
[23:14:06] <jepler> and I'm not using X at the console either
[23:14:13] <PCW> Yeah the Atom is pretty slow
[23:17:53] -!- dimas_ has quit [Ping timeout: 250 seconds]
[23:20:24] <PCW> DPLLCorrection <= FilteredPhaseErr + resize(BoundedPhaseErr(23 downto 4),24);
[23:20:25] <PCW> damping is dependent on this fixed divide by 16...
[23:42:24] -!- mhaberler has quit [Ping timeout: 252 seconds]
[23:42:50] -!- abcdfogl has quit [Read error: Connection timed out]
[23:49:59] amnesic is now known as amnesic_away
[23:55:28] -!- Nick001-shop has quit [Quit: ChatZilla 0.9.91.1 [Firefox 34.0.5/20141126041045]]
[23:56:04] -!- dimas_ has quit [Ping timeout: 276 seconds]
