Back
[01:35:51] <Jymmm> I jsut recorded off the air making end mills. It's about 300MB and the aspect ratio might be off. anyone interested?
[02:13:31] <A-L-P-H-A> Jymmm, yeah.
[02:13:41] <A-L-P-H-A> is it from "how it's made"
[02:13:46] <Jymmm> yep
[02:13:56] <A-L-P-H-A> yeah. seen it. :) love our canuck shows don't you.
[02:14:03] <A-L-P-H-A> but yeah, I wouldn't mind having a copy.
[02:14:49] <Jymmm> I RARELY record anything, so I didn't have it configured correctly, but "good enough"
[02:15:00] <Jymmm> ok, you got a place I can upload it to?
[02:15:22] <A-L-P-H-A> yeah. sec.
[02:15:31] <Jymmm> it's 300MB
[02:16:16] <Jymmm> can you open a Z7 archive?
[02:16:36] <A-L-P-H-A> Jymmm, yes
[02:16:49] <Jymmm> ok, let me see how small I can make it.
[02:34:23] <A-L-P-H-A> Jymmm, did add kick in?
[02:34:28] <A-L-P-H-A> ADD
[02:36:27] <Jymmm> ?
[02:41:09] <Jymmm> A-L-P-H-A did you set the perms right?
[02:41:32] <A-L-P-H-A> I'm behind a router
[02:42:00] <A-L-P-H-A> So you'll have to toggle passive mode
[02:42:02] <Jymmm> I logged in couldn't upload
[02:47:26] <A-L-P-H-A> Jymmm, oh ohwell.
[03:29:49] <CIA-12> 03compile-farm 07BDI-TNG (2.4.18-rtai) * 10emc2head/: build FAILED ; see
http://linuxcnc.org/compile_farm/emc2head_slot3_log.txt
[03:37:23] <CIA-12> 03jmkasunich 07HEAD * 10emc2/src/hal/utils/scope_disp.c: C90 doesn't allow mixed declarations and code, causes warnings on recent systems, compile failures on old ones
[03:39:02] <CIA-12> 03compile-farm 07BDI-4.20 (2.6.10-adeos) * 10emc2head/: build FAILED ; see
http://linuxcnc.org/compile_farm/emc2head_slot5_log.txt
[03:54:15] <cradek> jmkasunich: I was just going to fix that but you're faster
[03:54:56] <jmkasunich> heh
[03:55:27] <jmkasunich> I found another warning, but I'm not sure what the original intent was
[03:55:34] <jmkasunich> SWPadnos might know
[03:55:36] <CIA-12> 03compile-farm 07BDI-TNG (2.4.18-rtai) * 10emc2head/: build PASSED
[03:56:04] <jmkasunich> if(prompt_mode) {
[03:56:04] <jmkasunich> fprintf(stdout, scriptmode ? "%\n" : "halcmd: "); fflush(stdout);
[03:56:23] <jmkasunich> is it supposed to print "%" as a prompt when in script mode? or nothing at all?
[03:56:43] <jmkasunich> the compiler sees % followed by /n and says "huh?"
[03:56:54] <jmkasunich> should either lose the %, or escape it, I think
[03:56:57] <cradek> I think someone meant %%
[03:57:27] <jmkasunich> I don't know anything about script mode, I think SWPadnos worked that out with ray
[03:57:37] <jmkasunich> and I'm too lazy to try to figure it out
[03:57:38] <cradek> something about halshow needs % signs, I don't know the details
[03:57:51] <cradek> I think just change it to %%
[04:01:13] <CIA-12> 03compile-farm 07BDI-4.20 (2.6.10-adeos) * 10emc2head/: build PASSED
[04:01:21] <CIA-12> 03jmkasunich 07HEAD * 10emc2/src/hal/utils/halcmd.c: fix a warning
[04:03:30] <jmkasunich> bedtime
[04:04:08] <cradek> me too, night
[06:52:43] <Jymmm> Jymmm is now known as MrAsshole
[06:53:29] <MrAsshole> MrAsshole is now known as Jymmm
[08:26:00] <Lerneaen_Hydra> 'lo
[08:26:50] <ValarQ> g'day
[08:26:58] <A-L-P-H-A> Lerneaen_Hydra, this is quiet time... please. some of us are trying to be doing other stuff.
[08:26:59] <A-L-P-H-A> :)
[08:27:09] <ValarQ> :)
[08:28:55] <Lerneaen_Hydra> haha
[08:29:08] <Lerneaen_Hydra> or were you serious...
[08:30:34] <A-L-P-H-A> no
[08:33:26] <Lerneaen_Hydra> ok, good
[08:34:28] <Lerneaen_Hydra> oh, random musing from the weblist, as it stands now it seems that when doing a linear feed with an angular feed, that the linear feed determines the rotational speed of the axis
[08:35:02] <Lerneaen_Hydra> which would mean that the operator has to calculate the "compensated" feed, so it doesn't break the tool
[08:38:02] <Lerneaen_Hydra> wouldn't it be trivial to change that behaviour so that when doing say, g0 x0 z10 , g1 x10 a360 f100 that emc calculates the total distance that the tool tip passes (sqrt((2*10*pi)^2*10^2) and uses that feed instead of the current behavior?
[08:38:41] <Lerneaen_Hydra> I'm not saying that this should be implemented, I'm just curious as to why it isn't implemented, as this seems like the behaviour that one would expect
[08:40:34] <Lerneaen_Hydra> also just doing a360 while standing still in linear axes seems to define F as degrees/min, why have that rather than a tooltip calculated perimeter feedrate, as mm/min / mm/turn
[08:56:49] <Lerneaen_Hydra> * Lerneaen_Hydra pokes cradek
[10:35:59] <A-L-P-H-A> not really work safe...
http://www.metacafe.com/watch/142221/smallest_mp3_player_ever/
[10:45:54] <ValarQ> it is here, "You don't have the latest version of Macromedia Flash Player"
[11:04:19] <A-L-P-H-A> ValarQ, well... sucks to be you. :)
[11:04:26] <A-L-P-H-A> if this was yoga everywhere...
http://www.metacafe.com/watch/126280/yoga_for_dudes/
[11:05:15] <ValarQ> and flash 8 and 9 only exists for Mac OSX and Windows...
[11:11:16] <A-L-P-H-A> ValarQ. wine?
[11:11:35] <ValarQ> might work
[11:38:32] <jepler> Lerneaen_Hydra: the rs274ngc spec doesn't define the meaning of rotary axes well enough for that to be possible.
[11:39:35] <jepler> Lerneaen_Hydra: the "A" axis isn't necessarily along the axis Y=Z=0
[11:44:05] <jepler> even if it is, imagine that you moved the tooltip to X0Y0Z0, which makes a cut to the center of a small cylinder of material. You rotate a180, which moves the tooltip no distance. Doesn't your logic say it's OK to do this at the fastest speed possible?
[12:54:09] <harty1> harty1 is now known as help
[12:54:17] <help> help is now known as harty1
[12:54:33] <harty1> help
[12:55:02] <harty1> please disregard that
[13:48:30] <Lerneaen_Hydra> jepler: yes, wrt. the last move (at center of peice) you'd get a divide by zero-esque movement, so I don't know what would be best
[13:48:54] <Lerneaen_Hydra> all that I know is that I find the current behavior to be counter-intuitive
[13:49:42] <cradek> I just sent another post about that with a link to the ngc spec
[13:49:51] <cradek> http://www.isd.mel.nist.gov/personnel/kramer/pubs/RS274NGC_3.web/RS274NGC_32a.html#1010695
[13:50:35] <cradek> like jepler says, I don't think you can do better than the spec if you don't know the positions of the rotaries, and we don't
[13:51:41] <Lerneaen_Hydra> hmm, I guess you're right
[13:51:58] <Lerneaen_Hydra> if one were to imagine that emc did know the positions
[13:52:06] <Lerneaen_Hydra> in some manner
[13:52:09] <cradek> sure then you can calculate the feed better
[13:52:12] <Lerneaen_Hydra> which issues would then arise
[13:52:25] <Lerneaen_Hydra> except for the center of material things
[13:52:31] <Lerneaen_Hydra> s/things/thing
[13:53:07] <cradek> I haven't thought that through
[13:53:40] <Lerneaen_Hydra> ok. Am I the only one who thinks that rotaries are handled unelegantly now?
[13:54:07] <Lerneaen_Hydra> or is it a "it's too big of something to change now, but maybe we'll look into it later" thing
[13:55:00] <cradek> I'm sure everyone wants emc to figure out the tool tip vs part surface feed even when doing mixed linear/rotary moves, but that requires information that it doesn't have
[13:55:59] <cradek> I'm not sure I'd call it inelegant that the spec chooses a different behavior that is possible and understandable
[13:56:25] <cradek> (but it's certainly not the ideal behavior)
[13:56:34] <steves_logging> steves_logging is now known as steve_stallings
[13:57:09] <cradek> hi steve
[13:57:24] <steve_stallings> Handling feed rate control for non-Cartesian axes requires additional knowledge of the geometry of the machine and/or fixtures.
[13:57:36] <cradek> yes
[13:58:22] <steve_stallings> Since machine tool makers are reluctant to have users fiddling with the setup paramaters of their machines, the problem has typically been handled in CAM software.
[13:58:41] <cradek> that's good to hear
[13:58:47] <steve_stallings> The CAM gets configured by the user for the geometry and uses the inverse-time feed rate to get the desired results.
[13:59:24] <cradek> cool (I'm not a cam user so I don't know these things)
[14:00:04] <Lerneaen_Hydra> oh, that simplifies matters somewhat, although g-code programmers are still stuck with the old system
[14:00:29] <steve_stallings> It does get messy because you have to input all your tool data into the CAM package also, and tool substitution at run time screws thing up.
[14:01:16] <Lerneaen_Hydra> I'm not sure if the point about machine tool makers and end users setting up applies to emc though, as the end user (or system builder) has to do quite a lot of configuring. (HAL config springs to mind)
[14:02:01] <steve_stallings> True, EMC users typically do their own configuration. My point was to explain where the industry was and why.
[14:02:17] <cradek> the hand gcode programmer is unlikely to program a stacked-rotary machine or other complex motion
[14:02:34] <cradek> I bet he's more likely to use one rotary for indexing, or to cut circles or spirals
[14:02:51] <cradek> and these concerns are pretty easy to deal with in the simple cases
[14:02:59] <steve_stallings> There are a few machines that handle things on-board, but they basically have CAM integrated into the machine and accept solid models as input.
[14:03:05] <Lerneaen_Hydra> that would also explain why rs274 spec specified it as such, as it was intended to be as standard for larger corporations (if I understood things correctly)
[14:03:41] <Lerneaen_Hydra> cradek: other people that use the lathe I've run with an indexed spindle program lots of rotary axis things by hand
[14:03:57] <Lerneaen_Hydra> and really don't like that behavior
[14:04:02] <cradek> just becaue emc can do a helix in XYZ with all three rotaries moving, it doesn't mean some gcode programmer will want that move (or know what shape it makes)
[14:04:55] <Lerneaen_Hydra> a lathe code like this is quite common though: g0 x10 z5 g1 z-10 a360 f100
[14:05:18] <cradek> what's A on a lathe?
[14:05:19] <steve_stallings> An extension of NGC to handle one rotary axis with a declared center of rotation might be workable. Tool lenght offset would still be messy.
[14:05:35] <cradek> usually A is parallel to X
[14:05:49] <Lerneaen_Hydra> err C I meant
[14:07:14] <steve_stallings> much delayed.... Hi Cradek
[14:07:38] <cradek> steve_stallings: also imagine a XYZC machine being used to cut a 3-jaw spiral using an XC G1: the angular feed has to change throughout the cut
[14:08:18] <cradek> currently a G1 has just one feed for the whole move
[14:08:22] <cradek> so that's a major change
[14:10:31] <cradek> today the easy solution is to generate a bunch of XY arcs and not use the rotary at all
[14:10:43] <cradek> looks like we have a working mailing list again
[14:11:00] <steve_stallings> Yes, I got a 20 message dump this AM.
[14:11:22] <steve_stallings> Not just delayed, but out of time sequence also. 8-(
[14:11:29] <cradek> yep
[14:13:47] <cradek> is it just me or is it getting more and more painful to read the emc-users list
[14:13:55] <steve_stallings> Arc moves currently adjust individual axes during move. Perhaps we could add a new "token" to "add line" with varying feed rate?
[14:15:45] <cradek> I agree it could be done, but everything along the way assumes that for G1/2/3, along the entire path there is only one accel, one velocity, one decel
[14:16:53] <cradek> you could approximate it at the interp level by breaking the move into many moves
[14:18:05] <steve_stallings> Perhaps I don't get it, but ARCs handle this while the individual axes have differing requirements. The math solution for velocity would differ, but approach should be similar.
[14:18:25] <cradek> think of the velocity along the arc path: it stays the same
[14:18:50] <cradek> that's how the planner sees it
[14:19:10] <steve_stallings> And that should be the goal of any enhanced rotary move also, just a different way to get there.
[14:19:42] <cradek> I understand
[14:19:50] <cradek> I'm struggling to explain what I'm thinking
[14:20:15] <Jymmm> * Jymmm giggles
[14:21:25] <steve_stallings> A rotary move would be complicted just like the arcs. An algro would be needed to solve for each axis much like the arc solution. Result would vary over time.
[14:21:58] <cradek> ok, I see what you mean
[14:22:25] <cradek> I'm stuck in "how it works now" mode where a G1 is just a G1
[14:22:26] <steve_stallings> I guess we would have to exclude mixing an ARC with a rotary move... 8-)
[14:22:36] <cradek> but an XY G1 and XC G1 are totally different animals
[14:22:52] <Lerneaen_Hydra> steve_stallings: an arc move + rotary should be valid
[14:23:02] <Lerneaen_Hydra> at least, it's quite common to perform that
[14:23:06] <steve_stallings> Yes, but the solution to XC G1 would be more like an ARC solution.
[14:23:12] <cradek> right
[14:23:30] <cradek> Lerneaen_Hydra: in what kind of machining?
[14:23:37] <steve_stallings> Should and practical might be two different things.
[14:23:38] <Lerneaen_Hydra> oh, right. as long as a XZC G2/3 is valid
[14:23:48] <Lerneaen_Hydra> say when doing radial machining in a lathe
[14:23:54] <Lerneaen_Hydra> with an indexed chuch
[14:23:56] <Lerneaen_Hydra> chuck
[14:24:23] <Lerneaen_Hydra> then you want to be able to make a circle on the side, or a pocket with a radius larger that the tool radius
[14:24:38] <Lerneaen_Hydra> (this is with driven endmills for instance)
[14:24:52] <steve_stallings> My assumptions are related to mills, haven't thought thru lathe and probably don't have enough experience to do so...
[14:25:08] <Lerneaen_Hydra> I think the same thing would be valid for a mill
[14:25:37] <Lerneaen_Hydra> http://www.teksoft.com/images/C_axis_OD1.jpg
[14:25:45] <Lerneaen_Hydra> say that curve near the end of the part
[14:26:12] <Lerneaen_Hydra> and just ignore that that's a lathe for the moment ;)
[14:28:06] <cradek> I'd find that most natural to program as if the part is "unrolled" which would be lines and arcs in XC (I think)
[14:28:32] <cradek> no, ZC
[14:28:38] <Lerneaen_Hydra> uh, right
[14:28:52] <Lerneaen_Hydra> which means you have to support arcs, and not only G1/g0
[14:29:16] <cradek> there's certainly no ZC arc plane in ngc
[14:29:34] <Lerneaen_Hydra> oh.
[14:29:40] <cradek> but you could do that with G1 today
[14:29:52] <Lerneaen_Hydra> you mean arc approximation?
[14:29:56] <cradek> yes
[14:32:05] <steve_stallings> You could also assign spindle rotation to Y and apply the "unrolled" solution as an arc in YZ. Feedrate would have to be manually figured out based on distance from center.
[14:32:27] <cradek> yeah that's the way to do it with today's emc
[14:32:37] <Lerneaen_Hydra> steve_stallings: how do you mean?
[14:32:42] <Lerneaen_Hydra> oh. I think I get it
[14:32:58] <cradek> but on a mill you don't have Y conveniently left over
[14:33:13] <Lerneaen_Hydra> doesn't emc support more than 3 linear axes?
[14:33:18] <steve_stallings> Catch is.... many such toolpaths are not actually arcs, but parabola or other special cam activating curve.
[14:34:18] <steve_stallings> Yes, EMC will support 6 linear axes, but you revert to manual feedrate calculation.
[14:34:30] <Lerneaen_Hydra> oh.
[14:34:54] <Lerneaen_Hydra> any particular reason to support 6 axes
[14:35:08] <Lerneaen_Hydra> and not more/less
[14:35:27] <cradek> the spec says ABC are parallel to XYZ
[14:35:34] <cradek> I'm sure that's why there are 6
[14:35:49] <cradek> no more axes to put rotaries parallel to
[14:35:50] <steve_stallings> One common one is mills that have both a quill (Z) and a knee parallel to Z.
[14:35:52] <Lerneaen_Hydra> oh, no VW or DE axes
[14:36:38] <cradek> steve_stallings: do you ever cut by moving the knee, or do you just use it for gross positioning?
[14:36:40] <steve_stallings> Cuts are taken with quill. Knee is moved, then locked before another cut is taken.
[14:36:48] <cradek> ok
[14:36:57] <cradek> so coordination is not really an issue
[14:37:27] <steve_stallings> There are mills that cut with knee, but I was describing those that do not. I do not know of any that move quill and knee at same time.
[14:39:20] <steve_stallings> There are also "Swiss" lathes that run multiple cutters at the same time on different slides.
[14:40:15] <steve_stallings> Motion on "Swiss" lathes may or may not need coordination based on job.
[14:41:10] <steve_stallings> Imagine turning the OD of a bushing with one cutter while another is boring and cutting an internal snap ring groove.
[14:41:31] <steve_stallings> Later another slide performs cutoff.
[14:42:45] <cradek> sounds like you might want several EMCs with some scheme that synchronizes a few points
[14:43:00] <steve_stallings> I have (but not set up yet) a Hardinge Superslant that runs two turrets with two Fanuc controls. Controls play tag team with interlocks.
[14:43:24] <cradek> wild
[14:43:37] <steve_stallings> Scary to think of programming it.... 8-)
[14:43:37] <cradek> not exactly our target machine
[14:43:42] <cradek> no kidding
[14:44:18] <steve_stallings> I disagree, EMC could someday end up running that machine.
[14:44:54] <steve_stallings> The iron typically outlives the controls.
[14:45:50] <cradek> hmm, that's definitely true
[14:46:45] <cradek> I guess you actually could use two EMCs today, they could synchronize with HAL connections between the two
[14:48:35] <steve_stallings> Even get adventuresome and try to run two EMCs on one CPU. 8-)
[14:49:08] <cradek> that would take a lot of hacking...
[14:49:22] <cradek> if you have that lathe I bet you can afford two PCs!
[14:49:57] <steve_stallings> Two PCs about equal the cost of moving the lathe.
[14:50:38] <steve_stallings> Lathe itself was only $2500 on eBay no less.
[14:51:45] <cradek> http://www.colemanmw.com/facilities/images/nc_lathe-01.jpg
[14:52:12] <cradek> wow, it must have really been in someone's way
[14:52:39] <Lerneaen_Hydra> 2500 for that lathe?
[14:52:43] <Lerneaen_Hydra> my my
[14:53:29] <steve_stallings> Typical price for old and heavy. Over 11,000 pounds heavy. It was Hardinge's first CNC from the ground up and as typical they over did it.
[14:54:47] <Lerneaen_Hydra> erk. ok. that is somewhat understandable then
[14:55:47] <cradek> I'm off to find some breakfast
[15:09:38] <steve_stallings> Just checked the Haas milling machine documentation. Haas REQUIRES that all 4 and 5 axis motion be done with inverse-time feedrate control.
[15:10:47] <steve_stallings> The indicate that you should "see your CAM software" to set it up. Also recommend locking A and B axis whenever not actually involved in the motion of a cut.
[15:11:13] <cradek> cool, that's good info
[15:12:49] <steve_stallings> FYI -
http://www.haascnc.com/customer_service/manual/vmc/96-8000.pdf
[15:16:15] <steve_stallings> Time to go play outside. Later....
[15:16:34] <steve_stallings> steve_stallings is now known as steves_logging
[15:48:28] <Lerneaen_Hydra> meep
[15:57:46] <robin_sz> indeed
[17:51:46] <Lerneaen_Hydra> uh, bbml
[17:51:55] <Lerneaen_Hydra> a few days or so
[17:52:26] <Lerneaen_Hydra> * Lerneaen_Hydra poofs into the real world, a scary place not for the faint of heart
[18:07:48] <Gene> I made it!
[18:08:13] <Gene> And how has everyone been 'summering'?
[18:09:54] <Gene> Humm, rather quiet, anybody awake on a lazy saturday afternoon?
[18:10:47] <Gene> Who is the hal config file guru here?
[18:11:50] <Gene> I got discouraged, saved the two config files I'd played with, blew the whole emc2 dir away and did a new checkout using:
[18:13:28] <Gene> gene@shop:~$ cvs -z5 -d:ext:anon@cvs.linuxcnc.org:/cvs co -rRELEASE_2_0_1 emc2
[18:14:04] <Gene> then configured and built it with the --enable_run-in-place option
[18:14:25] <Gene> and followed that with a make && sudo make setuid
[18:15:03] <Jymmm> * Jymmm leaves this world, exit stage right
[18:15:53] <Gene> Now after transfering my screw scaling factors to the new stepper_inch.ini, and adding the probe_parport statement to standard_pinout.hal, I'm getting this when I run it:
[18:16:41] <Gene> gene@shop:~/emc2$ scripts/emc
[18:16:41] <Gene> EMC2 - 2.0.1
[18:16:41] <Gene> Machine configuration directory is '/home/gene/emc2/configs/stepper/'
[18:16:41] <Gene> Machine configuration file is 'stepper_inch.ini'
[18:16:41] <Gene> Starting emc...
[18:16:41] <Gene> scripts/emc: line 435: /home/gene/emc2/bin/: is a directory
[18:16:44] <Gene> HAL:8: ERROR: Can't find module 'probe_parport' in
[18:16:46] <Gene> HAL config file /home/gene/emc2/configs/stepper//standard_pinout.hal failed.
[18:16:47] <Gene> Shutting down and cleaning up EMC...
[18:16:49] <Gene> Could not find pid(s) for task halshow
[18:16:52] <Gene> Cleanup done
[18:17:35] <Gene> So where did I screw up this time?
[18:18:55] <steves_logging> steves_logging is now known as steve_stallings
[18:19:15] <Gene> Or do I need to change the checkout -rOPTION?
[18:19:25] <steve_stallings> Don't know enough to help with your problem, but did want to let you know that you are being heard on IRC.
[18:20:27] <Gene> Thanks Steve, I was beginning to think the screen was an internally generated echo
[18:20:48] <steve_stallings> Things are pretty quite, most folks are just logging.
[18:20:55] <danfalck> like me
[18:21:09] <Gene> Howdy Dan
[18:21:14] <danfalck> hi Gene
[18:21:46] <danfalck> I'm playing with some os cam tools and sending output to Axis
[18:21:58] <danfalck> just taking it easy today
[18:22:26] <Gene> I'm in WV, where are you? Interesting, I hope to get to the cam stage at some point myself
[18:22:47] <danfalck> I'm in Beaverton Oregon, near Portland
[18:22:51] <danfalck> http://timeguy.com/cradek/truetype
[18:23:01] <danfalck> I just tried that one out and it works
[18:23:08] <danfalck> for me
[18:23:47] <Gene> This sounds like a text to cnc file translator? Neat!
[18:23:55] <danfalck> yes
[18:24:10] <Gene> That I gotta get, brb
[18:24:26] <danfalck> chris and jeff do some cool stuff
[18:24:38] <danfalck> along with everyone else on the project
[18:27:04] <Gene> Ok, whats the command line to get apt to install it?, its on that machine now.
[18:32:53] <Jymmm> apt-get install [package name]
[18:36:44] <cradek> dpkg -i some.deb
[18:37:59] <cradek> sudo dpkg -i some.deb
[18:41:50] <Gene> the sudo dpkg -i worked Chris. But I had to make a local softlink named ttt before I could follow the readme instructions :)
[18:42:29] <cradek> debian already had a ttt package, so I called it truetype-tracer
[18:42:41] <Gene> This is cool as can be, I can see me carving brass plates for the front door etc.
[18:42:50] <cradek> ttt - A standalone program for local traffic-monitoring
[18:43:11] <cradek> it sure could be used to cut out some nice letters
[18:43:14] <Gene> ttt? On this bdi install, no such thing that I can find.
[18:43:19] <cradek> there are a LOT of nice truetype fonts
[18:43:56] <cradek> BDI aside, there already is a package named that in the debian repos.
[18:44:32] <Gene> Which I take it we can specify on the cli? I have some absolutely beautifull cursive font on this box that would look great in metal.
[18:45:36] <Gene> Didja back up and see my plea for help Chris?
[18:46:00] <cradek> Gene: truetype-tracer -?
[18:46:16] <cradek> no, and now I'm scared to
[18:46:34] <cradek> I could have sworn I put a man page in that deb
[18:46:54] <Gene> Nope
[18:47:07] <Gene> Just a short readme
[18:47:29] <cradek> aha, found it, let me update the web page
[18:48:50] <cradek> done
[18:49:03] <cradek> get the new version 3.0-2 and install it, you'll have a man page
[18:50:52] <cradek> hmm, not a great man page, but it does have good usage examples
[18:51:34] <Gene> Got it thanks
[18:52:45] <cradek> about your problem: I don't think the probe_parport module is in the 2.0.1 release, it's very new
[18:53:37] <Gene> It worked before I got discouraged over the other stuff and blew the whole thing away and grabbed that
[18:54:01] <cradek> it's in head, but you've checked out the 2.0.1 release, not head
[18:54:18] <Gene> How do I now suck the latest? presumably a "cvs -rHEAD -Pd"
[18:54:30] <Gene> How do I now suck the latest? presumably a "cvs update -rHEAD -Pd"
[18:54:54] <cradek> cvs update -A -C -dP
[18:55:17] <cradek> but are you sure you don't want to run the release? is this a production machine or are you playing with bleeding edge stuff?
[18:55:50] <Gene> more play toy than wage earner
[18:56:08] <cradek> ok
[18:56:26] <cradek> it's up to you, but if you run head you have to keep up with the goings-on a lot more
[18:56:46] <Gene> I intend to
[18:57:28] <Gene> the 201 release seems to be disconnected from the parport, doesn't move the motors at all
[18:58:17] <steve_stallings> steve_stallings is now known as steves_logging
[18:58:29] <cradek> ok, maybe you have this probing problem then that jepler talked about
[18:58:35] <cradek> try head I guess
[18:59:24] <Gene> I think so, I'd added that line to standard_pinout.hal and it seemed to run from this cli ok.
[19:00:44] <Gene> It should be noted in this probing problems discussion that if modprobe is to be sued to remove those 3 modules after the bootup loads them, they have to be removed in the correct order.
[19:01:05] <cradek> the right fix is for your system to not load parport_pc
[19:01:28] <cradek> I know how to fix that on ubuntu (and our emc packages do it) but I'm not sure how to do it on BDI
[19:01:47] <cradek> I think jon elson posted instructions on emc-users a while back
[19:02:25] <jepler> Subject: [Emc-users] overnight problems with BDI 4.30 -- solution
[19:02:33] <jepler> Date: Wed, 14 Jun 2006 22:05:35 -0500
[19:02:45] <jepler> but he only addresses how to get 'cups' to not run, not how to disable the kernel module altogether
[19:03:34] <Gene> I saw that go from my motel room in MI. So that msg is buried in the so-called fileing system tbird uses. Sucks.
[19:04:11] <Gene> But if thats a problem, I can add that unload to rc.local, no big deal.
[19:04:54] <Gene> And I think cups works, to this printer, from out there.
[19:05:11] <Gene> but haven't tried recently :(
[19:06:42] <Gene> Humm it runs, but tkemc so I need to edit stepper_inch.ini to fix that.
[19:06:48] <cradek> thanks jepler
[19:09:39] <Gene> Humm, odd, I changed the scales to my screw, and the display to axis, and it upchucks now
[19:10:05] <Gene> EMC2 - pre-2.1 CVS HEAD
[19:10:05] <Gene> Machine configuration directory is '/home/gene/emc2/configs/stepper/'
[19:10:05] <Gene> Machine configuration file is 'stepper_inch.ini'
[19:10:05] <Gene> Starting emc...
[19:10:05] <Gene> Can't execute DISPLAY program /home/gene/emc2/bin/axis
[19:10:09] <Gene> Shutting down and cleaning up EMC...
[19:10:11] <Gene> [2]- Terminated $EMC2_BIN_DIR/$EMCSERVER -ini $INIFILE
[19:10:13] <Gene> Could not find pid(s) for task halshow
[19:10:15] <Gene> Cleanup done
[19:10:17] <Gene> EMC terminated with an error. You can find more information in the log files
[19:10:19] <Gene> /home/gene/emc_debug.txt
[19:10:21] <Gene> and
[19:10:21] <cradek> you didn't build axis
[19:10:23] <Gene> /home/gene/emc_print.txt
[19:10:25] <Gene> as well as in the output of the shell command 'dmesg'
[19:10:29] <cradek> you didn't build axis
[19:10:46] <Gene> I need to rebuild it everytime too?
[19:10:48] <cradek> get the latest and put it in /home/gene/emc2/src/axis
[19:10:52] <cradek> it will rebuild automatically
[19:11:21] <Gene> ahh, I'll move the 1.4awhatever (yesterdays) to there and redo it
[19:11:41] <cradek> you'll have to rerun configure and make
[19:12:16] <Gene> Do I need to rename it to just 'axis'?
[19:12:32] <cradek> it can be axis.anything
[19:12:32] <cradek> as long as it's in emc2/src
[19:12:33] <Gene> ok, here goes
[19:12:39] <cradek> configure will say if it finds it
[19:15:48] <Gene> Bingo, runs from here. Now its time to go see if x-chat is installed out there, and continue
[19:20:27] <gene_> Ok, I'm at the machine, and still don't have a parport
[19:21:25] <gene_> Also, the motion axis is showing is about .005" per minute
[19:23:20] <cradek> are you running one of the configs that came in cvs?
[19:23:49] <gene_> If mine got overwritten by the update, then yes.
[19:24:17] <cradek> your config was inside the cvs directory?
[19:25:32] <gene_> gvim /configs/stepper/stepper_inch.ini shows an empty file!!!!!
[19:25:53] <cradek> you probably mean gvim configs/stepper/stepper_inch.ini
[19:26:49] <gene_> Duhh.
[19:28:04] <gene_> whats the line to add for the parportt probe?
[19:28:30] <gene_> its missing from standard_pinout.hal, again.
[19:28:51] <cradek> if you're going to use CVS, make your custom configuration OUTSIDE of the cvs tree
[19:29:05] <cradek> I tell you this every time you have trouble but you never do it
[19:29:17] <cradek> ls
[19:29:28] <cradek> oops
[19:29:37] <gene_> guilty
[19:29:59] <cradek> first go to your home directory and move your emc2 directory out of the way: like mv emc2 emc2.head
[19:30:06] <cradek> then mkdir -p ~/emc2/configs
[19:30:19] <cradek> cp -R emc2.head/configs/stepper ~/emc2/configs
[19:30:34] <cradek> now edit ~/emc2/configs/stepper and cvs will never screw it up
[19:32:51] <gene_> Ok, done
[19:33:34] <gene_> but I first overwrite standard_pinout.hal with my saved one and that broke it again.
[19:33:54] <cradek> ok don't do that
[19:33:58] <gene_> HAL: ERROR: pin 'iocontrol.0.spindle-on' not found
[19:33:58] <gene_> HAL:38: link failed
[19:33:58] <gene_> HAL config file /home/gene/emc2/configs/stepper//standard_pinout.hal failed.
[19:33:59] <cradek> you'll have to investigate the differences
[19:34:45] <gene_> it looks as if we need a better way to handle the loadrt parport_probe
[19:34:55] <cradek> I bet several things have changed since you made that config
[19:36:07] <cradek> brb
[19:36:07] <gene_> Possibly, the top of that file is now:
[19:36:38] <gene_> # first load the parport driver
[19:36:38] <gene_> # if dmesg says its a PNPBIOS parport, do as root:
[19:36:38] <gene_> # modprobe -r lp parport_pc parport
[19:36:38] <gene_> # the order of removal above is important
[19:36:38] <gene_> loadrt probe_parport
[19:36:38] <gene_> # a comment for its time lag?
[19:36:40] <gene_> loadrt hal_parport cfg="0x0378"
[19:37:34] <gene_> Is that correct for head?
[19:37:48] <cradek> I think so
[19:38:07] <cradek> well I think the comment is not right, but that's not important
[19:39:41] <gene_> ok, another try, from ~/emc2.head:
[19:39:55] <gene_> gene@shop:~/emc2.head$ scripts/emc
[19:39:55] <gene_> EMC2 - pre-2.1 CVS HEAD
[19:39:55] <gene_> scripts/emc: line 1: /home/gene/emc2/tcl/bin/pickconfig.tcl: No such file or directory
[19:40:02] <cradek> ok
[19:40:17] <cradek> since we moved the source tree, you have to rerun configure and make
[19:40:31] <gene_> Do I need to go thru another rebuild, I thought so.
[19:41:58] <gene_> in progress
[19:43:41] <gene_> Humm, looks like I ned to switch owners on axis, the make is comnplaining it can't rm the old files
[19:44:04] <cradek> you must be using sudo when you shouldn't
[19:44:31] <cradek> the only time to use it is at 'sudo make setuid', never cvs, never to run emc, never to edit files
[19:45:41] <gene_> correct, but some subdirs of the axis dir are owned by root, and I never touched it as root
[19:46:29] <cradek> you must be mistaken, because a non-root user cannot make files that are owned by root
[19:46:36] <cradek> maybe the directories were old or something
[19:46:51] <cradek> files or dirs, I mean
[19:47:13] <gene_> and the error is still there after a sudo chown -R gene:gene axis-tab
[19:47:28] <gene_> scratching head...
[19:47:35] <cradek> what's the error?
[19:50:18] <gene_> dunno, but I had to do a full su - to fix it. sudo wouldn't.
[19:50:44] <gene_> its rebuilding again
[19:50:55] <gene_> and look ok for a change
[19:52:42] <gene_> and back to this:
[19:52:45] <gene_> HAL: ERROR: pin 'iocontrol.0.spindle-on' not found
[19:52:45] <gene_> HAL:38: link failed
[19:52:45] <gene_> HAL config file /home/gene/emc2/configs/stepper//standard_pinout.hal failed.
[19:54:21] <cradek> spindle-on has been moved into the motion controller
[19:54:29] <cradek> change that to motion.spindle-on
[19:55:32] <gene_> in standard_pinout.hal?
[19:55:44] <cradek> yes
[19:57:20] <gene_> and the motors run by golly!
[19:57:26] <cradek> yay
[19:57:32] <gene_> THANKS
[19:57:58] <cradek> welcome!
[19:57:59] <gene_> Noiw to see if it will go thru the motions of Hello World...
[19:58:33] <gene_> Opops, loadfile is an error now.
[19:58:53] <gene_> Exception in Tkinter callback
[19:58:53] <gene_> Traceback (most recent call last):
[19:58:53] <gene_> File "/usr/lib/python2.3/lib-tk/Tkinter.py", line 1345, in __call__
[19:58:53] <gene_> return self.func(*args)
[19:58:53] <gene_> File "/home/gene/emc2.head/bin/axis", line 2051, in open_file
[19:58:54] <gene_> all_extensions = set([".ngc"])
[19:58:56] <gene_> NameError: global name 'set' is not defined
[19:59:25] <cradek> bizarre
[19:59:49] <gene_> I had that earlier with 2.0.1 too
[20:00:09] <cradek> I wonder if that's a python2.3 problem
[20:00:19] <gene_> this is a bdi install, maybe a ubuntu singularity?
[20:00:21] <cradek> I bet we're all using python2.4
[20:00:41] <cradek> might have to get jepler's help on that one
[20:01:05] <gene_> lemme see if I can do an apt-get update, this box is a little old now.
[20:02:29] <jepler> CVS versions of AXIS now require Python 2.4
[20:04:34] <gene_> apt-get update is stuck on an .ro site, damn. Timed out and retrying
[20:04:57] <robin_sz> meep?
[20:05:19] <gene_> if it ever completes, then apt-get upgrade python-* is next?
[20:06:04] <gene_> meep? Hi robin_sz
[20:06:29] <danex> Hello All
[20:06:30] <jepler> I don't know what it takes to get a newer verison of python on bdi
[20:06:48] <jepler> it may be available by apt-get as python2.4
[20:07:11] <gene_> oh oh, sounds like its ubuntu time
[20:07:34] <jepler> in emc2/src/Makefile you would also have to change 'python' to 'python2.4' around line 40
[20:08:04] <gene_> its still timing out and retrying that site at 5 minute intervals. Grrrr
[20:08:41] <cradek> I've been playing with Dapper the last few days and am fairly impressed
[20:09:13] <gene_> brb, gota get a whistle wetter, so was I the one time I used it to rescue an FC5 install on my lappy
[20:09:42] <cradek> it does make a nice rescue disk, I did that too lately
[20:10:20] <danex> Dapper installed fine on my test box
[20:11:45] <danex> cradek, have you worked with the Tkemc GUI much
[20:11:55] <robin_sz> so ... goes well?
[20:13:37] <robin_sz> I think part of the trouble may be that apt is in python, so its a bit self-referentail
[20:14:00] <gene_> it finally gave up, but an upgrade isn't doing any python packages
[20:15:10] <robin_sz> I think its about time I ordered a servo card ...
[20:15:42] <robin_sz> mined ewe, Ive said that enough times already
[20:17:14] <gene_> faint reference to the road to he!! ? chuckle
[20:20:29] <gene_> Question, whats bdi-4.30 use for a gui package manager, I know I used it last winter but alzheimer has set it..s
[20:25:04] <gene_> Looks like I'm going to have to copy the configs over to another machine and blow this bdi-4.30 away in favor of kubuntu 6.06 anyway, and I need to go feed me & the missus, so I'll be back sometime tomorrow.
[20:25:22] <gene_> bye all
[20:33:44] <robin_sz> sigh .. it still seems so *expensive* sigh ...
[20:34:43] <robin_sz> evewn the vitalysystems card is over $500 .
