Back
[01:16:39] <SkinnypuppY34> Does EMC spilt the difference of backlash when closed and reopened? Having a problem getting my offsets to stay still b/t opening and closing. I have G54 @ 0,0 on DRO G55 @ x-2y2 G56 @ x2y2 G57 @ x2y-2 G58 @ x-2y-2 So there is something solid to compare to .
[01:20:21] <SkinnypuppY34> Upon restart X will be shifted ~.006 and Y ~.007, two restarts doubles of EMC to .012 and .014 this error will apply to g54-g59 and I can't figure the trick to home it @ 0,0 in G54 on the DRO and get 55-59 not to be offset by whatever amount ...
[01:21:25] <SkinnypuppY34> It's easy enough to realign g54 by g1x1y1 and then touch off by whatever the dro value reads, is there a simpler way to keep these put ?
[02:04:30] <fenn> SkinnypuppY34: try g92 instead of g54
[02:05:03] <fenn> but the backlash thing shouldn't happen either
[02:05:34] <fenn> does it only shift when you close emc after traveling in a certain direction?
[02:20:26] <SkinnypuppY34> If I approach 0,0 from 1,1 and restart both axis will end up -.007 and -.008 if 0 is approached from x-1 y-1 then both will shift +.007 and +.008 my backlash is .014 and .016 in stepper_inch.ini so pretty much 1/2 B.L.
[02:21:44] <SkinnypuppY34> Now as long as I keep EMC open it will STAY put all day long in synch with the real DRO
[02:22:35] <SkinnypuppY34> But sometimes I get the no G2G3 movement in mdi and have to restart EMC...
[02:24:46] <fenn> i see
[02:25:20] <fenn> btw are you using an old emc? the small arc move bug was fixed a while ago
[02:26:16] <SkinnypuppY34> 2.2.3 yes ?
[02:30:21] <SkinnypuppY34> Using g92 after opening and g1x1y1 and g92 x1.007 y1.008 will synch up g54, but "show machine position" shows where I'm off by .007 .008 I'm guessing that machine position is what the other offsets are anchored to and how they are off too. Can I manipulate machine position?
[02:46:45] <fenn> no
[02:47:02] <fenn> the other offsets have g92 added to them too
[02:49:11] <fenn> you can't change machine position except by re-homing
[02:56:27] <fenn> oh i guess the arc feed bug wasnt really fixed after all
[02:56:40] <fenn> there will be a band-aid fix in 2.2.2. For 2.3 we should carefully
[02:56:40] <fenn> reexamine helix constraints.
[02:57:24] <SkinnypuppY34> Well I found a way to fool it , just park at x-.007 y-.008 approached from x-.5 y-.5 this seems to work like a charm as far as everything lining back up
[02:57:56] <fenn> anyway if you get the arc bug you shouldn't have to restart emc. just abort and do a g1 move
[03:04:12] <SkinnypuppY34> Ok thats verified that doing g1 x-.5 y-.5 , g1 x-.007 y-.008 before shutdown will give me a perfect g1 x1y1 upon restart and g55-59 line right back up . Wierd if it can keep up with what direction backlash was approached from last why does it split the difference on restart?
[03:54:12] <SkinnypuppY34> http://imagebin.org/14130 http://imagebin.org/14131
[03:55:04] <SkinnypuppY34> http://imagebin.org/14101 http://imagebin.org/14104
[03:59:31] <fenn> what are you making?
[04:04:27] <SkinnypuppY34> A jig for this
http://www.cnccookbook.com/CCHulaHula.html
[04:04:47] <tomp> i like the tit wiper( curved entry and exit eliminates mark on contour )
[04:06:01] <SkinnypuppY34> tit wiper haven't heard it called that yet :O
[04:07:45] <tomp> wedm talk, will you ruin it on compressed air or will you build a steam boiler?
[04:08:07] <tomp> run
[04:10:01] <SkinnypuppY34> Air, I haven't done any boiler stuff as of yet.
[04:10:32] <fenn> hmm for steam why not just go with an eccentric vane motor?
[04:11:20] <SkinnypuppY34> I have a good bit of parts made up, and been working on some gcode to speed things up with in the future.
[04:14:51] <SkinnypuppY34> I think the little six is interesting looking, I'd like to have one powered from an aquarium pump from underneath with a belljar over top just slowly turning
[04:27:53] <SkinnypuppY34> THK KX Precision Ground is a pretty good ballscrew yes? Anyone using these ?
[04:33:43] <toastydeath> it's hard to like, give reviews of ballscrews by themselves
[04:35:15] <toastydeath> because you don't know if like, your axes resemble a rhombus
[04:36:08] <SkinnypuppY34> gotcha there
[04:45:22] <fenn> what's that got to do with it?
[04:45:28] <tomp> SkinnypuppY34: thats a great site
[04:47:07] <SkinnypuppY34> cnccookbook.com something I think I ran across here
[04:48:28] <fenn> SkinnypuppY34 just make sure you are getting something with no backlash and you can worry about the last micron of accuracy when you need it
[04:48:42] <toastydeath> ^^^ signed
[04:49:53] <fenn> toastydeath i feel like you might be saying something but i can't quite figure out what it might be
[04:50:13] <toastydeath> IT'S A TRAP
[04:50:14] <toastydeath> no.
[04:50:26] <toastydeath> what i meant in the beginning is you can't really get a good "review" of a ballscrew
[04:50:38] <toastydeath> unless like, you produce ballscrew reviews for a living.
[04:50:56] <toastydeath> because there are things like the rest of the machine that get in the way
[04:51:27] <SkinnypuppY34> As long as nsk screws aren't known for being junk is about all I am concerned with
[04:51:50] <fenn> but if you write ballscrew review for a living you are highly suspect of being bribed (since nobody with the capability for testing them is going to believe you anyway)
[04:52:01] <SkinnypuppY34> screwballs ..
[04:52:11] <SkinnypuppY34> err ballscrews
[04:52:18] <SkinnypuppY34> uh scrrewit
[04:52:20] <toastydeath> fenn: that is true
[04:52:27] <toastydeath> skinnypuppy34: i kind of liked screwballs
[04:52:51] <SkinnypuppY34> ;o)
[05:13:33] <fenn> what integrates force besides a compressible gas through a restricted orifice?
[05:14:03] <fenn> gas/fluid
[05:14:30] <fenn> (integrates something to produce force)
[05:16:30] <fenn> trying to think of a mechanical analogy for the I in PID
[05:33:51] <JymmmEMC> an AC unit is what you just described, or a carburator
[05:34:15] <JymmmEMC> or a frosting bag tip
[05:34:51] <JymmmEMC> floor jack?
[05:35:53] <JymmmEMC> pressure cooker =)
[05:37:10] <eric_U> matlab crashed X, very nice
[05:37:50] <JymmmEMC> thye dont call it number CRUNCHING for nothing =)
[05:38:16] <eric_U> I didn't even ask it to do anything difficult, 3d bar chart
[05:38:59] <JymmmEMC> in color?
[05:39:07] <eric_U> ya
[05:39:16] <JymmmEMC> See, there ya go! ;)
[05:39:21] <eric_U> zat make it harder?
[05:39:33] <JymmmEMC> (just kidding)
[05:40:20] <gezar> i think my head is going to explode and I have yet to master the definitions :(
[05:40:26] <JymmmEMC> unless you were making a fractal 3d chart
[05:40:44] <eric_U> I have a demo that requires a lot of setup, and I haven't fixed the classes I'm using in matlab so you can't do the setup and save
[05:41:09] <eric_U> about half the time when I'm about to run it, matlab crashes x and i have to start over
[05:41:32] <eric_U> gezar: guess I won't post the current Ph.D. comics then
[05:43:41] <gezar> eric_U: its really hard man, I look at a problem, and my mind much like a oh, say volcano, begings to spew formulas like lava and pyroclastic flows that burn massive holes into the pages that lay before me
[05:44:12] <gezar> too bad descriptive writting wont get me anywhere in calculus
[05:44:15] <eric_U> I've been there, recently
[05:45:29] <eric_U> I'm working in two areas where my background isn't very good, it's very painful
[05:46:07] <gezar> oh, my comp sci project isnt done, but I should have the time morrow after the test, if im not so frustrated I want to cut myself
[05:46:43] <eric_U> my wife is a psychiatrist at a large university, don't say things like that m'kay?
[05:47:46] <gezar> im stating the lim x->0 f(x)=pass(x)/fail(x)^4e^x
[05:48:27] <gezar> I would never do such a thing anyway, im doing all I can, and if thats not enough, then its just not enough
[05:48:40] <eric_U> there's always late drop
[05:49:29] <gezar> well, its ride it out and work for a C and maybe fail, ride it out and get that C, or fail and start with an A in algebra
[05:50:02] <eric_U> hate to even think about wasting more time than needed in school
[05:50:20] <eric_U> the day after you graduate, nobody cares if you got a c in calc
[05:50:29] <gezar> I agree there, thats why I started with the hardest thing I could take
[05:51:46] <gezar> if I can master and maintain the definitions, I should pass this test tommrow
[05:52:11] <gezar> my math may look like hell, but its getting better. and thats what school is supposed to be about, getting better
[05:52:50] <gezar> and if I fail because I wasnt able to get good enough then so be it, einstein worked as a patten clerk, so Ive got all the looking up in the world to do
[05:53:55] <eric_U> get back to work
[13:09:08] <tomp> another rotating ball nut for a Z drive
http://www.cnccookbook.com/CCBlogMar2007.htm about 30% down the page
[13:37:09] <Guest943> logger_emc: bookmark
[13:37:09] <Guest943> Just this once .. here's the log:
http://www.linuxcnc.org/irc/irc.freenode.net:6667/emc/2008-02-19.txt
[13:39:04] <Guest943> Guest943 is now known as skunkworks
[13:40:14] <jlmjvm> skunkworks:everything is wired up and working well
[13:44:24] <skunkworks> Nice.. Now work on adaptive feedrate
[13:44:25] <skunkworks> :)
[13:44:36] <skunkworks> Great work btw - your the first to try it.
[13:47:49] <jlmjvm> im impressed with the results
[13:48:54] <jlmjvm> many thanks to everyone that lended a hand with the configuration
[13:49:49] <jlmjvm> that doesnt look right
[13:50:25] <jlmjvm> many thanks to everyone that helped with the configuration
[13:50:48] <skunkworks> it made sense
[13:51:13] <jlmjvm> cool
[13:54:13] <jlmjvm> jlmjvm is now known as stepperschlag
[13:54:47] <stepperschlag> now theres a nick
[13:55:59] <skunkworks> odd
[13:56:10] <archivist> even
[13:56:49] <stepperschlag> stepperschlag is now known as jlmjvm
[14:05:27] <ALS> hey stepperschlag what type of config you get running?
[14:10:04] <jlmjvm> a boss bridgeport,2 parports and steppers with encoders,used the sample stepper inch config and added the extras
[14:10:37] <ALS> closed loop?
[14:11:48] <jlmjvm> in a sense,uses ferror,if it gets out of position it halts everything,but it cant correct position
[14:12:05] <ALS> sweet!
[14:12:27] <jlmjvm> very handy on a stepper mill
[14:13:03] <ALS> have you lost steps b4
[14:13:50] <jlmjvm> no,but i have stalled a motor before,and it handles that perfectly
[14:14:21] <ALS> what size motors?
[14:14:55] <jlmjvm> pacsci nema 34 640 oz in
[14:15:48] <jlmjvm> got them off ebay for 35 bucks apiece,was a 350 dollar motor with a 250 dollar accucoder encoder already on it
[14:16:14] <jlmjvm> had no idea what that stuff cost when i bought em
[14:16:24] <ALS> good deal
[14:16:56] <ALS> what drives do you have?
[14:17:07] <jlmjvm> gecko 203v
[14:17:49] <ALS> ipm?
[14:19:48] <jlmjvm> 100 ipm rapids right now at 35v dc
[14:19:54] <jlmjvm> http://pastebin.ca/909775
[14:20:33] <jlmjvm> heres a write up that i thought i had put on the wiki,but i cant seem to find it
[15:25:38] <gezar> well, I dont think I failed it, but I dint do very good
[18:45:27] <MASEngr> Good morning, everyone.
[18:45:57] <micges> good evening :)
[18:46:19] <MASEngr> Well, good evening then. ;)
[18:46:42] <MASEngr> I have a question about cutting out a photo. My boss wants to get a scanned image and cut it out with the CNC machine.
[18:47:17] <bill20r3> uhm. I think you'd want a vinyl cutting plotter for that.
[18:47:29] <bill20r3> or an exacto.
[18:47:47] <MASEngr> Okay, let me rephrase that in a less stupid way.
[18:48:14] <bill20r3> heh, ok.
[18:48:23] <archivist> 2d, 3d
[18:48:26] <bill20r3> do you mean he wants it etched into metal?
[18:48:39] <MASEngr> He wants the image on the photo to be traced onto the aluminum. I think he's looking at 2D.
[18:48:47] <bill20r3> for a decorative plaque of some sort?
[18:49:04] <MASEngr> I suppose so. It's probably a photo of his kids.
[18:49:13] <bill20r3> if it were me, I'd try a trophy shop.
[18:49:41] <bill20r3> or you could do a chemical etch, if copper(and maybe brass?) would be an acceptable substitute for aluminum.
[18:50:03] <archivist> MASEngr, as an outline?
[18:50:41] <MASEngr> Yeah, it's probably going to be an outline.
[18:51:23] <archivist> there are utilities to do outline from bitmap
[18:51:44] <MASEngr> Is there one that you'd recommend?
[18:52:13] <fenn> use inkscape's built in tracing (based on potrace)
[18:52:42] <fenn> then you have to figure out how to turn it into g-code - the current way leaves much to be desired (only straight lines)
[18:53:25] <MASEngr> Have you used bmp2cnc?
[18:53:32] <archivist> no
[18:53:48] <fenn> raster scan stuff looks ugly imho
[18:54:09] <archivist> depends if he fills the area
[18:55:16] <fenn> MASEngr:
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?InkscapeHowto
[18:58:32] <MASEngr> Cool, I'll play with that and see how it works.
[18:59:12] <MASEngr> Thanks for the OT help. I appreciate it.
[18:59:26] <fenn> from the description it sounds rather primitive
[19:01:44] <Guest943> Guest943 is now known as skunkworks
[19:09:55] <micges> have anyone know how beam shape correction can be done in EMC ?
[19:11:16] <micges> someone ever try ?
[19:23:33] <fenn> micges: can't you just use the regular tool diameter compensation? (g41/g42)
[19:24:09] <fenn> or is it something complicated like a cone
[19:24:26] <micges> complicated
[19:25:23] <fenn> do you have any links to pages explaining the issues?
[19:26:01] <micges> not yet
[19:26:25] <micges> I dont know english that good to explain this
[19:26:46] <fenn> draw some pictures then :)
[19:26:57] <micges> Im going to find some pages :)
[19:50:35] <micges> ok hard to find pages
[19:50:47] <micges> Ill try to explain
[19:51:06] <micges> we have laser and beam :)
[19:51:34] <micges> and we have beam who has shape of oval
[19:51:54] <micges> then when we set f500
[19:52:11] <micges> when oval has more in x than y
[19:52:35] <micges> speed of axis y has to be 95% of F500
[19:53:15] <micges> and speed of axis x has to be 105% of F500
[19:53:45] <micges> then even beam is oval every line burned has same width
[19:53:53] <micges> this is basic idea
[19:54:23] <micges> :)
[20:01:48] <skunkworks> we have something similar on our fanuc controller for our laser. It lets you set 2 different feed rates for x and y
[20:02:28] <skunkworks> it kinda sucks - it then calculates the actual feedrate depending on the angle of the line being cut. So running this mode - it stop at every end point
[20:03:00] <skunkworks> circles don't work at all. (it cannot adjust the feedrate dynamically_
[20:04:15] <jepler> it's tempting to imagine that you can compute the direction at any time and a function of direction gives you an adaptive-feed number (though adaptive-feed never goes above 100%)
[20:06:11] <skunkworks> interesting.
[20:06:22] <micges> omg
[20:06:25] <micges> have idea
[20:07:02] <micges> I set F2000 on starting emc
[20:07:18] <micges> then control speed only by adaptive feed
[20:07:57] <tomp2> yes, oversize the speed, and let adaptive always reduce it
[20:08:15] <tomp2> reduce it some or a lot, never 1 to 1
[20:08:34] <micges> have 2 parameters : vel-correction-x and y
[20:08:41] <skunkworks> you could scale the adaptive feed so 100% = max feed your machine could do.
[20:08:44] <micges> in percents
[20:08:59] <tomp2> yes 2 scaling factors
[20:09:00] <fenn> skunkworks: that's how it works
[20:09:25] <skunkworks> fenn: I don't think I explained it right :)
[20:10:18] <micges> when I have two scaling factors and speed
[20:11:38] <micges> I must have velocityx/velocityy value somehow
[20:11:59] <micges> then some math and have adaptive-feed value to write to hal
[20:12:02] <micges> and it works :)
[20:12:16] <micges> arc and circles also :)
[20:12:40] <micges> Im going to pencil and paper
[20:14:38] <micges> ok
[20:14:39] <micges> this is idea
[20:15:13] <micges> 2 parameters: vel-correction-x, vel-correction-y
[20:15:43] <micges> one more: vel-base which is base velocity to whole process
[20:16:37] <micges> we have oval beam wider in x by 50%
[20:18:29] <tomp2> can this work with gcode and the emc tp that is enforced by gcode?
[20:18:30] <tomp2> I think xvel & yvel can be independantly scaled when using tiny vectors hal-streamed to hal but not with gcode.
[20:19:07] <fenn> micges: adaptive feed will multiply the vector velocity by some percentage (so base velocity is not needed)
[20:19:30] <tomp2> independantly to x and y
[20:19:32] <tomp2> ?
[20:19:41] <fenn> no, it's a single value
[20:19:59] <tomp2> he wants differnt velocities on x and y
[20:20:04] <tomp2> i think
[20:20:22] <fenn> yes but it should follow the programmed feed
[20:20:39] <fenn> * correction factor
[20:21:09] <tomp2> right, cant chg both and stay on path doh!
[20:21:42] <fenn> * fenn senses a failure to communicate
[20:23:39] <micges> this must be done in motion controler
[20:24:37] <micges> base velocity is vel to set with F code
[20:24:47] <micges> we set F2000
[20:24:57] <micges> and if actual speed is 500
[20:25:05] <micges> adaptive feed is 0.25
[20:26:13] <micges> idea is two independent velocity scale factors in motion controler
[20:27:33] <fenn> no, what will happen is you get 0.25*500 = 125
[20:27:41] <SWPLinux> micges: are you trying to change the milled shape?
[20:27:57] <fenn> swp read the log ;)
[20:28:06] <tomp2> if moving along a line, the relation of x vel to y vel is determined by the angle of the line, you cant independantly scale the x or y velocity
[20:28:11] <SWPLinux> did that, still don't know ;)
[20:28:23] <micges> fenn: F2000*0.25 is 500
[20:28:31] <SWPLinux> of course, I didn't read too far back ...
[20:28:49] <fenn> micges: how do you do different feeds in the same program then?
[20:29:26] <micges> my own m code
[20:29:32] <fenn> aww :(
[20:29:36] <SWPLinux> ok, you want to get the correct amount of burn regardless of the path, with a non-round beam
[20:29:45] <micges> M112 P (requested feed)
[20:29:55] <fenn> that's gross
[20:30:54] <SWPLinux> micges: to keep the burned line width the same regardless of direction of cut, you have to rotate the beam shape
[20:31:11] <SWPLinux> scaling X and Y feeds independently will give you the wrong path
[20:31:13] <micges> yes
[20:31:16] <tomp2> yes he wants uniform kerf
[20:31:30] <SWPLinux> do you have rotation control over the laser?
[20:31:35] <SWPLinux> s/over/for/
[20:31:59] <fenn> micges: the laser spot is a gaussian distribution right?
[20:33:29] <skunkworks> SWPLinux: what he is hoping for is adjusting the adaptive feed on the fly depending on the direction(vector) the laser is cutting.
[20:33:59] <micges> http://www.pastebin.org/20282
[20:34:07] <fenn> adaptive feed will work. just multiply by cos(atan2(y,x)) if your oval has the long end in the y axis
[20:34:15] <SWPLinux> sure, that's easy enough (SMOP)
[20:34:20] <SWPLinux> maybe SMOHC
[20:34:27] <SWPLinux> (simple matter of HAL configuration :) )
[20:35:02] <SWPLinux> ok, so you want that in realtime, right?
[20:35:10] <fenn> don't use python :)
[20:35:13] <SWPLinux> heh
[20:35:35] <tomp2> oh not independantly scale independant velocities, make the single velocity dependant on angle to x
[20:35:48] <SWPLinux> yeah, I'm just getting that myself :)
[20:36:04] <micges> skunkworks: this is the idea
[20:37:35] <fenn> micges have you read about 'comp' yet?
[20:37:47] <micges> yes
[20:38:02] <fenn> i think this is easy with comp
[20:38:12] <skunkworks> I love this quote.
http://www.cnczone.com/forums/showpost.php?p=404959&postcount=18
[20:38:44] <archivist> hehe
[20:38:45] <skunkworks> lets rip everything out and switch to step and direction servo drives - just so we can use mach
[20:39:00] <skunkworks> because it is easier
[20:39:30] <archivist> Im playing with lvdt for homing
[20:39:43] <SWPLinux> plus you don't hav eto learn that newfangled geeky Linux thing
[20:40:08] <SWPLinux> low voltage differential transmission?
[20:40:17] <micges> (start writing some comp rt module)
[20:40:38] <tomp2> still the vel asked for must be less than the max possible vel, to allow for the >1 scaling
[20:41:06] <tomp2> lower your expectations
[20:41:08] <micges> I know
[20:41:18] <tomp2> old SLN joke
[20:41:35] <tomp2> SNL doh
[20:41:57] <micges> but burning almost ever < F1000
[20:42:18] <micges> and after stop adaptive-feed is turned off
[20:42:34] <micges> so jogging can be done max vel
[20:42:38] <fenn> eh just set feed override to center x/y adaptive feed around 100%
[20:43:47] <micges> ok
[20:44:53] <SWPLinux> woohoo - found an outlet!
[20:45:38] <SWPLinux> feed override and AF are multiplied together I believe
[20:46:01] <fenn> does anyone know where the adaptive feed documentation is?
[20:46:08] <SWPLinux> in the source
[20:46:13] <fenn> right
[20:46:13] <SWPLinux> and maybe elsewhere :)
[20:46:37] <SWPLinux> what kind of docs? how it works, how to connect it??
[20:46:52] <fenn> i'm wondering where jepler got the "must be <100%" frmo
[20:47:06] <SWPLinux> because AF can only reduce the speed, not increase it
[20:47:08] <fenn> whhy
[20:47:10] <SWPLinux> I bet he remembered that
[20:47:30] <fenn> feed override can be >100%
[20:47:42] <SWPLinux> I'm not positive why, but I do know that the original intent was to reduce speed for EDM-type processes
[20:47:46] <jepler> It's probably a 1-line change somewhere in motion to *not* cap AF at 1.0 (=100%)
[20:47:56] <SWPLinux> I remember discussing it, but don't remember the reasons
[20:48:10] <SWPLinux> yes, likely to remove one line
[20:48:38] <SWPLinux> it may be in a place where the velocity is already expected to be <max though, and if so that code would need to be moved
[20:49:17] <SWPLinux> http://www.linuxcnc.org/docs/html/gcode_main.html#sec:M52:-Adaptive-Feed-Control
[20:49:23] <SWPLinux> ^^ the what but not the why
[20:50:15] <fenn> is feed_scale the same as feed override?
[20:50:36] <SWPLinux> I think that ends up being the product of several things which includes FO
[20:50:55] <SWPLinux> but I didn't look at the code before saying that
[20:51:01] <fenn> feed_scale; /* velocity scale factor for all motion
[20:51:07] <fenn> net_feed_scale; /* net scale factor for all motion */
[20:51:18] <SWPLinux> hmmm. dunno then
[20:52:27] <fenn> did anyone ever get emc running on a wire edm?
[20:52:47] <tomp2> yeh, not me tho
[20:54:00] <fenn> seems like there should be a clamp parameter for adaptive feed
[20:54:46] <tomp2> mdynac did it
http://timeguy.com/cradek/emc/edm
[20:54:56] <micges> I must go
[20:55:06] <SWPLinux> see you
[20:55:16] <tomp2> bye best of luck
[20:55:27] <micges> think that tomorrow comp will work
[20:55:56] <tomp2> clamp param beside limts of 0 to 1?
[20:56:09] <SWPLinux> clamp instead of 1
[20:56:11] <micges> (have simple idea which cant be explained in english)
[20:56:23] <micges> will be good
[20:56:24] <tomp2> :)
[20:56:27] <micges> bye all
[20:56:46] <fenn> something like motion.adaptive-feed-max (param)
[20:56:49] <micges> bbl
[21:01:46] <fenn> heh "Bite me, spammers. Go ahead and harvest this. I use SpamAssassin; you lose."
[21:02:25] <fenn> so, there's definitely not any pictures on that page
[21:05:07] <cradek> I put them back
[21:08:34] <cradek> http://timeguy.com/cradek-files/emc/edm/MVC-028S.JPG
[21:09:49] <archivist> cradek I saw an wedm'd .15 module gear at a show last week
[21:10:53] <cradek> neat
[21:11:13] <archivist> done with .1mm wire iirc
[21:11:30] <archivist> about 10mm long
[21:11:48] <archivist> crap black finish though
[21:12:06] <archivist> not a watchmakers polish
[21:18:44] <skunkworks> cradek: made it home ok?
[21:18:51] <skunkworks> obviously.. ;)
[21:19:07] <tomp2> thanks cradek
[21:19:34] <SWPLinux> oh yeah - the wireless worked great at the airport Hilton - I downloaded those kernel updates at about 400 kBytes/sec
[21:20:48] <SWPLinux> in other news, LaGuardia has no good coffee, at least not in the USAir terminal
[21:21:02] <SWPLinux> Dunkin Donuts is the closest
[21:21:22] <jepler> meh
[21:21:40] <SWPLinux> unless you prefer McDonalds
[21:23:15] <gezar> program due in 7 hours, and im up to 7 functions :(
[21:23:48] <gezar> and I dont know how I did on the math test, i had some plate shifting going on cause a few minor erruptons
[21:37:37] <NewType__> NewType__ is now known as _NewType_
[21:39:03] <_NewType_> _NewType_ is now known as __NewType
[21:40:39] <__NewType> __NewType is now known as e__NewTyp
[21:41:17] <e__NewTyp> e__NewTyp is now known as pe__NewTy
[21:44:00] <pe__NewTy> pe__NewTy is now known as ype__NewT
[21:44:18] <ype__NewT> ype__NewT is now known as Type__New
[21:45:06] <Type__New> Type__New is now known as F91
[21:46:45] <SWPLinux> tomp2: still around?
[21:47:01] <SWPLinux> (for a pyvcp question or two)
[21:47:14] <F91> can someone point me to a good place to understand how to interface a servo motor?
[21:47:28] <SWPLinux> that depends on which part of the interface you're talking about
[21:47:33] <SWPLinux> and what kind of servo motor
[21:47:58] <SWPLinux> or are you looking for general information like "the leg bone is connected to the ankle bone"?
[21:48:04] <F91> I want to purchase one from Parker Motion
[21:48:19] <F91> and it seems to take a serial port input...
[21:48:28] <SWPLinux> EMC can't use seial at the moment
[21:48:36] <F91> but I think there are other version
[21:48:49] <SWPLinux> with appropriate hardware, you can use step/direction, PWM, or analog commands
[21:48:52] <F91> but it isn't like a stepper which takes a step.
[21:49:09] <SWPLinux> appropriate hardware can be as simple as a parallel port
[21:49:12] <F91> see, it in itself has close loop
[21:49:43] <F91> but it takes either a position or velocity
[21:49:53] <SWPLinux> if it uses something like one of those optical/ethernet buses, then it won't work with EMC at the moment
[21:50:16] <SWPLinux> velocity is OK, but the command can't be serial. analog or PWM only I'll bet
[21:50:19] <F91> I am still reading other ones, but I know stepper can be done quickly with emc.
[21:50:33] <SWPLinux> servos are fine, but not serial-only ones :)
[21:50:37] <F91> so let's say it is velocity for now, how I can use the parallel port?
[21:50:43] <SWPLinux> as PWM
[21:50:55] <SWPLinux> plus a filter/buffer = analog
[21:51:21] <F91> can you give me a little bit more... PWM to generate a voltage or a frequency?
[21:51:40] <F91> voltage.
[21:51:41] <F91> OK.
[21:51:46] <SWPLinux> I suppose you could do either, there's a PWMgen component and a freqgen component
[21:52:04] <F91> then the position is compute internally in emc?
[21:52:15] <SWPLinux> yes, so the motor feedback has to come to EMC as well
[21:52:38] <SWPLinux> and it's unlikely that a nice high-resolution/high speed servo system will be able to use software position feedback
[21:52:49] <SWPLinux> you're likely to need hardware for counting encoder feedback
[21:52:50] <F91> humm. that's the part I get stuck. the controller is closing the loop in itself. so I can't get the information back to EMC.
[21:53:06] <F91> I see.
[21:53:23] <SWPLinux> if the controller is integral to the drive, and you can't bypass it, then it will require some position command, like step/dir
[21:53:36] <F91> I see.
[21:53:42] <SWPLinux> that can work with EMC, but it does bypass much of the goodness that EMC brings along
[21:54:05] <F91> I see... OK.
[21:54:12] <F91> let me think some more.
[21:54:18] <SWPLinux> EMC basically has to tell itself that the motors are always in the expected position, and hope the drives do that (like steppers)
[21:54:29] <F91> right.
[21:54:31] <SWPLinux> so EMC is running open-loop, and the drives are running closed-loop
[21:54:49] <F91> that's why I can confused when the doc said it can do servo.
[21:54:52] <SWPLinux> you do have to run error indications back to EMC though, so it can shut down other axes when one lags
[21:55:16] <SWPLinux> I think serial servo drives are possible, but there's no software/hardware to do it yet
[21:55:31] <F91> how do I feedback? as a pulse?
[21:55:38] <F91> I mean I do have IO left.
[21:55:44] <F91> but voltage doesn't mean much.
[21:55:49] <SWPLinux> there are reprogrammable FPGA cards that aren't too expensive (especially compared to Parker motors/drives ;) )
[21:55:54] <skunkworks> what are you using? printer port?
[21:56:09] <F91> donated motor that has been sitting here for a while.
[21:56:11] <F91> :)
[21:56:19] <skunkworks> When you say 'I do have i/o left.'
[21:56:20] <SWPLinux> generally wquadrature encoders are used for feedback (or synthesized encoder outputs, provided by the drive)
[21:56:31] <SWPLinux> -w\
[21:56:55] <F91> I am doing one drive only, so I should have some IO pin left.
[21:57:14] <SWPLinux> oh, that helps
[21:57:27] <F91> yeah, the controller has closeloop in itself... that's why I can figure out "who is the boss"?
[21:57:43] <SWPLinux> EMC likes to be the boss, which is why there's no simple answer for you
[21:57:48] <F91> I see I see.
[21:57:51] <F91> let me think some more.
[21:58:08] <SWPLinux> take your time :)
[21:58:11] <F91> I am using only one for now.. but I like to use it on 4 axis.
[21:58:22] <F91> I mean total 4 servo...
[21:58:29] <F91> but I need to do more homeowkr.
[21:58:34] <SWPLinux> then you should look at the I/O requirements, you may need more than a single parport can provide
[21:58:38] <SWPLinux> it's even likely
[21:58:44] <F91> thanks for the info! if it get's too hard, I'll buy stepper.
[21:58:57] <F91> right, see, stepper will not have this problem. :)
[21:59:02] <tomp2> SWPLinux: ?
[21:59:14] <SWPLinux> well, they're open loop without the servo control, so they're not exactly better
[21:59:25] <SWPLinux> tomp2: you did a lot of the pyvcp work, right?
[21:59:29] <F91> true. I am considering a 2nd PCI parallel card already.
[21:59:39] <tomp2> did some, hope i can help
[21:59:41] <SWPLinux> heh
[22:00:02] <SWPLinux> I'm just trying to center some text in a table cell (spanned, if it matters)
[22:00:06] <skunkworks> F91: this has some good info on cheap and dirty
http://www.cnczone.com/forums/showthread.php?t=25929&highlight=large+brushed
[22:00:12] <SWPLinux> the sticky tag listed in the docs doesn't seem to work
[22:00:14] <F91> great!
[22:00:37] <SWPLinux> I haven't gone to the extent of putting an hbox in the cell for the label (yet)
[22:01:11] <SWPLinux> are the Parkers DC? (my bet is AC or BLDC)
[22:01:22] <F91> not sure yet... iBC
[22:01:25] <F91> I think
[22:01:38] <tomp2> SWPLinux: my own pyvcp diverged from teh standard, but i can try some code with std interpreter if you can pastebin
[22:01:51] <F91> that's why I need to check out EMC first, to make sure I have the right kind of command.
[22:02:26] <F91> but it looks like it is goign to be hard.
[22:02:30] <F91> using servo I mean
[22:02:37] <F91> for 4 axis
[22:02:38] <SWPLinux> tomp2:
http://pastebin.ca/910362
[22:02:53] <SWPLinux> F91: I don't know what iBC is
[22:03:06] <SWPLinux> other than some television station or something
[22:03:13] <SWPLinux> err - no, root beer maker :)
[22:03:15] <F91> I am trying to figure it out myself. it has serial port input on the front only....
[22:03:24] <F91> Thanks SWPLinux!
[22:03:31] <F91> I'll go do some homewokr now.
[22:03:35] <SWPLinux> enjoy
[22:03:39] <F91> that's for the link skunkworks!
[22:05:56] <fenn> DB-9 connector isn't necessarily serial (rs232)
[22:06:06] <SWPLinux> hmmm. it occurs to me that it isn't so easy to make one checkbutton control two HAL Pins
[22:06:32] <fenn> eh? can't you just linksp twice?
[22:06:53] <SWPLinux> you can't create one pyvcp control that has two outputs
[22:07:13] <fenn> dont need two outputs
[22:07:22] <SWPLinux> much less two outputs that are inverses of each other
[22:07:35] <fenn> aha! now we get to the real problem
[22:07:41] <SWPLinux> I think I do for what I'm trying to do :)
[22:08:07] <fenn> not
[22:08:26] <fenn> (the component, not the valley girl expletive)
[22:09:09] <SWPLinux> yes, that works but doesn't accomplish my end goal
[22:09:41] <SWPLinux> which is to have a fake parallel port in pyvcp, so it's easier to load parport configs in sim
[22:10:11] <fenn> that does sound useful
[22:10:18] <SWPLinux> I may have to (gasp) write a comp or something
[22:10:45] <SWPLinux> but it seems much better to have the I/Os available for user interaction
[22:10:58] <tomp2> SWPLinux: got the panel up, now what
[22:11:14] <fenn> could you have a 'pass thru' fake parport so you could use it in a running config as well?
[22:11:16] <SWPLinux> notice how the inputs label is right-justified in the table?
[22:11:39] <SWPLinux> fenn: I'm not sure why - so you could see the parport pins?
[22:11:45] <fenn> yeah
[22:12:18] <SWPLinux> that can be done in HAL - the idea here is to have things named parport.0.xxx so only one line has to be changedto load a config in sim
[22:12:23] <fenn> i'm imagining a diagram of a db-25 connector with blinkenpins
[22:12:39] <SWPLinux> yeah, that would be cool (and I did think of it), but I'm lazy :)
[22:12:42] <SWPLinux> err - busy
[22:13:10] <fenn> eh well maybe i'll add it to the graphical hal configuratormobile
[22:13:17] <SWPLinux> heh
[22:13:19] <tomp2> SWPLinux: yeah, all the features of tkinter formatting are not in pyvcp ( where mine diverges trying to egt some of those goodies )
[22:13:34] <SWPLinux> ok - just wondering
[22:13:47] <SWPLinux> the sticky tag is in the pyvcp documentation though
[22:13:54] <SWPLinux> I may have been using it wrong
[22:14:07] <tomp2> where? i could fix maybe ( docs or implementation )
[22:14:13] <SWPLinux> one sec
[22:14:26] <SWPLinux> http://www.linuxcnc.org/docview/html//hal_vcp.html
[22:14:29] <tomp2> thx
[22:14:32] <SWPLinux> sure
[22:16:31] <SWPLinux> maybe I'll just leave the -not pins out for the moment
[22:18:27] <SWPLinux> hey tomp2, can you add comments to pyvcp (or add documentation if they exist)
[22:18:36] <SWPLinux> can you just use the <-- blah> format?
[22:19:14] <SWPLinux> nope
[22:19:21] <jepler> I think the XML comment is <!-- ... -->
[22:19:29] <SWPLinux> oh, right. lemme check that
[22:19:57] <SWPLinux> ah yes, thanks
[22:20:03] <SWPLinux> <!-- stuff -->
[22:23:36] <tomp2> SWPLinux: right like html
[22:24:05] <SWPLinux> yep, jepler pointed me in the right direction
[22:24:37] <SWPLinux> I wonder if it makes sense anywhere else to have an "inverted-output" option for the button and checkbutton?
[22:25:05] <SWPLinux> (which causes the creation of both normal and "yaddayadda-not" pins to be created)
[22:25:22] <SWPLinux> with the obvious relationship between them
[22:25:46] <SWPLinux> hmmm. or maybe a "nothalpin" attribute, with the name of the inverted output pin :)
[22:28:22] <tomp2> where are the widgets enum'd? used to be in vcp_widgets.c:vcp_widget_def_t
[22:29:58] <tomp2> i ran your code yet cant find a mention of table in the emc2 src corp. it must exist, it ran
[22:32:13] <SWPLinux> damfino
[22:32:34] <SWPLinux> I thought it passed off the text to tkinter or something, so it wouldn't necessarily know what it is
[22:35:05] <tomp2> sticky is nsew ( north south east west). the docs you pointed to show it with impossible values
[22:35:25] <tomp2> it's an allignment like in tk
[22:36:37] <SWPLinux> OK. I assumed that things would stretch if they were connected to E+W, for example
[22:36:45] <SWPLinux> but there's no C anyway :)
[22:36:49] <tomp2> examples in image-to-gcode.py
[22:36:52] <SWPLinux> maybe the hbox is my best bet
[22:36:57] <tomp2> no stretch
[22:37:08] <SWPLinux> ok, so the "new" example is bogus
[22:37:51] <SWPLinux> n s e w nw ne sw se are the valid options
[22:37:56] <SWPLinux> ?
[22:38:18] <SWPLinux> heh
[22:38:26] <SWPLinux> hmmm - nevermind that
[22:40:20] <tomp2> you woint find all direction possible in hbox or vbox, this was a stumbler for me & i went off trying to rewrite pyvcp.
[22:40:58] <tomp2> it didnt work, and jepler had made some shortcuts but they worked well ( good shortcuts )
[22:41:01] <SWPLinux> I think centering was listed in the docs, but then again that's what got me to where I am now :)
[22:41:46] <tomp2> when i tried to expand them i got some limited success but lost standardization of the pyvcp
[22:43:06] <tomp2> i see someone tried 'ew' in image-to-gcode, i bet its ignored
[22:43:46] <tomp2> widgets[k].grid(row=j, column=1, sticky="ew")
[22:48:05] <jepler> http://emergent.unpy.net/files/sandbox/grid-sticky-ew-is-useful.png
[22:48:22] <jepler> "ew" causes the allocated space for .m to go from the left to the right of its cell
[22:51:15] <jepler> if .m was something without a distinctive background color, and it naturally placed its data at the left of its allocated space, then it would be hard to tell the difference between "e" and "ew"
[22:51:48] <SWPLinux> is it equivalent to center?
[22:52:37] <SWPLinux> oh - I see. the widget is the full size of the container in the case of m there
[22:53:19] <SWPLinux> it looks like there's a bug in pyvcp (or in my python installation)
[22:53:48] <jepler> afair the sticky option is passed right through to the grid manager in pyvcp
[22:54:02] <jepler> this one shows the difference between empty sticy, and the options I already mentioned:
http://emergent.unpy.net/files/sandbox/sticky2.png
[22:54:42] <jepler> bbl
[22:54:46] <SWPLinux> that pastebin gives me this error:
[22:54:48] <SWPLinux> steve@laptop-m570:/Project/emc2/configs/sim$ halcmd loadusr -Wn parport.0 pyvcp -c parport.1 parport-out.xml
[22:54:50] <SWPLinux> pyVCP: Creating widgets from parport-out.xml ...
[22:54:51] <SWPLinux> Error constructing hbox({}):
[22:54:53] <SWPLinux> pyvcp_tablespan instance has no attribute 'tk'
[22:54:54] <SWPLinux> <commandline>:0: pyvcp exited without becoming ready
[22:55:07] <SWPLinux> hmm
[22:55:28] <SWPLinux> even if I correct the naming typo
[23:13:52] <SWPLinux> ok, time to get to the gate. see you all later
[23:24:36] <micges> have noticed strange thing
[23:24:54] <tomp2> the example at
http://www.linuxcnc.org/docview/html//hal_vcp.html#r1 needs to be ... <label text="C, D (cells 1,3 and 1,4)"/> ( becuz '/' missing) and <label text="K (cell 3,3)"/> (becuz cell 3,2 is occupied already)
[23:25:04] <tomp2> micges, continue please
[23:25:06] <micges> when setp hal pin and link it to something then value of pin is again zero
[23:25:32] <micges> is this correct ?
[23:25:52] <tomp2> it's been mentioned, so do setp after linkp
[23:26:06] <micges> is zero even if linked value is nonzero
[23:26:31] <micges> I did that but doesnt work
[23:27:02] <micges> It worked when in name of pin there wasnt any "-"
[23:27:14] <micges> I converted - to _ and it works
[23:27:18] <micges> strange
[23:27:57] <micges> module and algorithm works for speed compensation :)
[23:28:08] <micges> must only put this together
[23:29:44] <tomp2> congrats, thats a great idea for the laser
[23:30:56] <micges> thanks
[23:32:10] <micges> linuxcnc wiki has area to put some images with algorithms to make something ?
[23:32:32] <micges> or data flow algorithm tree
[23:34:40] <tomp2> make a new page in wiki,
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?BasicSteps
[23:35:34] <tomp2> and dont worry about english, we'll try to help
[23:37:10] <micges> ok
[23:53:47] <micges> ok link added to main wiki page
[23:54:05] <micges> rest tomorrow becouse its late
[23:54:12] <micges> goodnight all
