Back
[00:01:15] <archivist> you can invert the signal as needed for direction and also invert input sense for close/open switches
[00:10:04] <gene> i just reran it again, and now have limit switch errors for all 4 axis's. And this time the travel limits did make it to the .ini file.
[00:11:37] <gene> and it won't reopen those files wtf?
[00:12:30] <gene> is 2.2.4 out yet?
[00:14:10] <kanzure> Does anybody have a useful ontology for metalshopping?
[00:17:08] <archivist> "ontology"? what do you mean
[00:17:54] <SWPadnos> gene, Y shouldn't move for a right/left jog
[00:18:08] <SWPadnos> it's always the motion of the tool relative to the work
[00:19:16] <SWPadnos> so for a bridgeport-style machine, where the spindle is fixed and the table moves left/right on a saddle that moves "toward/away from" the operator, +X means the table moves to the left and +Y means the saddle (carrying the table) moves toward the operator
[00:19:25] <SWPadnos> (and +Z means the quill/head moves up)
[00:19:35] <toastydeath> if dictionary.com is to believed for the definition of "ontology" in this context
[00:19:41] <toastydeath> then no, there is no such thing.
[00:20:07] <archivist> "Ontology is a study of conceptions of reality and the nature of being" wikipedia
[00:20:32] <SWPadnos> http://www-ksl.stanford.edu/kst/what-is-an-ontology.html
[00:20:39] <SWPadnos> "An ontology is a specification of a conceptualization"
[00:20:47] <SWPadnos> (whatever the hell that means)
[00:21:01] <archivist> kanzure, you looking for metal properties?
[00:22:00] <kanzure> archivist: No, I mean tools.
[00:22:10] <kanzure> An ontology is like a taxonomy.
[00:22:11] <gene> I'm in stepconf, trying to generte a new config that will work, and failing miserably Steve
[00:23:07] <SWPadnos> unfortunately, I can't help you much at the moment. I'm on a Windows machine right now, and I'm not sure which (if any) of my EMC machines have a working stepconf
[00:23:16] <gene> Since the normal jog keys on the keyboard don't work in stepconf, I have NDI which was the tables are supposed to move as all there is is a left right jog arrow.
[00:23:18] <SWPadnos> my laptop is sim only, and I'm not sure how stepconf works there
[00:23:19] <dmess> you ALWAYS drive the spindle.... dont look at thetable...
[00:23:36] <SWPadnos> stepconf only deals with one axis at a time
[00:23:48] <SWPadnos> + = tool moves right, forward, up
[00:24:00] <dmess> yes
[00:24:10] <SWPadnos> - = tool moves left / back (like taking a step backwards or toward you) / down
[00:24:19] <dmess> positive quadrant motion
[00:24:39] <gene> correct, right forward=to post or to me?
[00:24:43] <SWPadnos> in a right-hand coordinate system
[00:24:55] <SWPadnos> forward as if you were walking forward (toward post)
[00:25:00] <gene> so plus should move towardthe post?
[00:25:16] <dmess> some hardinge lathes ARE bas asswards
[00:25:22] <SWPadnos> tool moves in that direction, not the table
[00:26:19] <dmess> STOP looking at the table movement just where it ends up
[00:26:24] <gene> So the table moves toward me. Ok.
[00:26:30] <toastydeath> stop looking at the table movement
[00:26:36] <gene> and +=up too.
[00:26:43] <toastydeath> kanzure: there is no such thing
[00:26:47] <toastydeath> kanzure: what's your question
[00:27:07] <kanzure> toastydeath: Just reading up on Wikipedia at the moment, nothing specific. :)
[00:27:29] <gene> I've tried to reopn the files to fix them, but stepconf cannot see the goiles it just made to reopen them????
[00:27:31] <kanzure> There are always ways to approach certain subjects -- such as in QM, I use 't Hooft's ontology, and in mathematics, I use Rusin's.
[00:27:37] <kanzure> and in synbio, etc.
[00:27:37] <toastydeath> there are so, so many different tools and variation thereof it would be useless to have such a thing unless you already pretty much knew what you were looking for
[00:27:46] <kanzure> perhaps that's true
[00:27:50] <kanzure> maybe there's a better way
[00:27:58] <kanzure> I suppose the general ideas have abstractions, no?
[00:28:00] <toastydeath> also it's useless from a professional perspective
[00:28:13] <toastydeath> it would be like classifying wrenches.
[00:28:15] <SWPadnos> gene, what version are you running? (installed 2.2.3, or from CVS?)
[00:28:15] <kanzure> I guess the fundamental components would have to be the servos
[00:28:24] <kanzure> and then larger engines to power piston motors
[00:28:27] <gene> installed 2.2.3
[00:28:47] <archivist> toastydeath, heh I collect adustable wrenches
[00:28:57] <SWPadnos> ok. I know there were some changes since then, but I'm not aware of any that would affect the ability to re-load files
[00:28:59] <kanzure> 'adustable' - not able to be dusted? :)
[00:29:00] <toastydeath> that actually makes the point i was about to make
[00:29:01] <archivist> adjustable
[00:29:17] <gene> :)
[00:29:29] <dmess> the g codes and buttons drive the spindle of the machine tool.... if you worry about /ALL the kin's a DMG Evolution 5 axis siemens 840d^2 would hurt YOUR brain... it did mine..
[00:29:42] <toastydeath> the people who do metalworking professionally don't need such a document
[00:29:46] <SWPadnos> gene, do you get errors, or does the config just not load?
[00:29:53] <toastydeath> so one doesn't exist, not to the degree you're referring to.
[00:30:03] <kanzure> toastydeath: it's not a problem, I'm sorry I asked
[00:30:34] <SWPadnos> oh, are you looking for something that would tell you the components of a machine tool (more or less)?
[00:30:43] <SWPadnos> or at least common subsystems
[00:30:58] <kanzure> SWPadnos: that would be very nice :)
[00:31:13] <SWPadnos> I don't know of one, but I'm sure the information is available :)
[00:31:14] <gene> Joint errors. I'm in the middle of pass 3e8 approximately, and this time I've set the thing so there are no switches cuz there ain't. But thiswould be a hell of a lot easier if I could just re-open the file I just made and fix the one thing thats wrong...
[00:31:44] <dmess> its called the machinist handbook GUYS
[00:31:45] <archivist> gene you can (i do)
[00:31:50] <gene> specifically, joint on limit errors
[00:32:03] <SWPadnos> gene, that wasn't the question :) I'm wondering what stepconf does that tells you you can't reload a stepconf-generated config
[00:32:11] <gene> what, re-open a file?
[00:32:13] <kanzure> SWPadnos: For starters, it looks like everything is basically going to be an electric motor (either EM magnets, or piezos), or internal combustion, pneumatics, or other form of pressurized systems; and then the milling machines and lathes are just built around those concepts to manipulate metal more accurately.
[00:32:37] <SWPadnos> for the most part, yes
[00:33:17] <gene> Oh, that, there are no files displayed to click on once you've navigated to the directory they are in.
[00:33:30] <toastydeath> i would argue the core elements of machine tools are the ways and spindles.
[00:33:30] <SWPadnos> you have a work-holding part, a tool-holding part, some components that let you move the tool relative to the wrk, and a control system that decides what the tool/work relationship should be at any given time (probably driven from user input)
[00:33:54] <kanzure> toastydeath: ways? spindles?
[00:34:00] <toastydeath> and that power and control methodolgy are completely secondary.
[00:34:07] <SWPadnos> beyond that, it's all engineering, and there are a zillion ways of putting a machine together
[00:34:13] <kanzure> I would think that the power is more fundamental
[00:34:18] <kanzure> since the holding and positioning is mostly obvious
[00:34:22] <kanzure> as long as you can do precision ;)
[00:34:23] <toastydeath> it isn't. you can have a human powering a tool.
[00:34:37] <archivist> a file
[00:34:54] <SWPadnos> it's not so obvious when you get into high precision and/or large workpieces
[00:35:10] <toastydeath> the ways, providing precice linear motions, and spindles, providing precice rotary motion, are the key concepts of a machine tool.
[00:35:12] <dmess> not cost effective unless your in CHINA
[00:35:12] <SWPadnos> power is still fundamental - the human is the power source for a file
[00:35:24] <kanzure> toastydeath: My intuition says that a human couldn't grind down metal into the sort of precision required, since the amount of force expressed over a longer period of time than a machine would allow the metal to cool down and lose some of the applied energy and thus not be manipulated as would otherwise occur in high-power scenarios. But I hope I am wrong.
[00:35:33] <toastydeath> you are.
[00:35:38] <kanzure> great
[00:35:41] <toastydeath> if they used guides and spindles.
[00:35:46] <kanzure> links?
[00:35:52] <SWPadnos> toastydeath, there are also hexapods, and you could conceivably make a pumpkin-carving machine with one, which uses a knife as the cutting tool rather than a rotating mill
[00:36:09] <kanzure> Hm.
[00:36:11] <toastydeath> the hexapod legs are linear guides.
[00:36:13] <kanzure> I need a #engines
[00:36:14] <toastydeath> next?
[00:36:19] <archivist> I do hand turning of metal (graver)
[00:36:24] <dmess> i can do that on a toshiba mill
[00:36:38] <toastydeath> a shaper doesn't have any spindles.
[00:36:48] <SWPadnos> toastydeath, sure - conceptually though, those are implementations of mechanical motion systems (with many good properties)
[00:37:03] <archivist> I did hand engraving today
[00:37:04] <gene> Oh, that, there are no files displayed to click on once you've navigated to the directory they are in. And the open button does nothing of course.
[00:37:14] <SWPadnos> you could also use several wires, such as the skycam does
[00:37:31] <SWPadnos> gene, ok, on that I can't really help unfortunately :)
[00:37:50] <gene> is thisa known bug in stepconf?
[00:38:09] <SWPadnos> not known to me, but that's not saying much :)
[00:38:16] <dmess> i did some hand work on some cf18 l/g today too.... now i feel better
[00:38:39] <toastydeath> you're saying a machine tool will use wires.
[00:38:44] <gene> Also, it apparently only selects mode 0 for pwmgen, and it has 2 more modess, I need mode 1.
[00:38:46] <toastydeath> a machine tool, not an arbitrary motion system
[00:38:55] <archivist> wire eroder
[00:39:02] <toastydeath> a machine, for cutting material to a precice dimension.
[00:39:27] <dmess> GFL
[00:40:04] <toastydeath> you can swap power sources and it will still be the same thing
[00:40:10] <dmess> power control thru to cnc is a biatch
[00:40:18] <toastydeath> i can power a lathe spindle with a capstan and steam engine, or a direct mount DC servo
[00:40:31] <toastydeath> and it's still a lathe, with the same arrangement of linear guides and a spindle.
[00:40:43] <dmess> si
[00:40:55] <toastydeath> i can use a rack and pinion, or a screw, or a hydraulic pistion to provide motion
[00:41:07] <toastydeath> but as soon as you start changing the layout and relationship of the ways and spindles
[00:41:11] <toastydeath> the name you give the machine changes.
[00:41:31] <dmess> si
[00:41:48] <dmess> it transmorgifies
[00:43:17] <toastydeath> you can control it with human, tracer, cam, or computer, and it's still a lathe.
[00:44:24] <toastydeath> add a Y axis to the lathe spindle, and you have yourself a very primitive line boring mill.
[00:45:43] <SWPadnos> toastydeath, I agree that ways and spindles are better in most (probably all) machining implementations, but conceptually they represent "a motion system"
[00:46:00] <SWPadnos> just a motion system that's rigid and rugged enough for machining heavy stuff :)
[00:46:10] <toastydeath> a motion system is several abstractions above what we are talking about.
[00:46:15] <SWPadnos> you could use wire for something like a hot-wire foam cutter, which is still a machining system
[00:46:17] <toastydeath> we're talking about a very specific kind of motion system.
[00:46:25] <dmess> WFL....
[00:46:47] <dmess> out of Austria
[00:46:54] <toastydeath> and you are using the wires as linear guides.
[00:47:39] <toastydeath> my point is that trying to classify based on control or power is ridiculous because that does not change the type of machine you have.
[00:47:42] <dmess> si
[00:47:45] <SWPadnos> no, I can use wires to hold the two endpoints in some relationship, so the hot wore goes where I want
[00:47:58] <toastydeath> can you use one wire to provide circular motion?
[00:48:20] <toastydeath> no, so it's a linear guide.
[00:48:31] <archivist> yes if held at one end
[00:48:46] <toastydeath> my point is simple, dude
[00:48:50] <gene> I give up. no limits switches configured, all joints on limit at initial loading.
[00:48:57] <SWPadnos> I can use six wires to control the location and orientation of another wire strung between those two points
[00:49:02] <toastydeath> whether or not you use wires, magnets, or streams of plasma
[00:49:15] <SWPadnos> gene, that is an error that was recently corrected, I believe
[00:49:22] <toastydeath> the arrangment of axes gives you a hot wire cutter
[00:49:23] <SWPadnos> at least, there was something related to homing
[00:49:43] <SWPadnos> I'm looking at the code now, but I'm not terribly proficient in Python, nor am I particular familiar with that code
[00:49:52] <gene> no special homes set either, all defaulted to 0
[00:50:17] <toastydeath> swpadnos: you are still defining things in terms of X,Y/U,V
[00:50:22] <SWPadnos> are you sure you're getting stuff saved?
[00:50:31] <toastydeath> the relationship of the axes has not changed.
[00:50:36] <gene> I did have it working well, damnifIknow.
[00:50:49] <SWPadnos> toastydeath, you said you need ways and spindles. I'm pointing out that those, while quite useful, are not core concepts for machining
[00:50:57] <toastydeath> they ARE core concepts
[00:51:05] <SWPadnos> linear and rotary motion are core concepts
[00:51:19] <SWPadnos> ways and spindles are useful implementations of the core concepts
[00:51:26] <toastydeath> okay, whatever technicality you want to zing me on is fine
[00:51:29] <SWPadnos> heh
[00:51:30] <toastydeath> the point i am making to you
[00:51:32] <toastydeath> is that control
[00:51:34] <toastydeath> and power
[00:51:36] <toastydeath> are NOT the core concepts
[00:51:45] <toastydeath> which is what you originally proposed and I am refuting
[00:52:13] <archivist> nothing happens with 0 control or power
[00:52:22] <toastydeath> yes and that's true of everything in the universe
[00:52:24] <gene> Everything in that dir is about 5 minutes old.
[00:52:26] <SWPadnos> I think power is central to machining, since it takes energy to cleave or abrade material (or melt it, as the hot wire foam cutter would do)
[00:52:42] <toastydeath> nothing in the unverse moves without energy of some sort, and it moves according to the laws of said universe
[00:52:49] <SWPadnos> central vs core is debatable though
[00:52:52] <SWPadnos> sure
[00:53:09] <SWPadnos> application of power at certain points is the key, I guess
[00:53:26] <archivist> so power and control are core to something happening
[00:53:30] <tomp2> gene: maybe this is of use "Having trouble getting <0,0,0> where you want it for your gcode?"
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?CoordinateSystems
[00:53:36] <SWPadnos> it is obvbious that power is needed (as you say, it's needed for basically everything, why should machining be different :) )
[00:53:36] <toastydeath> right, and you need to define those points with linear and rotary motion constraints.
[00:53:52] <toastydeath> whether or not you use manual or CNC is irrelevant to "do i have a lathe?"
[00:54:21] <toastydeath> it IS relevant to "what kind of lathe do i have?"
[00:55:09] <gene> That doesn't appear to apply here, darnit.
[00:55:33] <toastydeath> and also whether or not the power is on and is anyone home is irrelevant to "do i have a lathe"
[00:55:47] <toastydeath> but it DOES apply when you ask "what kind?"
[00:55:55] <tomp2> gene: it does talk about 6 or so places that limit motion or determine position
[00:56:20] <SWPadnos> tomp2, I think the problem is way before that. he's trying to set up a spindle (and the rest of the machine) with stepconf
[00:56:20] <tomp2> gene: and i take it that you're in between limits that are too small to be useful
[00:56:30] <SWPadnos> oh, interesting point
[00:56:31] <tomp2> oh, nevermind
[00:56:49] <SWPadnos> no, you may have a point. if some things aren't getting saved, then limits could be fubar'ed
[00:57:11] <SWPadnos> but "joint XX is on limit" means the limit switch was tripped, not "soft limit exceeded"
[00:57:21] <tomp2> i hace engr's always setting limits inside out :) and cant move at all after homing
[00:57:30] <gene> X is set for -8.0 to 8.0=16 inches, more than the table can move
[00:57:53] <SWPadnos> lemme see if stepconf runs on sim :)
[00:59:00] <gene> Otherzs are set similary, and the indivudual axis section in the output .ini has HOME_IGNORE_LIMITS = YES in all 4 axis's. I'm bumfuzzled and need a beer I think, maybe 2 even...
[00:59:17] <SWPadnos> HOME_IGNORE_LIMITS only applies when homing
[00:59:34] <SWPadnos> does that error appear while homing? (I thought it was at startup)
[00:59:46] <gene> Ok, heres the whole x section:
[01:00:10] <gene> [AXIS_0]
[01:00:14] <gene> TYPE = LINEAR
[01:00:18] <gene> HOME = 0.0
[01:00:21] <SWPadnos> pastebin ...
[01:00:22] <gene> MAX_VELOCITY = 0.4
[01:00:26] <gene> MAX_ACCELERATION = 3.5
[01:00:30] <gene> STEPGEN_MAXACCEL = 3.675
[01:00:34] <gene> SCALE = -32000.0
[01:00:38] <gene> FERROR = 0.05
[01:00:42] <gene> MIN_FERROR = 0.01
[01:00:46] <gene> MIN_LIMIT = -8.0
[01:00:50] <gene> MAX_LIMIT = 8.0
[01:00:54] <gene> HOME_OFFSET = 0.000000
[01:00:55] <gene> HOME_SEARCH_VEL = 0.050000
[01:00:55] <gene> HOME_LATCH_VEL = -0.031250
[01:00:55] <gene> HOME_IGNORE_LIMITS = YES
[01:00:55] <gene> HOME_SEQUENCE = 1
[01:01:05] <gene> at startup when the f2 key is pressed to enable it
[01:01:17] <SWPadnos> can you pastebin the hal file?
[01:01:35] <gene> pastebin.ca?
[01:02:00] <gene> There are two, one is labeled custom, haven't lkooked at it.
[01:03:07] <SWPadnos> ok. one sec, I'm trying to see if I can replicate your problems here
[01:04:18] <gene> http://www.pastebin.ca/939080 for the .hal
[01:05:55] <gene> http://www.pastebin.ca/939081 for the empty custom.hal
[01:07:11] <SWPadnos> I note that the .stepconf file is stored in my home dir/emc2/configs, not in the actual config dir ir created
[01:07:22] <SWPadnos> s/ir/it/
[01:07:50] <SWPadnos> is that where you were trying to reload it from?
[01:08:10] <gene> I saw that, looked like a dup maybe? No, from the configname subdir
[01:08:21] <SWPadnos> ok, that's one problem solved :)
[01:08:50] <gene> How?
[01:09:57] <SWPadnos> you need to load my-mill.stepconf from ~/emc2/configs if you want to edit a previously saved config
[01:10:07] <SWPadnos> (or whatever the name was)
[01:10:33] <gene> ah, can I say duh about now?
[01:10:40] <SWPadnos> ok, go ahead :)
[01:10:47] <gene> DUH!
[01:10:56] <jmkasunich> I see oceans!
[01:11:00] <jmkasunich> http://www.nasa.gov/qtl/151335main_NASA_TV_QT.qtl
[01:11:22] <SWPadnos> you only need the custom.hal checkbox if you want to add hal setup to your config. this prevents the hal files from failing the md5sum stepconf uses to see if you fiddled with anything
[01:12:20] <SWPadnos> is that from ISS?
[01:12:26] <jmkasunich> shuttle
[01:12:29] <SWPadnos> oh, cool
[01:12:37] <gene> Now that is being entirely too picky...
[01:12:37] <SWPadnos> I didn't realize there was one aloft at the moment
[01:12:37] <jmkasunich> they're doing the wing damage inspection
[01:12:55] <jmkasunich> I suspect it will stop looking at oceans and start looking at shuttle soon
[01:13:14] <SWPadnos> I'm seeing the earth go by, in luxurious grayscale
[01:13:17] <SWPadnos> oooh, audio too
[01:13:20] <SWPadnos> copy that
[01:14:53] <SWPadnos> ouch. looks nasty from here
[01:14:59] <jmkasunich> ?
[01:15:43] <gene> Humm, when I reopen it, the parportconfig has been reset for all limit switches, not what I previously selected as un-connected.
[01:15:45] <SWPadnos> the video I'm looking at shows what look like holes or burn marks in the tiles
[01:16:07] <SWPadnos> or maybe it's just dark tiles among the light ones
[01:16:13] <jmkasunich> I think the latter
[01:17:05] <jmkasunich> they don't sound worried
[01:17:13] <SWPadnos> they never do :)
[01:19:51] <jmkasunich> sounds like they're homing
[01:21:51] <jmkasunich> cycle start ;-)
[01:25:26] <gene> Ok, got all axis's moving again in emc. I edited the hal file to make pwmgen_type=1, and I now have two run buttons. But its not trying to run the spindle.
[01:26:14] <gene> No action is making it to the pwm output, nor to the ccw pin, 14 on the parport, pwm is 16.
[01:28:55] <jmkasunich> halcmd is your friend
[01:30:15] <gene> A man page would be nice. OTOH, eveything but pwmgen is nicely covered in the hal pdf.
[01:31:06] <jmkasunich> man pwmgen
[01:31:14] <jmkasunich> man halcmd
[01:31:17] <jmkasunich> 2.2 has both
[01:31:21] <gene> Now, pwm isa .045 volts when the stop button is down, and goes to 3.3 volts when either direction button is clicked, and the ccw signal goes high only for the reversse button.
[01:32:31] <gene> The last time I looked at a .hal file, I couldn't find a pwmgen_enable in it.
[01:32:44] <gene> lemme see if its there now...
[01:35:17] <gene> yes, its there now. Lemme check to see if I have the blue pwm wire on pin 16, back in 10 or so I have to open it up.
[01:45:59] <gene> Yes, its on what Jeff purports to be pin 16 of the parport, let me see if I can ring it out. Yes, it rings out. And the port is no longer stuck low so I think its safe to assume the port is good.
[01:48:40] <gene> So we're back to its not being enabled, I'll paste this hal again, <
http://www.pastebin.ca/939131>, and the qquestion is, why won't pwmgen gen some pwm's?
[01:50:10] <SWPadnos> gene, can you run halscope and look at spindle-cmd?
[01:50:45] <gene> brb
[01:54:08] <SWPadnos> gene, one other thing: is your max spindle speed 8000 RPM?
[01:54:29] <gene> s/b 1200, as if its in low gear
[01:54:32] <SWPadnos> hmmm that makes no sense
[01:54:38] <SWPadnos> ok, 1200 is more like it :)
[01:55:01] <gene> and spindle_cmd is going up and down according to halscope
[01:55:30] <SWPadnos> ok, good
[01:55:41] <SWPadnos> can you see halscope or halcmd from where you are?
[01:55:51] <gene> range is theoretically set for 10 rpm tp 1200, duty min .05, duty max .95
[01:56:00] <SWPadnos> or do you need to go back and forth to do that?
[01:56:09] <SWPadnos> ok
[01:56:20] <gene> its on a separet screen but yes when I switch to that one
[01:56:43] <SWPadnos> ok - don't want to run you ragged looking at stuff :)
[01:57:13] <gene> 2 foot move max, I've drug the keyboard out to a more comfortable location :)
[01:57:59] <SWPadnos> ok. please open a halcmd session (halcmd -kf) if you don't already have one
[01:58:32] <gene> with emc running?
[01:58:42] <SWPadnos> oh, you've shut down EMC? that's OK
[01:58:52] <gene> no its runninmg
[01:59:07] <gene> fat fingers
[01:59:12] <SWPadnos> ah. yes, with EMC running. RT/HAL have to be loaded for halcmd to work anyway
[02:00:03] <SWPadnos> close halscope, and in the halcmd window, unload the scope sampling module (unloadrty scope_rt)
[02:00:05] <SWPadnos> -y
[02:00:08] <gene> ok, got a halcmd shell
[02:00:45] <SWPadnos> then re-run halscope (from the halcmd window, that would be loadusr halscope), but select the fast thread for the sampler
[02:01:35] <gene> thats what I was looking at before
[02:01:38] <SWPadnos> oh, ok :)
[02:02:00] <SWPadnos> is the spindle supposed to be running now?
[02:02:35] <SWPadnos> if so, in the halcmd window do "show pin pwmgen"
[02:02:42] <SWPadnos> and make sure the enable is TRUE
[02:02:57] <gene> s/b fwd, slowly, about half a dozen taps on the + button after enabling it
[02:03:48] <gene> halcmd: show pin pwmgen
[02:03:48] <gene> Component Pins:
[02:03:48] <gene> Owner Type Dir Value Name
[02:03:48] <gene> 8 bit OUT TRUE pwmgen.0.dir
[02:03:49] <gene> 8 bit IN TRUE pwmgen.0.enable <== spindle-enable
[02:03:49] <gene> 8 bit OUT TRUE pwmgen.0.pwm ==> spindle-pwm
[02:04:17] <gene> 8 float IN 701 pwmgen.0.value <== spindle-cmd
[02:04:26] <SWPadnos> ok, that's as expected
[02:04:46] <SWPadnos> except that spindle-cmd looks high for just a few taps on the button :)
[02:05:12] <SWPadnos> if you scope pwngen.0.pwm, what do you see?
[02:05:13] <gene> it goes up 100 per tap
[02:05:47] <SWPadnos> ok
[02:09:19] <gene> it appears to be stuck high, but not for the full width of the 'auto' triggered trace
[02:10:38] <SWPadnos> ok. try reducing the spindle speed to 100
[02:10:51] <SWPadnos> or go to MDI and do M3S10
[02:11:37] <SWPadnos> (that was a 10 by the way, I'd like to see something lower than 20, but 100 is as close as you can get with the buttons)
[02:12:29] <gene> Its still stuck, at what the scope says is 1 volt even
[02:12:54] <SWPadnos> no, it's a 1, as in 1 or 0 (halscope knows it's a bit)
[02:13:28] <SWPadnos> can you paste the result of "show param pwmgen"
[02:14:20] <gene> ok,
[02:14:27] <gene> halcmd: show param pwmgen
[02:14:31] <gene> Parameters:
[02:14:35] <gene> Owner Type Dir Value Name
[02:14:39] <gene> 8 float RO -1 pwmgen.0.curr-dc
[02:14:43] <gene> 8 bit RW FALSE pwmgen.0.dither-pwm
[02:14:47] <gene> 8 float RW 1 pwmgen.0.max-dc
[02:14:51] <gene> 8 float RW 0 pwmgen.0.min-dc
[02:14:55] <gene> 8 float RW -56.11111 pwmgen.0.offset
[02:14:59] <gene> 8 float RW 100.2335 pwmgen.0.pwm-freq
[02:15:03] <gene> 8 float RW 1322.222 pwmgen.0.scale
[02:15:07] <gene> 8 s32 RO 144 pwmgen.make-pulses.time
[02:15:07] <gene> 8 s32 RW 12194 pwmgen.make-pulses.tmax
[02:15:07] <gene> 8 s32 RO 1888 pwmgen.update.time
[02:15:07] <gene> 8 s32 RW 14263 pwmgen.update.tmax
[02:16:01] <jmkasunich> why is there an offset?
[02:16:30] <SWPadnos> that's how stepconf sets up the scaling
[02:16:46] <SWPadnos> that offset is in PWM units though, not scale units
[02:16:55] <gene> damnifIknow, sorry, i didn't put it in there, and I note that its now about 1/3rd of what it was the first time I looked 3 days ago.
[02:17:05] <SWPadnos> gene, change pwmgen.0.offset to -0.05
[02:17:18] <SWPadnos> (ie, 5%)
[02:17:23] <gene> how
[02:17:32] <SWPadnos> man halcmd ;)
[02:17:40] <jmkasunich> halcmd setp pwmgen.0.offset -0.05
[02:17:41] <SWPadnos> err, I mean setp pemgen.0.offset -0.05 :)
[02:17:47] <SWPadnos> right, pwmgen :)
[02:18:13] <jmkasunich> you'll eventually have to change it in the .hal file, but for now, setp lets you change it on the fly
[02:18:38] <gene> and the relays clicked on!
[02:19:29] <gene> And the haaalscope shows pulses now too, slow, as in 5% max, but they are there.
[02:19:50] <SWPadnos> those should change as you change the spindle speed
[02:21:09] <gene> MS1000 ran it up to about 85% I'd guess.
[02:21:37] <SWPadnos> sounds about right
[02:21:54] <gene> So mgo fix the hal file then
[02:21:58] <SWPadnos> 1000/1200 = 0.8333, +/- those 5-95% offsets
[02:22:18] <gene> So go fix the .hal file then, same value?
[02:23:02] <SWPadnos> actually, make the changes in the custom.hal file
[02:23:29] <SWPadnos> just put the line "setp pwmgen.0.offset -0.05" there, and you'll still be able to load the config with stepconf
[02:23:45] <SWPadnos> I think
[02:24:13] <Chris_sub_1_> Gene - Are you setting up a PMDX-106?
[02:25:17] <gene> Yes
[02:26:22] <gene> I just found out that hitting the ccw button, then the plus button actually stop it. Odd.
[02:26:37] <Chris_sub_1_> I went through that recently (but not using a par port). You may know this, but I think you need to set the pwm scale a little higher than your real maximum because if you set to 100% you get no pulses. Also, once you get the pwm sorted out you need to do the cal procedure for the board.
[02:27:18] <gene> I expect so, but for now I'm happy to see the relays clicking.
[02:27:49] <Chris_sub_1_> It's cool when things start working, isn't it? :)
[02:29:08] <gene> Yup. I just put that in the custom.hal file. Is loading that automatic?
[02:29:42] <SWPadnos> yes
[02:30:02] <SWPadnos> as long as you don't uncheck the "use custom HAL configuration" checkbox
[02:30:11] <gene> So I should be able to stop emc, reload it and it should still work?
[02:30:28] <gene> Oh shit, I think I did.
[02:30:29] <SWPadnos> though you won't be able to use stepgen again anyway because you had to change the pwm_type
[02:30:31] <SWPadnos> heh
[02:30:44] <SWPadnos> take a look at the ini file
[02:30:54] <gene> Yeah, its not quite ready for prime time :)
[02:31:14] <SWPadnos> if it's not there (right under the my-mill.hal line), just add HALFILE=custom.hal
[02:31:18] <gene> Yeah, I can spec that in there I believe
[02:31:51] <SWPadnos> sure, you can add HALCMD=setp ... in the ini file as well
[02:33:13] <gene> I just added the file, I assume its legal to spec more than one HALFILE?
[02:33:28] <SWPadnos> yes, that's how stepconf does it :)
[02:34:29] <gene> ok, I should be ready to hook the VSR up and give it a bit of excerise then, but not tonight, its getting seriosly cool in the shop.
[02:34:40] <SWPadnos> heh
[02:34:53] <gene> Many thanks guys, all of you!~
[02:35:28] <SWPadnos> you're welcome. enjoy
[02:36:21] <gene> I just tried the shut down and restart, it still works, but then you KNEW that :)
[02:37:07] <SWPadnos> well, there's no telling for sure when I'm not at the keyboard making the edits ;)
[02:54:52] <Chris_sub_1_> Last night's episode ended with the discovery that removing the tool change from the beginning of a file that broke my system (3D_Chips) allowed the rest of the program to run normally. It looks like I had mistakenly commented out the lines in m5i20_io.hal that loop back the tool loading pins. The resulting misbehavior in Axis was bizarre. Everything appears to be back to working now.
[02:56:59] <SWPadnos> that's mostly good news :)
[02:57:19] <Chris_sub_1_> :)
[03:39:42] <kanzure> Hm. I want to find a local 'metal' shop. Anybody here in Texas? heh'
[03:43:07] <toastydeath> i would really like to own an old 80's Matsuura VMC
[03:44:58] <toastydeath> although i suppose i should get my hands on something with a yasnac control before doing so
[03:45:01] <toastydeath> since i've never used yasnac
[03:45:44] <SWPadnos> Yasnac? rip it out and install EMC2, man!
[03:45:47] <SWPadnos> :)
[03:45:56] <SWPadnos> especially if it's '80s-era
[03:46:18] <toastydeath> i have interface gripes with emc
[03:46:32] <SWPadnos> are they valid or are you just being a pain? :)
[03:47:20] <toastydeath> i mean i sure feel they are valid
[03:47:26] <SWPadnos> heh
[03:47:36] <SWPadnos> UI or other interfaces? (like the G-code dialect)
[03:47:51] <toastydeath> nah, my only issue with the EMC g-code was the things not implemented yet
[03:47:59] <toastydeath> which i don't know if they have been implemented since i last peeked
[03:48:07] <toastydeath> i really like the o-code idea
[03:48:17] <toastydeath> and the running external programs from inside g-code
[03:48:25] <toastydeath> it's purely UI
[03:49:05] <toastydeath> if you want an elaboration i'd be glad to give one, i just don't know if you want to hear it =)
[03:49:11] <SWPadnos> like what? I'm curious because we have so many to choose from :)
[03:49:44] <SWPadnos> well, I'll consider it your opinion, not the law, so fire away (not that I'm likely to "fix" it, since I'm not much ofa UI guy with respect to EMC)
[03:51:10] <toastydeath> emc is non-modal from what i've seen of it (played around with it on my nix box)
[03:51:45] <toastydeath> on other controls (even conversational), you set the control into different modes of operation based on what you're doing.
[03:52:03] <toastydeath> it splits it up into mode, and display
[03:52:18] <toastydeath> modes are things like: run, edit, MDI, jog, rapid, zero return
[03:52:23] <SWPadnos> like manual vs. running G-code vs. editing setup... ?
[03:52:26] <toastydeath> graphics, auxillary
[03:52:31] <toastydeath> yes
[03:52:39] <SWPadnos> rapid is a separate mode?
[03:52:49] <SWPadnos> or is that a sub-mode of jog?
[03:52:50] <toastydeath> displays are things like positional information, program check screen, edit screen, tool table/work table
[03:52:55] <toastydeath> rapid is a seperate mode
[03:53:00] <SWPadnos> strange
[03:53:06] <toastydeath> some machines it isn't
[03:53:24] <toastydeath> there's sometimes a button for rapid, or there's some other provision for it
[03:53:41] <toastydeath> the handwheel is always it's own mode
[03:53:49] <SWPadnos> that's jog?
[03:54:03] <toastydeath> nah, jog/rapid are for the axis buttons on the control itself
[03:54:11] <toastydeath> handwheel/mpg is for the handwheel only.
[03:54:26] <toastydeath> (because you can always bump the handwheel accidentally when you don't want to)
[03:54:57] <SWPadnos> sure, though in EMC the handwheel can only do anything while in manual mode - it won't do anything in run mode unless it's connected to spindle or feed override
[03:55:11] <SWPadnos> (where it does the obvious thing)
[03:55:19] <toastydeath> right, which is kind of modal (i approve_
[03:55:19] <toastydeath> )
[03:55:35] <SWPadnos> in fact, you can't jog at all - keyboard or wheel - when it's in run mode
[03:55:54] <toastydeath> but the modes change the entire function of the machine and the display screens.
[03:56:07] <toastydeath> you will have like 8 modes, and 6 screens of information
[03:56:14] <toastydeath> which change slightly based on what you're trying to do.
[03:56:30] <toastydeath> it's a lot of idiot proofing, which i really like.
[03:56:32] <SWPadnos> I guess I see that as an implementation based on low display "resolution" of older machines, not a feature
[03:56:43] <toastydeath> nah, even new machines keep the screens
[03:56:49] <toastydeath> they just have MORE crap they put on the same 6
[03:56:51] <SWPadnos> but you should look at the mini interface. it has some more separation between tasks
[03:57:05] <toastydeath> perhaps!
[03:57:31] <SWPadnos> you use different "tabs" to select the right screen for whatever you're doing - MDI, looking at backplot, looking at the running program, etc.
[03:57:45] <SWPadnos> (though I don't recall the exact split there, I haven't looked at it in a long time)
[03:58:02] <toastydeath> but that's where i start to have beef
[03:58:09] <SWPadnos> heh
[03:58:15] <toastydeath> i feel the machine should do what it's doing regardless of what screen i am looking at, you know?
[03:58:27] <toastydeath> and i may be misinterpreting what you say.
[03:58:48] <SWPadnos> well, if you switch to the jog screen while a program is running, what is the correct thing to do?
[03:58:54] <SWPadnos> do you not allow it in the first place?
[03:58:56] <toastydeath> well there is no jog screen
[03:58:59] <SWPadnos> do you stop the running program?
[03:59:08] <SWPadnos> do you allow the switch, but disable jogging?
[03:59:09] <toastydeath> jog is a mode, so the machine stops
[03:59:14] <toastydeath> feed hold
[03:59:19] <SWPadnos> ok, mode, screen - close enough :)
[03:59:33] <toastydeath> i could jump between the "edit" screen, which is view only in run mode
[03:59:38] <toastydeath> and the positioning screen
[03:59:47] <toastydeath> which also includes graphics on new controls
[04:00:41] <toastydeath> shows you machine/work/operator/dist to go coordinate systems, all active modal codes, a brief snippet of what's coming up next in the program
[04:00:57] <toastydeath> all axis loads
[04:01:08] <toastydeath> the edit screen just lists the program, things like that.
[04:01:39] <SWPadnos> well, I could say something like "if you want that interface, feel free to write it", but I'll restrain myself
[04:01:51] <toastydeath> i kind of agree
[04:02:06] <toastydeath> which is why i'd stick to yasnac/fanuc/whatever comes with the machine, because it's already how i want it
[04:02:28] <toastydeath> agree re: "feel free to write it"
[04:02:37] <SWPadnos> I'm pretty suspicious that this organization of control functions is legacy, due to its origination on slow computers with small/text-only screens
[04:03:01] <toastydeath> do you program at the tool or via cam
[04:03:12] <SWPadnos> though there are more "operational" features on a Haas than there are in EMC
[04:03:34] <SWPadnos> ie, you can jog and use MDi, but there's no other conversational stuff (at the moment), or other simple-to-use canned cycles
[04:03:52] <SWPadnos> (in emc)
[04:03:54] <toastydeath> a lot of those features are there as a result of a control-freak philosophy
[04:04:00] <toastydeath> (in traditional cnc controls)
[04:04:06] <toastydeath> like, the very latest fanuc controls still have all that stuff
[04:04:43] <SWPadnos> I just remember seeing a video of maybe a TL-1 or something, and it had facing and turning to diameter "macros" that you could enter at screens with graphics for what each number means for the function
[04:04:44] <toastydeath> and fanuc changes enough crap revision to revision for me to believe that it's there for a reason, not just legacy
[04:04:59] <kanzure> Does cnczone moderate my posts? I just posted via quickreply and I don't see it. Kind of weird. Black hole of info?
[04:05:01] <toastydeath> swpadnos: yeah, that's an okay version of conversational
[04:05:18] <SWPadnos> but you're right, it did have a lot of sub-screens, and you'd put it into the "macro" mode or whatever they called it
[04:05:55] <toastydeath> also if you are interested in conversational, the bridgeport CNC stuff is a shining example of good conversational control
[04:06:09] <toastydeath> like, i would seriously use it if it were available on a bigger machine
[04:06:45] <SWPadnos> I haven't seen a modern Bridgeport CNC (later than the mid '80s-early '90s I think)
[04:06:56] <toastydeath> these are like, the Accu-rite controls and stuff
[04:07:02] <toastydeath> they're more conversions than true-blue cnc bridgeports
[04:07:13] <toastydeath> very recent stuff, 1990-2000
[04:07:50] <toastydeath> but my gripe with THOSE is that i can't jam g-code into the machine to make it do exactly what i want
[04:08:08] <SWPadnos> heh
[04:08:15] <toastydeath> there's no middle ground, it's either all conversational which imposes some limits to what you can do, or it's all g-code which takes forever
[04:08:50] <SWPadnos> other than the conversational stuff, I think mini was meant to be a simpler "one thing at a time" kind of interface. it's not exaxctly what you want, but it may be closer
[04:08:50] <toastydeath> whutevs, now i am just complaining =)
[04:08:54] <SWPadnos> heh
[04:14:52] <SkinnYPuppY> I could see a g70g71 lathe rough profiling finishing cycle being useful but I aint fussin
[04:16:18] <SWPadnos> ok, that's it. I'm not asking anyone what they don't like about EMC any more ;)
[04:16:25] <toastydeath> looool
[04:16:50] <SkinnYPuppY> I love EMC ;O) thank all you guys
[04:23:59] <SWPadnos> ok, time for me to actually try to get some work done
[04:24:01] <SWPadnos> or go to bed
[04:24:07] <SWPadnos> decisions, decisions
[04:59:17] <SWPadnos_> SWPadnos_ is now known as SWPadnos
[05:07:22] <JymmmEMC> SWPadnos:
[12:25:57] <alex_joni> is there a special word for "cutting depth" ?
[12:26:39] <archivist> also known as depth of cut
[12:27:05] <archivist> cant think of a single word
[12:27:09] <alex_joni> archivist: funny :P
[12:27:24] <alex_joni> ok, thx
[12:31:40] <archivist> one of those situations where one needs to be descriptive to make sure of meaning also see kurf
[13:50:49] <cradek_> cradek_ is now known as cradek
[14:08:49] <steves_logging> steves_logging is now known as steve_stallings
[14:09:34] <Guest931> Guest931 is now known as skunkworks_
[15:07:59] <steve_stallings> steve_stallings is now known as steves_logging
[15:12:59] <BigJohnT> steves_logging: are you in the lumber business or mud logging?
[15:16:29] <BigJohnT> or none of the above
[15:16:48] <SWPadnos> his IRC client is logging the discussion
[15:27:12] <BigJohnT> Ok thanks
[15:28:44] <alex_joni> heh
[15:35:03] <BigJohnT> bbl
[17:10:49] <fenn> BigJohnT: here's a 5-axis timing belt plasma table idea:
http://fennetic.net/sketches/hexegrity.png http://fennetic.net/sketches/hexegrity-belt-anchor.png
[17:11:11] <fenn> well, six axis actually
[17:12:17] <fenn> the orange boxes are fixed to a frame, probably an octahedron
[17:12:42] <fenn> they have winches in them that extend/retract the timing belts
[17:12:59] <BigJohnT> what are the spring thingies
[17:13:05] <fenn> springs
[17:13:28] <fenn> it applies force to the structure, in order to tension the belts
[17:13:42] <skunkworks_> would there be ringing issues?
[17:13:55] <fenn> you could have a single spring hanging from overhead (or rely on gravity) but then you'd need some kind of crane structure
[17:13:56] <BigJohnT> makes my brain hurt
[17:14:32] <fenn> skunkworks_: the ringing would be longitudinal (along the belts) not transverse like a guitar string
[17:14:53] <skunkworks_> ah
[17:14:54] <fenn> and belts have pretty good damping i think since they're composite rubber/kevlar
[17:15:10] <BigJohnT> bbl
[17:15:47] <fenn> i guess there would be some transverse motion due to sagging under gravity
[17:19:30] <fenn> i'm not sure about the springs. i'll have to build a model
[17:53:40] <micges> hi all
[17:56:39] <lerman> hello
[17:57:24] <lerman> I'm getting ready to start the implementation of user defined canned cycles.
[17:57:47] <lerman> Does anyone here have any thoughts about how to handle errors?
[17:59:11] <lerman> [More accurately, they should be "integrator define canned cycles"]
[17:59:31] <cradek> lerman: have you had any thoughts about MDI Oxxx call? I think that would be handy.
[18:00:04] <cradek> (and, I don't see how a subroutine is fundamentally different from a canned cycle)
[18:00:09] <lerman> Once upon a time, I tried to make that work, but the code didn't work. I'll try again.
[18:00:50] <lerman> A subroutine is invoked with "call". A canned cycle is invoked with Gxx.x Xxxxx Yxxxx, etc
[18:00:54] <cradek> I think that would be a way to put a menu in the gui that has common things.
[18:01:21] <cradek> ok, so they are fundamentally the same except for the invocation syntax
[18:01:55] <lerman> Yes, it would be. Yes, just the syntax is different. But think about the reason for the creation of the thread canned cycle.
[18:02:04] <cradek> I think of a canned cycle as the thing with a repeat number, can work on several planes, etc. It sounds like you are thinking of a superset of what I think of as canned cycles.
[18:02:11] <lerman> I would much prefer complex stuff like that to be in separate integrator defined files.
[18:02:49] <lerman> I'm thinking of a simple way to add new things invoked with Gxx.x.
[18:02:56] <cradek> I understand now
[18:03:32] <lerman> BTW: I have named Owords working. [Still needs major testing.]
[18:04:12] <lerman> As part of that, local Owords are also implemented.
[18:05:15] <lerman> cradek: You are correct. MDI invocation of Owords is probably more important. :-)
[18:05:17] <cradek> I saw jmk use indirect calls (O[#123] call). This is not possible with the names.
[18:05:47] <cradek> but the names are good for readability in programs that don't care about that
[18:05:50] <lerman> Correct. But you don't have to use names.
[18:06:23] <lerman> I'd love to have the ability to have parameters with textual values.
[18:06:31] <cradek> I have not answered your original question about errors. unfortunately I have no idea.
[18:06:49] <lerman> But that's a lot of work for an odd case that isn't used much.
[18:06:58] <cradek> many of the tests the interpreter does just can't be written in gcode because it doesn't have much introspection capability at all
[18:07:20] <lerman> Existing canned cycles just abort the program with an error.
[18:07:37] <cradek> sure, but you don't understand what I mean
[18:07:46] <lerman> I'd add some more introspection where needed.
[18:07:47] <cradek> for instance "Can't do that without the spindle turning"
[18:08:36] <lerman> Ah. Do existing cycles give that error?
[18:08:57] <lerman> (I think not)
[18:08:58] <cradek> I am pretty sure some do
[18:09:11] <cradek> _("Spindle not turning in g86"), // convert_cycle_g86
[18:09:17] <cradek> _("Spindle not turning clockwise in g84"), // convert_cycle_g84
[18:09:51] <lerman> How does the interp know if it is turning? Does zero speed count as turning?
[18:09:57] <cradek> different kinds of trouble:
[18:09:59] <cradek> _("X and y words missing for arc in xy plane"), // convert_arc
[18:10:05] <cradek> (plane dependence)
[18:10:44] <lerman> That's easy. The code can check the current plane. If that isn't visible, it should be added as another nmbered parameter.
[18:11:07] <cradek> I agree that one's easier
[18:11:10] <lerman> X and Y words would, of course, be visible.
[18:11:20] <cradek> (it's not currently available as a parameter)
[18:11:42] <lerman> Fortunately, adding that doesn't break any existing programs.
[18:12:33] <cradek> well that's debatable I think. I wish NGC had spelled out a "reserved" number space for the interp. I don't think it does - but I could be wrong.
[18:13:20] <nim1> hello
[18:13:30] <nim1> i have a question
[18:13:36] <lerman> I'd just add more parameter numbers. The existing space goes to 5400, I believe. (Or is that just the ones that are stored in the file).
[18:13:42] <nim1> it is simple
[18:13:50] <lerman> i have an answer. Let's see if they match.
[18:14:23] <nim1> i have a error code linear move 513 out of range
[18:14:31] <nim1> what is the deal?
[18:15:11] <cradek> on line 513 of your program is a move that would cause the machine to exceed its limits
[18:15:16] <lerman> The system checks to see if the X, Y, Z values are within the software defined limits of the machine.
[18:15:30] <nim1> ohhh
[18:15:31] <lerman> (I believe that's after coordinate transformation.)
[18:15:39] <nim1> lets see if that helps
[18:15:44] <nim1> one sec ...
[18:16:14] <cradek> lerman: you are right. The spec says they go to 5400. We could safely add whatever we want above that.
[18:17:51] <lerman> That's some good news. Let's reserve 9000 to 9999 for "us".
[18:18:53] <cradek> I just recalled that some words (L) are ints and some (X) are floats. Will this be trouble?
[18:19:12] <cradek> (a few, like P, are used both ways)
[18:19:28] <lerman> Nope. They're all stored as floats (doubles, actually).
[18:25:58] <cradek> that is incorrect: int l_number;
[18:26:29] <lerman> What are you saying?
[18:26:33] <cradek> also some of the ints don't have an ON_OFF flag; they use -1 as a special value for "off"
[18:26:51] <cradek> have a look at the "block" struct
[18:27:05] <jepler> I think lerman means that gcode "parameters" are always stored as C doubles
[18:27:08] <cradek> there's currently no way to read L1.5; it's an error
[18:27:28] <lerman> jepler: that's what I meant.
[18:27:44] <cradek> 13:18:52 < cradek> I just recalled that some words (L) are ints and some (X) are floats. Will this be trouble?
[18:27:57] <cradek> sorry, I thought we were talking about this
[18:28:01] <lerman> cradek: you are correct about the values of "words".
[18:28:33] <lerman> You are also correct about what you said. Don't be sorry -- I should be.
[18:28:45] <cradek> no problem at all
[18:29:00] <cradek> I sometimes left-turn a conversation and go off on a tangent by myself :-)
[18:29:33] <lerman> I'm trying to find the mdi stuff in the code so I can try to implement your suggestion
[18:29:36] <cradek> I'm just thinking (out loud) about the possible problems
[18:30:04] <cradek> I'll leave you alone then, it would be great if you could fix that
[18:30:18] <lerman> A good thing to do. Quite helpful. It will make things harder that some "words" are not doubles.
[18:31:05] <lerman> My previous attempt at mdi "calls" was to notice in execute that the current file was still active and run it until done.
[18:31:28] <lerman> I really should be looking at the current subroutine level.
[18:31:56] <lerman> Should this be part of a general "fix" to permit mdi to be used during pause.
[18:32:34] <lerman> pause/stop even estop on some machines.
[18:32:41] <cradek> I don't think that's broken so I'm not comfortable calling it a fix
[18:32:54] <jepler> I'm pessimistic enough to believe that's impossible
[18:33:01] <lerman> Sure call it a change, instead.
[18:33:18] <cradek> people generally want to jog during a pause (and now that I think of it, they want to change offsets, which involves MDI, so you are right)
[18:33:20] <lerman> Might be impossible without major changes.
[18:33:21] <jepler> (at least without large scale changes)
[18:33:51] <cradek> IMO fixing any problem that may or may not exist with run-from-line is the approach we should take instead
[18:34:24] <cradek> I think we could actually do that and have (pretty much) the functionality people want.
[18:35:24] <cradek> the functionality most people who are asking about this want (as far as I can tell) is the ability to manually touch off a tool after a tool change.
[18:36:03] <micges> cradek: I have those functionality (run from line and such) in my modified axis
[18:36:34] <micges> really want to talk about it someday
[18:36:46] <cradek> we all have run-from-line - can you say specifically what you have done that is different or is a fix?
[18:36:50] <archivist> I dont know my offset until an unknown number of trial cuts have been done (better measuring may fix but unlikely)
[18:37:50] <micges> my run-form line restart program in a state and position that it was stopped
[18:38:13] <SkinnYPuppY> As far as switching b/t program and mdi It would be helpful to alert upon entering mdi what the current offset is
[18:38:15] <lerman> If I had my druthers, you would be able to manually step thru a program by turning a dial. Forwards and *Backwards*.
[18:38:38] <lerman> That would require major "enhancement" to the interpreter.
[18:38:49] <cradek> and everything else
[18:39:11] <lerman> everything else == Axis (at least)
[18:39:34] <cradek> motion
[18:39:35] <cradek> task
[18:40:10] <cradek> and yes all the guis
[18:40:42] <micges> lerman: what is druthers ?
[18:41:33] <lerman> "I'd rather" when spoken rapidly is "I druther".
[18:42:08] <lerman> Probably qualifies as dialect.
[18:42:48] <cradek> to me it means "if I could have whatever I want, ..."
[18:43:10] <lerman> Yep. I'd rather have ...
[18:43:23] <cradek> lerman and I may or may not speak the same dialect :-)
[18:43:28] <micges> ok
[18:44:26] <micges> my dialect is little diffrent than yours :)
[18:45:18] <jepler> micges: if you have a change you want to propose for the "official" version of emc2, it is best to prepare it as a patch, which is a process described here:
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?CVS#Patch_Submission
[18:46:16] <micges> thanks
[18:46:28] <micges> I have about 30 :)
[18:46:35] <lerman> jepler: Is stuff that has been added to trunk automatically included?
[18:47:09] <micges> bbl
[18:48:25] <jepler> lerman: TRUNK will eventually be the basis for emc 2.3. To make bugfix changes for the emc 2.2.x series, you have to check out the v2_2_branch and commit the bugfix there as well as on the TRUNK
[18:49:10] <lerman> I think it reasonable to wait for the 2.3 release for my fixes.
[18:50:35] <jepler> ok, I accept your judgement on that
[18:51:00] <jepler> you're talking specifically about the bugfixes for SF#1709015 and 1807740 that you recently made in TRUNK?
[18:51:25] <lerman> I assume that those numbers are correct. YES.
[18:52:57] <lerman> Just checked the bug numbers. YES.
[18:53:31] <SkinnYPuppY> How do other controllers handle the current coord system when going from program to mdi? Say you're in offset 59 when you paused or ended your program, am I wrong to guessingly expect mdi to be in g59 already instead of g54 or whatever g5x mdi was last in?
[18:54:12] <cradek> in emc, m2/m30 reset you into g54 according to the ngc spec
[18:54:29] <cradek> but I don't know the answer for other controls, which is what you actually asked...
[18:54:45] <jepler> SkinnYPuppY: if readahead did *not* reach m2/m30, though, you could be in another coordinate system that was in effect earlier in the program
[18:55:03] <cradek> bleh
[18:56:17] <SkinnYPuppY> Both were relevant thanks, it only took me one nicked up pocket to figure that.
[19:05:10] <jepler> If I used other fixture offsets than G54, I think I would try to train myself to MDI the desired offset when switching to MDI -- because I know there are a few less-than-desirable behaviors in emc with regard to fixture offsets and program aborts
[19:11:03] <SWPadnos> lerman, I think a primary problem with O-words in MDI is that MDI has only a single-line context
[19:11:09] <SWPadnos> where would a subroutine come from?
[19:11:25] <SWPadnos> implemenenting a subroutine library is step 1, I think
[19:11:26] <lerman> From the previous context.
[19:11:44] <lerman> Also, the current code will look for files containing the called sub.
[19:11:48] <SWPadnos> from the loaded program?
[19:11:50] <SWPadnos> ok
[19:12:23] <lerman> Does explicitly MDI destroy the existing context?
[19:12:51] <SWPadnos> there's an interp_reset call in the mode switch, I believe
[19:13:13] <SWPadnos> but more importantly, the program itself isn't really available in MDI mode
[19:13:16] <lerman> Is that inside the gui (Axis)?
[19:13:17] <SWPadnos> afaik
[19:13:39] <SWPadnos> no, MDI is a separate command to the interp, distinct from "run_file" (or whatever it's called)
[19:13:52] <SWPadnos> running a program is not simply sending a sequence of lines from a file
[19:14:05] <SWPadnos> (like automatic issuance of MDI commands)
[19:14:56] <alex_joni> lerman: I ws wondering if your approach to implement new Gxx.x by the interpreter can't be used to overload existing g-codes aswell
[19:15:12] <alex_joni> s/interpreter/integrator/
[19:15:51] <alex_joni> say the integrator wants to do some funky toolchange.. then he would have to overload M6
[19:16:00] <lerman> It could be. But the basics should be untouchable G0 G1 G2 G3 G4 plus some others.
[19:16:12] <SWPadnos> hmmm. preconditions and postconditions are mostly in arrays right now. Those can pretty easily be put into external files
[19:16:22] <lerman> I was looking at Gcodes, but Mcodes could also be done.
[19:16:38] <SWPadnos> the actual motion primitives are a pretty small set
[19:16:59] <cradek> why untouchable?
[19:17:35] <cradek> say I want G0 to go up then over, or over then down, instead of in a straight line. I'd also like M2 to pull the quill up.
[19:17:46] <alex_joni> so people can't redefine G0 as G3 and G3 as G2 to cause havoc :p
[19:17:47] <SWPadnos> you need to have linear and arc primitives, with or without spindle sync, and with traverse or feed rate (arc + traverse is probably unnecessary, but not harmful)
[19:17:50] <cradek> I want G2, G3 to have absolute arc centers in G90 mode, instead of relative
[19:18:17] <alex_joni> cradek: I'm kidding, I also think general overload should be possible..
[19:18:21] <lerman> Because I can't think of a decent way to implement G1 without using G1. Of course, I could make it so that when these were overridden, the originals would still be accessible to the implementations of the new ones.
[19:18:24] <cradek> G4 should take centiseconds for the pause time
[19:18:43] <cradek> (I'm actually mostly serious)
[19:19:19] <cradek> I'm not sure I think this type of configurability is an important goal, but if it is, I can't see any reason to allow only half of it
[19:19:29] <SWPadnos> G2 would be implemented with the "coordinated linear feed move" primitive. it doesn't have to eb called G1 in a macro language
[19:19:38] <SWPadnos> uh, G1 that is
[19:19:39] <alex_joni> lerman: it's probably interesting to see what happens with recursive defines
[19:19:40] <SWPadnos> :)
[19:19:40] <lerman> Overloading G0-G3 would let me add small coordinate correction after probing the work piece.
[19:20:05] <alex_joni> G1 XxYyZz calling G1Zz, then G1Xx then G1Yy
[19:20:16] <SWPadnos> the idea would be to define all moves in this sub-G-code, including the primitives like G0-G3
[19:20:16] <cradek> alex_joni: nope
[19:20:30] <alex_joni> SWPadnos: sounds like canon calls
[19:20:33] <SWPadnos> yes
[19:20:34] <cradek> alex_joni: you have to be able to tell if the new Z is higher or lower than the old Z
[19:20:39] <SWPadnos> but in an external file rather than compiled in
[19:20:43] <cradek> you need full introspection
[19:20:48] <cradek> it's a very big problem
[19:21:00] <alex_joni> cradek: doesn't matter.. my point was what G1 do you call the second time
[19:21:06] <lerman> Introspection is big, but not complex.
[19:21:16] <lerman> One "variable" at a time.
[19:21:18] <cradek> alex_joni: ok, I understand
[19:21:23] <alex_joni> G1() {G1(x); G1(y); G1(z);}
[19:21:24] <SWPadnos> as I said, the preconditions and postconditions are already in arrays for the most part, so a lot of the "can I do this in this state" should be relatively easy to "externalize"
[19:22:11] <alex_joni> I think the solution to this is having a different language with CANON stuff in it
[19:22:20] <SWPadnos> G1() {std::G1(x); std::G1(y); std::G1(z); }; :)
[19:22:55] <cradek> alex_joni: I halfway agree. But canon is a little too basic. It doesn't know coordinate systems or cutter comp for instance
[19:22:59] <SWPadnos> yes, that's what I was saying with the primitive thing. there will be something that is the equivalent of G1 now (and G1 would be exactly that primitive by default)
[19:23:12] <lerman> CANON is too difficult (it gives me a headache) compared to G1-G4. SWPadnos has the right idea.
[19:23:14] <alex_joni> cradek: oh, right.. then maybe g-code with some extentions
[19:23:23] <SWPadnos> some folks (like petev) would like cutter comp in CANON
[19:23:30] <alex_joni> __G1() ?
[19:23:34] <cradek> G1'X1Y2
[19:23:34] <SWPadnos> heh
[19:23:47] <alex_joni> to make it C style, not C++ :P
[19:23:49] <lerman> Just give the original functions a new name. G1->G1001, G2->G1002, etc.
[19:23:49] <SWPadnos> __do_G1_motion() ;)
[19:23:52] <SWPadnos> like the kernel
[19:24:10] <SWPadnos> G-1 G-2 G-3
[19:24:18] <cradek> SWPadnos: I might agree with him, I dunno
[19:24:19] <alex_joni> heh
[19:24:24] <lerman> SWPadnos: that works.
[19:24:49] <jepler> G-0 might be a problem, though
[19:24:52] <alex_joni> cutter comp should be way deeper in emc
[19:24:58] <alex_joni> although how deep, I have no idea
[19:25:02] <SWPadnos> yeah, I think it shouldn't be there, because languages on top of it may treat comp differently (like STEP or APT maybe)
[19:25:04] <SWPadnos> heh
[19:25:06] <alex_joni> (so it works with nontrivkins machines)
[19:25:23] <alex_joni> like cutting comp in UVW space, after inverse kins
[19:25:39] <alex_joni> (or whateverdirection kins, as I am not able to remember which one goes what way)
[19:25:44] <lerman> I don't think you can get there from here.
[19:25:55] <cradek> alex_joni:
http://www.isd.mel.nist.gov/personnel/kramer/pubs/RS274NGC_3.web/RS274NGC_34a.html#1000607
[19:25:59] <lerman> (At least not in small steps.)
[19:26:03] <alex_joni> lerman: as usual we drift away into OT
[19:26:14] <cradek> swerve, not drift
[19:26:21] <cradek> veer? thunder?
[19:26:26] <lerman> And I was about to bring up the squid's eye.
[19:26:32] <SWPadnos> hairpin turn, I think
[19:26:55] <lerman> Or the appendix.
[19:27:30] <alex_joni> back to topic :)
[19:27:46] <alex_joni> something involving overloading g-codes with o-word procedures
[19:28:24] <SWPadnos> just don't use G-codes as the macro language
[19:28:50] <lerman> Then no one will be able to read the macro language.
[19:28:55] <SWPadnos> SF = straight feed. ST = straight traverse ...
[19:29:04] <alex_joni> lerman: do you think (in the long run) it's feasible for an integrator to create a M6.ngc file, place it in some location where regular operators/users don't have access
[19:29:32] <alex_joni> and from then on, when the interp reads files with M6 expands the M6 call with the proper procedure/parameters call?
[19:29:48] <lerman> Sure. Although I was thinking of Gxxx.ngc files; not Mxxx files.
[19:29:54] <alex_joni> both
[19:30:04] <lerman> Sure.
[19:30:15] <alex_joni> M1xx are already somehow done
[19:30:24] <alex_joni> although they don't get interpreted, just run
[19:30:31] <alex_joni> executed I mean
[19:30:39] <lerman> Mx don't have arguments, though. Or do they?
[19:30:47] <alex_joni> they do, but only 2
[19:30:49] <alex_joni> P and Q
[19:31:17] <lerman> Is that general, or is that emc?
[19:31:26] <alex_joni> emc
[19:31:27] <cradek> probably emc
[19:31:34] <alex_joni> not sure about any other controls..
[19:31:36] <cradek> I think there is no 'general'
[19:31:47] <alex_joni> right, that's machine specific
[19:32:05] <lerman> Some of the hard things with M codes are which get done in what order and which can be on the same line.
[19:32:25] <alex_joni> I don't think we should allow changing that
[19:32:41] <alex_joni> and M-codes have also modal groups, and precedences, just like g-codes
[19:32:49] <cradek> yes I agree the order is already defined
[19:32:54] <SWPadnos> those modal group numbers are also an array of ints, I believe
[19:33:04] <alex_joni> SWPadnos: yes, they are
[19:33:07] <lerman> Also with G codes. I was looking at doing just motion control stuff for the G codes. All would be in the same group then.
[19:33:13] <SWPadnos> ie, easy to read from a file instead of compiling them in
[19:33:18] <lerman> And only one on a line.
[19:33:23] <cradek> if you make M3 pause and G4 turn on the spindle though, you'll be able to screw it up
[19:33:32] <alex_joni> const int Interp::_gees[] = {
[19:33:36] <alex_joni> for g-codes
[19:33:47] <alex_joni> const int Interp::_ems[] = {
[19:33:50] <SWPadnos> if you change (or define) the meaning of a code, you also have to be able to define its group
[19:33:51] <alex_joni> for m-codes
[19:34:04] <alex_joni> SWPadnos: I don't think so
[19:34:17] <alex_joni> at least I don't see how you could do that..
[19:34:22] <alex_joni> or why
[19:34:46] <SWPadnos> if I make a few M codes to do funky things with my spindle, I need to be able to define those as being mutually exclusive
[19:34:47] <lerman> Nope. No changing of groups. And probably only minor tweaks in meaning. It makes sense to add canned cycles. It doesn't make sense to change the meaning of G1.
[19:35:58] <alex_joni> SWPadnos: lets get simple things going, then we'll see/worry about more extensive changes
[19:36:01] <lerman> Any integrator who uses this stuff is going to have to be able to document it. The modal groups is already complex enough.
[19:36:13] <jepler> it might make sense by starting with the question: what do people wish to change about emc's gcode?
[19:36:32] <alex_joni> jepler: one example: rack-tool changer
[19:36:32] <jepler> Some possible reasons for modifying the behavior of G0 and G1 have been proposed
[19:36:44] <alex_joni> that's another one..
[19:36:46] <SWPadnos> alex_joni, I understand the idea of baby steps, but I think it's actually harder to implement something that only allows you to change certain things than it is to make something that's universally reconfigurable
[19:36:48] <lerman> Well, a recent change was to add a lathe threading cycle.
[19:37:22] <alex_joni> SWPadnos: I think overloading can be quite "simple" to implemente
[19:37:39] <alex_joni> imagine it as a verbatim "include" or as a #define
[19:37:43] <jepler> (diameter mode on lathes is another reason to modify motion codes)
[19:37:55] <cradek> very true
[19:38:24] <SWPadnos> since you need to be able to do some reconfiguration of some codes, that means the functionality to interpret "macros" as G-codes needs to be there. If that's the case, then limiting the interpreter to only loading some codes from external definition files is more work than just loading everything from external files
[19:38:34] <alex_joni> well crap.. gotta run for ~45 minutes.. will read when I'm back
[19:38:43] <lerman> OK. So we now agree that we should be able to overload G1... AND still invoke the old version.
[19:38:49] <SWPadnos> no
[19:39:02] <alex_joni> SWPadnos: sure we do
[19:39:07] <cradek> heh
[19:39:09] <alex_joni> not by writing G1 though
[19:39:12] <SWPadnos> we agree that the integrator needs to be able to overload G1, and that there needs to be a primitive that has the same functionality as G1 currently has :)
[19:39:24] <alex_joni> yeah, that.. maybe G-1
[19:39:24] <SWPadnos> how we spell it is up to us :)
[19:39:26] <lerman> SWPadnos: OK.
[19:39:34] <SWPadnos> GEE-ONE
[19:39:37] <alex_joni> bbl.. sadly
[19:39:45] <SWPadnos> see you
[19:40:06] <jepler> another thing that keeps going through my head is this: the integrator *already* has a way to add unlimited new instructions to gcode, and to modify the existing ones in any way he desires. It's called the C++ source code.
[19:40:49] <cradek> (fwiw I agree with jepler)
[19:40:54] <SWPadnos> that's not really appropriate for machine tool makeers
[19:41:07] <jepler> (I cry big, big alligator tears for the self-styled "integrator" who is selling a product and doesn't know how to program it or employ someone who can)
[19:41:08] <SWPadnos> also, distribution is a nightmare
[19:41:14] <cradek> SWPadnos: it certainly is, for FOSS software
[19:41:20] <lerman> Which the integrator must then maintain. Check out the latest head and merge his changes into it.
[19:41:27] <SWPadnos> "programming" a machine tool is not the same as changing the program
[19:41:42] <SWPadnos> and make distributable packages for his customers
[19:41:57] <SWPadnos> I agree it's not "our responsibility" to make it easy to change though
[19:42:59] <SWPadnos> it can also be desirable to have different personalities for the interp - to execute legacy G-code that was posted for another control
[19:43:34] <SWPadnos> (all we have to do is wait for cradek to make a big library of BOSS code, then have his control fail :) )
[19:44:00] <cradek> G81 X0. Y0. Z1. Z2. Z3. Z4. Z5.
[19:44:15] <cradek> it's totally incompatible and none of these proposals would change that
[19:44:31] <jepler> SWPadnos: an integrator had better be prepared to package and distribute his own bugfix release
[19:44:48] <SWPadnos> does it actually allow something like that? (is that a series of depths to peck?)
[19:44:53] <cradek> yes
[19:44:57] <cradek> F1. F2. F3.
[19:45:06] <cradek> (different feeds for the various parts of the cycle)
[19:45:12] <jepler> "oh, your machine is unusable due to that control I'm selling you support on? sorry, you'll have to wait for a fat, bearded, unpaid, smelly man I don't even *know* to fix it and package it up, *then* you can have your bugfix"
[19:45:25] <SWPadnos> heh
[19:45:29] <cradek> I resent the "smelly" part
[19:45:34] <SWPadnos> and I'm not fat
[19:45:57] <jepler> or bearded, as far as I can recall
[19:46:03] <SWPadnos> oh, true enough
[19:47:26] <lerman> I'm looking at the source of the threading cycle.
[19:47:36] <dave_1> Questions, always questions ....
[19:47:58] <cradek> lerman: I know it offends you that I wrote that in C, but I think it would be even more horrific if I had written it in gcode...
[19:48:05] <lerman> WE have answers. Let's see if we can find one to match your question.
[19:48:12] <cradek> ha
[19:48:24] <cradek> no! yes! rtfm!
[19:48:25] <lerman> Nope, not offended. Offended that we have to do it in C.
[19:48:30] <dave_1> how much would it take to change emc so it works with the synergy so the tool dia is the deviation from norm
[19:48:37] <lerman> Not that you did it in C.
[19:49:07] <dave_1> i.e. synergy uses g41/g42 and an offset tool path
[19:49:14] <cradek> dave_1: emc supports tool comp used as deviation from nominal, but it has the same problems tool comp in emc always has (namely failing at concave corners)
[19:49:35] <cradek> dave_1: I think this usage is even described in the manual. it's explicitly supported.
[19:49:36] <lerman> That's a feature; not a problem.
[19:49:53] <jepler> it's part of the specification; that doesn't mean our users find it desirable
[19:50:02] <cradek> lerman: there's not consensus about whether or not it's a feature :-)
[19:50:30] <cradek> dave_1: when you try to run synergy code with nonzero tool diameter what happens?
[19:50:36] <lerman> What do we need to add to the ini file? ENABLE_GOUGE_MODE = YES
[19:50:51] <dave_1> OK , I set my tool dia to 0.0 and use synergy all the time. How do I fake it to cut a bit smaller or larger
[19:51:02] <cradek> lerman: the comp algorithm would need to be rewritten in order to support concave corners
[19:51:08] <dave_1> I think I get the 'gouge \'errro
[19:51:34] <cradek> dave_1: it could be that synergy does not put arcs on corners, or that it makes invalid entry or exit moves
[19:51:49] <lerman> Apparently the people with the skills to "fix" it don't believe that it is enough of a problem to fix it.
[19:52:08] <dave_1> so far I've been unable to set a 0 tool dia in the program itself and get that to work.
[19:52:18] <dave_1> it is a niche problem
[19:52:51] <dave_1> and synergy works just fine if one gets acceptable results with standard dia tools
[19:52:53] <cradek> (lerman: it's hard)
[19:53:25] <dave_1> I'm also looking at APT as a way around this but the learning curve is steep
[19:54:11] <cradek> dave_1: since synergy is commercial, it seems to me that you should complain to your vendor if you can't use its output on your chosen control. this is expecially true if synergy claims to work with emc.
[19:54:20] <cradek> especially
[19:54:45] <dave_1> BTW .. anyone have an email address for Dennis Messier (sp)
[19:55:29] <dave_1> I've talked to Weber ... and they don't think much of cutter comp in emc.
[19:55:29] <jepler> cradek: it's not clear to me how you would write gcode that you can use in this way with emc, except by adding undesirable radiuses as big as the maximum expected tool diameter deviation at all corners.
[19:55:42] <cradek> jepler: I agree
[19:56:03] <cradek> dave_1: in their place I'm sure I'd also say that :-)
[19:56:46] <dave_1> If I can manage to use a zero tool dia in synergy then it does thing like emc expects and I can use adjustable tool dia in emc like everyone else
[19:57:00] <cradek> jepler: you could generate the gcode with undersized nominal, and always use a positive comp value.
[19:57:14] <dave_1> their method seems to work on commercial controls
[19:57:46] <cradek> jepler: ... since the corner swap doesn't happen unless you use negative tool diameter
[19:57:53] <dave_1> I'm still back on 2.0.0 on the test machine but I think I tried plus and minus 0.010 and they both failed
[19:58:45] <cradek> dave_1: sorry I don't think there's a good answer except to re-export when you change tool size, and tell emc the tool is 0 diameter
[19:59:07] <dave_1> I've have thought about declaring a undersize tool but that is a real pain.
[20:00:52] <dave_1> guess there is more work to be done.... in faking the controller
[20:00:55] <dave_1> or me
[20:00:58] <SkinnYPuppY> I haven't used synergy but have gotten a corner error when trying to g2g3 in a corner the same radius as my tool. You may want to look at the generated gcode of a simple box pocket to see if the Ior J value in the corner = the tool radius and therefore the path offset
[20:01:28] <dave_1> synergy does a nice job of cutting with an oversize tool ..
[20:02:00] <dave_1> then one can come back with a tool all the way down to essentially the radius and clean out the corner.
[20:02:25] <dave_1> so roughing is easy
[20:03:55] <dave_1> there are also ways to set min inside rad and outside radii
[20:04:13] <cradek> oh?
[20:04:35] <cradek> did you try setting those to .011 if you want to use +010 or -010 tool sizes
[20:04:58] <dave_1> no I didn't try that... hmmmm
[20:05:06] <cradek> yeah, hmmmm
[20:05:14] <cradek> you never know, it just might work
[20:05:15] <dave_1> maybe even duh
[20:05:30] <cradek> haha
[20:05:32] <dave_1> well it is all about lying to the system
[20:05:36] <cradek> yes
[20:05:41] <cradek> you just have to get your lies straight
[20:05:51] <dave_1> "computers are not intelligent they only think they are"
[20:05:55] <SkinnYPuppY> This is the Synergy you are using yes?
http://www.webersys.com/
[20:06:02] <dave_1> yes
[20:06:27] <SkinnYPuppY> If you don't mind what did the package cost you ?
[20:06:53] <dave_1> The cost vary .. depending what you buy/can afford.
[20:07:02] <dave_1> the CAD is free
[20:07:15] <dave_1> 2.5D cam is $250
[20:07:33] <cradek> does it do a good job with basic pocketing?
[20:07:55] <dave_1> there is an intermediate price for wireframe and then solids cost $1250
[20:08:04] <SkinnYPuppY> Thats not bad sounding, does the 30 day trial not output gcode?
[20:08:09] <cradek> I assume that's what 2.5D cam means - basic pocketing?
[20:08:36] <dave_1> nice job on pocketing. options for trichordal, back and forth, etc.
[20:08:46] <cradek> interesting
[20:09:16] <dave_1> the 30 day trial does everything including solids ... and yes it outputs gcode in trial mode
[20:09:59] <dave_1> pocketing, profiling, holes, tapered holes
[20:09:59] <SkinnYPuppY> That makes if worth trying out then.
[20:10:27] <cradek> maybe I should look at it again. I tried once but was horrified by the user interface (but to be fair, I only spent a few minutes trying to figure it out)
[20:10:37] <dave_1> My guess is that 90-95 % of the people on this list could do with just the 2.5D
[20:11:07] <cradek> oh for Free pocketing code...
[20:11:31] <dave_1> The real problem is that the program is so rich in features that it take a while for people to learn ... even the very bright ones
[20:11:57] <SkinnYPuppY> Thats about how I feel with MasterCamX
[20:12:05] <dave_1> Bob did comment that he had one guy with lots of 3D experience doing good stuff at the end of the 30 days
[20:12:40] <dave_1> well it is only free for 30 days
[20:12:58] <dave_1> but I know of nothing that competes with it for $250
[20:14:19] <dave_1> you can draw for free but after the 30 days the 2.5D cam costs $250
[20:15:41] <dave_1> If I didn't have synergy I'd be writing a bunch of functions to do pocketing, holes, profiling, etc. but then you still need a drawing program
[20:16:11] <cradek> we have qcad...
[20:16:34] <dave_1> to pick intercepts or do it like APT does and compute intercepts for various geometric objects
[20:17:03] <dave_1> and qcad gives you the same capability as synergy?
[20:18:47] <cradek> I don't use either one, so I'm not an expert, but qcad is simply 2D cad
[20:19:05] <cradek> quit
[20:19:07] <cradek> oops
[20:19:15] <dave_1> from which you do your own gcode?
[20:19:31] <cradek> I was just responding to "but then you still need a drawing program"
[20:19:35] <SWPadnos> isn't that the one where you more or less define a series of operations, adn it spits out the Gcode
[20:19:45] <cradek> apt, yes
[20:19:52] <SWPadnos> err - qcad
[20:19:58] <cradek> you describe geometry, like CSG
[20:20:10] <SWPadnos> you make an outline and then make it a pocket of some depth
[20:20:11] <cradek> no, qcad doesn't know anything about gcode, it's 2d -> dxf
[20:20:27] <SWPadnos> ah, I'm thinking of GCam
[20:20:29] <SWPadnos> probably
[20:20:34] <cradek> yes I think so
[20:20:44] <cradek> (I have also not used gcam)
[20:20:54] <dave_1> one way to work in APT allows you to do pt to pt
[20:21:33] <dave_1> the other is one in which you describe objects in 2 or 3 D and let it do the math
[20:21:47] <dave_1> I'm not really there yet
[20:21:56] <SWPadnos> so, did I change something or can everyone scroll through their broswer history using shift+scrollwheel? (in Firefox)
[20:22:04] <cradek> I successfully made (one) apt program
[20:22:32] <dave_1> what did you declare at the machin ?
[20:22:38] <dave_1> as
[20:22:44] <cradek> emc I think
[20:23:00] <dave_1> hmmm
[20:23:14] <cradek> aha!
http://timeguy.com/cradek-files/emc/circles.apt
[20:23:24] <dave_1> I've tried the default from the book which is sheldon
[20:23:32] <cradek> ^^ this is my first and maybe last apt program
[20:23:38] <cradek> it actually worked
[20:23:45] <SWPadnos> what, you don't like fedrat?
[20:24:21] <dave_1> were you under vapt or straight apt-360
[20:24:46] <cradek> this is how I ran it as an AXIS input filter:
http://timeguy.com/cradek-files/emc/aptfilter
[20:25:00] <cradek> I think it was apt360
[20:25:11] <cradek> apparently the binary that got installed was just named "apt" if that helps
[20:25:16] <cradek> this has been a while ago
[20:25:44] <cradek> as you can see, it's poorly suited to being run as a filter
[20:26:00] <alex_joni> * alex_joni reads back
[20:26:04] <SkinnYPuppY> dave_1: are you using that on ubuntu?
[20:27:09] <dave_1> my synergy is on FC5 but apparetly the system of choice today is Ubuntu
[20:29:04] <cradek> I did this partly to see if it would generate arcs when cutting around a circle. some cam sucks so bad it can't get even that right. iirc apt did generate arcs.
[20:30:24] <SkinnYPuppY> It's deb package is wanting libqt3c102-mt and isn't satisfied by libqt3-mt, libqt3-mt-dev, and libqt3-headers I have installed
[20:30:26] <dave_1> iirc it did it in segmens
[20:30:43] <dave_1> segments
[20:31:00] <cradek> pretty sure I got arcs. the machine is not on or I'd try it...
[20:31:36] <dave_1> apt is legacy stuff and ran for years on 360's I should be well debugged except for glitches in the translation to c
[20:32:39] <dave_1> thanks for the conversation .. gotta go try to get something done.
[20:41:51] <SkinnYPuppY> Hmm if libqt3-mt has replaced libqt3c102-mt and libqt3c102-mt isn't available for ubuntu how to install?
[20:42:16] <SWPadnos> --force-depends or something like that
[20:42:28] <SWPadnos> or just --force maybe
[20:43:00] <SkinnYPuppY> Thanks SWP I'll check how to --force dep
[20:43:19] <cradek> all sorts of --force-things in man dpkg
[20:43:24] <cradek> (really that's what it's called)
[20:45:30] <SWPadnos> heh:
[20:45:32] <SWPadnos> "dpkg --force-help
[20:45:33] <SWPadnos> Give help about the --force-thing options."
[21:31:42] <SkinnYPuppY> sudo dpkg -i --force-all synergy-cad_16.0-8_i386.deb worked fine for synergy install on ubuntu if someone is searching log in future
[21:45:23] <alex_joni> http://ubuntuforums.org/archive/index.php/t-497025.html
[21:45:30] <alex_joni> quite a long list with linux CAD's
[21:51:30] <skunkworks> wow
[21:51:37] <skunkworks> alex_joni: nice find
[21:52:43] <archivist> theres a pythoncad in that lot
[21:53:27] <fenn> it's much worse than qcad
[21:53:40] <fenn> and the code isn't the simplest thing
[21:58:27] <fenn> cadvas is better (if you're looking for a 2d python cad)
[21:59:51] <archivist> I want an open source solidworks that talks to emc , not much really!!
[22:01:44] <skunkworks> I ordered a fluke network cable testing kit for work finally. The guy at work (we like to call him chicken little.) thought all of our network cables where all bad as we put the ends on them our selves.. (and wire tie and kink them here and there.). Well - we tested the worst of the worst - they all checked ok for 1gb networking.. :)
[22:02:10] <alex_joni> heh
[22:03:50] <skunkworks> looks like you really have to screw up the pairs before they cause problems..
[22:05:49] <archivist> Ive had cable problems here (cable to portacabin outside)
[22:06:16] <archivist> probably a flexing failure or rats
[22:13:36] <skunkworks> heh - I have had some fail that have been burried.
[22:45:42] <alex_joni> good night all
