Back
[08:46:58] <skunkworks> hmm
https://groups.yahoo.com/neo/groups/mach1mach2cnc/conversations/messages/148029
[08:51:03] <archivist> touched a raw nerve :)
[08:56:01] <skunkworks> it's ok.. Other controllers do the same thing.
[09:00:23] <pcw_home> wonder if they ever checked what is was actually doing?
[09:03:03] <skunkworks> I really doubt it...
[09:14:54] <skunkworks> art made some comment about mit students anylizing the ouput of mach.
[09:20:46] <pcw_home> Kind of hard to make the argument that acceleration needs to be "hit harder" when they have lookahead
[09:27:36] <pcw_home> I've heard someone supporting the GRBL style acceleration violations (acceleration violations only for bounded distance for stepper systems)
[09:31:19] <pcw_home> At low speeds this can possibly improve performance since for most useful torque in a stepper
[09:31:20] <pcw_home> you want to lead the stator by a full step at all times (what a servo does by commutation)
[09:31:21] <archivist> I wonder if they are dreaming the microstepping is going to save their bacon
[09:34:06] <pcw_home> probably a much better way to do this lead is to supply a acceleration dependent lead to the position
[09:34:55] <pcw_home> since you are pulling the rotor around with a "spring"
[09:35:42] <archivist> one step lead would be a cogging situation methinks, part of a step I agree
[09:36:37] <archivist> depends on the magnetics of that rotor I suppose
[09:37:29] <pcw_home> one step lead is how BLDC/PMSM servo drives work (90 electrical degrees so all Q and no D)
[09:38:53] <pcw_home> that is stator field applying torque, not trying to pull the rotor apart which is what a step motor does most of the time
[09:40:22] <archivist> I am thinking of those not made so accurately so keeping it under the max torque situation for reliability
[09:47:06] <pcw_home> Yeah, in a normal step motor system you have no idea what the rotor is doing so you have to be conservative
[10:12:57] <jepler> pcw_home: for stepgen, does the dpll control when the new velocity command is latched, or when the position feedback is latched? for encoder, I assume it is when position feedback is latched...
[10:13:40] <jepler> ah in regmap it says for sampling position
[10:14:11] <pcw_home> just position feedback currently (the errors from variable velocity update timing are very small so probably not worth doing)
[10:21:17] <jepler> so if I put a ddt on position-fb I should see that it is much more stable when the dds is used than when it is not
[10:21:29] <jepler> er the pll
[10:22:15] <seb_kuzminsky> good morning
[10:22:22] <jepler> hi seb_kuzminsky
[10:22:33] <seb_kuzminsky> does anyone know how rob is coming with the latest tp fix?
[10:23:34] <skunkworks> I emailed him last week and he said he hoped to look at it this week.
[10:23:58] <seb_kuzminsky> ok thanks
[10:26:46] <pcw_home> http://freeby.mesanet.com/stepgen-residual-errors.png
[10:26:48] <pcw_home> heres an example of the residual errors caused by delays in writing the velocity
[10:32:05] <pcw_home> The following errors track the delays visible in the dpll-phase-error-us
[10:32:06] <pcw_home> these errors are so small they are swamped by mechanical errors or
[10:32:08] <pcw_home> chord errors (due to stepped velocity) so I have not worried about them
[10:36:08] <pcw_home> ( the largest error spike is due to FF2 being late since its calculated by a difference and not provided by the TP with all pipeline delays equalized)
[10:36:59] <skunkworks> that is still just .000003?
[10:38:19] <pcw_home> yes...
[10:41:20] <skunkworks> wow
[10:41:26] <pcw_home> none of those errors are important on real machines, but position sampling is
[10:41:27] <pcw_home> since the sample noise is multiplied by the P term and bogus corrections are made
[10:55:56] <jepler> to try it for encoders, I would raw write 0x9000 at 0x3500 to use timer 1 and then set dpll.01.timer-us to .. what ?
[10:58:14] <jepler> is the "d" suffix for dpll? testing with 7i80hd_16_svst1_5_7i47.bit
[11:13:45] <pcw_home> Thats right I think I need to make up a new bitfile with encoder DPLL (you can check by setting the timer select bits and reading them back)
[11:15:10] <pcw_home> the timer is set earlier than the largest baseline drift (I use -50 usec on good systems and -100 on lousy)
[11:15:44] <pcw_home> (minus means latch _before_ the nominal read time)
[11:18:13] <skunkworks> https://groups.yahoo.com/neo/groups/mach1mach2cnc/conversations/messages/148031
[11:25:11] <jepler> 2964/2944sut not be supported in my fw
[11:25:14] <jepler> errr
[11:25:22] <jepler> it reads back as FFFFFFFF so it must not be supported in my fw
[11:25:58] <jepler> afk
[11:26:48] <pcw_home> Yeah only a few test bitfiles have the encoder DPLL sampling option. (though any new one built with DPLL will get that option included)
[11:28:06] <pcw_home> skunkworks likes to poke a stick in the hornets nest...
[11:34:37] <pcw_home> actually too long a sample interval can only result in lower acceleration readings...
[11:34:38] <pcw_home> I like the "you measured it wrong, it works well in practise but we are going to fix it" response
[11:39:20] <mozmck> heh!
[11:46:48] <skunkworks> PVT?
[11:49:17] <skunkworks> ah - position-velocity-time
[11:53:39] <jepler> pcw_home: so there are configs with dpll that works with stepgen but not with encoder? (er I should have said, testing with ...7i47d.bit, it does have that d suffix)
[11:53:54] <jepler> pcw_home: can I tell by looking at encoder version, or just at how the register reads back?
[11:59:38] <jepler> seb_kuzminsky: can I do llio reads/writes during hm2_encoder_parse_md ?
[12:01:03] <PCW> currently you can only tell by what the timer select register reads back
[12:01:04] <PCW> (the stepgen driver code does this to check the encoder DPLL support code could clone that)
[12:01:11] <jepler> ah will check
[12:03:51] <PCW> I would be nice to have a encoder/stepgen version change but its too disruptive to older systems
[12:03:53] <PCW> sure wish I had started with a major/minor version system so minor changes/added capabilities could work with older drivers
[12:05:45] <jepler> I actually don't see in the source code where it does this write / read back test for the dpll timer number
[12:05:47] <Tom_itx> draw a line in the sand and say 'these files work with newer boards'
[12:07:18] <PCW> yeah except it already takes 1/2 a day to update some sets of card bitfiles I really dont want to double that time
[12:08:52] <PCW> that test should be in the stepgen code somewhere
[12:24:58] <seb_kuzminsky> jepler: yeah, any time
[13:42:59] <PCW> freeby.mesanet.com/7i80hd_16_svst1_5_7i47d.bit
[13:43:00] <PCW> should have DPLLtimers on stepgens and encoders
[13:43:17] <skunkworks> zlog
[14:56:22] <jepler> pcw_home: yup now I can see a difference in ddt(encoder.NN.position) with that firmware
[15:01:12] <jepler> I'm not sure why I'm getting the specific velocity I'm getting, though
[15:01:38] <PCW> I tested it by looping back a stepgen
[15:01:43] <jepler> me too
[15:02:24] <jepler> I have my stepgen with step_type = 2, position-scale 1000, steplen=stepspace=1000, maxvel=0
[15:03:03] <jepler> anyway, stepgen's velocity-cmd is 1000 and velocity-fb is 500
[15:03:19] <jepler> encoder has scale 1000 and velocity 1961
[15:03:54] <jepler> I expected encoder velocity to match stepgen velocity
[15:04:42] <jepler> anyway with the dpll selected by register at 0x3500, I get ddt(position-fb)=1961+0-1. when off, it's +-10 or so
[15:04:45] <PCW> Yeah thats what you would expect but the stepgen scaling is funny in quadrature mode
[15:08:04] <PCW> (4 edges per accumulator count)
[15:09:22] <PCW> I think you are running out of headroom at those settings
[15:09:38] <jepler> ah must be
[15:09:49] <jepler> with velocity-cmd 400 I get encoder velocity 1600
[15:10:25] <PCW> 1000 counts/unit * 1000 units/second = faster that you can go with 1000/1000 step times
[15:11:18] <PCW> for quadrature you can set the step times to 50 ns or so
[15:11:22] <jepler> seems like I've found a case where stepgen velocity-fb is incorrect then
[15:12:21] <PCW> the 4x encoder velocity is expected for quadrature
[15:12:44] <jepler> but I had stepgen velocity-fb 500 and encoder velocity 1960
[15:15:06] <PCW> thats about right (running into the 1/(1000ns+1000ns) limit
[15:16:28] <PCW> you can set the velocity as fast as you like but the hardware is limited by step-length and step-space so the stepgen wont run any faster
[15:22:03] <PCW> the fact that the encoder velocity is 1960 instead of 2000 may be due to various rounding errors and stepgen pipeline delays
[15:22:05] <PCW> that is, the maximum speed it will run if its running out of headroom is not exactly 1/(steplength+stepspace) but a bit less
[15:38:22] <jepler> right
[15:38:35] <jepler> but shouldn't stepgen velocity-fb take all that into account?
[15:43:24] <jepler> http://emergent.unpythonic.net/files/sandbox/encoder-dpll-disabled.png http://emergent.unpythonic.net/files/sandbox/encoder-dpll-enabled.png
[15:44:08] <jepler> I don't know what to expect phase-error to look like, but it's interesting to me that it alternates being above and below 0 by a fairly big step.
[15:45:53] <jepler> I see your plot doesn't look far different, I guess it's typical
[15:54:53] <PCW> yeah my plots are similar (and there will be large spikes) If you move the mouse or do something else that busies the computer you can see the baseline shift
[15:56:58] <PCW> if you have huge steps (100 usec) you probably have interrupt coalescing enabled on your MAC
[16:00:45] <PCW> BTW there's a minor math bug somewhere in the DPLL frequency setting
[16:05:55] <PCW> The default frequency setting is off, that is if you set the servo thread to 3 Khz (333333 ns) the DPLL setting is 3.003003 KHz (~0.1% high)
[16:05:57] <PCW> which causes an offset in the phase error but if you setp the DPLL frequency to 3 KHz its all fixed
[16:13:00] <jepler> I'm using a 1ms thread and the automatic setting seems to be right. setting it to 1.001 gave a clear offset
[16:13:40] <PCW> yeah 1 and 2 and 4 work 3 is wrong
[16:15:33] <jepler> when somebody tracks down that bug it'll be obvious in retrospec
[16:15:34] <jepler> t
[16:16:00] <PCW> seems like a rounding bug somewhere
[16:39:10] <jepler> when I zoom in on the individual wobbles of velocity, I can see that they consist of 1 more cycle of +1 than -1
[16:39:36] <jepler> so I think the true rate is 2000+epsilon
[16:40:07] <jepler> but that's also down to how well the clocks agree between linux and the hm2 board, and we know that's not perfect by any means
[16:42:24] <PCW> The DPLL filter is not perfect either
[16:43:18] <PCW> I could improve the damping factor a bit
[16:47:11] <PCW> I would expect to be within 100 PPM or so (7I80 is +-50 PPM, PC should be similar))
[16:48:20] <PCW> (not that its terribly important)
[16:58:35] <jepler> in that trace I captured, I think the nominal rate is 1600*1000 edges/second. 14 edges are gained over 500ms. 1600028/1600000-1 is 17.5ppm, so it's actually quite decent agreement
[16:59:27] <jepler> or did I miss a 0 in there somewhere?
[16:59:39] <jepler> no I think that's right
[17:22:04] <KGB-linuxcnc> 03Jeff Epler 05jepler/hm2-encoder-dpll f687ca9 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=f687ca9
[17:22:05] <KGB-linuxcnc> 03Jeff Epler 05jepler/hm2-encoder-dpll 841ae71 06linuxcnc 10docs/man/man9/hostmot2.9 hm2: improve documentation of timers on ssi, stepgen * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=841ae71
[17:24:51] <jepler> pcw_home: branch jepler/hm2-encoder-dpll for you to test if you're so inclined
[17:25:58] <KGB-linuxcnc> 03Jeff Epler 05master c4ea03c 06linuxcnc 10docs/src/Submakefile 10docs/src/gui/gmoccapy.txt Merge remote-tracking branch 'origin/2.7' * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=c4ea03c
[17:54:43] <PCW> I'll give it a test tomorrow
[20:19:16] <Tom_itx> pcw_home, will some pins on the 7i90 show logic low by default?
[20:19:45] <Tom_itx> specifically IO 0,1,2,3,18,20 & 21
[20:20:02] <Tom_itx> pretty sure the board is fixed since i get the same result on both boards
[20:21:00] <Tom_itx> i suppose it could depend on the bit file loaded
[21:03:26] <PCW> all I/O should be high until linuxcnc enables outputs
[21:04:06] <PCW> independent of bit file
[21:04:29] <Tom_itx> it must be the config then or something, both boards show the same IO low
[21:05:30] <PCW> after the driver loads many pins may be low, before, all should be high regardless of config
[21:06:00] <Tom_itx> i was looking at it in hal showconf
[21:06:50] <PCW> once the driver loads many pins may be low (stepgen pins, PWM pins, GPIO set as outpust etc)
[21:07:11] <Tom_itx> i'm pretty sure the board is fixed then
[21:07:55] <PCW> we have a loopback program but its DOS only
[21:08:09] <Tom_itx> hmm
[21:08:22] <Tom_itx> i did make that dos boot thumb drive i could try it
[21:08:48] <Tom_itx> although i feel like it's ok
[21:09:20] <PCW> load a justio config...
[21:09:39] <Tom_itx> i will but i need to strip down a config for it to load
[21:10:41] <PCW> just use halrun
[21:10:42] <PCW> loadrt hostmot2
[21:10:44] <PCW> loadrt hm2_7i90
[21:10:46] <Tom_itx> the 3.3 & 5v look good now
[21:10:53] <PCW> show pins
[21:10:55] <Tom_itx> never tried halrun
[21:11:08] <Tom_itx> from a terminal?
[21:11:14] <PCW> yeah
[21:11:48] <Tom_itx> i put it up for tonight but i'll try it tomorrow
[21:12:06] <PCW> of course I'm not sure anyone has ever tried a GPIO only config
[21:12:08] <PCW> hostmot2 may crash
[21:12:22] <Tom_itx> guess we'll find out
[21:13:01] <Tom_itx> i think i may have done a stripped down config for the justio bit file already, i'll have to look
[21:14:50] <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
[21:15:57] <PCW> (it drives the outputs low, floats then and the reads the input state)
[21:16:09] <PCW> floats them
[21:17:05] <Tom_itx> what was smflash for? i forgot but it's on the thumbdrive
[21:23:47] <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)
[21:24:07] <PCW> same as mesaflash --recover option
[21:24:17] <Tom_itx> ahh ok
