it is not my night!!
anyone have a spare servo motor?
ah forget it! (yayyy!)
what kind of wear/failure would cause the motor shaft to get shorter?
the back of the pulley dug into the front of the motor and it froze
this is on your bp?
how much clearance was there before?
(are we talking about it moveing a few thou, or a quarter inch?
I wish I new that
it ground .012 off the front of the motor before it finally stuck
so >= .012
how much is the pulley now misaligned with the other pulley?
I haven't put it back on yet
are you sure the pulley didn't just move on the shaft?
it was pretty tight
but I'd definitely like to believe that's what happened
but you don't have any positive evidence, like dirt lines on the shaft or something?
the motor shaft seems short now. It doesn't come up flush with the pulley
I wish I had noticed how long it was before I took it off.
what is on the other end of the shaft? encoder or something? if the shaft moved, you'd see it there
(no way it actually got shorter, but maybe it shifted in the bearings
you'd think the encoder would fail without too much movement
these are brush servos, right?
I could pull a brush... the wear line would be shifted
read my mind
ha, great minds and all that
the only thing worse than cutting sheet steel with a jigsaw is cutting it by hand
and sometimes I'm not even sure about that
if it moved, it didn't move much.
how is the pulley held on the shaft? keyway and setscrew? two setscrews?
that bridgeport collet thing
got me at a loss there
it's a collet
clamps onto the round of the shaft
and a thing
taper inside the pulley
and a thingy to clamp it on the front
very neat actually
bushing that is tapered on the OD and cylinder inside, with a slit (or slits)
and a tapered hole in the pulley
you know, a collet :-)
those usually don't shitf
you wouldn't think so.
I would not be able to tell .012 on the brush wear
but I can tell it's not (say) .03
which axis is this?
Y, the easy one to work on
so the motor is down and right, pointing out at your knees
no it's straight down, sticking back under the table
oh, must be thinking of some other machine
this one has both motors underneath which is very nice
the pulley end is pointing at your knees tho
did you remove the motor, or just the pulley?
and then the pulley (its not still on there is it?)
I'm putting it back on now
I'm going to assume the pulley moved on the shaft until other evidence shows something more sinister
damn, only I could manage to damage myself with a file
fortunately you're made of auto-regenerating meat
assuming your damage is within the auto-regeneration limitations
I bet this should be VERY tight
I made a puller to get the pulley off, but it didn't take much pulling.
how is it tightened? three bolts that jack the bushing into the pulley?
if you backed them off, then all you needed to do with the puller is break the friction grip (like a morse taper)
yeah but when I took them off the first time (a while back) it was very hard
of course they had probably been on for 20+ years
oh, you've had this off before?
which makes it much more likely it was together incorrectly
did you get it back together?
yes, working fine
big sigh of relief?
yeah and back to work... I really want to get Z mounted tonight
yay, the part requiring the 1/4 x 3.5" end mill (of which I had only one) is done
it's like cutting aluminum with jello nailed to a stick
you designed this part?
why didn't you design something easier to machine?
it sucks because I wanted it made out of one block. that's the real problem.
hard parts are done. now I only have to drill some more holes in the right places.
I'm down to my last half-dozen holes
that sounds very promising
I decided to rebuild the PC mount, so it could use a standard mobo
so there's no way I'll be moving things today, but I think I'll get the PC mounted in the boc
that sounds like a nice accomplishment anyway
everything cut and drilled, time for rivets
case built, nothing in it yet
one of the holes I want to mount it in the main box with is blocked now that I've riveted it together
I don't fricking believe this
the power supply hole patteren in this back panel doesn't clear the plug on my ps
I thought those cutouts were standard
the fan lines up, the screws line up, just can't plug the line cord in
well, the computer is in the new "case"
but the case isn't in the main box yet
and I'm fading fast
how is your part going?
done! it's even upright
within about .002/foot
I have to drill and tap 4 holes on the existing base and XYZB is done - only C to go
sucks about your holes
you'd think we'd have standard holes for motherboards and power supplies in 2007
I fixed that - took everything out, jigsaw and file, put it back together
pics in a minute
[05:41:46] <jmkasunich> http://jmkasunich.com/pics/case-front-IMGP1751.JPG
[05:41:54] <jmkasunich> http://jmkasunich.com/pics/case-back-IMGP1754.JPG
quite nice I think
yes very nice!
your yearly power supply replacement will be very easy now
the side with the slots will be on top when I mount it in the box
I hope so
the next supply will probably have the plug somewhere else
you'll just have to shop around
or jigsaw and file some more ;-)
eventually any power supply will fit, or else they'll all fall through the hole
I have a large pile of shrapnel laying around the bandsaw
this started out as a full tower gateway system
now its only 14 x 10-3/4 x 8-1/2
well, the dog expects me to walk him before bed
time to go
tissf: if you have tested the link checker for the v2_2_branch and think it will help you, please go ahead and check it in.
sorry I didn't answer you before now.
Just this once .. here's the log: http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2007-12-10.txt
tissf: I notice that in the 2.2 documentation you have included g38.3,4,5 (LOGOPEN) (LOGCLOSE) and other items that are new features in TRUNK and not present in emc 2.2.
jepler: I removed?
you should remove them. (and I don't know if that's a full list of the items that should be removed -- just the ones I noticed right away)
the only other thing I see that is added in the english TRUNK version is G73, but I don't think you have that yet
jepler: corrected for next commit
jepler: no problem
EMC: 03tissf 07v2_2_branch * 10emc2/docs/html/gcode_fr.html: French translation removed G38.3,4,5 (LOGOPEN)(LOGCLOSE)
EMC: 03tissf 07v2_2_branch * 10emc2/docs/src/gcode/main_fr.lyx: French translation removed G38.3,4,5 (LOGOPEN)(LOGCLOSE)
I am getting demoralized by all the problem reports in stepconf
have a cookie :)
homemade, you bastard
all I had was taht damned snickers bar
and it wasn't even one of the dark chocolate ones
jepler, do you have more reports that people have emailed you directly, or is it just the few on the users list?
the other day someone had brought some hershey's kisses to the office. damn if that isn't terrible chocolate. so I ate it anyway.
I am such stupid meat
when in rome or something
SWPadnos: no, those are the only reports I have
ok, it sounds like 3 or 4 then, not a lot
it's a hard thing - making software that can tell when it needs to change from GIGO mode to GINO (garbage in, no output) mode
jmkasunich has a good point about BASE_PERIOD, but how do I choose one that is "low enough"?
I actually used 100000 as base_period on zenbot and I don't think I suffered any ill effects .. not that I've seriously used that machine yet
I thought we found all machines could run 25000. why not just make that the max?
I know that doesn't answer your question of course
the other thing I need is a rule for when to not enable doublestep .. I lean towards thinking it should only be disabled when the timings present a problem (e.g., 25000ns step time) while jmk seems to lean towards enabling it only when needed to obtain the requested step rate
if it's not needed to obtain the requested step rate is there another advantage to using doublestep?
stepconf always uses it because having one "case" to generate is easier than two
to configure it, you need more precise knowledge of the hardware. that seems like a drawback if you aren't getting some other benefit
I think I'd lean toward using doublestep only when necessary
stepconf actually loads the RT system and allows you to do a latency test, right? (or does the test automagically?)
no, it requires you to write down the number
ok, but does it allow you to run the test from within stepconf?
I guess I could boot up an EMC2-capable computer and look for myself :)
I added the button either in TRUNK or in a working tree that I haven't committed yet
you have to run latency-test separately in 2.2, and manually write the number in the appropriate field
I was wondering because it would be possible to run the latency test twice, with different base periods, and try to figure out the fastest it should be set (more or less)
though that's a pain, because you have to start/stop the RT system 2 or 3 times
looks like adding a call to interp.close() in gcodemodule.cc may fix it
that may fix a whole class of possible bugs?
maybe you should put it on the 2.1 branch too
are we going to build another 2.1 ever?
EMC: 03jepler 07TRUNK * 10emc2/src/emc/rs274ngc/gcodemodule.cc: make 'touch off' work when the loaded file uses percent signs
there are a few other fixes there iirc
hmmm. how does the interp handle parsing errors? especially when it's called from the touch-off dialog
jepler: we sure could...
although I know that's not what you asked
if there are relevant bug fixes, it might be nice. 2.1 runs on breezy, doesn't it?
SWPadnos: it uses the embedded interpreter to check that the expression is valid, and also to compute its actual value to show to the user
ok, so it would be nice (though I'm not pushing, since I'm not the one doing the work) to keep releasing 2.1 until it becomes terribly annoying
SWPadnos: basically, it does an MDI M199 P[expression] in the embedded interpreter, then looks at the value that was passed to the custom M code
jepler, right. I guess I'm wondering whether there's something that makes certain errors "sticky"
when you'd normally get an error dialog and dismiss it (in the course of a g-code run)
in theory, interp::reset and interp::close (which calls interp::reset) clear those flags. but I wasn't calling interp::close when I was done reading a part program for preview. In that case, the percent flag was sticking and causing the problem I saw.
oh - sorry, I was thinking of the "invalid number" errors - I didn't make that clear
EMC: 03jepler 07v2_2_branch * 10emc2/src/emc/rs274ngc/gcodemodule.cc: merge from TRUNK: make 'touch off' work when the loaded file uses percent signs
EMC: 03jepler 07v2_1_branch * 10emc2/src/emc/rs274ngc/gcodemodule.cc: merge from TRUNK: make 'touch off' work when the loaded file uses percent signs
EMC: 03jepler 07v2_1_branch * 10emc2/debian/changelog: note new fix
EMC: 03jepler 07v2_2_branch * 10emc2/debian/changelog: note new fix
SWPadnos: I don't know why "invalid number" errors would stick, but it's possible that calling .close() would unstick that too
* jepler shrugs
I hope it works out that way :)
too bad we don't have jack's gcode.
what happens if there's an M199 script on the system?
does it actually run, or is that hijacked somewhere?
SWPadnos: no, it's thoroughly hijacked
ok (I figured you'd have thought of that :) )
the interpreter only makes a certain canon call when M1xx is encountered; in task, this leads to a call to the external program during program execution. in axis, it doesn't.
EMC: 03tissf 07TRUNK * 10emc2/docs/src/ (Master_HAL_fr.lyx Submakefile index.tmpl index_fr.tmpl): French translation
EMC: 03tissf 07TRUNK * 10emc2/docs/src/hal/rtcomps_fr.lyx: French translation
hello again :)
we try to keep it less technical in #emc so new users aren't scared to ask more basic questions
right... makes sense
I looked through your patch and everything looks good to me, but I'm not an expert on drivers
is that zip file something that comes from peter w?
yep, that's all his vhdl code
I think the patch didn't include the zip because it is binary
is there a gpl statement in his code?
not that I've seen, but he seems OK with adding them (in general)
yes I think last time we only had to ask him and he added it
there is no copyright statement or license statement, but i have an email from pcw saying he wants to release it dual licensed, bsd & gpl
it would be nice if he would add that statement to the files for us
the zip file isn't needed to build, but I'll add it anyway
yes it is important that each source file have a notice that the file is available under the GPL v2
i'll ask him to put it in there (or offer to do it for him)
I think he (the author) should do it
yes you're right
verilog source files are just the same as C/C++ source files
aside from this issue of the firmware license, I don't see any problems with including this driver in a future release
I just emailed pcw asking him to add the copyright and the GPLv2 license
AFter he does that I'll update the driver and release 0.5
seb_kuzminsky: I will add you as a cvs committer, so when the license thing is worked out you can go ahead
what is your sourceforge login?
when you eventually add the verilog source code to the emc2 source tree, it should be as individual .v (or whatever extension) files, not as a .zip file
that way, if the individual files are revised, cvs will help track the revisions
jepler: i agree, i'll do that for the next version
chris: i had one a long time ago but it looks like it's expired, i can make a new one if you really need it
all of the project except cvs is hosted on sf - the bug tracker and mailing lists
I think everyone else has a sf id so they can be added to the project there. it would be nice if you did too
is skuzminsky ok for a login?
it's nice, but not required, that they match on cvs and sf
I prefer "seb" if it's all the same to you. Hm, it looks like y'all's standardized on that pattern though so if you like i'll conform
Peter Wallace asks if it's ok if he just includes a comment in the vhdl with a pointer to the license file?
I think a few line comment saying that he's the author and that he's releasing it under the GPLv2 would be sufficient. there may need to be a pointer to fsf.org or something, but the requirements are pretty small
seb_kuzminsky: it should be the standard block shown in the GPL in the section "How to Apply These Terms to Your New Programs".
we can use 'seb', no problem
we have an occasional troll who likes to claim that there are (usually unspecified) "license problems" in the software; by not including the entire block, it gives the troll something new to troll about.
hmmm. is the license block in this sufficient? http://cvs.linuxcnc.org/cvs/emc2/src/hal/components/blocks.c?rev=1.26
it doesn't have any pointers to the full GPL, though it does list the author, a claim of copyright, and the GPL as the license
seb_kuzminsky: you should be able to get a developer checkout now
maybe we should make emc output a "short notice" and force the user to type "yes, i understand" every time they run the program
SWPadnos: let me put it this way: I wouldn't turn down a patch that makes the author's intent to GPL the software more clear.
seb_kuzminsky: (fenn isn't the usual troll)
we all have our days
I'm just not too familiar with the marking requirements of the GPL
i blame cairo's lack of an arc_to command
ok, "seb" and "skuzminsky" were both taken, i'm seb_kuzminsky at sf.net now.
SWPadnos: According to the license itself, it applies to any "work which contains a notice placed by the copyright holder saying that it may be distributed under the terms of this General Public License". The "How to Apply" section is what standards people call "non-normative"
ok I will add you to the project there too.
if you can, try your cvs access while we're both around
I've been doing anon cvs checkouts for a few months, i'll try developer now, hold on
jepler, err. I understood up until the non-normative part :)
[19:47:03] <fenn> http://en.wikipedia.org/wiki/Normative
so i guess that means you can put a license block in if you want to, but it doesn't really matter
Dec 10 13:48:48 cvs sshd: Accepted publickey for seb
chris: yes it looks like its working :-)
we are done. welcome to the team
I'll be hacking on the 7i43 driver, hoping to add hostmot2 in the next month or so
i prolly wont get too deep into the rest of the code at this point
hmmm. I never got around to ordering a few of those
that's ok, work on whatever part you like.
of course :-)
ah one thing i had been thinking about is an internal parport infrastructure in rtai/hal like linux has
seems like there's a couple of implemetations of epp i/o in src/hal/drivers, maybe unify & abstract that
may not be worth it...
i think it's worth it
i've also been talking to pcw about writing yet another driver for the 5i2x cards...
epp/parport is basically the only commonly available rt interface to custom hardware (unless you go with a pci card)
there's bound to be more drivers that use epp
have you looked at the work that's been done on the new 5i2x driver infrastructure?
epp is 32 bit, so you could have an epp-parport hal driver with u32 signals in/out of it (perhaps a useless idea)
I don't think you can abstract it at that level - there's no guarantee that a single 32-bit address contains a single piece of HAL data
or that you can individually read/write all the addresses
or that the addresses mean the same thing when read vs. written ...
not the address, it sends 32 bits per transfer
swpadnos: the 5i2x infrastructure is the stuff in src/hal/drivers/mesa_5i2x?
seb_kuzminsky, yes, I think it's there. there's a separate CVS branch for it as well
fenn: is that true? i thought the epp spec required only 8 bits, and the 16- and 32-bit extensions were optional or non-standard (though very widely supported)
uh, well epp is rather useless if you're only sending 8 bits
no, it allows you to use a single CPU I/O instruction instead of 3 or more
i disagree, the hardware-supported interlocking handshaking of epp is excellent even for 8 bit transfers
the handshake is done in hardware instead of polling in software
ok, but if you're only sending 8 bits, using a 32 bit hal signal should still work
there would be some param to select 8,16,32
the trouble is that different hardware may have different packing for data, and may have different setup that needs to be done before starting a read or write cycle
all the better to have that in one place
when you look at the epp signals, it doesn't differentiate between 8- 16- or 32-bit transfers; they're just sequential byte transfers.
some existing epp hardware is oriented around 24-bit words (pico)
but now that we have several drivers to look at (pico, pluto, mesa) we have a pretty good idea of the variations
yeah - I think it would be great to have a single library at least, and a single kernel module at best
personally, I saw a library more than a series of HAL pins or parameters, so I pulled out some routines into "pluto_common.h" -- it wasn't abstract enough to be used in the mesa driver, though.
an epp abstraction would need methods something like this: init(), check_timeout(), clear_timeout(), write_addr(), read_data(), and write_data()
the code is small, it's unlikely to have more than one copy loaded in a running system anyway, and we have poor support for (un)loading non-HAL modules, so using a "header" file seemed pretty natural
with a parport_t struct to keep everythign neat & organized
basically ripping off the parport architecture in linux
init() and cleanup() would probably need to be callbacks
though I should look at the relevant code befor emaking such a statement
are you saying it's unlikely to have more than one epp-parport being used in the same machine?
fenn: not at all, i plan to support multiple 7i43 boards in a single system RSN
more than one parport-connected device would be somewhat odd, but not outside the realm of possibility
fenn: I think it would be odd to mix & match one pluto and one mesa (for example)
err - more than one type of device, that is
out of laziness, the pluto driver only supports one device as well
seb_kuzminsky: happen to know if 7i33 can have more than one device per epp bus, like pico?
it presents a problem for firmware uploading, that's for sure
jepler: the current 7i43 supports only one device per parport afaik :-(
but parports are only like $15 at frys
and there are apparently PCIe parallel port cards now ...
jepler: the 7i43 has a cpld talk to the parport when the fpga is not initialized, so that's potentially a place to multiplex boards
aight, i'mma go do some of the work that actually pays, see you all later
EMC: 03tissf 07v2_2_branch * 10emc2/docs/src/ (Master_HAL_fr.lyx Submakefile index.tmpl index_fr.tmpl): French translation
EMC: 03tissf 07v2_2_branch * 10emc2/docs/src/hal/rtcomps_fr.lyx: French translation
EMC: 03tissf 07TRUNK * 10emc2/docs/src/ (4 files): French translation
EMC: 03tissf 07TRUNK * 10emc2/docs/src/ladder/ladder_intro_fr.lyx: French translation
good night all