#emc | Logs for 2007-08-30

Back
[01:24:12] <^Fritz> logger_emc, bookmark
[01:24:10] <^Fritz> Just this once .. here's the log: http://www.linuxcnc.org/irc/irc.freenode.net:6667/emc/2007-08-30.txt
[01:48:12] <^Fritz> Blast!...I was going to play with emc2-trunk, and I inadvertently did a 'sudo make install'...now I have to clean up everything everywhere
[01:49:16] <^Fritz> I'd really, REALLY like to try out the double-step patch
[01:49:38] <^Fritz> My Taig beseeches you!
[01:51:54] <SWPadnos> ^Fritz, try the apt-get incantation to reinstall emc2
[01:52:10] <SWPadnos> it's something like `apt-get --reinstall emc2`
[01:52:40] <SWPadnos> or `apt-get --reinstall install emc2`
[01:54:00] <SWPadnos> (or, use synaptic and mark emc2 for reinstallation)
[03:28:39] <skinnypuppy1334> Anyone know if FreeCad is worth installing? Spent the evening learning GCAD. Pretty cool, but I need something else for generating datapoints. I've been using a trial version of Mastercam X, but it won't save your work and won't output gcode....
[03:28:55] <fenn> the one based on opencascade?
[03:29:29] <fenn> i never got it to compile, something in the 500+ MB of libraries wasnt working right
[03:29:29] <skinnypuppy1334> GCAM not GCAD, my bad
[03:29:48] <skinnypuppy1334> http://juergen-riegel.net/FreeCAD/Docu/index.php?title=Main_Page
[03:30:23] <fenn> it seems to be actively developed, maybe i should try again
[03:31:39] <skinnypuppy1334> That screenshot looks a lot like X
[03:39:17] <skinnypuppy1334> What other alternatives are there? Qcad?
[03:44:56] <fenn> qcad is just 2d drafting
[03:45:12] <fenn> brlcad maybe?
[03:45:37] <skinnypuppy1334> Not familiar with brlcad
[03:46:13] <fenn> its more like a 3d modeler than a cad program, but its old enough that it supports fancy math stuff
[03:46:26] <fenn> unlike the new stuff where they just throw more polygons at everything
[03:47:34] <fenn> there's a lot of 3d modelers out there (ayam aoi blender k3d etc) but nothing that supports standard cad style interaction
[03:48:14] <fenn> i liked ayam's interface but it kept crashing and never displayed CSG right
[03:48:43] <skinnypuppy1334> brlcad site looks interesting
[03:49:36] <fenn> you should be warned, brlcad is very Unix
[03:52:43] <skinnypuppy1334> That freecad debian package installed in fiesty no problem. Guess I'll be checking it out a little while tonight.
[04:16:06] <skinnypuppy1334> Help function doesn't seem to work on that FreeCAD free-cad-sourceforge.net is no longer hosting the webdownload help files
[04:23:37] <sed__> sed__ is now known as sed
[04:26:11] <Skullworks-PGAB> cradek: what's a good basic lube for plastic (delrin? nylon?) against drill rod? - Wax or parafin based oil
[04:29:07] <toast> toast is now known as toastydeath
[04:29:23] <fenn> freecad certainly looks promising
[04:30:00] <skinnypuppy1334> fenn you playing with freecad? I haven't figured out how to do anything more than make a cube...
[04:30:08] <fenn> skinnypuppy1334: i think that's all it does right now
[04:30:20] <fenn> dunno why he hasnt implemented other shapes, seems like that's the most fun part
[04:30:25] <skinnypuppy1334> woohoo
[04:30:36] <SWPadnos> it's not shape based
[04:30:52] <SWPadnos> from the (very) little I read, it's feature-based, like SolidWorks
[04:31:14] <fenn> features then
[04:31:20] <SWPadnos> so you draw a 2D sketch, then do some process to make it into a 3D feature
[04:31:29] <toastydeath> i can't find freecad screenshots
[04:31:34] <SWPadnos> well, it's not so much the same thing
[04:31:39] <SWPadnos> (or it could be :) )
[04:32:04] <skinnypuppy1334> Scratchin my head
[04:32:24] <fenn> woah the animated julia set is cool
[04:32:32] <skinnypuppy1334> I haven't used solidworks just mastercam and catia
[04:32:50] <SWPadnos> I didn't think mastercam was a CAD program
[04:33:10] <toastydeath> it has basic cad features
[04:33:13] <SWPadnos> catia should have the features of solidworks, but I'm not sure if it works the same way
[04:33:36] <SWPadnos> "features" meaning that the program is at least as capable
[04:33:45] <toastydeath> uh
[04:33:47] <toastydeath> catia is like
[04:34:06] <toastydeath> the SR-71 blackbird of parametric modeling programs
[04:34:11] <SWPadnos> catia is the thing that solidworks tries to emulate :)
[04:34:44] <SWPadnos> but I don't know if it uses the same user interactions - feature tree, drag-drop rearrangement of features, sketch-then-whatever ...
[04:34:48] <skinnypuppy1334> Catia class for elective was cool , not like I'll ever afford it
[04:34:56] <toastydeath> solidworks is like the top end of the affordable CAD programs
[04:34:59] <fenn> toastydeath: didnt they use catia to design the sr-71? :)
[04:35:06] <toastydeath> i'm not sure, they probably did
[04:35:13] <SWPadnos> I don't think catia is that old
[04:35:15] <fenn> i know it was made for airplanes
[04:35:20] <toastydeath> catia is very old
[04:35:22] <SWPadnos> the SR-71 is older than me :)
[04:35:40] <SWPadnos> (but not by much, if I have the dates right)
[04:36:21] <toastydeath> ha
[04:36:34] <toastydeath> solidworks has trouble doing tremendously complicated curved surfaces
[04:36:49] <toastydeath> i ran up against it when I was doing cast parts
[04:37:05] <SWPadnos> then there's the problem of the company SolidWorks being so far up Microsoft's ass, it isn't even funny
[04:37:35] <toastydeath> eh, i don't think the people who use unix/linux on the desktop really go for the whole solidworks-level CAD programs
[04:37:51] <SWPadnos> they're actually worse than National Instruments and Microsoft regarding file versions and which version of software you need to read them
[04:37:55] <fenn> toastydeath: what do you mean?
[04:38:23] <fenn> i've never used solidwords so i dont know what "solidworks-level" means
[04:38:27] <SWPadnos> CAD started on Unix. it's only recently that the "low end" has caught up in features
[04:38:28] <toastydeath> CATIA and Pro/E definately, and I believe NX
[04:38:37] <toastydeath> all do Unix and Windows
[04:38:51] <SWPadnos> SolidWorks is an excellent CAD package, adn is very easy to use (and has a lot of good eye candy)
[04:39:04] <fenn> solidworks doesnt run on unix because of microsoft's .NET EULA
[04:39:04] <SWPadnos> it's cheap for good CAD, at $5500 or so
[04:39:24] <toastydeath> fenn: i'm saying the people i've seen using Linux
[04:39:24] <toastydeath> in engineering
[04:39:26] <fenn> s/unix/anything but windows/
[04:39:29] <toastydeath> usually have very, very expensive software
[04:39:28] <SWPadnos> solidworks doesn't run on Unix because they made the decision very early on (well before .NET) to only support Windows
[04:39:37] <toastydeath> to run on it
[04:40:35] <toastydeath> like, they don't blink at buying 50 CATIA seats
[04:40:55] <SWPadnos> heh - at $30-100k a pop, depending on features :)
[04:41:00] <toastydeath> yep
[04:41:00] <fenn> well it's easy to spend other peoples' money
[04:41:08] <SWPadnos> though there must be discounts for that wuantity
[04:41:22] <skinnypuppy1334> Anyone familiar with GCAM? I couldn't get the drilling function to work, I made some profile and pockets holes...
[04:41:32] <SWPadnos> Twingy is
[04:41:38] <fenn> heh he better be
[04:41:45] <SWPadnos> one would hope
[04:42:35] <Jymmm> why?
[04:42:42] <skinnypuppy1334> I haven't caught him chatting yet, and didn't want to bug him with noob questions
[04:42:57] <SWPadnos> Jymmm, because he wrote it
[04:43:28] <SWPadnos> skinnypuppy1334, unfortunately, he's probably the only person here who can answer any questions about it
[04:43:36] <Jymmm> SWPadnos: So? doens't mean he knows how it works. At least if you consider most developers.
[04:43:40] <Jymmm> =)
[04:43:44] <SWPadnos> I don't think anyone here has used it beyond checking it out
[04:43:49] <SWPadnos> Jymmm :P
[04:43:54] <SWPadnos> :P :P :P :P
[04:44:00] <SWPadnos> good night :)
[04:44:07] <Jymmm> G'Night SWPadnos
[04:44:12] <SWPadnos> got a morning meeting - ugh
[04:44:32] <Jymmm> I got a hot date with a pillow at 3:30
[04:44:59] <skinnypuppy1334> I've been playing with it making pockets and slots and checking out the gcode output in tkemc backplotter... pretty cool
[04:45:20] <Jymmm> And from what my gf just told me, that might be literal.... 85F still
[04:46:56] <fenn> ok i cut the cube in freecad.. now if i could just figure out how to rotate it to see what the heck i did
[04:48:12] <toastydeath> haha
[04:48:31] <skinnypuppy1334> try the middle mouse button fenn
[04:49:22] <fenn> it just drags the view around
[04:49:33] <toastydeath> hold shift
[04:49:36] <toastydeath> and middle mouse?
[04:49:39] <toastydeath> ctrl + middle?
[04:50:15] <fenn> shift/ctrl dont seem to affect anything
[04:50:19] <toastydeath> owned
[04:50:29] <toastydeath> you know what cad program sucks?
[04:50:33] <toastydeath> Autodesk Inventor.
[04:50:51] <skinnypuppy1334> it's the front, top, back. right left box icons
[04:50:51] <toastydeath> how did the company that makes Autocad screw up parametric modeling so bad
[04:52:07] <fenn> well, maybe i'll ask if shift/ctrl+middle mouse button can do zoom and rotate
[04:53:38] <fenn> its pretty slick how you can dock/undock windows and move them around
[04:53:44] <fenn> i guess qt gives you that for free
[04:54:58] <skinnypuppy1334> Fenn, did you really take a hunk outta that cube?
[04:55:17] <toastydeath> skinnypuppy1334:
[04:55:21] <toastydeath> that's how you do parametric modeling
[04:55:56] <fenn> skinnypuppy1334: made two cubes, select both of them in the part tree, then click on cut which should no longer be grayed out
[04:57:17] <fenn> er.. click on "box fix 1" and then "box fix 2" to create the cubes
[04:57:34] <fenn> otherwise you would have to move them, which seems to not be there yet
[04:58:00] <fenn> moving/rotating stuff is probably the first thing i'd do in a cad program, i wonder what kind of weirdo this guy is ?)
[04:58:05] <toastydeath> why would you move a parametrc solid
[04:58:15] <toastydeath> you should define it in the right spot to begin with?
[04:58:19] <toastydeath> (not that i'm using freecad)
[04:59:11] <fenn> uh, because you want to put it in the right place?
[04:59:26] <toastydeath> that does't quite make sense to me
[04:59:29] <fenn> ok
[04:59:39] <toastydeath> like, how i'm used to parametric programs working
[04:59:43] <toastydeath> is you make your base solid
[04:59:54] <toastydeath> then you constrain additional solids, at the time of creation, to the other solid
[05:00:26] <fenn> sure
[05:00:39] <toastydeath> so creating a solid and then constraining it afterwards seems backwards
[05:00:40] <fenn> i dont know how to do that either
[05:01:41] <fenn> you might think that "h" and "l" or maybe "x y z" would change the dimensions or location of the box, but you would be wrong
[05:03:30] <toastydeath> i just downloaded one of the things
[05:03:30] <toastydeath> i want to see tis
[05:03:32] <toastydeath> *this
[05:06:04] <skinnypuppy1334> Jeez, I wish there were a way to save files atleast in this darn mastercamX demo...
[05:06:40] <fenn> http://fenn.dyndns.org/pub/irc/freecad.png as you can see it mostly works with my colorscheme
[05:09:23] <toastydeath> freecad is linux only
[05:09:25] <toastydeath> oh well
[05:10:13] <skinnypuppy1334> I'll give it this much , the debian package installed painlessly
[05:10:48] <fenn> freecad is not linux only
[05:10:58] <toastydeath> i don't see a windows download
[05:11:01] <fenn> they even package all the random libraries and such for windows download
[05:11:12] <fenn> its on the *drumroll* download page
[05:11:31] <toastydeath> link?
[05:11:36] <toastydeath> oh, goddamn
[05:11:42] <toastydeath> i passed right over the windows link
[05:11:42] <toastydeath> on the page
[05:12:04] <skinnypuppy1334> toasty needs to rub his eyes
[05:14:11] <fenn> its really neat how you can have multiple documents open on the same workspace
[05:15:03] <toastydeath> where the heck are the planes
[05:15:23] <fenn> or even split out windows to the window manager
[05:16:20] <toastydeath> this is ridiculous
[05:19:38] <fenn> yeah its obviously not one
[05:19:39] <fenn> done*
[05:19:48] <fenn> but i like what i see
[05:19:51] <toastydeath> this is harder to use than pro/e
[05:25:41] <fenn> i just posted one
[05:25:47] <fenn> ack
[11:17:38] <sonicmook56> What 2d CAD software would one recomend for use with EMC2
[11:17:41] <sonicmook56> ?
[12:14:35] <skunkworks_> fenn: you are now a sticky :)
[12:16:11] <cradek> what's brown and sticky?
[12:17:34] <skunkworks_> heh http://www.cnczone.com/forums/showpost.php?p=337010&postcount=16
[12:17:40] <skunkworks_> morning chris
[12:18:42] <jepler> good morning
[12:18:45] <skunkworks_> it is suprising that halfstepping was quieter than 1/8 stepping.
[12:18:55] <skunkworks_> morning jeff
[12:19:11] <skunkworks_> to me anyways. :)
[12:19:29] <jepler> yeah the "common wisdom" I've always heard is that the smaller the steps the better
[12:20:26] <skunkworks_> are you running the rated current to the steppers?
[12:21:18] <jepler> suppsedly they're 2.0A
[12:21:29] <jepler> I ran them some at 1.5A and some at 2.0A, it didn't seem to make much difference
[12:21:35] <cradek> it not just sounded better, the motion was also better
[12:21:36] <skunkworks_> ok
[12:21:49] <skunkworks_> I say - if it works :)
[12:22:41] <cradek> I'm surprised that you get better performance out of your smaller motors at 29v than I get from my larger motors at 60? v
[12:22:50] <cradek> (much higher top speed)
[12:22:56] <cradek> ack, bbl
[12:23:26] <jepler> yeah I ought to be driving into work instead of sitting comfortably on my couch at home :-P
[12:23:32] <jepler> bbl too
[12:23:39] <skunkworks_> must be nice ;)
[12:24:05] <skunkworks_> I have a vanilla cappuccino - it isn't all bad.
[12:25:50] <skunkworks_> your running the motors at 1500rpm.. that is pretty good to me :) The router seems to be limited to around 1800rpm.
[12:27:22] <skunkworks_> 1440rpm I should say
[12:38:02] <jepler> yay now I am at the office
[12:38:12] <jepler> geez over 10 minutes? killer commute.
[12:38:42] <skunkworks_> heh - mine is around 20-25. not too bad
[12:40:13] <skunkworks_> I take it cradek has a little longer drive ;)
[12:40:26] <jepler> he gets to drive at highway speeds for part of it though
[12:42:06] <skunkworks_> how is the backlash?
[12:42:07] <jepler> google says 2.9mi, 9 minutes for me; 7.4mi, 19 min for him
[12:42:27] <skunkworks_> not too bad.
[12:44:12] <jepler> skunkworks_: haven't measured it yet. The spiral didn't have obvious quadrants or flats. However, on the splash gcode none of the letters are quite "closed" -- look at the top left of the "M" in http://axis.unpy.net/files/01188441458/img_7040-medium.jpg
[12:44:34] <jepler> dunno if that is backlash or blending with the "Z" moves in and out
[12:45:47] <skunkworks_> it the roughness the cutter chipping the material out?
[12:46:04] <jepler> I don't know
[12:46:43] <jepler> I see it happens more in one direction than the other
[12:47:02] <skunkworks_> what was the bit?
[12:47:10] <jepler> whatever came in the dremel tool box
[12:47:15] <skunkworks_> heh
[12:47:27] <skunkworks_> could it have been pulling the cd up?
[12:47:33] <skunkworks_> how was it held down?
[12:49:01] <jepler> some cellophane tape on 3 or 4 edges
[12:49:29] <jepler> the tool must be a "191 high speed cutter" http://www.dremel.com/en-us/attachments-and-accessories/attachment-accessory-detail.htm?H=188537&G=66237&I=66273
[12:53:05] <skunkworks_> it it odd that it ony seems to be doing it on the left side of the cut
[13:55:21] <gene> hi guys, I'm getting a bad character message from line 10, here is 9 & 10
[13:55:40] <gene> #36 = [[#35] / 2.0] - 0.125 (should now be the correct radii to cut a 1.130" diameter hole)
[13:55:38] <gene> #37 = -0.140 (starting z - in case of restart)
[13:55:56] <jepler> #36 = [[[#35] / 2.0] - 0.125]
[13:56:09] <jepler> you need more brackets. Try the line above:
[13:56:27] <cradek> the - is a subtraction operation, not part of a negative number, so it needs to be in []
[13:56:27] <gene> whats wrong? i've been playing the 10k monkeys thing for about an hour now
[13:56:40] <SWPadnos> the entire equation has to be inside brackets
[13:57:00] <SWPadnos> you have some stuff in brackets, but the last subtraction is hanging in "free space"
[13:59:15] <gene> ahh, I think I tried that, but brb. Ok, that moved it down to linbe 16, probably the same error, thanks Jeff
[14:00:27] <skunkworks_> It usually takes me 3 tries to get the brackets in the right place. :)
[14:39:12] <CIA-24> 03jepler 07TRUNK * 10emc2/src/hal/utils/comp.g: --install-doc to install manual pages to the standard location
[14:50:16] <CIA-24> 03jepler 07TRUNK * 10emc2/src/hal/utils/comp.g: --install for .py files: strips extension, adds or fixes #!-line, makes executable
[15:22:45] <skunkworks_> jepler: plan on mounting home/limitswitches on it?
[15:44:29] <jepler> skunkworks_: yeah chris planned that all out for me too
[15:45:48] <jepler> skunkworks_: for now, X and Y are really easy to home by eye, and Z isn't bad
[15:46:06] <jepler> but eventually I'd like home switches plus tool length switch
[15:46:07] <cradek> with phase drive you could have a kind of index pulse generated internally (some particular configuration of what coils are powered). with step/dir that's harder - you'd have to have feedback from the driver.
[15:46:32] <jepler> there's actually a "home output" on most stepper drivers (including l298 and xylotex)
[15:46:34] <cradek> I wonder if you could home repeatably with this additional information
[15:46:37] <cradek> oh!
[15:46:46] <jepler> er, well, on allegro 3977
[15:46:52] <jepler> I don't think it's exposed anywhere on the xylotex board
[15:47:12] <cradek> is it what I said (a particular configuration of coil activation)?
[15:47:20] <jepler> yes
[15:47:24] <cradek> neat.
[15:47:40] <cradek> it's not as good as 1ppr of course
[15:48:23] <jepler> "home state = 45 degree step angle"
[15:48:33] <jepler> +70.71% current on both windings
[15:48:35] <jepler> that's also the power-up state
[15:48:43] <cradek> interesting
[15:50:33] <skunkworks_> I think the parker drives have an input like that also.
[15:50:36] <cradek> oh hey, the power up state is fixed? that would give you the same thing if by just keeping count
[15:50:44] <cradek> s/if//
[15:52:50] <jepler> on a 20TPI screw, one full step is .00025 in, so there's really not much distance between two adjacent "home" locations
[15:53:08] <cradek> oh hmm, forget it then
[15:53:13] <SWPadnos> heh
[15:53:39] <SWPadnos> even direct driving a 5TPI screw (say, on a Bridgeport), it's 0.001
[15:54:14] <jepler> seems to me someone mentioned bridgeport using this in homing
[15:54:17] <jepler> at workshop
[15:54:30] <SWPadnos> I think that was Stuart talking about "home to next index"
[15:54:30] <cradek> that would be easy - it was a phase drive
[15:55:18] <SWPadnos> I think that's how the AC servo drives give you such high resolution. there are some that have 2.5 million counts per motor rev
[15:55:21] <jepler> sure could a "home" output pin to stepgen for phase drive types, in case somebody wants to use it
[15:56:32] <jepler> or for step+dir and quadrature type when a steps-per-mumble parameter is set to nonzero
[15:57:16] <jepler> but you'd have to take care to power on the drivers at the same time you start emc
[16:16:49] <fenn> i think PID is best explained with code. i wonder why they always mess it up
[16:18:39] <fenn> diagrams like this really dont help at all http://en.wikipedia.org/wiki/Image:Pid-feedback-nct-int-correct.png
[16:19:00] <fenn> if someone knows how to read a diagram like that, they already know how PID works, guaranteed
[16:19:52] <skunkworks_> heh - exactly
[16:21:56] <jepler> "Source
[16:21:57] <jepler> Made using Microsoft Word"
[16:22:14] <jepler> what I think is even less likely is that someone who uses microsoft word to draw technical diagrams actually understands them </snark>
[16:22:40] <fenn> meh. it looks pretty
[16:39:12] <skunkworks_> Set Zero Phase Input
[16:39:29] <skunkworks_> This input allows you to reset the motor phase currents to the power up position.
[16:40:17] <SWPadnos> which moves an unknown number of microsteps ...
[16:41:58] <skunkworks_> I would think if you hit a homing switch then set this input - it should be exact. :)
[16:42:19] <skunkworks_> every time
[16:42:59] <jepler> no -- imagine you're halfway between adjacent "power up positions"
[16:43:02] <SWPadnos> you'd be at a known step motor phase, but that doesn't necessarily relate to the home switch position
[16:43:02] <jepler> which one do you think it will "snap to"?
[16:43:06] <jepler> it would be about 50/50
[16:43:19] <skunkworks_> unless you where unlucky enough to hit the switch exactly half way between... jeez you guys type fast
[16:43:55] <JymmmEMC> skunkworks Somehow you think they're Hu-Mon
[16:44:17] <SWPadnos> you are not morg, you are not I-morg
[16:44:19] <jepler> we are not grinning scarecrows sent to torture and manipulate you
[16:44:44] <JymmmEMC> morg?
[16:44:53] <skunkworks_> mental note - Kashi frozen meals are pretty damn good.
[16:45:05] <SWPadnos> Star Trek:TOS, Episode "Spock's Brain", I believe
[16:45:19] <JymmmEMC> ah, damn trekkies =)
[16:45:41] <SWPadnos> no - it's this brain of mine - I remember lits of useless stuff (which often seems to push out more important things)
[16:45:46] <SWPadnos> lots, too
[16:46:00] <archivist> sign of old age
[16:46:11] <SWPadnos> I can't read signs
[16:46:16] <archivist> * archivist shuts at his age
[16:46:21] <JymmmEMC> archivist: No, he rememered the phone # of a restraunt
[16:46:34] <SWPadnos> address, not phone number :)
[16:47:39] <SWPadnos> and that's one of the important things to hold on to :)
[16:47:41] <skunkworks_> boy - that is as bad as my wife knowing the order of the songs on all of her cd's
[16:47:41] <JymmmEMC> SWPadnos: You pulled up the phone # faster than I could look it up.
[16:47:41] <SWPadnos> I had it in my phone ;)
[16:47:41] <SWPadnos> skunkworks_, doesn't everyone know that?
[16:47:41] <JymmmEMC> lol, that's right. I forgot.
[16:47:42] <jepler> and I'm referring to http://tmbw.net/wiki/Lyrics:Critic_Intro
[16:47:42] <SWPadnos> I've got Guido's in LA in there as well
[16:48:12] <JymmmEMC> Never been there.
[16:48:30] <SWPadnos> most excellent Italian
[16:48:37] <SWPadnos> 11980 Santa Monica Boulevard, IIRC
[16:48:47] <fenn> i've seen jepler type, and it truly is amazing
[16:48:55] <JymmmEMC> SWPadnos: Let me guess, on a Sunday afternoon?
[16:49:03] <jepler> * jepler blushes at fenn
[16:49:20] <SWPadnos> I think I'm about as fast as jpeler at hitting keys, but I have a much higher percentage of backspace usage
[16:49:25] <SWPadnos> japler, too
[16:49:29] <SWPadnos> no, jepler
[16:49:31] <SWPadnos> yeah!
[16:49:46] <JymmmEMC> SWPadnos: You missed the backspace key
[16:49:45] <fenn> * fenn points at the tab key for future reference
[16:49:49] <jepler> oh there are lots of edits when I type
[16:50:06] <SWPadnos> not as many as me :P :P
[16:50:12] <SWPadnos> err - wait
[16:56:03] <JymmmEMC> When I try to keep up with you guys, somehow between my brain and my fingers gets lost in translation.
[16:56:14] <SWPadnos> I can see that
[16:56:30] <SWPadnos> (s/somehow/something/ :) )
[16:56:59] <JymmmEMC> Shit, and I even tried to slow way down to say that correctly.
[16:57:27] <archivist> brain needs oiling
[16:57:47] <SWPadnos> now, why does godaddy send me a renewal notice just after I've renewed all my domains withthem?
[16:57:50] <JymmmEMC> archivist: I think I need to repave the roadway more than the brain
[16:58:15] <JymmmEMC> SWPadnos: You're too good... renewing before the due date.
[16:58:34] <SWPadnos> well, the due dats is only ~2 weeks away, and I did it ~2 weeks ago so ...
[16:58:39] <SWPadnos> date
[16:58:55] <JymmmEMC> SWPadnos: But, I'm glad they send out so many renewal notices.
[16:59:06] <SWPadnos> yeah - gotta have fuel for the fireplace
[16:59:15] <JymmmEMC> Internic might have sent out one iirc
[16:59:47] <JymmmEMC> SWPadnos: Fuel? You got a paper notice?
[16:59:48] <fenn> pebkab
[16:59:51] <SWPadnos> they do have a neat service as well - you can push out a registration in one month increments for $0.75/month
[17:00:00] <SWPadnos> it lets you synchronize renewals
[17:00:09] <SWPadnos> yes, snail mail
[17:00:37] <JymmmEMC> SWPadnos: See, I wouldn't want that in case I was sick/out of town. Then all my domains might go bye-bye
[17:00:45] <SWPadnos> I get email as well
[17:00:58] <JymmmEMC> I've never gotten snail mail from godaddy
[17:00:58] <SWPadnos> and this is the second or third notice I've gotten
[17:01:09] <SWPadnos> it's just that the others all happened to be before I renewed
[17:01:11] <skinnypuppy1334> Guys, I'm going to order three geckos today, are the G210's worth the extra money over G201's?
[17:01:19] <fenn> i always have a picture of a nice little snail delivering mail with his US MAIL pouch and glasses (which would be useless on a snail)
[17:01:31] <SWPadnos> skinnypuppy1334_, only if you need the step multiplier
[17:01:46] <SWPadnos> what is really worthwhile is the g203v instead of either the 201 or 210
[17:02:39] <SWPadnos> you basically can't kill those. the worst you can do (without really trying) is to fry a $0.22 fuse
[17:02:54] <SWPadnos> obviously hammers and drills can cause permanent damage
[17:03:32] <skinnypuppy1334> I've got a good enclosure, so if it were you it would be 203v's ?
[17:03:33] <SWPadnos> if you haven't read it: http://www.geckodrive.com/photos/Differences_between_G201_G202_and_G203V.pdf
[17:04:10] <SWPadnos> if I were making my first stepper control system, then yes, it would be G203V
[17:04:31] <SWPadnos> if I had made 100 before and really knew the design and the motors were good, then I might go for something else
[17:04:52] <skinnypuppy1334> I'll be reading it now, I hadn't run across it yet. Yeah steppers, I can't afford that servocontrol card
[17:07:45] <SWPadnos> if you need the step multiplier, then the G212 might be the way to go. there's supposed to be a G213 (with the multiplier) and a G903 (the step multiplier board for the G203V), but I don't see either on the gecko site
[17:08:24] <SWPadnos> the only difference between the G203 and the G202 is short circuit protection (if a motor coil or the motor leads short out)
[17:08:47] <SWPadnos> err -and some other stuff at the end of the list :)
[17:09:01] <fenn> and it will suck your blood at night
[17:09:07] <SWPadnos> argh. ignore that last bit
[17:09:38] <SWPadnos> there are a ton of differences - I was looking at that list as a feature list, not two distinct lists of differences
[17:10:41] <fenn> swp so .. you aren't making your first stepper control system?
[17:10:55] <SWPadnos> nope, nor my hundredth
[17:11:01] <SWPadnos> I'm not making one :)
[17:11:12] <fenn> well, obviously, but in the future i mean
[17:11:17] <SWPadnos> I might one day
[17:11:21] <skinnypuppy1334> Crappers the 203v is the ones the pmdx 131 doesn't support
[17:11:28] <SWPadnos> heh
[17:11:49] <fenn> hrm is USC universal stepper controller or universal servo controller?
[17:11:57] <SWPadnos> stepper
[17:12:19] <SWPadnos> with the G320/G340, it ends up controlling servos, but it's a step generator
[17:23:22] <JymmmEMC> fenn: SWPadnosmight make a step gen, but not a drive
[17:23:33] <skinnypuppy1334> That microstep morphing looks interesting... but I'm not seeing anything on pmdx that says it will run it
[17:23:43] <skinnypuppy1334> G203v that is
[17:45:34] <fenn> Since Ladder Logic diagrams don't have "source files", simply upload a screenshot :(
[18:21:06] <anonimasu_> hi
[18:21:11] <anonimasu_> anonimasu_ is now known as anoniamsu
[18:22:23] <jepler> microstep morphing?
[18:22:30] <ler-hydra> 'lo
[18:22:36] <jepler> hi ler-hydra
[18:22:41] <ler-hydra> I'm having issues getting a pci parport card to work. I've tested it before on a previous setup so I know the card works, and since that setup I've got another pci card (two in total) and changed motherboard/cpu/etc. I've tried all combinations in lspci -v and none of them seem to work
[18:22:49] <ler-hydra> the integrated motherboard parport seems to work though
[18:22:52] <SWPadnos> it changes from driving the motor with microsteps to driving it in full steps when the speed gets high enough that microsteps don't help any more
[18:23:05] <cradek> ler-hydra: last time you had this problem, you forgot to add parport.1.read and write to the thread
[18:23:06] <SWPadnos> it still takes microsteps in though
[18:23:13] <cradek> ler-hydra: maybe it's that again?
[18:23:21] <ler-hydra> there's a pdf with some scope shots that show the morphing
[18:23:31] <ler-hydra> cradek: hmm, I'm reuing the same config
[18:23:36] <cradek> oh ok
[18:23:51] <skinnypuppy1334> http://www.geckodrive.com/photos/How_the_G203V_gets_the_most_from_your_motor.pdf
[18:24:16] <ler-hydra> also, is there any way to see which of the three adresses are correct depending on the length (size=4,8,32)
[18:24:28] <ler-hydra> when looking at the lspci output
[18:24:31] <skinnypuppy1334> SWPandos what are you controlling 203v's with?
[18:24:43] <jepler> 8 and 4 are more likely than 32
[18:24:42] <SWPadnos> skinnypuppy1334I don't use them at all - no steppers here
[18:25:13] <ler-hydra> hmm, I have got two cards (and the integrated parport), which is a total of three but I'm only loading the first two...
[18:26:02] <fenn> is there an address conflict?
[18:26:14] <fenn> if they both want the same address
[18:26:26] <ler-hydra> no, all adresses are different
[18:26:28] <ler-hydra> all six
[18:26:53] <JymmmEMC> * JymmmEMC read that as: jepler: 8 and 4 are more than likely 32
[18:27:04] <skinnypuppy1334> SWP, what will drive them then? I've been looking on PMDX but didn't see anything mentioning 203v's other than the 131 won't drive them ...
[18:27:30] <fenn> JymmmEMC: 8*4 == 32??
[18:27:51] <SWPadnos> the 203v can probably be driven directly from a parport - it has a much lower current requirement and the disable input is isolated (step and dri are isolated on all their drives)
[18:27:58] <JymmmEMC> fenn: No, no, that's NOT what jepler said.
[18:28:07] <skinnypuppy1334> Been trying to keep up with the GF today, we're sanding wood trim throughout the house.... dusty fun
[18:28:11] <JymmmEMC> fenn: I just rad it backwards
[18:28:15] <JymmmEMC> read
[18:28:36] <fenn> p(8*4==32) = 0.7 depending on the alignment of saturn
[18:29:07] <fenn> g201's cant be driven directly from a parport?
[18:29:22] <cradek> depends who you ask
[18:29:30] <skinnypuppy1334> Straight off the Parallel port instead of needing something like PMDX 131 breakout board?
[18:29:31] <cradek> (or depends on the parport, probably)
[18:29:45] <fenn> i thought running off the parport was sorta the whole point
[18:29:52] <anoniamsu> ofcourse they can be driven off a parport.
[18:30:01] <anoniamsu> anyone who tells you otherwise is lying
[18:30:00] <skunkworks_> * skunkworks_ are driving my parker drives directly from the printer port...
[18:30:09] <anoniamsu> they are optoisolated..
[18:30:14] <skunkworks_> oops
[18:30:21] <anoniamsu> so it shouldnt be a problem
[18:30:24] <cradek> some parports are 5v, some are 3.3, and they have different current outputs
[18:30:45] <SWPadnos> the optos in the non-g203 drives all need 16 mA of current to drive the LED. many parports can't source/sink that much
[18:30:46] <anoniamsu> cradek obviously you need a parport that gives 5v which is withing the spec..
[18:30:52] <jepler> I think the current requirement is not met by some actual parports, even though ideal / "in spec" parports should have ample current
[18:30:58] <SWPadnos> the 23V only needs 2 mA, which basically any port can supply
[18:31:02] <SWPadnos> 203V
[18:31:11] <anoniamsu> wtf.. I never cared about it and it's worked for several setups..
[18:31:13] <SWPadnos> it's not the voltage, it's the voltage under load
[18:31:29] <SWPadnos> it "should" work, but doesn't always
[18:31:28] <cradek> 16 mA is a lot
[18:31:37] <SWPadnos> right
[18:31:42] <SWPadnos> it helps noise immunity though ...
[18:31:46] <skunkworks_> * skunkworks_ still hasn't taken out a printer port. tried though..
[18:31:56] <anoniamsu> I have.. once
[18:32:17] <anoniamsu> but I had some leds hooked up, for giving me irc status..
[18:32:17] <anoniamsu> :p
[18:32:24] <skunkworks_> * skunkworks_ likes talking in the third person.
[18:33:53] <ler-hydra> cradek, jepler, apparently I needed to load all three parports for it to work
[18:33:55] <ler-hydra> funny
[18:34:09] <cradek> * cradek rolls his eyes
[18:34:09] <SWPadnos> hmmm. that's not funny :)
[18:34:27] <ler-hydra> funny hmm, not funny haha
[18:34:49] <SWPadnos> can you pastebin the output of lspci and the config that works (along with the parport line that doesn't work)?
[18:34:57] <skunkworks_> * skunkworks_ wonders why ler-hydra needs 48 i/o.
[18:35:11] <ler-hydra> SWPadnos: sure
[18:35:13] <fenn> for his 36 strut oligopod
[18:35:22] <SWPadnos> it's the borgopod
[18:35:46] <skunkworks_> you will be kinsimilated
[18:37:21] <ler-hydra> http://pastebin.ca/676035
[18:38:20] <ler-hydra> skunkworks_ becuase I'm lazy and another parport is cheaper than a breakoutbox that divides IO for my pendant and limit switches
[18:39:01] <SWPadnos> now that's strange
[18:39:02] <ler-hydra> btw, was the anti-jogwheel-windup feature going to be in 2.1.x?
[18:39:24] <SWPadnos> you're using the 32-byte region for parport 3 and the 8-byte region for parport 2
[18:39:24] <cradek> almost certainly no
[18:39:42] <ler-hydra> feature-freeze was a while back?
[18:39:42] <cradek> 2.2 should be out pretty soon...
[18:39:52] <ler-hydra> SWPadnos: I'm not using parport 2 atm
[18:39:53] <skunkworks_> woo whoo
[18:39:55] <cradek> 2.1 doesn't get new features, only safe bugfixes
[18:40:06] <SWPadnos> well, s/2/1/
[18:40:22] <ler-hydra> I just used it as a placeholder to allocate IO to the second parport
[18:40:28] <ler-hydra> cradek: oops, I meant 2.2.x
[18:40:52] <cradek> oh
[18:41:10] <cradek> we haven't called for an official freeze, but I think we're all being careful not to badly break anything
[18:41:21] <cradek> I think everyone was waiting for the new board to deal with 2.2 :-)
[18:41:23] <ler-hydra> oh, ok. I see
[18:41:26] <SWPadnos> does it work if you use CC00 and D800 (along with 0378)?
[18:41:27] <ler-hydra> so it's getting there
[18:41:29] <cradek> I know I was
[18:41:59] <cradek> but unfortunately, it still seems to be my problem for some reason
[18:42:03] <SWPadnos> cradek, too bad you didn't dodge that one :)
[18:42:06] <SWPadnos> heh
[18:42:31] <ler-hydra> SWPadnos: yeah, it works with that
[18:42:38] <SWPadnos> ok, that's a good sign
[18:43:02] <SWPadnos> and if you take out 0378, it doesn't work with just CC00 and D800?
[18:43:00] <skunkworks_> * skunkworks_ wonders is cradek was hoping not to be re-elected ;)
[18:44:00] <cradek> no, I was just joking. I could have declined the nomination if I wanted out.
[18:44:18] <cradek> but, I may not be the release manager for the 2.2 series, don't know yet
[18:44:49] <skunkworks_> * skunkworks_ thinks jepler would have hacked into cradek mail server anyways and sent a nomination acceptence
[18:45:29] <cradek> nah, I use bsd. His powers are nullified there
[18:45:35] <cradek> and backspace works
[18:45:42] <cradek> * cradek snickers
[18:48:18] <skunkworks_> SWPadnos: can you see this? http://www.cnczone.com/forums/attachment.php?attachmentid=42886&d=1188494073
[18:49:06] <ler-hydra> SWPadnos: yeah, that works
[18:50:10] <SWPadnos> ler-hydra, oh good. does this mean that it's working as you want - the two PCI parports only?
[18:50:27] <ler-hydra> SWPadnos: oh, no, I want all three
[18:50:27] <SWPadnos> skunkworks_, yes, I can see that
[18:50:31] <skunkworks_> SWPadnos: http://www.cnczone.com/forums/showthread.php?t=14477&page=47
[18:50:40] <ler-hydra> 2 pci parports and the integrated
[18:50:53] <fenn> skunkworks_: what thread is that from?
[18:50:59] <SWPadnos> ler-hydra, ok. so it's working either way, and you can do what you want now? :)
[18:51:03] <ler-hydra> I couldn't get the pci ones to work without defining both of them
[18:51:09] <fenn> looks like mariss' current limit circuit with some diodes stuck on it
[18:51:14] <ler-hydra> SWPadnos: it's woring great now
[18:51:30] <ler-hydra> *working
[18:51:52] <skunkworks_> fenn: the last post of this thread http://www.cnczone.com/forums/showthread.php?t=14477&page=1
[18:52:34] <skunkworks_> SWPadnos: what do you think that circit would do between the supply and 1900uf cap my h-bridge.
[18:53:05] <SWPadnos> so - cap connected to the bridge pin, or the supply pin?
[18:54:07] <ler-hydra> how are feedhold button implemented in hardware, one button for feedhold and one for resume?
[18:54:29] <ler-hydra> are program start and resume one and the same?
[18:55:02] <fenn> emc likes separate buttons and indicators
[18:55:03] <skunkworks_> the cap is mounted directly to the circuit board across the supply lines. (low inductive loop)
[18:55:41] <SWPadnos> well, if Mariss says "this curcuit does XXX", then for the most part I believe him :)
[18:55:45] <SWPadnos> circuit
[18:56:36] <skunkworks_> I am more worred about the capacitance 'after' the current sense resister.. Not a problem (thinking recharging of the cap tripping the current sense circuit)
[18:57:35] <SWPadnos> if the cap is connected to the wire marked "From Supply" in that drawing, then it's before the sense circuit, so charging the cap won't be detected (unless it's charging from back EMF)
[18:57:52] <skunkworks_> it would be after
[18:57:58] <skunkworks_> to bridge
[18:58:29] <SWPadnos> then it won't work as you want, since the cap is intended to supply the current spikes from PWM switching
[18:58:51] <skunkworks_> ok - that is what I was hoping would not be a problem ;)
[18:58:56] <SWPadnos> so as you pointed out, you'd be measuring the transformer charging the cap, not the cap/bridge supplying the motor
[18:59:08] <lewin1> lewin1 is now known as lewing
[18:59:53] <fenn> man 47 pages on that ac drive thread.. this is why i hate web forums
[19:00:17] <skyfox00> To whom do I direct questions concerning pluto_servo issues?
[19:00:31] <cradek> skyfox00: the entire channel!
[19:00:32] <fenn> if they had been using a wiki it would all be laid out pro's and con's with datasheets attached etc, but instead you have to dig through 47 pages of banter in order to find anything, and as a consequence nothing gets done
[19:02:39] <SWPadnos> kind of like IRC
[19:03:17] <jepler> wikis can be every bit as chatty if there is not a strong ethic/style to the contrary
[19:03:25] <fenn> if there's no overflow like irc
[19:03:28] <jepler> heck, some of emc's documentation is way too chatty
[19:03:38] <SWPadnos> wikis are also only as correct as the last editor
[19:03:44] <fenn> hey man, everyone loves tinkertoys!
[19:04:06] <SWPadnos> for some reason, the word "tinkertoys" first registered as "monkeys" for me
[19:04:16] <fenn> everyone loves monkeys!
[19:04:25] <fenn> * fenn flings poo at the channel
[19:04:32] <SWPadnos> maybe I should replace these fuzzy CRTs with LCDs
[19:04:44] <fenn> i thought you had 20" star-trek monitors
[19:04:46] <jepler> skyfox00: in case you are not sure, cradek is serious when he says "the entire channel". On IRC, the best way to get help with your question is to simply ask it, not ask whether you may ask it or who you should ask about it.
[19:05:06] <SWPadnos> fenn, they're 24", thank you
[19:05:31] <SWPadnos> but those aren't in use on this computer at the moment, and I'd have to clean my desk (and the stacks of stuff on top of the monitors) to use them
[19:05:31] <cradek> yes, I was serious, sorry if that wasn't clear
[19:05:49] <jepler> what are the advantages of high-side current sense? can someone point me at an authoritative-sounding wiki page on the subject?
[19:05:50] <SWPadnos> LCDs have the (dis?)advantage of not acting like shelves
[19:06:01] <fenn> not if you build shelves into them
[19:06:06] <cradek> SWPadnos: where would dogbert sit?
[19:06:10] <SWPadnos> or mount them on the wall
[19:06:19] <skyfox00> The other day I got a Pluto-P board; I dont seem to be able to get emc2 to load the firmware though... (in windboze, fpgaconf.exe from knjn.com loads the ledblink.rbf fine)
[19:06:52] <cradek> is your parport in EPP mode in the system bios?
[19:08:43] <skyfox00> first I tryed it in ECP mode and NOTHING happend, so I changed it to EPP mode and now the 'communications-error' counter counts up at a constant fast rate... (the behaviore is the same if the board is not even connected to the parport)
[19:09:11] <jepler> does the LED stay dim?
[19:09:43] <skyfox00> the LED runs at a constant brightness all the time, even after loading emc2...
[19:10:28] <skyfox00> when I try to load the pluto_servo firmware using the windows fpgaconf.exe, the LED goes out after about 3 seconds...
[19:11:55] <jepler> I think you are right to diagnose that it is not properly being programmed in linux.
[19:13:02] <skyfox00> does the pluto_servo driver use EPP mode to program or does it use the bit-bang method?
[19:13:05] <jepler> next you should check that ioaddr is correct (the default, 0x378, is correct for many but not all machines), and try with ioaddr_hi=-1 and/or with epp_wide=0
[19:13:15] <jepler> pluto_servo uses bit-bang to program and then switches to EPP mode after that
[19:13:56] <skyfox00> I tryed all those options... seemd to make no difference.
[19:14:35] <cradek> what emc version is this?
[19:15:53] <skyfox00> emc2 version 2.1.6, rtai version 3.5, linux version 2.6.17.13, distro: slackware 11
[19:17:09] <jepler> does hal_parport work on your port?
[19:17:20] <skyfox00> one thing I did not try was epp_soft (or whatever it was called, I remember seeing it in the pluto_servo driver)
[19:17:36] <jepler> epp_soft doesn't work..
[19:18:03] <gene> Hi guys, got nother math prrob I think. Can someone take a look at <http://www.pastebin.ca/676077>
[19:18:15] <jepler> I tried to write it following the linux kernel's soft epp implemention but never got it working/finished
[19:18:36] <cradek> gene: what line?
[19:18:51] <gene> and tell me why the hole jumps from 1.74" to 2.05" when changing #36 by .0001"
[19:19:39] <cradek> oh man
[19:20:08] <skyfox00> hal_parport is a kernel module.... how do I test it? (i have a file named pluto.hal that blinks the LED, should I put 'loadrt hal_parport' at the top and run it?)
[19:20:24] <cradek> wait pluto.hal does blink the led?
[19:20:38] <gene> ahh, s/b 1.84 to 2.05 1.84 for #36=0.9223 and 2.05 when #36=0.9224
[19:20:37] <skyfox00> its suposed to, does not work...
[19:21:24] <jepler> skyfox00: hal_parport is a HAL hardware driver that gives individual control over each input and output pin in the parallel port
[19:22:03] <jepler> skyfox00: many people use it to control step+direction machines, but you could use it with a logic probe or some other method to determine whether the parallel port is working at all in your linux+emc2 build
[19:22:23] <Nighthawk> good evening folks
[19:22:27] <gene> Chris: I'm trying to mill recesses in a block of alu to hold an axial load ball bearing.
[19:22:47] <jepler> skyfox00: you would "test" it by typing in some commands in halcmd (loadrt hal_parport, loadrt threads, addf, start, setp)
[19:23:19] <jepler> skyfox00: or you could load the stepper_inch sample configuration, run one of the programs, and it would create lots of pulses on the port for you to see with a logic probe
[19:24:12] <cradek> skyfox00: your system is not loading the kernel parport_pc module is it?
[19:24:25] <Nighthawk> can I ask to someone linuxcnc guru a simple question?
[19:24:41] <cradek> Nighthawk: you don't have to ask to ask, just ask
[19:25:03] <SWPadnos> gene, can't tell you what's going wrong, but you may want to add a line after 38 that checks to be sure #37 hasn't gone below #31
[19:25:16] <skyfox00> *GRIN*.... yeah parport_pc, parport, lp are all loaded...
[19:25:26] <cradek> ah, unload parport_pc and try again
[19:25:58] <SWPadnos> and stop cups if it's running :)
[19:26:09] <Nighthawk> ok cradek, :)
[19:26:10] <jepler> gene: computer arithmetic is not done in decimal, so sometimes math that looks like it should be exact is not. For instance, ".1 + .1 + ... + .1" (total of ten times) is not always equal to 1.0.
[19:26:39] <gene> using what ge, gt, le, lt ? I've stared at ths for 2 hours now. How many places does emc use?
[19:26:43] <Dallur> to be more exact decimal != floating point
[19:26:54] <jepler> gene: just like trying to add 1/3 + 1/3 + 1/3 by writing everything in decimal, you get .33 + .33 + .33 = .99
[19:27:16] <gene> hummm
[19:27:20] <Nighthawk> I'd like to know if it possible to obtain the spindle rpm via a simple step/direction input
[19:27:25] <Nighthawk> no quadrature encoder
[19:28:21] <SWPadnos> Nighthawk, sure. I think there's a counter HAL module, there's a mux, and there's a scale block. the only question is whether there's a way of converting from counter output to a float (if it doesn't output float)
[19:28:33] <jepler> gene: computer arithmetic is not done in decimal, so asking "how many places does emc use" is the wrong question. In some places it uses 24 bits and in other places it uses 53 bits
[19:28:45] <jepler> SWPadnos: counter has a floating-point output of both position and velocity
[19:29:14] <SWPadnos> Nighthawk, actually, it's not as simple as I thought, because you want to sample the direction line at the same time as you count, so nevermind :)
[19:29:21] <SWPadnos> jepler, does it have an up/down input?
[19:29:28] <jepler> http://linuxcnc.org/docs/2.1/html/man/man9/counter.9.html -- in emc2.1 it is usually desirable to put the .velocity output of counter through a 'lowpass' filter to give a sort of averaged speed over many milliseconds
[19:29:49] <jepler> SWPadnos: no, counter has phase-A and phase-Z; encoder has phase-A, -B and Z
[19:30:00] <jepler> I don't think any of them take up/down or step/dir
[19:30:31] <cradek> counter only counts up
[19:30:51] <jepler> I don't know what kind of spindle has a step/direction output!
[19:30:53] <Dallur> gene: if you absalutely need to compare two floating point calculated values you can do so reliably by counting the number of decimals and checking if the values are within the tolerance
[19:30:55] <fenn> "spindle" makes me think it only goes one direction mostly
[19:30:57] <jepler> new one on me
[19:31:03] <Nighthawk> the direction is fixed
[19:31:11] <gene> Chris, those #37 values are the depth, not the radii of the hole anyway
[19:31:16] <SWPadnos> oh, if the direction is fixed then just use counter
[19:31:16] <Nighthawk> the "encoder" is on a spindle
[19:31:17] <cradek> what kind of sensor is it?
[19:31:28] <cradek> just a disc with slots in it or something?
[19:31:40] <SWPadnos> the trouble comes in when you need to track both directions
[19:31:47] <Nighthawk> yes, exactly, cradek
[19:31:54] <Nighthawk> no
[19:32:02] <cradek> ok, that's what the counter module is for, it's just like a one-channel encoder
[19:32:02] <Nighthawk> I need to know the RPM
[19:32:04] <jepler> gene: one way to do it is to start with the minimum diameter, then increase it each time by the increment as long as it is strictly less than the final value. Then do one pass at the final desired value
[19:32:27] <jepler> "strictly less" is LT
[19:32:57] <gene> min dia is zero, increment is calculated
[19:33:11] <gene> s/b straight division
[19:33:12] <fenn> gene you should use my spiral script :) http://fenn.dyndns.org/pub/irc/lengthspiral.py
[19:33:24] <Nighthawk> can someone pastebin a simple hal configuration
[19:33:41] <Nighthawk> the parallel port pin is 15
[19:34:20] <skyfox00> well, I unloaded all parport related modules and running the pluto.hal file has the same result as before...
[19:35:00] <jepler> Nighthawk: http://cvs.linuxcnc.org/cvs/emc2/configs/nist-lathe/nist-lathe.hal?rev=1.16;content-type=text%2Fplain read down to "beginning of thread-related stuff"
[19:35:24] <jepler> Nighthawk: in this case pin 11 is the pin that sees a square wave when the spindle is turning
[19:35:51] <jepler> Nighthawk: pin 12 not used, and pin 13 is the one-pulse-per-revolution signal ("index pulse")
[19:36:06] <fenn> hmm i could add a depth of pass parameter i guess
[19:36:07] <gene> Fenn, unforch python is swahili to me
[19:36:23] <fenn> er, width of cut i mean
[19:36:23] <jepler> you'll also need to look above for the "loadrt counter" and "addf" lines that are related
[19:36:39] <fenn> gene: that's ok i'm sure you'll do better sticking to your own code
[19:37:05] <fenn> gene: g-code is like egyptian hieroglyphics to me
[19:37:43] <jepler> gene: another way to do it is to have an *integer* count from 0 or 1 up to the total number of passes (comparisons with integers below about 4 billion are always reliable), and then find the diameter or depth with a multiplication by the per pass increment you determined earlier
[19:38:01] <jepler> bbl
[19:38:36] <fenn> depth of cut and number of passes dont always divide evenly
[19:38:49] <fenn> by the radius
[19:39:13] <SWPadnos> skyfox00, did you run through the various combinations of ioaddr_hi and epp_wide after removint parport, lp, and parport_pc?
[19:42:15] <skyfox00> no, not yet, but I just tryied to get the emc2 servo_inch config to work.... so far, unable to detect anything with the oscilloscope...
[19:42:52] <SWPadnos> hmmm. is your parport at some strange address?
[19:43:51] <SWPadnos> (that's stepper_inch, isn't it?)
[19:47:50] <skyfox00> ok, I ran the stepper_inch and there is a constant +5v on all parport data pins...
[19:48:17] <SWPadnos> while jogging/running a g-code program?
[19:48:23] <SWPadnos> (just making sure :) )
[19:49:02] <skyfox00> the parport is a at 0x378(yes, while running the example emc2 gcode splash)
[19:49:41] <SWPadnos> ok :)
[19:50:09] <skyfox00> hmmm, that parport data pins are high even when emc2 is not running...
[19:50:21] <SWPadnos> right - EMC isn't seeing/working the port
[19:50:54] <SWPadnos> yo uhave only one parport in this PC?
[19:52:04] <skyfox00> yes, only 1 parport... and it works... I wrote a program a while back that usess libieee1284 for reading/writeing all the pins, etc and it worked fine....
[19:52:29] <SWPadnos> that's ECP isn't it?
[19:53:57] <SWPadnos> I wonder if it would help to load probe_parport early in the .hal file?
[19:54:40] <Nighthawk> ok folks, I'll study the code you gave to me
[19:54:45] <Nighthawk> many thanx to all!
[19:54:56] <SWPadnos> stick "loadrt probe_parport" just above the "loadrt hal_parport ..." line
[19:55:10] <skyfox00> I also wrote a program that did bi-directional (full protocoll, 8 bit wide) communications with a pic chip
[19:55:26] <skyfox00> ok, the logic high's on all the data pins is just the internal pullups...
[19:55:30] <SWPadnos> right
[19:56:40] <skyfox00> ok, so i need to put probe_parport into the stepper_inch file? or the pluto.hal file that is saposed to blink the LED..
[19:57:00] <SWPadnos> try that in stepper_inch first
[19:57:08] <skyfox00> ok....
[19:57:15] <SWPadnos> I suspect that if stepper_* doesn't work, there's no way pluto will
[19:58:22] <ler-hydra> hmm, right now I have a button that starts the current program (halui.program.run), I'd like to add a button that pauses/feedholds the current program, which is resumed by pressing the existing button, is this possible?
[20:00:12] <skyfox00> ok, that runs ok, what do I look for in dmesg?
[20:00:49] <SWPadnos> so stepper_inch now outputs to the port?
[20:01:23] <skyfox00> oh, emc2 loaded without bombing out... let me check for pulses on pins...
[20:03:00] <Nighthawk> jepler: In this way it'll returns on motion.spindle-revs the revolution per second or a incremental count?
[20:03:28] <skyfox00> still all logic high's on the parport pins...
[20:03:50] <SWPadnos> ok. it may be time to fiddle with BIOS settings. you may want to try setting it to SPP
[20:05:28] <skyfox00> doesnt Pluto_servo reqire EPP though?
[20:05:53] <SWPadnos> I don't think so
[20:06:09] <SWPadnos> but I'm not sure. jepler wrote it and knows far more
[20:07:06] <skyfox00> what other names does SPP go by?(output only, etc?)
[20:07:38] <jepler> yes, EPP is required by pluto_servo
[20:07:55] <JymmmEMC> Bi directional isn't it?
[20:07:58] <jepler> another thing to try is loadrt probe_parport before loadrt hal_parport or loadrt pluto_servo
[20:08:00] <SWPadnos> ok- nevermine me :)
[20:08:07] <SWPadnos> tried that
[20:08:25] <jepler> oh sorry, I didn't read back far enough
[20:08:31] <SWPadnos> np
[20:12:10] <skyfox00> ok, I just tryied loading probe_parport right before loading pluto_servo and I cant tell if it put anything into dmesg or not...
[20:12:47] <jepler> [2096062.508088] parport: PnPBIOS parport detected, io_lo=378 io_hi=778
[20:13:04] <jepler> it prints something like this ^^^ on a system where it is useful
[20:13:32] <ler-hydra> what's the difference between feedhold and pause?
[20:13:48] <skyfox00> well, no reference to parport anywhere...
[20:14:04] <jepler> ler-hydra: pause works by line of gcode, feedhold works at any time
[20:14:06] <cradek> ler-hydra: a big difference is feedhold will hold mdi and jogs
[20:14:10] <jepler> .. or is that step?
[20:14:20] <ler-hydra> oh, I see
[20:14:23] <cradek> pause will stop in the middle of a gcode block
[20:14:43] <ler-hydra> uh, happen to remeber the halui code for feedhold?
[20:14:55] <cradek> halcmd show *feedhold*
[20:15:06] <ler-hydra> oh
[20:15:08] <ler-hydra> nice
[20:15:20] <cradek> err show pin
[20:15:22] <cradek> something like that
[20:15:55] <cradek> 32770 float IN 1 motion.adaptive-feed
[20:15:54] <cradek> 32770 bit IN FALSE motion.feed-hold
[20:16:05] <ler-hydra> hmm I didn't get any lines
[20:16:10] <CIA-24> 03jepler 07TRUNK * 10emc2/src/hal/halmodule.cc: fix for python2.5 + 64-bit machines from Chris Lesiak
[20:16:21] <ler-hydra> maybe it only shows pins loaded?
[20:16:40] <cradek> % halcmd show pin '*feed*'
[20:16:44] <cradek> 32770 bit IN FALSE motion.feed-hold
[20:16:46] <cradek> ...
[20:16:59] <ler-hydra> oh, I see
[20:17:12] <ler-hydra> how would I most easily bind to it in hal?
[20:17:38] <ler-hydra> ie a button for feedhold and a button for resume
[20:17:58] <skyfox00> I also tried running 'halrun -I' and the typing 'loadrt probe_parport' and it did nothing...
[20:18:55] <cradek> ler-hydra: are you using ladder yet?
[20:19:02] <ler-hydra> cradek: nope
[20:19:04] <cradek> I posted *exactly* the ladder you need for that to the list
[20:19:09] <jepler> skyfox00: these messages we are talking about appear in the output of the 'dmesg' command, or in /var/log/kern.log (on ubuntu; slackware may have a different name)
[20:19:20] <jepler> skyfox00: is that where you are looking for the messgae?
[20:19:20] <ler-hydra> oh, I was hoping not to need ladder for this machine
[20:19:43] <skyfox00> yeah, i was looking in dmesg for anything related to parport.... nothing...
[20:20:04] <jepler> skyfox00: I expect it to either print the "PnPBIOS parport detected" message, or "ERROR: pnp_register_driver() -> <number>" in the case that no PnPBIOS parport was detected.
[20:20:28] <cradek> ler-hydra: maybe you want an RS flipflop module then
[20:20:45] <ler-hydra> hmm that sounds reasonable
[20:21:05] <skyfox00> nothing in syslog or messages either...
[20:21:39] <cradek> ler-hydra: I bet you could use "updown"
[20:21:43] <JymmmEMC> LSD Converter software!
[20:21:56] <ler-hydra> cradek: is there data on it somewhere?
[20:22:00] <cradek> max 1, min 0, no wrap, yes clamp, etc
[20:22:05] <cradek> man updown
[20:22:28] <Nighthawk> jepler, I don't understand if linksp spindle-pos => motion.spindle-revs outputs an incremental counter or revolutions per second.
[20:22:31] <Nighthawk> can you help me
[20:22:35] <ler-hydra> surely it's not a standalone binary?
[20:22:43] <ler-hydra> with it's own man page?
[20:22:44] <cradek> ler-hydra: it's a hal module
[20:23:44] <jepler> cradek: output of updown is s32 so it can't be linked to feed-hold (type 'bit')
[20:24:09] <cradek> conv_s32_bit
[20:24:31] <Nighthawk> I'm back
[20:24:33] <jepler> Nighthawk: spindle-pos is connected to counter.0.position, so it counts up as the spindle turns
[20:24:44] <jepler> Nighthawk: counter.0.velocity is spindle velocity in revolutions per second
[20:24:54] <jepler> Nighthawk: you would want to create a new signal that is connected to counter.0.velocity.
[20:25:06] <skyfox00> ok, I am going to tinker with the BIOS, be back in a bit, nibble or byte, depending on how long it takes....
[20:26:15] <Nighthawk> perfect jepler. so with counter.0.velocity I'll got the RPS. scale it to 60 and I'll got RPM that I can visualize with PyVCP, is it right?
[20:27:05] <jepler> Nighthawk: yes. You may also want to use a "lowpass" to smooth the value
[20:27:38] <Nighthawk> I'll try it, i don't remeber how use the scale command. Can you remeber me the syntax
[20:27:39] <Nighthawk> ?
[20:28:06] <jepler> Nighthawk: "man counter" in the terminal window for information about the counter component. "man scale" and "man lowpass" for those components
[20:28:32] <jepler> Nighthawk: if you don't get the right manual page, add 9: "man 9 scale" etc
[20:28:34] <cradek> ler-hydra: there's also a toggle component if you want to use one button
[20:28:54] <Nighthawk> many many many thanx jepler
[20:29:10] <jepler> Nighthawk: you'd hook counter.0.velocity to scale.0.in, set scale.0.gain to 60, hook scale.0.out to lowpass.0.in, and hook lowpass.0.out to your pyvcp widget
[20:29:32] <skunkworks_> oops
[20:29:34] <skunkworks_> that was bad
[20:29:45] <cradek> ouch
[20:29:50] <jepler> Nighthawk: then change lowpass.0.gain until you find a compromise you like between quickly tracking a changing RPM, and not changing too much while RPM is approximately the same
[20:30:31] <jepler> Nighthawk: and remember to 'addf' all the right things
[20:30:34] <ler-hydra> cradek: no, I've got two buttons
[20:30:44] <skyfox00> what mode does a regular stepper config operate in?(bi-directional?)
[20:30:47] <ler-hydra> where's the info about hal components?
[20:32:06] <Nighthawk> no words. Thanx a lot. another question. Do you think is better to scale the component via scale command or scale it via the counter.o.position-scale?
[20:32:12] <jepler> skyfox00: the regular stepper configs are "SPP" -- data port always in output mode, so on
[20:33:45] <jepler> Nighthawk: if you are on a lathe and want to do threading and feed-per-revolution, you have to set counter.0.position-scale to the number of pulses per revolution, because .position has to be revolutions and .velocity has to be revolutions per second
[20:34:09] <jepler> Nighthawk: if you're on a mill and don't want to use those gcodes ever, then you can set position-scale so that .velocity comes out in revolutions per minute.
[20:34:47] <Nighthawk> ok.
[20:34:55] <skyfox00> well, the BIOS help says there are 4 options, "bi-directional, EPP, ECP, Output Only" but I cant see where to set it to output only...
[20:34:57] <Nighthawk> I understand.
[20:36:40] <jepler> skyfox00: I would expect any of the modes to work, because they all are supposed to retain compatability with the original parallel port
[20:36:49] <jepler> skyfox00: so since it doesn't, I'm not sure what to suggest except "try them all"
[20:42:51] <ler-hydra> bbl
[20:47:40] <skyfox00> ok, I just tried stepper_inch with the bois set to ECP and it works, nice pulses on the scope...
[20:48:30] <skyfox00> if I wrote a function/library that did software epp, who would I talk to about implimenting it?
[20:49:32] <skyfox00> it would use libieee1284 in ECP mode.
[20:49:45] <jepler> skyfox00: subscribe to emc-developers mailing list and e-mail a patch against the CVS TRUNK version of emc to the list.
[20:50:10] <SWPadnos> skyfox00, can you use libieee1284 in a kernel module?
[20:50:31] <jepler> probably not
[20:50:35] <skyfox00> I have no idea...
[20:50:45] <SWPadnos> I'm thinking probably not as well
[20:53:38] <skyfox00> well, all the same pins can be accessed with inb and outb, right?
[20:54:18] <SWPadnos> yes, that's what hal_parport does
[20:56:35] <skyfox00> well, I was (mis)using libieee1284 kinda like inb/outb anyway...
[20:57:06] <SWPadnos> it may be interesting to look at their initialization/detection code. that could be very useful for EMC
[20:59:18] <jepler> looks like libieee1284 builds on an existing OS driver, so it does things like "look through /dev for likely entries"; this doesn't help with emc, where things have to be written from the inb()/outb() level
[21:00:03] <skyfox00> what part of libieee1284 would prevent it from being used in a module?(dynamic linking?)
[21:00:43] <SWPadnos> it's a user library - that doesn't lend itself well to kernel use
[21:01:08] <jepler> emc "real time components" are special kernel modules which can only use a few specific functions (the rtapi_* functions, inb, outb) in the parts that have to be run with reliable timing
[21:01:22] <SWPadnos> you can't open device nodes in the kernel, for example (not by /dev/whatever anyway)
[21:01:27] <SWPadnos> (AFAIK)
[21:01:45] <jepler> even if you *could* open a /dev/whatever, you could not do any actions to it from realtime code
[21:02:31] <skyfox00> what about implimenting some of the libieee1284 functions entirely inside of a module?(I am going to look at the source for ideas)
[21:05:02] <jepler> it looks like one of the interface methods of libieee1284 may be direct port i/o with inb and outb; it might be possible to cut out just this part and use it
[21:05:18] <skyfox00> thats what I was thinking...
[21:05:22] <jepler> but that's from a 2-second glance at their CVS source, the trenches view may be different
[21:05:49] <SWPadnos> since that's what EMC does already, I'm not sure it would be useful. if they have better detection and setup code, that would be very useful
[21:05:53] <roltek> in ubuntu how do i get to be root user to change files in etc/apt/sources.list
[21:05:59] <jepler> In pluto_servo.comp (or pluto_common.h in TRUNK), the EPP cycles are in the functions ADDR(), READ() and WRITE()
[21:06:03] <SWPadnos> roltek, use sudo
[21:06:13] <cradek> To run a command as administrator (user "root"), use "sudo <command>".
[21:06:12] <cradek> See "man sudo_root" for details.
[21:06:14] <SWPadnos> do you want to edit them by hand or use synaptic?
[21:06:20] <cradek> ^^ I get this message in every terminal I open
[21:06:26] <roltek> by hand
[21:06:41] <jepler> roltek: I found this page https://help.ubuntu.com/community/RootSudo as the first hit when I googled for: ubuntu root user
[21:06:57] <roltek> thanks guys
[21:07:48] <fenn> skyfox00: ieee1284 is EPP, not ECP. it wont work in ECP mode
[21:08:33] <fenn> er.. /me double checks that
[21:08:49] <skyfox00> my parport is in ecp mode right now and libieee1284 programs run fine
[21:08:52] <SWPadnos> I think 1284 covers ECP, and maybe EPP as well
[21:09:07] <jepler> skyfox00: besides ADDR, READ and WRITE the other EPP-related operations are in the setup function where an attempt is made to switch the port to SPP-mode to program the firmare, and into EPP-mode for the remainder of the time (function pluto_setup on TRUNK); in pluto_clear_error_register (on TRUNK); and in FUNCTION(read) to check the EPP error register
[21:09:10] <skyfox00> it might do EPP soft to, not sure...
[21:09:40] <jepler> skyfox00: so basically those things are what you would need to implement for a "soft EPP mode"
[21:09:54] <jepler> skyfox00: the linux kernel driver also has soft EPP mode, you may find that studying it is useful
[21:09:59] <jepler> bbl
[21:11:04] <skyfox00> i am a little slow understanding emc2/kernel modules, etc...
[21:11:53] <skyfox00> (in other words, I dont want modify any modules or emc2 yet...)
[21:12:18] <fenn> you could make a userspace module, but i'm not sure that would be of much use
[21:12:25] <fenn> a userspace hal module
[21:12:33] <fenn> maybe i should shut up
[21:12:52] <skyfox00> no, thast ok...
[21:14:34] <skyfox00> i should find a howto that tells how to make a kernel module that juts puts a message into dmesg...
[21:15:12] <skyfox00> typeing with 1 hand doesnt work very well...
[21:15:23] <fenn> i was wrong about epp/ecp. ecp allows you to do epp mode, and can also go both directions
[21:15:57] <fenn> skyfox00: you dont want to write a normal kernel module, you want a realtime module which is quite different
[21:16:17] <SWPadnos> ECP basically adds DMA support to EPP
[21:17:28] <skyfox00> i just wanted to see what would happen when i tried to use libieee1284 in a kernel module...
[21:17:44] <fenn> skyfox you should look at emc2/src/hal/drivers/hal_skeleton.c if you havent yet
[21:17:51] <SWPadnos> at best, it won't compile
[21:17:54] <SWPadnos> next best is it won't load
[21:17:57] <skyfox00> will look...
[21:18:07] <SWPadnos> then you start getting into the really bad things - like hard lockups :)
[21:18:47] <fenn> skyfox00: then when you're done with that, look at the stuff in src/hal/components to see how much easier it is
[21:21:02] <skyfox00> its all greek to me i'm afraid...
[21:21:14] <fenn> its surprisingly easy to lock up realtime code
[21:21:24] <fenn> linux spoils you
[21:22:06] <skinnypuppy1334_> If it weren't for mastercam I would have NO use for windows
[21:22:12] <skyfox00> well, I was hopeing that I could just write an EPP-soft set of functions and get someone else to impliment it ;)
[21:22:56] <skyfox00> the only time I use windbloze is when I need somthing to mock...
[21:23:58] <skinnypuppy1334_> And just to think once upon a time I studied for an MCSE ... bangs head on concrete
[21:25:00] <fenn> uh. does pluto_common.h have an epp write function?
[21:25:10] <fenn> and a read function
[21:25:27] <skyfox00> I actualy did a realtime program... It was a scanning cammera that connected to the parport and got its critical timing from a pic processor...
[21:25:32] <fenn> so, why dont you just use that stuff?
[21:26:16] <fenn> i'm feeling kinda stupid today. what's the problem again?
[21:26:38] <skyfox00> well, my origanal problem is, I cant get pluto_servo working...
[21:26:51] <SWPadnos> the pluto doesn't work with Linux/EMC, but it does in Windows on the same computer
[21:27:01] <SWPadnos> (is that a fair summary?)
[21:27:05] <skyfox00> (the parport dies when I put the BIOS into EPP mode...)
[21:27:14] <fenn> ok, what does this have to do with writing a custom hal module?
[21:27:42] <skyfox00> um, the computer that pluto works with is a 166 mhz laptop with win98
[21:27:53] <SWPadnos> it's not the same computer?
[21:28:30] <skyfox00> the other(linux+emc2) computer is a 1.8ghz desktop...
[21:28:46] <SWPadnos> ok. I thought they were the same computer
[21:28:51] <skyfox00> it was just to confirm that the pluto was not ZAPT
[21:28:57] <SWPadnos> that tells me that you need to find the BIOS settings that work on the faster computer
[21:29:15] <SWPadnos> also, make sure you're using the correct port address
[21:29:25] <fenn> int ioaddr = 0x378;
[21:29:25] <SWPadnos> if you have a printer, try printing something
[21:29:38] <fenn> you may need to change that line in pluto_common.h
[21:29:48] <SWPadnos> no - that's just the default
[21:29:56] <fenn> ok
[21:30:06] <SWPadnos> you override it on the loadrt line: loadrt pluto_servo ioaddr=0xaaaa
[21:30:07] <skyfox00> the windows FPGAconf.exe program was using printer mode, what ever that is(not EPP, the 166mhz laptop does not suport it)
[21:30:20] <fenn> i havent really looked at pluto at all yet
[21:31:01] <skyfox00> the printer port works in ECP mode fine, I have a program that I can tell it to write 8 bits and I test them with the scope...
[21:31:34] <fenn> what's the address of the port?
[21:31:39] <skyfox00> 0x378
[21:32:10] <fenn> is the port in use by another kernel module? what's lsmod | grep parport say
[21:32:25] <skyfox00> oh, useing the stepper_inch config works well with the port in ECP mode
[21:32:57] <skyfox00> um,(nagging question in back of head) let me try somthing...
[21:33:14] <SWPadnos> I thought you said the port pins didn't change when you use stepper_inch?
[21:33:39] <skyfox00> um, I unloaded all other parport modules (sheepish grin)
[21:34:17] <fenn> i wish i knew how to search the scrollback buffer in irssi
[21:34:59] <SWPadnos> err - ok. so after using stepper_inch (and having it work), does pluto_servo work?
[21:42:13] <skyfox00> well, nothings working now...
[21:47:15] <skyfox00> ok, Fresh reboot, remove all parport modules, run emc(stepper_inch): nice pulses on the scope.(BIOS set to ECP on 0x378, irq 7)
[21:47:32] <skyfox00> now what?
[21:47:50] <SWPadnos> exit from EMC and try running pluto_servo
[21:48:05] <SWPadnos> with the pluto attached, of course: :)
[21:48:26] <skyfox00> run 'halrun -I' and type 'loadrt pluto_servo'?
[21:48:55] <SWPadnos> err - I dunno. you could try running emc and load the pluto_servo config
[21:49:21] <fenn> * fenn wonders what the expected output is
[21:49:23] <SWPadnos> or halrun. I'm not sure what that leaves you with though
[21:49:40] <fenn> hello phil
[21:49:52] <pminmo> Hello
[21:50:21] <pminmo> How can I get a fact changed on the wiki?
[21:50:44] <fenn> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?BasicSteps
[21:51:13] <SWPadnos> you can't change the facts, only the description of them ;)
[21:51:47] <fenn> swp manifest your positive thinking!
[21:52:18] <pminmo> I was just trying to clarify I have pdf's available for boards, but don't give away eagle files like the Wiki says.
[21:52:34] <SWPadnos> ok. that sounds quit ereasonable
[21:52:51] <SWPadnos> it's a wiki, so people are supposed to participate by correcting errors :)
[21:53:16] <pminmo> That was my origiginal question
[21:53:56] <SWPadnos> yep - just joking around a little. if you follow(ed) fenn's link, you'll see how to do it
[21:54:09] <skyfox00> ok, the lathe-pluto config loads without any errors and the hal meter shows pluto-servo.communication-error to be zero...
[21:54:30] <skunkworks> is the led off?
[21:55:07] <skyfox00> the led is on about half way, never changed when emc loaded...
[21:56:08] <skyfox00> which pins does the pluto get programed with?
[21:56:31] <SWPadnos> that's a jepler or knjn question
[21:56:55] <skyfox00> ok
[21:58:28] <pminmo> Ok, I give where is the edit tab/link on the EMC2 supported harware page ?
[21:58:32] <fenn> is it just me or is there no way to specify a single line-break in groff?
[21:58:39] <fenn> pminmo: it's at the bottom
[21:59:01] <fenn> or, it should be there if you did everything correctly. i can fix it for you if that's easier
[21:59:37] <pminmo> says this page is read only. I think I'm logged in
[21:59:53] <fenn> did you put 'emc' in the administrator password?
[22:00:04] <pminmo> nope
[22:02:13] <pminmo> got it, thanks
[22:02:31] <jepler> hi pminmo. Is it a change in policy that you don't give eagle brd files? I could have sworn that when cradek milled his l297/8 boards he used the eagle files as his starting point.
[22:03:24] <pminmo> I did some time back. It just got to be a hassle, some guys were jerks.
[22:03:41] <skyfox00> I can connect the scope to the different pins of the pluto and when the driver programs it the wave forms show up, but after that, nothing shows up...
[22:04:21] <jepler> pminmo: that's a real pity. eagle files make a good basis for conversion to gcode for milling the boards, and also a basis for modification and improvement.
[22:05:35] <pminmo> I know, but by the same token. I'm pretty willing to accomdate changes and give somebody the result.
[22:06:09] <fenn> is it because you can't send a .pdf to a professional board house?
[22:06:35] <skyfox00> well, thanks for all your help, but I think I'm going to thow the towel in on this one...
[22:06:51] <Twingy> you can generate g-code in gcam too
[22:07:14] <jepler> do whatever you care to with the fruits of your labor, but distributing pdfs and keeping .brd/.sch is about as far from "open source" as I can imagine. Perhaps you should choose a different phrase.
[22:07:46] <Twingy> * Twingy has $600 standard version of eagle for linux, nice piece of software
[22:07:51] <cradek> hi pminmo
[22:08:04] <cradek> I'm using your boards to run my mill, we talked a while ago
[22:08:20] <pminmo> Hi cradek, are you timeguy?
[22:08:25] <cradek> yes
[22:08:39] <pminmo> Neat
[22:08:50] <skyfox00> I drew up a 4 channel, 80V, 25A board that would plug into the Pluto... never had it made though...
[22:09:14] <pminmo> Now vradek your a guy I was glad to have the info for
[22:09:19] <pminmo> cradek
[22:09:40] <cradek> yeah I remember we talked about a little improvement - I forget what it was
[22:09:42] <jepler> skyfox00: I wish I had some more troubleshooting ideas for you.
[22:09:53] <pminmo> 45V
[22:10:02] <skyfox00> Anyone interested in a new, slightly used pluto-p board?
[22:10:03] <cradek> unfortunately with just pdfs I wouldn't have been able to use the design, since I mill the boards with gcode generated in eagle
[22:10:29] <cradek> sorry you had troubles.
[22:10:34] <cradek> it sucks to give stuff away and get only static from people
[22:10:37] <pminmo> yes, but if somebody asks and gives me the mill info I will generate g-code
[22:10:39] <Twingy> hrm, if I wrote an image->gcam importer you could export g-code
[22:11:01] <anoniamsu> heh.
[22:11:03] <fenn> twingy you'd still need drill codes
[22:11:07] <Twingy> jes
[22:11:26] <Twingy> so it's not all surface mount? :)
[22:11:30] <anoniamsu> anoniamsu is now known as anonimasu_
[22:11:40] <Twingy> how 90's :}
[22:11:42] <skyfox00> does any one have any idea when the next version of emc will come out?
[22:12:05] <Twingy> why does it matter?
[22:12:12] <jepler> skyfox00: you can try the development version by CVS or tarball .. there's not been a feature freeze yet, and there's no firm date set.
[22:12:27] <fenn> twingy it's the coolness - look at my cnc mill drilling circuit boards
[22:12:31] <skyfox00> ok, thanks, I'll try that I guess..
[22:12:56] <fenn> sure you could do it by hand but then why did you get a cnc mill in the first place
[22:12:56] <skyfox00> oh rats, emc just hard locked up the other computer....
[22:13:02] <Twingy> fenn, huh? I make boards on my cnc in the garage/at work all the time
[22:13:36] <anonimasu_> fenn: agreed, having a cnc isnt nice when you have to do stuff manually anyway
[22:13:37] <Twingy> I do qfp64's and qfp80's mainly
[22:13:38] <cradek> argh, like I suspected, the NMTB 30 holder for my drill chuck doesn't fit
[22:13:44] <pminmo> So guys, convert me to emc2 and linux
[22:13:51] <fenn> twingy how do you get the machine to drill holes in circuit boards?
[22:13:56] <anonimasu_> pminmo: try it, it works :p
[22:14:10] <cradek> pminmo: it's a good system, but we're not linux missionaries
[22:14:18] <Twingy> fenn, I use a 1/50 or 1/32 ball nose for the holes and my 30 degree conical for the traces
[22:14:33] <anonimasu_> pminmo: that's probably the best point for running emc :)
[22:14:36] <Twingy> I can 10mil no problem
[22:14:41] <Twingy> 8mil is a little tricky
[22:14:43] <pminmo> I have a copy of the unbuntu live cd, but it was not real friendly to my PC
[22:14:44] <jepler> what's the "parallel port on idc-26" pinout? IDC pins 1, 3, 5 -> parport pins 1, 2, 3 and 2, 4, 6 -> parport pins 13, 14, 15?
[22:15:08] <skunkworks> pminmo: what do you have to run and what are you running it with?
[22:15:09] <jepler> I googled a bit bit did not find it..
[22:15:13] <Twingy> you really don't need 8 mil traces unless you are doing BGA stuff
[22:15:26] <anonimasu_> pminmo: got enough ram?
[22:15:32] <fenn> Twingy: didnt you say you use image-to-gcode for circuit boards? then how do you recognize a "hole feature" on the image?
[22:15:53] <pminmo> Motherboard/video and wireless is the problem
[22:16:12] <Twingy> fenn, no... I use EAGLE or import an RS274X (Gerber) into GCAM to generate G-Code, I also support excellon drill file importing in GCAM and if I'm using EAGLE I just pull it into EMC
[22:16:22] <Twingy> I was talking about writing one...
[22:16:27] <fenn> oh
[22:16:47] <fenn> right, so, you wouldnt be able to mill boards from just a .pdf with GCAM
[22:16:56] <Twingy> unless you had 2 pdf files
[22:16:58] <skyfox00> what is the cvs command to get the entire emc tree?(I think thats what I need)
[22:17:15] <pminmo> I wouldn't mind posting g-code or gerber files.
[22:17:20] <Twingy> then you could just compute the center of each hole and I could import that as drill points
[22:17:29] <Twingy> gerber file is what you want to post
[22:17:36] <Twingy> as well as excellon drill file
[22:17:42] <fenn> pminmo: why would you post gerber files but not eagle files? i dont understand
[22:17:57] <jepler> skyfox00: http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Installing_EMC2#Getting_the_source_with_CVS
[22:18:18] <jepler> skyfox00: export CVS_RSH=ssh
[22:18:17] <jepler> cvs -z5 -d:ext:anon@cvs.linuxcnc.org:/cvs co -demc2-trunk emc2
[22:18:34] <skyfox00> thanks
[22:18:52] <fenn> is -demc2-trunk really necessary?
[22:19:15] <jepler> fenn: no, but checking it out in ~/emc2 will stomp on existing customized configs from another version
[22:19:37] <fenn> oh, i thought -d was branch or something, i see
[22:19:45] <jepler> -d is local directory to put files in
[22:19:56] <jepler> -r is revision or branch, TRUNK if not specified on co
[22:21:01] <pminmo> my problem has been people wanting to make their own design, but botching it, then spending lots of time with them to square away. One person I had probably helped 40 hours, he was clueless what he was doing.
[22:21:23] <cradek> yeah that can suck. but when I run into that, I just decline to help
[22:21:25] <fenn> was his name bo^dick? :)
[22:21:31] <cradek> haha
[22:21:33] <SWPadnos> d'oh!
[22:21:35] <cradek> err did I type that?
[22:21:42] <SWPadnos> d'oh!
[22:22:00] <SWPadnos> hey - I should go get some donuts
[22:22:04] <pminmo> It's been more than one, and I finally said no more.
[22:22:25] <fenn> it sounds like you're trying to do too much by yourself
[22:22:26] <cradek> I don't see why that means you shouldn't give the "source" to people
[22:22:43] <cradek> I think you should just decline to help clueless people
[22:23:03] <SWPadnos> you just need to enlarge the font for the notice "privided without any warrantee or support"
[22:23:05] <cradek> you have NO obligation to back up your "source" with support
[22:23:09] <skyfox00> when is sombody going to create a stander emc hardware board?
[22:23:21] <fenn> skyfox00: that would be a terrible thing
[22:23:22] <SWPadnos> skyfox00, there are a dozen boards that work with EMC
[22:23:40] <skyfox00> why would it be terrible?
[22:23:52] <fenn> because no one board would be good for everyone
[22:24:23] <jepler> it would be fine if every machine was a 3-axis stepper machine with one limit switch input and one spindle enable output...
[22:24:28] <pminmo> fenn my objective hasn't been to do things by myself
[22:25:32] <pminmo> but it kind of has turned out that way
[22:25:44] <skyfox00> um, I am talking about a USB board that would have TONES of inputs/outputs and could do at least 4 steppers or 8 servo motors...
[22:26:00] <SWPadnos> USB is mostly incompatible with realtime control
[22:26:01] <fenn> yeah i know.. i'm the only person who ever wrote anything on this machine tool "wiki" i set up
[22:26:05] <SWPadnos> when you want feedback
[22:26:13] <fenn> even though it was supposed to be a group project of sorts
[22:26:32] <SWPadnos> if you want something very flexible and with a lot of I/O, the mesa cards are probably your best bet
[22:27:15] <skyfox00> USB can do 480Mbps and can stream quite nicly... and works with laptops that have no parport/pci slot...
[22:27:23] <cradek> bbl
[22:27:32] <SWPadnos> bandwidth and latency are not the same thing
[22:27:50] <fenn> * fenn yawns.. maybe i should make another cnczone post about USB.. or i could let SWPadnos do it
[22:27:57] <fenn> ;)
[22:28:05] <SWPadnos> I refuse to sign up for CNCZone, you can do it :)
[22:28:19] <skyfox00> who cares if your sending step left/right and the board does crital sync?
[22:28:21] <fenn> how bout you write me a nice summary, and i can post it and get all the fame and fortune
[22:28:26] <SWPadnos> I may change my mind if I release a line of CNC-related products, but until then ...
[22:28:27] <pminmo> since I'm not a EMC2 user yet, primarily because I'm not a linux user yet. But will be one of these days I do have a interface question regarding usb
[22:28:30] <ds2> USB is fine... just need someone to get EMC working well on ARM
[22:28:36] <ds2> }:-)
[22:28:53] <skunkworks> then it isn't a good match for emc. (moving motion outside of emc)
[22:28:57] <fenn> i think usb would work _if_ you had PID in the external hardware
[22:28:56] <skyfox00> I've had the ARM idea to ;)
[22:29:13] <SWPadnos> ds2, can you use multiple microframes in a sungle major frame to send data back and forth between a single device and the PC?
[22:29:17] <SWPadnos> single
[22:29:23] <skyfox00> OH yeah, put an xilinx spartan-3 on the board...
[22:29:29] <ds2> [PC w/Axis and USB host] ---- USB ---- [ARM w/EMC motion + USB gadget]
[22:29:31] <ds2> =)
[22:29:32] <SWPadnos> http://www.geckodrive.com
[22:29:47] <SWPadnos> G-Rex has all you want, except for EMC compatibility
[22:29:58] <SWPadnos> there's even Linux software to run it
[22:29:58] <ds2> SWPadnos: doubt it
[22:30:10] <jepler> pminmo: "why doesn't emc just use usb" is a little bit like "why don't I just plug my steppers into mains power" kinda question .. even though it might be possible to use mains power for steppers, it's so different from the ruling paradigm that it would take lots of effort and expertise to pull it off .. and there's no guarantee of success
[22:30:15] <jepler> pminmo: I'm sure you've heard the latter question
[22:30:27] <pminmo> why not just shorthand a command stream via usb
[22:30:51] <jepler> because that doesn't match the way emc2 was designed
[22:31:06] <fenn> its sorta like trying to drive your car by throwing bricks at the pedals
[22:31:05] <SWPadnos> ds2, the microframe question? that's what I thought, which forces command/feedback delays of 1-2 ms
[22:31:16] <pminmo> I thought emc2 was meant to close the loop
[22:31:28] <fenn> usb isnt responsive enough to close the loop
[22:31:33] <SWPadnos> USB is great, until you start talking about *FEEDBACK!*
[22:31:34] <jmkasunich_> jmkasunich_ is now known as jmkasunich
[22:31:38] <ds2> USB isn't able to react quick enough... it is like a pipe where you are allowed to send a RC car in every second but you really need to be able to react in less then a second
[22:31:40] <SWPadnos> for step generation, it's fine
[22:32:04] <ds2> SWPadnos: right which is why I am proposing running the motion half of EMC on the gadget end of the USB link
[22:32:13] <SWPadnos> sure, that's fine
[22:32:34] <ds2> and the most common gadgets are ARM based so porting it to ARM and let the PC do the axis and other UI stuff
[22:32:39] <SWPadnos> I'm finally using my PCB development package (in fact, I shouldn't be chatting :) ), I may get to that ARM replacement for hte rabbit soon
[22:32:47] <skyfox00> My USB idea was just to have a USB version of the Pluto-P(with more I/O)
[22:33:26] <SWPadnos> even step generation needs feedback, which is hard with a USB step generator that doesn't also have the "controller" on it
[22:33:32] <fenn> there's tons of arm boards out there already, it's just that you have to write all the software to make it useful
[22:33:42] <pminmo> does linux have a lot of overhead with usb?
[22:33:54] <SWPadnos> the controller needs to know how many steps have been issued, which it can't calculate exactly due to clock skew, among other things
[22:33:56] <ds2> fenn: just porting RTAI ;)
[22:34:07] <SWPadnos> pminmo, no, I don't think so
[22:34:24] <fenn> personally i think realtime ethernet is more interesting than USB
[22:34:28] <ds2> it isn't the OS but when Intel has done ;)
[22:34:32] <SWPadnos> I suspect the main limitation (for EMC) will be the difficulty of accessing device files from within the kernel
[22:34:42] <SWPadnos> fenn, I agree with that
[22:34:55] <ds2> SWPadnos: accessing?
[22:35:01] <ds2> why would you need that?
[22:35:05] <SWPadnos> but you still have to use something like time slicing to make it work
[22:35:19] <SWPadnos> well, if you don't want to write your own driver for every USB chip ...
[22:35:19] <pminmo> let the gadget handle time
[22:35:38] <SWPadnos> pminmo, the gadget still needs to tell the PC how many steps it's output
[22:35:41] <jepler> if it's going to be inside the position loop, you have to write a "real-time driver" for whatever hardware you want to talk to. writing a real-time usb2.0 driver is a lot of work.
[22:35:45] <pminmo> not a problem
[22:35:49] <ds2> I'd hack the USB drivers to give me raw access to the EP'ed
[22:36:17] <SWPadnos> you can always be off by 1 or 2 steps, and if you don't get the actual number back from the step generator, the errors can accumulate
[22:36:26] <ds2> I think if they start offering USB steering wheels in cars...
[22:36:27] <fenn> ds2: you wouldnt even need to port RTAI, there are other realtime OS's that are better suited to microcontrollers
[22:36:40] <ds2> fenn: but we are talking about EMC here
[22:36:58] <skyfox00> my brother is an engineer and makes boards all the time(and gives me pointers) and I have some eagle time under my belt, if anyone realy wants to give a smart USB board a try...
[22:37:05] <SWPadnos> you don't need an OS - just something that can communicate :)
[22:37:16] <pminmo> so how does emc handle open loop steppers?
[22:37:15] <fenn> rtai seems to be pretty x86-specific, i'm not sure what the point would be in porting it
[22:37:29] <ds2> if that's the case... a SiLab 8051 w/USB then :P
[22:37:40] <jepler> "why can't I run my stepper directly off mains power"?
[22:37:56] <SWPadnos> pminmo, the step generator keeps track of how many steps it has issued, and feeds this back to the motion controller as the position
[22:38:00] <jepler> "with an l297 chip"
[22:38:04] <fenn> jepler dont be mean
[22:38:20] <fenn> that's my job :P
[22:38:31] <pminmo> if you can to that with a stepper then you can do that with usb
[22:38:56] <ds2> not quite
[22:39:00] <skyfox00> ok, just got the cvs version compiled....
[22:39:05] <ds2> say you have 2 axis on 2 USB devices
[22:39:12] <jepler> skyfox00: any change in the behavior you're seeing?
[22:39:16] <ds2> you can't sync them up
[22:39:27] <SWPadnos> pminmo, no - it's very quick to read a memory location within the PC (to get dfeedback) - USB introduces roughly 1ms lag in each direction
[22:39:38] <pminmo> sure you can, async hardware is synced all the time
[22:39:55] <SWPadnos> no, there is no means to sync USB AFAIK
[22:40:04] <skyfox00> I tried run-in-place and it cant find a certian hal file...
[22:40:25] <ds2> I suppose you could do a software PLL if there is a cross connect between the USB devices
[22:40:25] <pminmo> your assuming two indepentent usb devices?
[22:40:35] <ds2> yes, 2 seperate devices
[22:40:38] <fenn> that's dumb
[22:40:40] <SWPadnos> it runs on its 1 KHz (or so) clock, and that's that. you may be able to reset or reinitialize the USB controller to change the clock phase, but you I don't think you have control over it on the fly
[22:40:44] <ds2> possibly on different nodes of the USB tree
[22:40:48] <pminmo> that wouldn't be the way to do usb and multiple axis
[22:40:53] <skyfox00> you could run sync wires between two USB devices
[22:41:15] <fenn> just use one usb device and run a realtime protocol to the end nodes
[22:41:42] <SWPadnos> there are always two USB devices - the PC counts as one
[22:41:47] <SWPadnos> at least two
[22:42:09] <fenn> hm. well, sync wires doesnt help if there's no port to connect them to
[22:42:29] <SWPadnos> also, USB is point to point (even though you can have a tree of connections), and there's one master
[22:42:57] <SWPadnos> on-the-go lets you have devices that choose who's the master depending on the cable you use, but it's still master/slave
[22:43:02] <ds2> USB is kind of like token ring
[22:43:18] <skyfox00> cvs emc2 just locked up agian....
[22:43:20] <SWPadnos> sort of, minus the ring
[22:43:43] <pminmo> so how are people stream 450Mb on usb?
[22:43:46] <SWPadnos> skyfox00, try booting from the EMC2 liveCD, and even try the pluto with that
[22:43:55] <SWPadnos> throughput is not the same thing as latency
[22:44:14] <pminmo> true
[22:44:22] <ds2> streaming is different; they are sending a series of bits with instructions to space them out
[22:44:23] <SWPadnos> I can mail you a 500GB hard disk. that has reasonable throughput but terrible latency
[22:44:27] <skyfox00> the liveCD does not work with the nvidia video card...
[22:44:31] <ds2> they don't care when the bits get there, just they are spaced out
[22:44:41] <SWPadnos> skyfox00, does it not boot, or do you not get acceleration?
[22:44:48] <ds2> side note -- DDS on USB? ;)
[22:44:49] <skyfox00> does not boot...
[22:44:50] <SWPadnos> I use nvidia on multiple computers with the liveCD
[22:44:59] <pminmo> That was why I asked if linux has a lot of overhead with usb
[22:45:01] <jepler> skyfox00: try to boot with the "vesa video" or "safe video" option
[22:45:35] <jepler> not sure what it's called
[22:45:52] <SWPadnos> pminmo, it's not overhead
[22:46:04] <SWPadnos> USB uses a fixed 1KHz packet rate
[22:46:28] <SWPadnos> this is also true with USB2, but each frame is divided into 8 microframes
[22:46:51] <SWPadnos> I don't know exactly how flexible each microframe is (regarding endpoint, direction, etc)
[22:47:17] <pminmo> I didn't know the packet rate was that slow
[22:47:20] <SWPadnos> what this means is that in a perfect world, USB1 or USB2 will only give one command and one feedback packet per millisecond
[22:47:33] <SWPadnos> and the command will be based on old data
[22:47:54] <SWPadnos> heh - there are reasons why I'm down on USB for RT control :)
[22:48:10] <pminmo> Still steppers run open loop
[22:48:43] <SWPadnos> yes, but if you de-synchronize the step generator from the controller, you have to be able to read back the number of steps that have been output
[22:48:43] <ds2> "Feed hold" could get interesting on USB ;)
[22:48:47] <fenn> you could send a series of time values to a usb device, and then have it generate step/dir commands from that
[22:48:51] <SWPadnos> you need the synthetic position feedback
[22:49:01] <fenn> no you dont
[22:49:07] <SWPadnos> something does
[22:49:18] <fenn> stepgen could be modified to talk to usb instead of generating pulses
[22:49:21] <ds2> or consider a lathe
[22:49:27] <SWPadnos> there will always be round-off error in timing of steps, timing of packets, base clock frequencies, etc.
[22:49:33] <ds2> how do you thread w/o feedback?
[22:49:33] <skyfox00> why not do somthing like the pluto except instead of over the parport, use USB?
[22:49:49] <fenn> skyfox00: yep that's what i'm saying
[22:49:58] <SWPadnos> skyfox00, please re-read your scrollback buffer. it's all about feedback
[22:50:02] <fenn> but only for steppers
[22:50:09] <SWPadnos> no no no no
[22:50:20] <ds2> even for steppers, rigid tapping/threading needs feedback
[22:50:26] <SWPadnos> consider this: EMC wants a step rate of 3457 Hz
[22:50:47] <SWPadnos> the nearest rate the pluto (or hypothetical USB device) can generate is 3459 Hz
[22:51:11] <skyfox00> ok, liveCD booted with save video option...
[22:51:11] <SWPadnos> you issue the command to the device, and then some time later you issue another rate command
[22:51:24] <SWPadnos> it doesn't matter if you send them in bulk or one at a time
[22:51:54] <fenn> no, you'd be sending an integer number of steps, and a rate value
[22:51:58] <SWPadnos> unless you read back the actual number of steps generated, you will not know where the motor is (supposed to be - we'll ignore stalls)
[22:52:09] <SWPadnos> then how can you when the command finishes?
[22:52:08] <fenn> there would be a queue of such commands in the usb device, and it would feed back the status of the queue
[22:52:18] <skyfox00> the pluto's LED never changed/went out... still on steady...
[22:52:28] <SWPadnos> feed back? I thought that's what I said
[22:52:45] <fenn> well, it's not that critical is it?
[22:52:58] <fenn> 'feed me data'
[22:53:03] <fenn> 1ms elapses
[22:53:08] <fenn> the queue goes down 20 commands
[22:53:16] <fenn> the controller replies with 100 commands
[22:53:23] <fenn> the device is happy for another 5 ms
[22:53:34] <pminmo> Obviously people are running emc2 open loop with steppers, l297's, 3977's, step/dir controllers
[22:53:58] <pminmo> so feedback isn't an absolute requirement
[22:53:58] <SWPadnos> open loop on EMC still means that the controller knows where the step generator thinks the motors are
[22:54:06] <ds2> or prehaps consider manual jogging
[22:54:15] <pminmo> still it's open loop
[22:54:15] <ds2> and breaking tools ;)
[22:54:15] <SWPadnos> stepgen on EMC feeds back a synthetic position to EMC
[22:54:30] <SWPadnos> yes, it's open loop
[22:54:31] <pminmo> still to external hardware it open loop
[22:54:36] <ds2> it is open loop but a lag is an invitation to break tools
[22:54:57] <fenn> swp stepgen would still be in emc
[22:55:00] <ds2> you click the wheel 10times then afew seconds later your tool tip is buried
[22:55:01] <SWPadnos> but it's still error-corrected up unti lthe parallel port
[22:55:04] <pminmo> back to thruput vs latency and a stream of data
[22:55:30] <skyfox00> I should have kept my mouth shut and never brought up USB....
[22:55:35] <SWPadnos> skyfox00, true :)
[22:55:45] <pminmo> Ok i give
[22:55:54] <ds2> channel is too quiet otherwise ;)
[22:56:06] <jepler> we have to have this argument every few weeks, it's inevitable
[22:56:14] <SWPadnos> pminmo, emc and mach both keep track of how many step pulses have been issued
[22:56:30] <SWPadnos> and use that fake position to decide on the velocity to get to the next point
[22:56:47] <fenn> i think this would work sorta like a unix pipe, but instead you'd use USB as the pipe
[22:56:50] <pminmo> I understand, its still open loop to the external hardware
[22:56:51] <SWPadnos> so it's not closed-loop, but it is error-corrected uptil the step signals leave the PC
[22:56:53] <skyfox00> ok, running the Ubuntu liveCD every thing is the same.... the pluto LED never goes out....
[22:56:54] <SWPadnos> right
[22:57:17] <fenn> heck it doesnt even have to be realtime
[22:57:35] <SWPadnos> skyfox00, your parallel port should probably be set to EPP, not ECP
[22:57:53] <fenn> you could pipe stuff into the device driver from userspace, which neatly solves all the driver issues
[22:58:03] <skyfox00> I will set it to EPP next...
[22:58:05] <pminmo> is there a emc/usb discussion subchannel :-)
[22:58:11] <anonimasu_> no
[22:58:13] <SWPadnos> an external USB device that happens to "close the loop" - whether it's PID or step counting - should work fine :)
[22:58:24] <jepler> skyfox00: can you 'pastebin' this .hal file you've been using? Have you been running it with 'halrun -I' or some other way?
[22:58:38] <jepler> http://pastebin.ca
[22:58:47] <SWPadnos> but if the motion controller on the PC is expected to do that (close the loop), then USB has issues
[22:58:48] <pminmo> This is my 1st time hear, I like it :-)
[22:58:52] <ds2> * ds2 stops adding gasoline }:-)
[22:59:15] <SWPadnos> it may be fine for a lot of stuff - a machine , especially a hobby machine, isn't likely to move far in 10 ms
[22:59:15] <skunkworks> jepler: I had this one http://www.electronicsam.com/images/KandT/servostart/pluto.hal
[22:59:26] <SWPadnos> so you could have a slower command rate
[22:59:28] <skyfox00> yep, thars the one...
[22:59:31] <skunkworks> but I think the conical names need to be changed
[22:59:36] <skunkworks> conical?
[22:59:41] <SWPadnos> canonical
[22:59:46] <skunkworks> right :)
[22:59:53] <ds2> cone shaped names? ;)
[23:00:04] <fenn> it should work for "deterministic" control systems, but not anything that relies on feedback
[23:00:12] <SWPadnos> Beldar, I summon you!
[23:00:52] <SWPadnos> fenn, it only works if you send position and time values, and the dingus at the other end calculates the actual distance from its count of steps issued
[23:00:56] <skyfox00> jepler, that link you posted is what i have been running with halrun -I, excep I modified it to show all 4 encoders and the communication errors...
[23:01:10] <fenn> swp what does distance have to do with it?
[23:01:22] <fenn> you send a integer number of steps
[23:01:24] <SWPadnos> you need distance to calculate rate
[23:01:27] <fenn> and a rate
[23:01:36] <fenn> the dingus does it
[23:01:38] <SWPadnos> what if it hasn't issued all the steps from the last command
[23:01:41] <SWPadnos> ?
[23:01:53] <SWPadnos> like its clock is 3.9999 MHz instead of 4.00000
[23:01:56] <fenn> it doesnt request more data if the queue is full
[23:02:08] <pminmo> you send a dumbed down G-code line
[23:02:13] <fenn> if the queue overflows it says 'hey stop that'
[23:02:31] <SWPadnos> I'm not talking about the queue - it doesn't matter if you send an entire program at once
[23:02:31] <fenn> is queue the right word?
[23:02:52] <SWPadnos> I send one command, it says "make 1000 pulses in the next 1 ms"
[23:03:21] <SWPadnos> but the clock isn't exaxctly right, so the software says "well, I know how to do that, just issue one step every 4000 clock cycles"
[23:03:43] <fenn> uh huh
[23:03:55] <SWPadnos> but the clock is slow, so it only issues 999 pulses
[23:04:12] <fenn> and then it does the last step and goes on to the next motion command
[23:04:17] <SWPadnos> the next command (buffered, queued, sent just in time) says "go 300 steps in the next 1ms"
[23:04:19] <fenn> now it's behind 1 microsecond
[23:04:35] <SWPadnos> well, in that case you end up with the commands taking too long ...
[23:04:43] <ds2> for this, couldn't you have a current queue depth returned?
[23:04:43] <fenn> ok, so what?
[23:04:52] <fenn> after 1000 cycles it's behind 1ms
[23:04:55] <ds2> and eventually you will converge on a desired level?
[23:05:10] <fenn> it doesn't request additional motion commands that communications period
[23:05:44] <SWPadnos> ok - if you want a "set it and forget it" thing, then USB is fine
[23:06:04] <fenn> the "sent just in time" is stupid when the devices has tons of memory to store commands
[23:06:05] <SWPadnos> if you want something that can be controlled by the PC, then it isn't as good for the time scales we like to use with EMC
[23:06:57] <SWPadnos> I don't want to say that USB is impossible to use, even though it sounds that way :)
[23:07:10] <SWPadnos> it's just not easy, and a lot of things need to be done very differently
[23:07:24] <fenn> i think this is how old style cnc machines worked more or less
[23:07:27] <skyfox00> why not do a stream capture on the step commands generated by emc (like an audio recording) and then stream that off to the board?
[23:07:26] <SWPadnos> and it is mostly impossible to use for non-open-loop systems
[23:07:30] <ds2> but then if you want to get USB to work, why not get bluetooth or wifi to work instead? less clutter in the shop ;)
[23:07:41] <SWPadnos> ds2, shut up!
[23:07:43] <SWPadnos> :)
[23:08:01] <fenn> heh dump some used motor oil on the fire
[23:08:11] <fenn> all the black smoke will drive everyone away
[23:09:00] <skyfox00> ok, I have changed the parport mode to EPP and rebooted...
[23:09:34] <skyfox00> ok, its working, led fades in/out...
[23:09:42] <skunkworks> sweet :)
[23:09:46] <SWPadnos> yay!
[23:09:59] <fenn> uh.. didnt you already try that? what was different this time?
[23:10:08] <skyfox00> this is the liveCD
[23:10:29] <skunkworks> skyfox00: http://www.electronicsam.com/images/KandT/servostart/ampmess.JPG
[23:10:44] <SWPadnos> I'd say there may be a problem with your RT kernel. it's uncommon for EMC to lock up a computer
[23:10:59] <skyfox00> and now if the computer was not shared, I would just install from the liveCD...
[23:11:26] <fenn> skyfox00: is there a (good) reason you aren't using the provided rt kernel?
[23:11:42] <SWPadnos> it's a shared PC with slackware, apparently
[23:12:04] <fenn> that's not a good reason
[23:12:18] <skyfox00> which provided rt kernel?
[23:12:27] <fenn> the .deb's on linuxcnc.org
[23:12:42] <fenn> they are brought in as dependencies when you install the emc package
[23:13:03] <skyfox00> oh, the computer is not mine, I can install software on it, but it needs to be a slackware box(runs servers, etc)
[23:13:22] <SWPadnos> that may not be an ideal computer to experiment on ;)
[23:13:27] <pminmo> I'm off, I'm glad I found this chat as I've been wanting to work with emc2. I always like to learn
[23:13:30] <fenn> right, well, i suggest you get a dedicated computer for running whatever you're going to be running
[23:13:49] <skunkworks> pminmo: give it a try. come back and ask questions
[23:13:48] <fenn> it doesnt need to be fancy
[23:13:55] <SWPadnos> pminmo, have fun
[23:14:03] <pminmo> thnkas guys
[23:14:05] <SWPadnos> and let us know if you solve the USB thing ;)
[23:14:22] <pminmo> got other projects in the que ahead of it
[23:14:30] <skyfox00> um, I've all ready spend 40% of my total budget on the pluto board....
[23:14:38] <skunkworks> heh
[23:14:38] <SWPadnos> oh right - other projects. see ya!
[23:14:57] <fenn> skyfox00: your 166mhz laptop may be enough.. emc was designed to run on less
[23:15:03] <pminmo> to many interests, not enough time...:-)
[23:15:27] <SWPadnos> I have this little 16-bit analog I/O board I'm (supposed to be) working on ...
[23:15:59] <jepler> skyfox00: now that you know a BIOS setting that works, reboot slackware in a way that parport_pc is never loaded and give it another try
[23:16:08] <skyfox00> its so old that I cant get Ubuntu to run on it at ALL... and my other laptop(this one, 1.3ghz) has no parport... and a EPP parport card is to expencive...
[23:16:23] <jepler> (e.g., put "install parport_pc /bin/true" in /etc/modprobe.d/emc2)
[23:16:46] <fenn> yes, ubuntu is a pig, and i'm not sure why
[23:16:59] <fenn> but debian is almost exactly the same and is not a pig, somehow
[23:17:21] <jepler> do as little as possible to the parport before loading pluto_servo, and you improve your chances that it will work..
[23:17:51] <skyfox00> hmmm, I think I was loading parport_pc in rc.local... will reboot and check...
[23:23:40] <skyfox00> where can you get a > 2.6.17 kernel source that has native realtime?(not a hacked patch)
[23:25:32] <LawrenceG> JymmmEMC: you alive?
[23:26:59] <jepler> skyfox00: sometimes they have other patch versions in their cvs, but I do not understand their system for naming or which patches are good to use .. http://cvs.gna.org/cvsweb/magma/base/arch/i386/patches/?cvsroot=rtai -- some patches up to 2.6.20 here
[23:27:08] <jepler> er, up to 2.6.22 I guess
[23:27:51] <skyfox00> I was hoping to avoid having to patch one my selfe...(in other words, get one that is known to work)
[23:28:11] <skyfox00> I have managed to reboot and no parport driver of any kind loaded...
[23:29:10] <skyfox00> ok, it works, led fades corectly...
[23:29:34] <skyfox00> now, lets hook up the encoders and see how they work...
[23:31:14] <jepler> really? hooray
[23:32:33] <skyfox00> yeah, it must have been the parport/lp driver interfiering...
[23:32:45] <skunkworks> yikes
[23:33:44] <JymmmEMC> LawrenceG: yes sir
[23:35:19] <skyfox00> well, were getting communication errors again...
[23:45:08] <skyfox00> I was able to get it working for a few seconds and it was tracking the encoder, but then it bombed out and started getting communication errors agian...
[23:45:43] <toast> so apparently we have scraping equipment at work
[23:45:44] <toast> and i'm free to borrow and use it
[23:45:46] <toast> huzzah
[23:47:52] <skunkworks> cradek may like to borrow it - from you..
[23:51:54] <skunkworks> so - I install a new screen and hardrive in a laptop - (dropped) the only odd thing is the intensity controls for the screen work in reverse now. Up is down and down is up. odd. (maybe it worked that way before - could be)
[23:52:32] <jepler> skyfox00: apparently different EPP ports require different actions to recover from a communication error. The method in 2.1 (error register is cleared after read) worked on my first test systems, but on other systems the value is latched and in 2.1 is not reset with anything short of a reboot. In emc2 CVS, three methods (read, write with 1, and write with 0; the methods the linux kernel epp driver uses) are used. If you try the CVS version you'll get
[23:54:15] <skyfox00> ok, thanks, I am trying Ubuntu liveCD right now to see how it tracks the encoders...
[23:55:02] <jepler> but if the communication isn't reliable, you still face restarting emc after a communication error -- if there is a communication error you may have lost position because the encoders overflowed between reads
[23:55:23] <jepler> use a shorter cable, use a higher quality cable, or hang the pluto directly off the parport connector
[23:56:34] <LawrenceG> JymmmEMC: hey.... I got a oem750 to play with
[23:56:36] <jepler> on slackware you are using release 2.1.7 right? very old 2.1.0 and 2.1.1 had a bug in the firmware that could lead to communication errors.
[23:56:52] <jepler> (2.1.6, which I think is on the current live cd, should be fine in this respect too)
[23:57:55] <skyfox00> yeah, i think its 2.1.6...
[23:59:03] <skyfox00> but I am running the Ubuntu liveCD and just had is start giving communication errors.... worked fine the boom!