Back
[00:36:32] <CIA-1> EMC: 03m-mcknight 07master * r5bdc6cfe54b8 10/src/configure.in: configure.in fix: added function to fully expand a variable (recursive eval)
[00:37:33] <PCW> Sebastian around?
[09:02:45] <hpbock> you might be interested in this SERCOS III linux driver announcement:
http://dwarf.members.selfnet.de/hpblog/?p=35
[09:12:13] <alex_joni> hpbock: nicer
[09:12:16] <alex_joni> hpbock: nice
[09:24:40] <micges> alex_joni: hi
[09:25:11] <alex_joni> micges: hello
[09:26:22] <micges> I've readed that there was discussion about removing iocontrol.cc and move all to task?
[09:27:36] <alex_joni> well.. actually to motion
[09:27:36] <micges> I'm asking becouse I've second atempt to write rack tool changer (nicer and more compatibile with core emc)
[09:28:05] <alex_joni> I see
[09:33:50] <micges> heh yes motion is better place for that ;)
[11:43:05] <cradek> alex_joni: that patch makes no sense at all
[11:43:37] <cradek> bbl
[11:48:31] <alex_joni> cradek: didn't have time to look it over thoroughly
[12:38:11] <jepler> if I understand which patch you need, it looks like it's mostly non-semantic formatting changes. reject for that reason alone: it's impossible to tell what the patch is really doing
[12:55:53] <cradek> it has at least one thing that must be mistakenly included (changing rcs_print to printf)
[12:56:10] <cradek> maybe other stuff too - there's so much noise it's impossible to tell what is meant
[12:57:35] <micges> I hasn't any of my patches to emctaskmain.cc
[12:57:38] <cradek> and a bunch of code is commented and functions are renamed to start with L_ ? Wonder what L_ is
[12:57:41] <micges> it
[12:58:38] <cradek> micges: did you fix this bug already anyway?
[12:59:19] <micges> no
[13:13:26] <micges> I see that he's messing with interp_list.clear() in readahead_reading()
[13:14:00] <micges> He moved it deeper into if {} switch
[13:15:48] <SWPadnos> I'm glad it's not just me who can't make heads or tails of that patch
[13:31:54] <jepler> cradek: local? lazy? lumpy? long?
[13:43:04] <CIA-1> EMC: 03micges 07master * rec24e13770d6 10/src/emc/nml_intf/ (emc.hh emcglb.h): Remove obsolete enums and defs
[13:56:04] <cradek> jepler: Liu maybe
[13:57:23] <SWPadnos> that patch is an instance of why I wanted a way to use meld (or something) to see a "before and after" view of a file
[13:59:10] <micges> his intentional changes didn't work, I think he accidentally fix this bug ;)
[14:00:52] <micges> bbl
[15:14:26] <skunkworks_> SWPadnos: did you figure out if it is 2.0?
[15:19:51] <SWPadnos> nope, haven't taken the time yet
[16:46:03] <CIA-1> EMC: 03micges 07joints_axes3 * rb5945b8aa011 10/src/emc/ini/initraj.cc: remove unused vars, update comments
[17:02:06] <CIA-1> EMC: 03micges 07joints_axes3 * r496dff139768 10/src/emc/ini/ (inijoint.cc inijoint.hh initraj.cc): More comments update, add check errors of emcJointActivate() call
[20:02:34] <CIA-1> EMC: 03micges 07joints_axes3 * r5a93d5ff5a74 10/src/emc/task/taskintf.cc: Allow missed axes in inifile (like XYZBC)
[20:03:24] <micges> good night all
[20:36:41] <seb_kuzminsky> hi PCW
[20:36:49] <PCW> Hi Sebastian
[20:37:27] <PCW> Got a question on the velocity estimation/timestamp logic
[20:37:35] <seb_kuzminsky> shooyt
[20:37:40] <seb_kuzminsky> -y
[20:38:25] <PCW> If you had a bit to lose in the timestamp/count register, which bit would be least painful to lose?
[20:38:59] <PCW> (I'm thinking the LSB of the timestamp)
[20:39:07] <PCW> (LSb)
[20:39:31] <seb_kuzminsky> my first thought is the MSb of the count
[20:39:33] <seb_kuzminsky> because:
[20:39:41] <seb_kuzminsky> 1 KHz servo loop
[20:39:57] <seb_kuzminsky> let's say 10 K rpm at the encoder
[20:40:18] <seb_kuzminsky> let's say 1024 lines on the encoder, so 4k edges/rev
[20:40:37] <seb_kuzminsky> 166 revs/second
[20:40:53] <seb_kuzminsky> 680k edges/second
[20:40:59] <seb_kuzminsky> 680 edges/servo loop
[20:41:34] <seb_kuzminsky> as long as the delta-count per servo loop is less than half the range of the count register we're fine
[20:41:59] <seb_kuzminsky> but maybe i'm missing something there
[20:42:09] <seb_kuzminsky> what are you thinking of using the extra bit for?
[20:42:51] <PCW> A flag bit to indicate that you should not use the timestamp
[20:43:41] <seb_kuzminsky> why would that be useful?
[20:43:49] <PCW> The other way of looking at it is a direction reversal indicator
[20:46:05] <skunkworks_> like if the servo is dithering?
[20:46:12] <seb_kuzminsky> the MSb of the timestamp reg would probably work well too
[20:46:44] <seb_kuzminsky> the bit would mean "there has been at least one direction-change since last time you read the register"?
[20:46:53] <seb_kuzminsky> and the driver should report 0 vel in this case?
[20:48:19] <PCW> Here's the problem: at low speeds/reversals you can get a very short time delta with a 1 count change
[20:48:21] <PCW> because say A goes high rigth at the end of one sample interval and then goes low right at the beginning of the next
[20:48:22] <PCW> so the time between A going high and low could be very short but 1 count would be registers leading to a possibly very high
[20:48:24] <PCW> velocity estimate
[20:50:16] <PCW> I haven't decided whether to have a sticky bit or just a status bit to indicate that the time is a A-A or B-B time
[20:50:17] <PCW> in which case it should not be trusted, and the velocity estimate set to 0
[20:50:31] <PCW> (time meaning timestamp)
[20:52:48] <PCW> Noticed this while working with M/N velocity estimation used for PID KD
[20:52:50] <PCW> (not HostMot2, PIC CPU)
[20:52:51] <PCW> Motor damping had sand with 1/RND grain size at reversals
[20:54:14] <seb_kuzminsky> yeah it makes sense, and your fix sounds like a good thing to try
[20:54:53] <seb_kuzminsky> it might be best to use the MSb of the timestamp, since the driver gets to control the timestamp frequency
[20:55:01] <PCW> Yes you really only want A-B and B-A times for velocity esimate
[20:55:36] <seb_kuzminsky> hmm
[20:56:22] <seb_kuzminsky> isnt it usually ok to measure AA & BB times?
[20:57:11] <seb_kuzminsky> if the fpga sees ABabA (rising on A, rising on B, falling on a, falling on b, rising on A), that's ok
[20:57:40] <seb_kuzminsky> it's only if it sees Aa (or aA or Bb or bB) that it's sketchy
[20:57:55] <seb_kuzminsky> only reversals, and then only if it's back at the count it was last servo period
[20:58:10] <PCW> OK that makes some sense as its basically a data poison bit for the timestamp
[20:58:11] <PCW> Yes A-A and B-B are fine but not if they are the only edges in a sample interval
[20:58:24] <seb_kuzminsky> agreed
[20:59:06] <seb_kuzminsky> ABabAa is probably ok, because something other than the reversal happened
[20:59:13] <PCW> There's no limit to how narrow A-A or B-B can be
[20:59:32] <seb_kuzminsky> though in that case, the driver will report positive vel, even though the FPGA knows that the axis is actually moving the other way now
[21:05:53] <PCW> Its really only a problem when you have 1 count and a reversal, but its a big problem if you use the velocity estimate for KD
[21:07:11] <PCW> (where its holding position and reversals are happening constantly)
[21:11:21] <PCW> OK Ill put the reversal bit in the timestamp MSB
[21:11:23] <PCW> (once I figure out how to implement it)
[21:11:25] <PCW> Active high for reversal/poison ( this will be Qcounter Rev 3)
[21:11:45] <seb_kuzminsky> sounds good man, send me the new regmap and a .bit to test with and i'll put it in the driver
[21:12:00] <PCW> OK BBL Lunch!
[21:12:08] <seb_kuzminsky> seeya :-)
[23:08:23] <BigJohnT> alex_joni: is the map borked?
[23:33:13] <BigJohnT> * BigJohnT wanders off to find out what that nice smell is...