#emc | Logs for 2004-12-09

Back
[00:14:27] <CIA-3> 03fjungclaus * 10emc2/src/po/de_rs274_err.po: Added to cvs ...
[00:15:11] <robin_sz> * robin_sz gets slowly drunk
[00:19:27] <robin_sz> hic .o0()0o.
[10:57:36] <CIA-3> 03Zathras 07BDI build system * 10Babylon Cluster/comps.xml: File changed. New revision:picax.xml
[15:31:54] <wb> wb is now known as fenn
[15:32:11] <paul_c> Afternoon fenn
[15:32:17] <fenn> g'mornin
[15:32:36] <paul_c> West coast ?
[15:32:39] <fenn> indiana
[15:33:40] <fenn> discussion of CAD/CAM packages for linux came up again on the gingery_machines list
[15:34:09] <paul_c> There are a few around now
[15:34:13] <fenn> everyone seems to think they exist but nobody knows any names
[15:34:52] <paul_c> Qcad, Synergy, etc...
[15:35:10] <paul_c> There's a bunch of links on www.linuxcnc.org
[15:36:10] <fenn> heheh i meant one that didn't cost thousands of dollars
[15:36:56] <fenn> i will check out those links
[15:48:37] <paul_c> * paul_c finds a new(ish) toy has duff memory...
[16:03:29] <paul_c> Now I know the west coast is stirring.
[16:03:37] <dave-e> just barely
[16:04:01] <paul_c> Middle of the afternoon...
[16:04:06] <dave-e> at least it is light outside
[16:04:18] <paul_c> sun's going down.
[16:04:48] <dave-e> yup... we are at Z-8
[16:05:31] <dave-e> I don't have jury duty...so am off to the treadmill...be back in an hour or so.
[16:05:45] <paul_c> at least we have the winter solstice to look forward to.
[16:05:57] <dave-e> shortly
[16:16:23] <fenn> * fenn wonders what duff memory is
[16:16:58] <paul_c> faulty, knackered, US.
[16:22:26] <fenn> the thing that bugs me about all these cad programs is they are based on manual drafting, whereas what I want will go straight to a toolpath generator
[16:23:05] <fenn> what's the point of a 2d cad package when you've got a 6D mill?
[16:23:40] <paul_c> you mean a six axis mill surely...
[16:23:51] <fenn> same thing if you think about it
[16:24:15] <fenn> er wellnot exactly
[16:24:34] <fenn> b/c a bridgeport has a knee and quill in the same dimension but diff axis
[16:24:42] <fenn> right?
[16:25:32] <paul_c> One would be Z, the other, W or Z'
[16:28:33] <CIA-3> 03Zathras 07BDI build system * 10Babylon Cluster/RELEASE-NOTES: File changed. New revision:1.32
[17:33:45] <paul_c> Yo Ray
[17:34:12] <paul_c> Begining to think you'd been hit by a major power cut.
[17:34:15] <rayh> Hi Paul. Got your note re the dl.
[17:34:33] <rayh> Got called away to repair a sawmill this morning early.
[17:35:09] <rayh> Much to much money in service to refuse.
[17:37:13] <paul_c> well.. 4.02 is (slowly) installing on a 433MHz board with a paltry 64Meg of memory.
[17:39:09] <rayh> Wish that I'd borrowed a few mil 2 years ago and put it into euros.
[17:40:01] <rayh> Sounds like a good compromise with the proc speed and memory requirements. The 512 was just to big.
[17:41:47] <paul_c> We'll see how it runs.... Might want to install icewm for speed.
[17:56:35] <rayh> Is ice on the disk?
[17:57:14] <paul_c> nope - That is on the "Look at, and maybe Do" list.
[17:57:32] <rayh> Ah.
[17:57:47] <rayh> It would work well in dedicated environments.
[17:58:30] <paul_c> For embedded systems, fluxbox might be a better choice.
[17:59:48] <rayh> Not seen that?
[18:02:21] <paul_c> http://fluxbox.sourceforge.net/ - But their web site appears to be having problems.
[18:02:27] <les> ray...a question
[18:03:51] <les> I'm looking at 150,000+ blocks of gcode for my turkey array
[18:04:06] <les> god knows how big that file will be
[18:04:09] <rayh> Okay.
[18:04:22] <paul_c> http://www.linux.org/lessons/short/fluxbox/ has some screenshots
[18:04:51] <les> so you were saying you did a script to automatically run multiple programs in sequence?
[18:05:06] <rayh> The final test for the Sherline was 4+meg and it ran without a flaw.
[18:05:37] <rayh> Yes. What version of emc are you running.
[18:05:48] <les> well at about 2k bytes per page....
[18:06:16] <rayh> I may need to do a bit of tuning cause I think something got broke.
[18:06:28] <les> thats 247 meg!!!
[18:06:37] <les> running 2.18
[18:07:21] <les> june 2004 emc build
[18:07:56] <rayh> The big issue with that sized file would be load time. Until the EMC intrpreter gets finished with read ahead, the tickle graphical interfaces don't respond.
[18:09:26] <les> right..i know that well
[18:09:31] <rayh> les. I believe that I'd burn that on a cd and try running it. You might want to use xemc rather than tkemc.
[18:09:44] <les> let me double check my numbers here...
[18:09:57] <paul_c> Oh Pooh.... anaconda just crashed on me..
[18:10:07] <rayh> Ouch.
[18:10:25] <paul_c> Ran out of memory and died.
[18:10:35] <rayh> les: if you could get it to run through, it would be something to crow about on the lists.
[18:10:46] <rayh> RAM or HD?
[18:10:54] <paul_c> RAM.
[18:11:21] <rayh> Darn. I was wishing...
[18:11:36] <paul_c> still have text mode.
[18:12:15] <dave-e> 150K blocks*(20 bytes agv/block) ~ 3M
[18:12:17] <rayh> You mean the great text guru was running a graphical install? Say it was only a test...
[18:12:51] <paul_c> Hey... Gotta test these things before the end user breaks them.
[18:12:52] <rayh> Hi dave. Didn't even look at the list here. How you doing today.
[18:13:15] <rayh> I knew he wouldn't admit to graphical anything.
[18:13:35] <les> yes my assumptions were wrong about file size...it will be only a meg or so
[18:13:41] <les> no problem
[18:13:47] <les> never mind haha
[18:13:56] <dave-e> yesterday after i got kicked off the jury I came back and fired up vsitest...and left it on the encoder for 4 hours without a single pulse
[18:14:20] <dave-e> no I need to try the same thing with the servo motor running...
[18:14:23] <dave-e> now
[18:14:40] <les> checking for that drift you had?
[18:14:51] <dave-e> just looking for emi
[18:14:57] <rayh> So the encoder -> board is good.
[18:15:07] <les> oh ok great
[18:15:20] <dave-e> I really think that the problem is in the loop
[18:15:38] <dave-e> lots more to do...
[18:15:47] <rayh> And the motor is rock solid on a battery box or a jumper.
[18:16:07] <dave-e> absolutely
[18:16:20] <dave-e> on the battery box
[18:16:52] <dave-e> I need to rebuild the driver...it won't read the encoder anymore
[18:16:55] <paul_c> rayh: Did we get an ftp account in SD to use ?
[18:17:20] <rayh> How rigid can you get the motor shaft with a jumper across input?
[18:17:30] <dave-e> immovable
[18:17:32] <rayh> We did get an ftp site there.
[18:18:16] <rayh> Probably be tomorrow morning/afternoon before i get it in there for them to try.
[18:18:57] <rayh> So tach is correct direction. What about tach gain?
[18:19:24] <dave-e> don't really know...I probably should play with that
[18:19:25] <paul_c> If I started an upload from here, it would be done by abot 06:00GMT
[18:19:41] <paul_c> (going for Tea)
[18:19:55] <rayh> So we are not getting it at my guy's place?
[18:20:05] <rayh> Or will both run?
[18:21:36] <dave-e> les ... I got a couple of mt30's from Doug....he did up the price...$220
[18:23:11] <les> no suprise....I need to change the web page then
[18:23:21] <les> still a bargain
[18:23:24] <dave-e> ray...I have x and y running on the Mazak...tuned to +/- 0.0004 with just a couple of tries
[18:23:31] <dave-e> yes it is
[18:23:47] <les> have not talked to him...how many does he have left?
[18:23:58] <rayh> Fantastic. Time to start making chips.
[18:24:03] <dave-e> les...he is down to about 6 and is trying to save some for himself
[18:24:35] <les> oh....better remove them from the forsale page
[18:24:57] <les> we had 105 to start
[18:24:59] <dave-e> ray...I really need the Z to start making chips. ...have 10 pin idc connectors ordered from Allied to do the encoders off the stg breakout board
[18:25:27] <rayh> You are getting close then.
[18:26:11] <dave-e> well..I have to give up the board for repair or do the 4th axis workaround
[18:26:21] <dave-e> also have to fuss with coolant
[18:26:27] <rayh> With that 8 axis stg you could shift the base address in software and use the last four channels.
[18:26:48] <dave-e> hmmm...good idea
[18:27:12] <dave-e> so how much do I have to shift
[18:28:06] <dave-e> guess i could try it and see what channels work
[18:28:14] <rayh> Not a clue. We need Paul or Les for that.
[18:28:41] <dave-e> I'm headed for the shop .....will checkin later
[18:28:43] <rayh> It might barf at the high end.
[18:32:52] <rayh> * rayh may go away while trying fluxbox.
[18:40:21] <paul_c> * paul_c is back for a few mins..
[18:45:28] <fenn> is STIX/STEP-NC/AP238 worth worrying about?
[19:10:49] <jepler> fenn: I've never heard of either of those, but after I searched for step-nc on google, I got a webpage that says I had better upgrade to netscape 4 to enjoy their site
[19:11:26] <jepler> it's hard to take a website like that very seriously
[19:11:51] <paul_c> StepNC is touted as the next big thing in CNC
[19:12:47] <jepler> the www.step-nc.org web page looks pretty stale, and the features they describe are irrelevant to me as a hobbyist
[19:15:05] <fenn> i'm currently worrying about writing some sort of NC output from Ayam and am considering my options
[19:15:32] <fenn> since there is a lack of toolpath generators out there
[19:15:52] <fenn> Gcode is rather old and clunky
[19:17:54] <paul_c> agreed... Nor is it particularly "standard" across the board.
[19:20:23] <fenn> since my interest is more in terms of hexapods (dont roll yer eyes) i'm looking for something that specifies surface normals. that way i can use a cylindrical endmilll and create a smooth (convex) surface without too many finish passes
[19:21:09] <fenn> i got the idea that gcode has problems with arcs in more than 2 dimensions
[19:23:01] <jepler> Arcs plus rotational movement seem to be ill-defined in the rs274ngc document I've read
[19:23:12] <paul_c> There is no simple way to define an arc in 3D
[19:23:50] <paul_c> Although... There are codes to incline a plane and use that as a reference.
[19:24:00] <fenn> you mean, in rs274 there is no simple way?
[19:24:03] <paul_c> but not in EMC (yet)
[19:24:07] <les> I wouldn't mind getting axis 4 and 5 on my machine
[19:24:20] <les> that's why I made the z so big
[19:25:04] <les> not enough io on the stg though (i think)
[19:26:26] <paul_c> hmmm.. G75 is listed as a multiquadrat circular interpolation move...
[19:28:06] <paul_c> * paul_c is heading out for the evening...
[19:28:26] <fenn> have fun
[19:28:27] <paul_c> back in four hours.
[19:28:47] <paul_c> * paul_c is away: Out on the tiles.
[19:32:17] <fenn> * fenn wishes he knew what multiquadrant meant
[19:38:42] <jepler> According to the web, some rs274 interpreters think a G2/G3 arc can never be in more than one quadrant
[19:39:15] <jepler> (eg the quadrant where x, y are both greater than the center of the arc)
[19:39:56] <jepler> g75 would then be the default emc behavior, with arcs specified with I- J- to be up to 360 degrees with no regard to quadrants
[19:40:12] <jepler> http://www.advancedmsinc.com/glossary/glossary_G.htm
[19:40:23] <jepler> "Another important case ..."
[19:41:30] <fenn> * fenn blinks
[19:43:12] <fenn> so if you do g2 0 0 0 0 it will do a point but g75 0 0 0 0 will make a circle?
[19:43:50] <cradek> g0x0y0 / g2x0y0i.5j0 will make a circle
[19:44:15] <cradek> (in emc)
[19:44:31] <jepler> but if emc had g74/g75 (it doesn't), then g0x0y0 / g2x0y0i.5j0 would do something else, possibly drawing only a point
[19:46:09] <jepler> er, g74 / g0x0y0 / g2...
[19:47:19] <fenn> sorry if i'm a pain but i've never had a chance to actually use gcode
[19:52:26] <fenn> my friend was cutting a piece that had rounded edges and the CAM software would only generate discrete steps along the rounded edge
[19:52:47] <cradek> that's pretty typical
[19:53:04] <fenn> the result was that the machine had to start and stop fifty times each pass over each edge
[19:53:12] <cradek> that's not
[19:53:18] <cradek> that's a deficiency in the motion planner
[19:53:29] <cradek> emc smooths out the segments so the machine doesn't have to stop at each one
[19:54:07] <fenn> that was turboCNC i think
[19:54:10] <cradek> depending on your setup, it can run pretty much full speed over those kinds of programs
[19:54:39] <cradek> I don't know anything about turbocnc, but if it stops at the end of every segment no matter what, it sucks.
[19:55:22] <fenn> yeah but i cant convince him to use EMC because he "likes dos"
[19:55:48] <fenn> he does have a point though - it starts up in three seconds
[19:55:53] <cradek> well, there's nothing wrong with using dos for some things
[19:56:10] <cradek> uh, if you spend an extra two hours machining your part, who cares about startup time?
[19:56:17] <fenn> heh
[19:56:38] <fenn> it took 24 hours to make the part :)
[19:56:58] <cradek> ouch
[19:57:42] <cradek> in all seriousness, emc gets this right and you would have much better luck with it
[20:01:47] <cradek> if the segments make a smooth path (no axis is reversing direction) emc will run right over them at nearly full speed
[20:02:19] <fenn> so emc will stop at the top of a bump?
[20:02:50] <fenn> or only the z axis will stop?
[20:03:22] <cradek> the Z has to stop and reverse direction, so its acceleration maximum comes into play. The other axes will do what's necessary to remain on-path
[20:03:42] <cradek> if your acceleration maximum is high, you won't see any discontinuity.
[20:04:11] <cradek> but someone recently had trouble with a program that reversed the Z axis every few thousandths of movement in X or Y
[20:04:19] <cradek> as you might guess, that can't be run through quickly.
[20:04:54] <fenn> depends how big your machine is
[20:05:33] <cradek> sure. I'm no expert on that.
[20:05:53] <cradek> I don't know who here is an expert on emc's motion planner.
[20:05:59] <cradek> all I can report is my experience using it
[20:06:55] <fenn> okay new topic
[20:08:28] <fenn> if you have a part geometry (not toolpath) and no time constraints, can you just trace over the part surface and steadily decrease the tool offset?
[20:08:50] <fenn> instead of defining each pocket separately
[20:09:01] <cradek> no
[20:09:17] <cradek> you will get an error if you try to fit a large tool into a small hole
[20:09:37] <cradek> it won't "ride over the top" like you want
[20:09:41] <fenn> pout
[20:09:47] <cradek> it's not nearly that simple
[20:10:17] <les> pocketing routines can be pretty complicated
[20:10:49] <cradek> at the most basic level the toolpath generator has to know the shape of the tool
[20:10:54] <cradek> emc can't know this
[20:13:53] <fenn> i'm trying to figure out what exactly tool offset does
[20:14:14] <cradek> lets you use the same program after you sharpen your tool
[20:14:44] <fenn> even if i.e. you grind on the side flutes of an endmill?
[20:14:49] <cradek> yep
[20:14:59] <cradek> I think that's a main reason for it
[20:15:07] <cradek> I don't use it since I don't handwrite any gcode.
[20:15:13] <fenn> even a ball end endmil?
[20:15:16] <cradek> maybe someone who uses it will speak up.
[20:15:27] <fenn> how do you generate gcode?
[20:15:41] <cradek> in general, I program in another language and have that generate it
[20:16:05] <cradek> in my opinion, gcode isn't a reasonable language to program in directly.
[20:16:22] <fenn> yeah it all looks like mush
[20:16:41] <les> I am having to do a bunch of manual cut and paste on gcode now
[20:16:52] <cradek> well, looks aside, there are no subroutines, loops, etc.
[20:17:33] <fenn> so what do you use, C? python?
[20:18:00] <jepler> A lot of the gcode I generate is from the Eagle circuit-board design program
[20:18:06] <jepler> it has its own "user language"
[20:18:14] <les> a text editor...for gcode
[20:18:40] <jepler> I would also recommend Python for that kind of task
[20:19:06] <jepler> .. as long as you are comfortable writing Python code to read whatever your input file is (such as dxf)
[20:19:14] <les> I just downloaded Autoeditnc from the sherline site...got tired of using word
[20:19:30] <fenn> heh word to edit NC files..
[20:19:40] <les> anyone know of a better freeware nc editor?
[20:20:16] <fenn> for windows?
[20:20:29] <les> yeah...I use that in the office
[20:21:18] <cradek> fenn: I've also used LISP
[20:21:26] <les> I have one nc file with 4 tool changes that makes one part
[20:21:27] <cradek> fenn: use whatever sane language you're comfortable with
[20:21:43] <cradek> you're just outputting some strings, so who cares what language you use
[20:22:05] <les> I have to now make an array of 54 parts
[20:22:07] <fenn> i'm just wondering what languages i will have to learn
[20:22:16] <les> and have to do that manually ugh
[20:22:28] <cradek> I've also used m4 to get looping, but you might not want to use that as a first choice.
[20:23:04] <les> hmm
[20:23:31] <fenn> so you were going to paste part code, change coordinate system, paste part code.. etc 54 times?
[20:23:35] <cradek> les: use g54 / g10 l2 p1 x... y... and loop
[20:23:40] <dave-e> how large is the program for one part?
[20:26:04] <dave-e> hi ray
[20:26:05] <les> I am using all fixture offsets to make a row of 9
[20:26:22] <les> then variables and another row of 9
[20:26:24] <les> etc
[20:26:53] <dave-e> why not use a language to generate the offsets for all 54 parts (one tool change)...
[20:27:02] <cradek> no kidding
[20:27:15] <dave-e> the change tools and duplicate that code, etc
[20:28:00] <les> well I could write a little code that does that sort of thing
[20:28:17] <dave-e> it really isn't too bad and is often reusable
[20:28:23] <cradek> I'd write a lot of code to keep from changing tools 212 times
[20:28:55] <les> I have to lump together all 54 with tool 1, then all 54 with tool 2, etc
[20:29:07] <les> doing that now
[20:29:19] <les> wish this had subroutines haha
[20:29:20] <dave-e> keep to tool change down to every 20 min or so?
[20:29:23] <rayh> Hi dave.
[20:29:51] <les> dave-e: thelonger between changes the better...
[20:29:59] <cradek> les: want my m4 looping code?
[20:30:20] <dave-e> I just tried to compile emc...not rcslib and it crashed as usual...on extbridgeportio
[20:30:32] <les> sure...but I read m4 as spindle ccw....??
[20:30:39] <cradek> haha
[20:30:41] <dave-e> the rcslib/etc has not been changed since the last build
[20:31:18] <cradek> dave-e: what error?
[20:32:04] <dave-e> oh, the usual....it looks at -loutb.c ...and says it is not a directory...which is true
[20:32:16] <cradek> yuck
[20:32:30] <cradek> you mean -Ioutb.c?
[20:32:52] <dave-e> the rcslib/etc has the tck...sh files in it...which usually cure the problem
[20:32:54] <dave-e> yes
[20:33:19] <cradek> dave-e: mkdir src/emcio/AAA
[20:33:24] <dave-e> opps...try tcl*.sh
[20:33:31] <cradek> dave-e: then try again
[20:33:43] <dave-e> OK
[20:35:42] <les> well enough of this text editor stufff....I need to go out and actually run one of the custom bits I designed and see how fast I can feed it
[20:36:31] <les> usually run out of power at about 180 ipm
[20:46:03] <dave-e> cradek...seems like voodoo but it works..clean compile but still no reading of the encoder..
[20:46:13] <cradek> dave-e: it is voodoo
[20:46:18] <dave-e> trying encoder on vsitest shows counts
[20:46:43] <cradek> dave-e: there's a makefile bug somewhere but I couldn't find it when I ran into that problem a while back
[20:46:54] <cradek> dave-e: so I figured out how to work around it
[20:46:59] <dave-e> cute
[20:47:11] <cradek> dave-e: sorry, don't know anything about encoders
[20:47:44] <dave-e> well I think I do but that doesn't help
[20:48:07] <cradek> coffee break...
[20:48:14] <dave-e> so what does m4 do for you that C won't
[20:49:48] <fenn> smaller gcode file :P
[20:50:10] <les> I'm trying to find that out...on the gnu M4 page now
[20:51:51] <cradek> dave-e: nothing
[20:52:04] <cradek> dave-e: it's a preprocessor, not a programming language
[20:52:29] <cradek> dave-e: they're really apples and oranges. you don't have to compile m4, for instance
[20:52:33] <dave-e> ok
[20:53:47] <cradek> I'm not sure I recommend using it, actually, but if you want a flexible preprocessor, you already have one on any unix
[20:54:03] <cradek> les: if you just want looping, I figured it out already and you're welcome to a copy of my file.
[20:54:24] <les> looping of a gcode file?
[20:54:40] <cradek> yeah, looping and calling "subroutines" in gcode with m4
[20:55:30] <les> yes thanks I would like to see that. Was M4 on rh6 distros?
[20:56:05] <cradek> -> rpm -qf /usr/bin/m4
[20:56:05] <cradek> m4-1.4-12
[20:56:44] <cradek> yes, rh6.2 had m4
[20:56:51] <cradek> (any system that has sendmail has m4)
[20:57:11] <les> aw stupid xp wouldn't allow the transfer
[20:57:30] <cradek> email?
[20:57:43] <les> what is the file name?
[20:57:48] <cradek> gcode-loop.m4
[20:58:10] <les> yes email would be quickest
[20:58:24] <les> leswatts@lmwatts.com
[20:59:39] <cradek> sent
[21:00:06] <les> thanks
[21:00:10] <cradek> welcome
[21:00:44] <cradek> if it's not obvious, run it with `m4 gcode-loop.m4 > outputfile.ngc'
[21:05:13] <dave-e> cradek...I'd appreciate a copy of that file also.. dengvall@charter.net
[21:05:47] <les> having a look at your code
[21:07:07] <fenn> *cough* perhaps that could end up on a bdi distro since it appears to be useful
[21:07:53] <les> what is that gcode in the M4 program?
[21:08:51] <cradek> the define `program' makes a circle at 0,0 after setting the coordinate system offset to ii,jj
[21:09:35] <cradek> the part between the percents is the actual g-code that calls the "subroutine" `program' in a double loop to make a grid of them
[21:10:16] <les> oh...so I put my gcode to be duplicated between the define and )dnl?
[21:10:22] <cradek> yes
[21:10:29] <cradek> and ii,jj are "passed in" to the define
[21:10:50] <cradek> ii,jj are integers so divide or multiply accordingly to get the coord offsets where you want them
[21:11:24] <les> and I guess preamble and ending are added to the whole thing after?
[21:11:33] <cradek> yeah
[21:11:38] <les> ok got it
[21:11:41] <cradek> just look at the output, it's obvious what's going on with those comments there
[21:13:00] <cradek> of course you can make many defines, name them whatever you want (`program' was a stupid name) and call them however you want, in loops or not
[21:14:53] <les> hmm g10 rather than g5x offsets...
[21:16:17] <cradek> it is using g54
[21:16:19] <cradek> see the beginning
[21:17:10] <les> yes...to set default
[21:21:49] <les> I was thinking of writing a little c thing to do this....but this looks fine
[21:23:51] <les> about 10 years ago I wrote a little c program to do arrays of micro optics with gcode
[21:24:03] <les> machine ran for about a week
[21:38:06] <les> oh...where do I set the array dimensions...in forloop(?
[22:27:32] <cradek> yes
[22:27:35] <cradek> forloop(`ii', 0, 3, `forloop(`jj', 0, 3, program)')dnl
[22:30:40] <les> what is the 0 and 3? one must be the array size
[22:39:46] <cradek> start and end
[22:49:30] <les> ok got it thanks
[22:49:46] <cradek> welcome