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
(since you obviously can't hook the A and B phases up)
jmkasunich: you had a source for timing pullys iirc (that you have used)
mcmaster has them
the other place I've never used, but their prices seem good
link is on my website somewhere, lemme look
I missed the original question, but it looks like sdp-si.com might also be an option
(based on what I see at econobelt)
main gripe with SDP (unless they've changed recently) is that they don't have online pricing
hmmm. they had it before (I think)
maybe I'm mis-remembering
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
ISTR also that SDP didn't have the larger sizes I was interested in
yeah, they seem to specialize in smaller stuff
I was looking at stuff for a 2HP or thereabouts spindle drive
they had XL and L belts IIRC
which should be big enough
yep, 1" wide L belts should do it I'd think
yep - we remembered right, no prices in the product listing, but they're on the product page
econobelt is what I was remembering.
It is looking like I need H or better.
looks like H is good for 20kwish at 1200rpm
EMC: 03cradek 07master * rd9469bf9c508 10/src/emc/rs274ngc/rs274ngc_pre.cc: I think this needs to be initialized
kinda late micges_work
I was working offline today
as a machine operator. yay!
* alex_joni is writing an article..
and hating that
same as documentation ;)
jepler: when v2_4_branch?
this week sometime
probably as soon as I commit "remove hostmot2 firmwares"
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?
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)
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?
Example 2. Topic branches Make a side branch for every topic (feature,
bugfix, ...). Fork it off at the oldest integration branch that you
will eventually want to merge it into.
so I think that's a yes?
It's clear you don't want it *after* the branch point
assuming I think that we might want it in 2.4 after it settles a bit
but I don't think it matters much if it was a few commits *before* the branch point
yeah, it's just fine if it's a few commits before the branch point
thanks, I can see that now
I have some doodles here that I can't very well show on IRC
It's all about whether v2.4_branch..feature and mater..feature both identify exactly the commits that implement feature
they do if feature starts at or before the common ancestor of v2.4_branch and master, but not if it comes after
Hi Chris. It's been awhile. Just thought I'd connect and listen.
who wants to hear the things we have to say?
at least one guy, I see
Lerman: we're close to making the branch for 2.4, that's as exciting as it gets
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.
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.
He has asked for more detail.
Can you answer him?
I already did
I see :-) Thanks.
"My long-term vision for this thing is indeed a revision control system based on S-expressions, not files."
argh why am I reading the git list?
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?
seb_kuzminsky: it seems so
maybe some bios issues or so
bummer about the system not working, but i'm glad it's not my fault!
is this the strange nan problem?
no this one's different
wow, stuart scanned that paper already
this problem is the firmware not loading...
istr micges said the nan was on a different machine
too bad your birds are farther than one stone apart
a machine that was not suspect like the firmware-not-loading machine
just need a bigger rock :-)
micges: is the vel nan machine using differential pairs for the encoder signals?
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
hm, the default setting on the driver is to reject anything shorter than 15 cycles (at 33 MHz) as noise...
micges: you didn't set hm2_*.encoder.*.filter to False, did you?
yes differential signals
seb_kuzminsky: those filter settings are on driver source?
they're in hal
no I mean " reject anything shorter than 15 cycles"
the filter is on the fpga
bummer that I can't manage to deeply test that machine with nan
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
maybe half day debuging with scope could help locate error
we've got another laser that will be soon up and running, old laser (with nan) can be fixed in meanwhile
seb_kuzminsky: do you know about latest Peter work with firmwares and indexes?
<pcw_home> jepler: I added the index(and probe) on the stepgen feature
<jepler> pcw_home: cool. that makes it "stepgen v3" I suppose?
i dont know anything about that
Sebastian: I can send the stepgen index regmap but I really need to get git going so I can merge in my changes
( I tried to make the changes as unobtrusive as possible), the v3 stepgen will work fine with the V2 driver
hi seb and micges
basically the mode register has added index and probe bits with the same functions as on the quadrature counter (but in different locations)
the to 16 bits of the mode register is now a position latch of the top 16 bits of the stepgen accumulator
[19:40:57] <jepler> http://pastebin.ca/1776112
that could cause the nan issue?
I can check it
basically, if I understand what's going on the prev_time_of_interest must be at least 1 tsc ago
so if the two are equal, there was a rollover
is the TSC 32 bits?
SWPadnos: 16 bits I think
(I thought they were longer)
oh - so not the CPU TSC, but a register on the mesa card
ah yes - /me reads the function name
x86 TSC is 64 bits
that's what I was thinking :)
should be a long time before rollover, even at several GHz
2^64/3GHZ ~= 200 years, so CPU TSC rollover is not much of a concern
that's what I was thinking :)
alex_joni: "were his last words"
tell that irssi :P
* jepler loves each chance he gets to correct alex_joni's english, since there are so few
well, I can change that :P
if it makes you feel better...
jepler: nice catch
looks like there are two places to make a similar change
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
seb_kuzminsky: I thought you found the same thing, but then decided it wasn't the problem
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
what's the clock rate of that TSC?
// The 7i43 has a 50 MHz ClockLow, giving TSDiv = 48 and 1 us/clock
// The PCI cards have a 33 MHz ClockLow, giving TSDiv = 31 and again 1 us/clock
the comments make me think that can be varied through TSDiv, but the driver sets it to give 1us
jepler: yes that's how it works
ok, so there's no big concern about using long servo periods
you'd have to be <16 Hz to have multiple overflows per period
wish I wasn't too tired to search the irc logs for our troubleshooting about that rollover thing
SWPadnos: the servo period must be shorter than 16 bits of microseconds, 65 milliseconds
otherwise you can't detect rollovers reliably
yep, that's what I said :)
"The PCI cards have a 33 MHz ClockLow, giving TSDiv = 31 and again 1 us/clock"
Actually thats not true, PCI cards differ in base clock rate
(I assume the driver uses Clock low and the comment is just wrong)
seb_kuzminsky: I think I'm thinking of a different time...
cradek: yes i think that's not it
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
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
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)
2009-11-12 05:12:57 <cradek> I have been doing g91g1x20f.036044934 for some time and have not seen the inf
(this line first)
Is it possible the NAN is the result if the driver seeing a count change but no TSC change?
I think this is possible on reversals
nan would be the result of 0.0/0.0. 1.0/0.0 results in inf.
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
at least that's how x87 calculations normally behave in userspace
seb_kuzminsky: we took it to email! no wonder I couldn't find it in irc logs!
The comparison i was freaking out about is doing the right thing. It's checking for rollover
of the tsc, which happens every 65 ms as we determined. The servo loop runs many times in this
interval, so it will catch the rollover reliably. The "time of interest" and "previous time of
interest" variables keep state between runs of the servo loop.
[sorry, bad paste, but this is what you sent me afterward]
right, i remember now
not that I understand it
maybe micges has a bad 64ms latency in his system he's neglected to mention all this time
i have a mind like a steel trap: rusty, and illegal in 37 states
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
PCW: right, i fixed that about the same time we were debugging this nan problem
nans show up on slow moving not reversals
(reversals may happen when you are moving slowly)
micges: do you have latency numbers from the machine that's NaN'ing?
I can try get in a few minutes
micges: and is it running an emc2 from december 2009 or newer?
I think I've updated hostmot2 after you're fix and there was no change
I can't check that now
argh, there is no one at work who can get me short latency test
jepler: machine has about 15m/min and acc 500 so 65ms latency would be heared already
jepler: now that chris reminded me to go look at our emails, i remember what we did
jepler: the "time_of_interest" is "time we last checked for rollovers", which we do every servo loop
so the only way it could be the same as "prev_time_of_interest" is if the time between servo loops is 65ms
There might be a way to get a delta count with 0 TSC change without a reversal
(with bad electrical noise coupled to A and B) but this would be rare
PCW: would that noise be detected/reported by the Quad Error bit of the Quadrature Latch/Control Register?
Probably, also I would expect to lose counts in this situation
"probably" because the current quadrature counter design has some weaknesses as far as error detection is concerned
better error detection/rejection requires cross coupling/checking the A/B filters which are independent now
well, why not just check dT_s > 0 and skip updating velocity if it's zero
we don't have to figure out what (possibly low-level) cause there is, we can avoid the nan output..
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
we don't change e->prev_time_of_interest in that case
hm maybe that's not relevant, since prev_time_of_interest will be set the next time around in state HM2_ENCODER_STOPPED..
yay... first cnc lathe part: before... http://imagebin.ca/view/wqh1PQ.html
LawrenceG: I liked the before better
thanks Jeff.... its a babington burner nozzle to be
LawrenceG: kidding, just pulling your leg, it's nice ;)
figuring arcs out on the lathe plane was interesting for a few minuts
interesting, I hadn't heard of Babington Burners before
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
there seem to be a wealth of web pages about it
lots of guys build different versions... so I wanted to try one
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
is it important that it be iron, or can you make it out of some aluminum or brass bar stock?
brass is the usual.... iron was cheap $0.77 for the cap if I remember right
jepler: that fix would probably make the problem go away, but i'm hesitant because i'd still like to know what causes it
maybe if it emitted a warning on that condition we wouldn't forget about it...
I still need to drill a #80 or smaller hole in the thing
LawrenceG: nice, congratulations on the first part! :-)
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
oooh, #80 on a shoptask?
yea... I am worried as well
now that your program is done, if you have trouble you can just try again for $0.77 + the cost of a #80 drill
hehe... that box of pcb drills may get a little smaller
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