Back
[00:06:19] <jepler> if it's hostmot2 encoder you could expose rawcounts (counts without index resets) as a pin and use the respective rawcounts as inputs to an encoder_ratio type component
[00:06:26] <jepler> (since you obviously can't hook the A and B phases up)
[00:10:44] <skunkworks> jmkasunich: you had a source for timing pullys iirc (that you have used)
[01:15:13] <jmkasunich> mcmaster has them
[01:15:24] <jmkasunich> the other place I've never used, but their prices seem good
[01:15:32] <jmkasunich> link is on my website somewhere, lemme look
[01:16:54] <jmkasunich> here:
http://www.econobelt.com/
[01:17:50] <SWPLinux> I missed the original question, but it looks like sdp-si.com might also be an option
[01:17:57] <SWPLinux> (based on what I see at econobelt)
[01:18:30] <jmkasunich> main gripe with SDP (unless they've changed recently) is that they don't have online pricing
[01:18:42] <SWPLinux> hmmm. they had it before (I think)
[01:19:01] <jmkasunich> maybe I'm mis-remembering
[01:19:10] <SWPLinux> but it wasn't like you'd see a list - I think you had to click down to the product page before you'd see it or somehting
[01:19:15] <jmkasunich> ISTR also that SDP didn't have the larger sizes I was interested in
[01:19:27] <SWPLinux> yeah, they seem to specialize in smaller stuff
[01:19:38] <jmkasunich> I was looking at stuff for a 2HP or thereabouts spindle drive
[01:19:45] <SWPLinux> ah
[01:19:53] <SWPLinux> they had XL and L belts IIRC
[01:19:57] <SWPLinux> which should be big enough
[01:20:56] <SWPLinux> yep, 1" wide L belts should do it I'd think
[01:21:25] <SWPLinux> yep - we remembered right, no prices in the product listing, but they're on the product page
[01:47:34] <skunkworks> jmkasunich: thanks
[01:48:15] <skunkworks> econobelt is what I was remembering.
[01:50:18] <skunkworks> It is looking like I need H or better.
[02:05:53] <skunkworks> looks like H is good for 20kwish at 1200rpm
[04:55:52] <CIA-81> EMC: 03cradek 07master * rd9469bf9c508 10/src/emc/rs274ngc/rs274ngc_pre.cc: I think this needs to be initialized
[11:32:04] <alex_joni> kinda late micges_work
[11:35:01] <micges_work> heh
[11:36:48] <micges_work> I was working offline today
[11:37:00] <micges_work> as a machine operator. yay!
[11:38:27] <alex_joni> yay ;)
[11:38:36] <alex_joni> * alex_joni is writing an article..
[11:38:40] <alex_joni> and hating that
[11:42:45] <micges_work> same as documentation ;)
[11:43:06] <alex_joni> worse :D
[11:56:54] <micges_work> lol
[14:09:00] <cradek> jepler: when v2_4_branch?
[14:11:32] <jepler> this week sometime
[14:12:16] <jepler> probably as soon as I commit "remove hostmot2 firmwares"
[14:13:16] <jepler> which reminds me, I'll need your help to put the new hostmot2-firmware.git on git.linuxcnc.org. I have to do a little tidying up of that source first. Tomorrow night, maybe?
[14:15:33] <cradek> sure
[14:47:10] <jepler> darnit, that PC I have the latest hostmot2-firmware work on isn't on the network (I haven't hooked it up since taking it home from chris's)
[14:56:52] <cradek> jepler: if I have a sorta-big new feature to add, should I wait until you make v2_4_branch and then put my feature on a new branch from that same point?
[14:58:53] <jepler> Example 2. Topic branches Make a side branch for every topic (feature,
[14:58:53] <jepler> bugfix, ...). Fork it off at the oldest integration branch that you
[14:58:53] <jepler> will eventually want to merge it into.
[14:59:54] <cradek> so I think that's a yes?
[15:00:10] <jepler> It's clear you don't want it *after* the branch point
[15:00:11] <cradek> assuming I think that we might want it in 2.4 after it settles a bit
[15:00:19] <jepler> but I don't think it matters much if it was a few commits *before* the branch point
[15:03:26] <jepler> yeah, it's just fine if it's a few commits before the branch point
[15:03:41] <cradek> thanks, I can see that now
[15:03:52] <jepler> I have some doodles here that I can't very well show on IRC
[15:04:51] <jepler> It's all about whether v2.4_branch..feature and mater..feature both identify exactly the commits that implement feature
[15:05:19] <jepler> they do if feature starts at or before the common ancestor of v2.4_branch and master, but not if it comes after
[15:05:42] <jepler> s/mater/master/
[16:23:30] <cradek> hi ken!
[16:24:16] <Lerman> Hi Chris. It's been awhile. Just thought I'd connect and listen.
[16:24:48] <jepler> who wants to hear the things we have to say?
[16:24:58] <cradek> at least one guy, I see
[16:25:09] <Lerman> Hi Jeff.
[16:25:17] <cradek> Lerman: we're close to making the branch for 2.4, that's as exciting as it gets
[17:04:34] <Lerman> cradek, jepler: Evgeni described a problem (on emc-users) concerning slow loading of a very large program. I responded with: The problem is the Axis interface, not the interpreter.
[17:04:35] <Lerman> I believe that there is a special comment format that will disable previewing parts of the file. Doing that will speed things up -- at the cost of not being able to preview those parts.
[17:04:37] <Lerman> He has asked for more detail.
[17:04:38] <Lerman> Can you answer him?
[17:04:55] <cradek> I already did
[17:06:47] <Lerman> I see :-) Thanks.
[17:38:43] <seb_kuzminsky> good morning
[17:38:59] <cradek> hi seb
[17:49:02] <micges> hi seb
[17:49:17] <cradek> "My long-term vision for this thing is indeed a revision control system based on S-expressions, not files."
[17:49:50] <seb_kuzminsky> hi micges
[17:50:01] <cradek> argh why am I reading the git list?
[17:50:36] <seb_kuzminsky> micges: about your recent email to me and peter, does that mean that you think the motherboard is bad and the 5i20 and the hostmot2 driver are both good?
[17:52:01] <micges> seb_kuzminsky: it seems so
[17:52:21] <micges> maybe some bios issues or so
[17:52:34] <seb_kuzminsky> ok
[17:52:50] <seb_kuzminsky> bummer about the system not working, but i'm glad it's not my fault!
[17:54:33] <cradek> is this the strange nan problem?
[17:54:44] <seb_kuzminsky> no this one's different
[17:54:58] <cradek> wow, stuart scanned that paper already
[17:55:21] <seb_kuzminsky> this problem is the firmware not loading...
[17:55:46] <seb_kuzminsky> istr micges said the nan was on a different machine
[17:56:07] <cradek> too bad your birds are farther than one stone apart
[17:56:10] <seb_kuzminsky> a machine that was not suspect like the firmware-not-loading machine
[17:56:22] <cradek> dang birds
[17:56:29] <seb_kuzminsky> just need a bigger rock :-)
[17:57:01] <seb_kuzminsky> micges: is the vel nan machine using differential pairs for the encoder signals?
[17:57:49] <seb_kuzminsky> i think maybe noise on the encoder signal lines could make the firmware report two edges in the same microsecond, which would explain why the driver got dt=0 and NaNed
[18:00:02] <seb_kuzminsky> hm, the default setting on the driver is to reject anything shorter than 15 cycles (at 33 MHz) as noise...
[18:00:44] <seb_kuzminsky> micges: you didn't set hm2_*.encoder.*.filter to False, did you?
[18:07:43] <micges> nope
[18:08:49] <micges> yes differential signals
[18:09:38] <micges> seb_kuzminsky: those filter settings are on driver source?
[18:10:04] <seb_kuzminsky> they're in hal
[18:10:37] <micges> no I mean " reject anything shorter than 15 cycles"
[18:11:40] <seb_kuzminsky> the filter is on the fpga
[18:11:53] <micges> oh ok
[18:12:17] <micges> bummer that I can't manage to deeply test that machine with nan
[18:12:18] <seb_kuzminsky> the driver tells the fpga whether to use a 3 cycle filter or a 15 cycle filter, and the user tells the driver which of those settings to use via that .filter pin in hal
[18:13:04] <micges> maybe half day debuging with scope could help locate error
[18:23:45] <micges> we've got another laser that will be soon up and running, old laser (with nan) can be fixed in meanwhile
[18:23:51] <micges> will see
[18:23:58] <micges> seb_kuzminsky: do you know about latest Peter work with firmwares and indexes?
[18:23:59] <micges> <pcw_home> jepler: I added the index(and probe) on the stepgen feature
[18:23:59] <micges> <jepler> pcw_home: cool. that makes it "stepgen v3" I suppose?
[18:26:15] <seb_kuzminsky> i dont know anything about that
[18:54:49] <pcw_home> Sebastian: I can send the stepgen index regmap but I really need to get git going so I can merge in my changes
[18:55:29] <micges> hi pcw_home
[18:55:32] <seb_kuzminsky> hi pcw
[18:55:41] <pcw_home> ( I tried to make the changes as unobtrusive as possible), the v3 stepgen will work fine with the V2 driver
[18:55:54] <seb_kuzminsky> great! :-)
[18:56:00] <pcw_home> hi seb and micges
[18:57:57] <pcw_home> basically the mode register has added index and probe bits with the same functions as on the quadrature counter (but in different locations)
[18:57:58] <pcw_home> the to 16 bits of the mode register is now a position latch of the top 16 bits of the stepgen accumulator
[18:58:16] <pcw_home> (the top)
[19:06:10] <pcw_home> bbl
[19:40:57] <jepler> http://pastebin.ca/1776112
[19:45:20] <skunkworks_> that could cause the nan issue?
[19:45:27] <jepler> not sure
[19:46:35] <micges> I can check it
[19:48:40] <jepler> basically, if I understand what's going on the prev_time_of_interest must be at least 1 tsc ago
[19:49:05] <jepler> so if the two are equal, there was a rollover
[19:49:56] <SWPadnos> is the TSC 32 bits?
[19:50:03] <jepler> SWPadnos: 16 bits I think
[19:50:03] <SWPadnos> (I thought they were longer)
[19:50:26] <SWPadnos> oh - so not the CPU TSC, but a register on the mesa card
[19:50:36] <jepler> yes
[19:50:42] <SWPadnos> ah yes - /me reads the function name
[19:50:43] <jepler> x86 TSC is 64 bits
[19:50:50] <SWPadnos> that's what I was thinking :)
[19:51:01] <SWPadnos> should be a long time before rollover, even at several GHz
[19:51:17] <jepler> 2^64/3GHZ ~= 200 years, so CPU TSC rollover is not much of a concern
[19:51:51] <SWPadnos> that's what I was thinking :)
[19:53:13] <jepler> alex_joni: "were his last words"
[19:53:26] <alex_joni> tell that irssi :P
[19:53:27] <jepler> * jepler loves each chance he gets to correct alex_joni's english, since there are so few
[19:53:46] <alex_joni> well, I can change that :P
[19:54:01] <alex_joni> if it makes you feel better...
[20:21:18] <seb_kuzminsky> jepler: nice catch
[20:21:29] <jepler> looks like there are two places to make a similar change
[20:21:39] <jepler> it's only a nice catch if micges says it makes his problem go away :-/
[20:22:39] <jepler> http://emergent.unpy.net/files/sandbox/hostmot2-tsc.patch
[20:24:46] <cradek> seb_kuzminsky: I thought you found the same thing, but then decided it wasn't the problem
[20:26:06] <cradek> seb_kuzminsky: back when you and I were working on it - we somehow calculated the (very slow) speed where we expected it, and we tested there, looking for it
[20:27:58] <SWPadnos> what's the clock rate of that TSC?
[20:30:08] <jepler> // The 7i43 has a 50 MHz ClockLow, giving TSDiv = 48 and 1 us/clock
[20:30:08] <jepler> // The PCI cards have a 33 MHz ClockLow, giving TSDiv = 31 and again 1 us/clock
[20:30:37] <jepler> the comments make me think that can be varied through TSDiv, but the driver sets it to give 1us
[20:31:42] <seb_kuzminsky> jepler: yes that's how it works
[20:31:44] <SWPadnos> ok, so there's no big concern about using long servo periods
[20:32:03] <SWPadnos> you'd have to be <16 Hz to have multiple overflows per period
[20:32:08] <cradek> wish I wasn't too tired to search the irc logs for our troubleshooting about that rollover thing
[20:32:21] <seb_kuzminsky> SWPadnos: the servo period must be shorter than 16 bits of microseconds, 65 milliseconds
[20:32:30] <seb_kuzminsky> otherwise you can't detect rollovers reliably
[20:33:17] <SWPadnos> yep, that's what I said :)
[20:34:33] <PCW> "The PCI cards have a 33 MHz ClockLow, giving TSDiv = 31 and again 1 us/clock"
[20:34:35] <PCW> Actually thats not true, PCI cards differ in base clock rate
[20:34:42] <seb_kuzminsky> cradek:
http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2009-01-27.txt
[20:35:19] <PCW> (I assume the driver uses Clock low and the comment is just wrong)
[20:37:38] <cradek> seb_kuzminsky: I think I'm thinking of a different time...
[20:38:28] <seb_kuzminsky> cradek: yes i think that's not it
[20:38:55] <seb_kuzminsky> PCW: yes, the driver uses ClockLow, not necessarily 33 MHz
[20:39:10] <cradek> http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2009-11-12.txt
[20:39:24] <cradek> 2009-11-12 04:21:17 <garage_seb> if the new edge came in exactly 16 bits of tsc after the previous one, the two times would be equal, so it would *not* increment the rollover counter... exactly
[20:39:37] <seb_kuzminsky> cradek: thanks
[20:39:45] <cradek> 2009-11-12 05:13:45 <cradek> I think that is the feed that should give 1 micron per rollover (assuming a perfectly spherical milling machine)
[20:39:56] <cradek> er
[20:40:00] <cradek> 2009-11-12 05:12:57 <cradek> I have been doing g91g1x20f.036044934 for some time and have not seen the inf
[20:40:04] <cradek> (this line first)
[20:40:23] <PCW> Is it possible the NAN is the result if the driver seeing a count change but no TSC change?
[20:41:31] <PCW> I think this is possible on reversals
[20:42:55] <jepler> nan would be the result of 0.0/0.0. 1.0/0.0 results in inf.
[20:43:10] <seb_kuzminsky> PCW: micges ran a test with a debugging patch i sent him, it shows the nan happening with a count-change of 1 and a time-change of 0
[20:43:16] <jepler> at least that's how x87 calculations normally behave in userspace
[20:43:18] <cradek> seb_kuzminsky: we took it to email! no wonder I couldn't find it in irc logs!
[20:43:49] <cradek> The comparison i was freaking out about is doing the right thing. It's checking for rollover
[20:43:53] <cradek> of the tsc, which happens every 65 ms as we determined. The servo loop runs many times in this
[20:43:56] <cradek> interval, so it will catch the rollover reliably. The "time of interest" and "previous time of
[20:43:59] <cradek> interest" variables keep state between runs of the servo loop.
[20:44:07] <cradek> [sorry, bad paste, but this is what you sent me afterward]
[20:44:20] <seb_kuzminsky> right, i remember now
[20:44:30] <cradek> not that I understand it
[20:44:30] <jepler> maybe micges has a bad 64ms latency in his system he's neglected to mention all this time
[20:44:32] <seb_kuzminsky> i have a mind like a steel trap: rusty, and illegal in 37 states
[20:48:13] <PCW> Count change of 1 and tsc change of 0 is possible without involving rollover, this is because the counter can count up and down between TSC samples
[20:48:53] <seb_kuzminsky> PCW: right, i fixed that about the same time we were debugging this nan problem
[20:49:00] <seb_kuzminsky> 2009-11-12
[20:49:11] <micges> nans show up on slow moving not reversals
[20:49:41] <PCW> (reversals may happen when you are moving slowly)
[20:49:44] <seb_kuzminsky> micges: do you have latency numbers from the machine that's NaN'ing?
[20:50:52] <micges> I can try get in a few minutes
[20:51:01] <seb_kuzminsky> micges: and is it running an emc2 from december 2009 or newer?
[20:52:30] <micges> I think I've updated hostmot2 after you're fix and there was no change
[20:52:51] <micges> I can't check that now
[20:54:55] <micges> argh, there is no one at work who can get me short latency test
[20:59:02] <micges> jepler: machine has about 15m/min and acc 500 so 65ms latency would be heared already
[20:59:35] <micges> I think
[21:02:09] <seb_kuzminsky> jepler: now that chris reminded me to go look at our emails, i remember what we did
[21:02:39] <seb_kuzminsky> jepler: the "time_of_interest" is "time we last checked for rollovers", which we do every servo loop
[21:03:08] <seb_kuzminsky> so the only way it could be the same as "prev_time_of_interest" is if the time between servo loops is 65ms
[21:03:37] <PCW> There might be a way to get a delta count with 0 TSC change without a reversal
[21:03:39] <PCW> (with bad electrical noise coupled to A and B) but this would be rare
[21:03:57] <PCW> nice "B"
[21:21:13] <seb_kuzminsky> PCW: would that noise be detected/reported by the Quad Error bit of the Quadrature Latch/Control Register?
[21:22:29] <PCW> Probably, also I would expect to lose counts in this situation
[21:32:25] <PCW> "probably" because the current quadrature counter design has some weaknesses as far as error detection is concerned
[21:32:27] <PCW> better error detection/rejection requires cross coupling/checking the A/B filters which are independent now
[21:49:48] <jepler> well, why not just check dT_s > 0 and skip updating velocity if it's zero
[21:50:28] <jepler> we don't have to figure out what (possibly low-level) cause there is, we can avoid the nan output..
[21:51:41] <jepler> hmmm
[21:52:36] <jepler> have you considered this? In the case HM2_ENCODER_MOVING with reg_count == e->prev_reg_count there is a rollover (e->tsc_num_rollovers++) and then the vel_timeout test leads to a break
[21:52:47] <jepler> we don't change e->prev_time_of_interest in that case
[21:54:08] <jepler> hm maybe that's not relevant, since prev_time_of_interest will be set the next time around in state HM2_ENCODER_STOPPED..
[21:56:47] <LawrenceG> yay... first cnc lathe part: before...
http://imagebin.ca/view/wqh1PQ.html after...
http://imagebin.ca/view/cjynVm.html
[21:57:30] <jepler> congrats
[21:57:51] <alex_joni> LawrenceG: I liked the before better
[21:57:57] <LawrenceG> thanks Jeff.... its a babington burner nozzle to be
[21:58:13] <alex_joni> LawrenceG: kidding, just pulling your leg, it's nice ;)
[21:58:38] <LawrenceG> figuring arcs out on the lathe plane was interesting for a few minuts
[22:00:24] <jepler> interesting, I hadn't heard of Babington Burners before
[22:02:23] <LawrenceG> they use part of a spherical surface to generate a thin oil film and then atomize it with a tiny air blast... only air in the nozzle lets you burn dirty oil without jet clogs
[22:02:39] <jepler> yep
[22:02:44] <jepler> there seem to be a wealth of web pages about it
[22:03:20] <LawrenceG> lots of guys build different versions... so I wanted to try one
[22:05:10] <LawrenceG> the version I built was a 0.7" radius face... I might try a 0.6"radius, but I'm not sure if there is enogh meat in the pipe cap to cut more of the corner off
[22:05:52] <cradek> is it important that it be iron, or can you make it out of some aluminum or brass bar stock?
[22:06:40] <LawrenceG> brass is the usual.... iron was cheap $0.77 for the cap if I remember right
[22:07:17] <seb_kuzminsky> jepler: that fix would probably make the problem go away, but i'm hesitant because i'd still like to know what causes it
[22:07:31] <seb_kuzminsky> maybe if it emitted a warning on that condition we wouldn't forget about it...
[22:07:39] <LawrenceG> I still need to drill a #80 or smaller hole in the thing
[22:07:52] <seb_kuzminsky> LawrenceG: nice, congratulations on the first part! :-)
[22:09:13] <LawrenceG> seb_kuzminsky, thanks... I have been using the mill with emc since the initial emc1 days, but never tried a lathe config on the shoptask until now
[22:09:33] <cradek> oooh, #80 on a shoptask?
[22:09:50] <LawrenceG> yea... I am worried as well
[22:10:57] <cradek> now that your program is done, if you have trouble you can just try again for $0.77 + the cost of a #80 drill
[22:11:29] <LawrenceG> hehe... that box of pcb drills may get a little smaller
[22:12:51] <LawrenceG> I was going to build a ball turning adapter for the lathe, but I though I should try arcs on the cnc first... much nicer