#emc | Logs for 2008-01-07

[00:02:17] <jmkasunich> cradek: you'll see when its done
[00:03:30] <tomp> cool, works for what i can imagine and run thru the calculator. kig is cool too. i didnt see the G18 cases tested. maybe CANON_PLANE_YZ doesnt happen
[00:17:13] <jmkasunich> I wonder if O#3 is legal? (I'll find out soon)
[00:17:28] <SWPadnos> interesting - it should be
[00:17:28] <jmkasunich> "O#3 call" I mean
[00:17:59] <SWPadnos> yeah - I'd hope that the variable replacement happens before interpretation (kinda has to go that way)
[00:24:14] <jmkasunich> gotta remember, no unary minus operation
[00:24:26] <SWPadnos> heh - [0-#xx]
[00:26:19] <jmkasunich> yep
[00:26:37] <jmkasunich> or in this case [-#11/2] becomes [#11/-2]
[00:32:20] <cradek> seems like [- should be a syntax error
[00:32:31] <SWPadnos> or a unary minus
[00:32:37] <jmkasunich> "bad number format"
[00:32:38] <cradek> ha, or that
[00:33:34] <SWPadnos> hmmm. I wonder if there are any errors that would arise from treating "[" as "[0"
[00:33:55] <SWPadnos> a number can have zeroes prepended without changing the value
[00:34:03] <jmkasunich> [0#2+3] isn't valid
[00:34:05] <cradek> [#1]
[00:34:07] <SWPadnos> but in the case of a - sign, you end up with [0-...
[00:34:18] <cradek> [sin[30]]
[00:34:24] <SWPadnos> 0#2 should be 0 + the text string representing #2
[00:34:30] <jmkasunich> don't go there SWPadnos
[00:34:33] <SWPadnos> ah, ok - forgot the functions. nevermind
[00:34:54] <jmkasunich> lack of unary minus is not hard to work around
[00:35:03] <SWPadnos> it's silly, but not hard to work around
[00:35:23] <jmkasunich> an implied zero is much more likely to have unintended consequences
[00:35:34] <jmkasunich> especially after we forget why its there, or that its there at all
[00:35:37] <SWPadnos> sure - especially when it causes things to fail which shouldn't
[00:35:39] <SWPadnos> heh
[00:43:27] <jmkasunich> btw, indirect calls (O#3 call) do work
[00:43:39] <SWPadnos> cool. I figured they would
[00:44:05] <SWPadnos> I knew that G#10 would work, O#10 seemed like it should be similar
[01:00:39] <skunkworks> * skunkworks thinks jmkasunich is having fun with his cnc.
[01:01:17] <jmkasunich> having fun with g-code
[01:01:26] <jmkasunich> haven't started the spindle yet on this part
[01:05:51] <Gamma-X2> hey everyone whats up
[01:06:02] <toastydeath> everything that isn't down.
[01:06:11] <toastydeath> and even then, some stuff that is.
[01:06:42] <Gamma-X2> true that!
[01:09:18] <Gamma-X2> still lookin for the pin diagram of the anilam controls
[01:25:19] <SWPadnos> I'm reasonably sure you won't find them here :)
[01:26:52] <Jymmm> Any other suggestion for a electical drawing program WITH proper symbols? And knows for sure
[01:27:03] <SWPadnos> Altium
[01:27:19] <SWPadnos> Windows or Linux?
[01:27:51] <Jymmm> SWPadnos: preferably gpl, either at this point. Dia has some symbols, but too complex to create new ones.
[01:28:00] <Jymmm> that are needed
[01:28:26] <SWPadnos> yeah - I was looking for something for doing wiring diagrams, and never found anything (for <$1000 or so) that seemed useful
[01:28:54] <Jymmm> Dia would work, but making the extra symbols would be time consuming
[01:29:08] <SWPadnos> everyone I've talked to just uses whatever CAD rpogram they're used to, be it AutoCad, EasyCad (jmk, I believe), some PCB program - whatever
[01:29:18] <SWPadnos> you could try electric or gschem
[01:29:30] <Jymmm> I looked at electric
[01:29:45] <Jymmm> does gschem have electrical symbols?
[01:30:04] <SWPadnos> I'd hope so, it's a schematic capture program
[01:31:20] <SWPadnos> oh - now that's cool
[01:31:38] <SWPadnos> I had left my laptop on, but had accidentally kicked the AC cord out
[01:31:45] <SWPadnos> so it was off when I just picked it up
[01:32:14] <SWPadnos> I hit the power button (after plugging it in, of course), and a little while later, voila - there's my session from last night
[01:32:19] <jmkasunich> nice
[01:32:47] <SWPadnos> either that or Linux decided to hibernate when I closed the li
[01:32:49] <SWPadnos> lid
[01:32:57] <jmkasunich> I think I've come to the conclusion that it is impossible to enter cutter comp inside a hole that is less than two cutter diameters wide
[01:32:59] <SWPadnos> either way, I was surprised to see the desktop :)
[01:33:17] <SWPadnos> do the entry move from "outside" the hole, above the top plane of the part
[01:33:25] <SWPadnos> then spiral down into it
[01:33:34] <jmkasunich> looks like thats what I'll have to do
[01:33:38] <jmkasunich> I was hoping to avoid that
[01:33:52] <jmkasunich> my roughing routine does exactly that, but
[01:34:08] <SWPadnos> I don't know how to construct a curve that's inscribed within another curve, but intersects at a tangent
[01:34:14] <jmkasunich> after completion of roughing, I'm all the way down, and I just want to transition to a new tool diameter and run the finish cut
[01:34:30] <jmkasunich> looks like after roughing I need to pull up, drop comp, recomp with the new diameter, and go back down
[01:34:58] <jmkasunich> annoying but doable
[01:35:16] <SWPadnos> you should be able to just change to the new diameter, I'd think
[01:35:18] <Skullworks-PGAB> JMK - milling?
[01:35:23] <Jymmm> SWPadnos: Dia is availablle for both nix and win. Take a look at it and tell me if you think it be worth the time to create a set of electrical symbols for it.
[01:35:33] <jmkasunich> nope, when you are compensating, you have to turn comp off, then back on with the new diameter
[01:35:41] <jmkasunich> Skullworks-PGAB: yes
[01:36:08] <SWPadnos> Jymmm, have you looked at kicad?
[01:36:27] <SWPadnos> I have run dia, and it's a lot like Corel Draw in terms of how you draw with it (IIRC)
[01:36:38] <Skullworks-PGAB> you should only need a bit more than the listed cutter radius
[01:36:48] <jmkasunich> thats what you'd think
[01:36:52] <jmkasunich> but it doesn't work that way
[01:36:57] <cradek> jmkasunich: useful-subroutines.ngc has hole milling with comp
[01:37:05] <cradek> iirc it enters comp before entering the hole
[01:37:44] <Skullworks-PGAB> I bet it will
[01:37:47] <jmkasunich> I'm convinced that is required
[01:37:56] <SWPadnos> Jymmm, dia (0.94 for Windows) has electric, schematic, network (Cisco-specific, even) symbols already
[01:38:01] <jmkasunich> unless the hole is at least 2x the tool size
[01:38:04] <SWPadnos> among others
[01:38:07] <Skullworks-PGAB> what sized hole, what sized tool?
[01:38:25] <jmkasunich> Skullworks-PGAB: doesn't matter
[01:38:36] <SWPadnos> the trouble is the entry move. you can't have a cusp
[01:38:47] <Skullworks-PGAB> I want to give you a short code to test
[01:38:56] <SWPadnos> and it's hard to make a circular arc that's inscribed within another circular arc, but intersects at a tangent
[01:38:58] <jmkasunich> I have my own code to test
[01:39:07] <SWPadnos> ("intersecting at a tangent" is a clue there ... )
[01:39:34] <jmkasunich> is easy if you have control over some of the other constraints
[01:39:50] <SWPadnos> I don't see it, geometrically (could be me though)
[01:39:53] <jmkasunich> draw a line from the center of the larger circle to the desired tangent point on that circle
[01:40:07] <jmkasunich> the center of the smaller circle can be anywhere on that line
[01:41:09] <SWPadnos> but the tool would have to be off that line to have an arc move, and it has to start >1 radius away from all points on the outer circle
[01:41:26] <jmkasunich> yep - thats the hitch
[01:41:40] <SWPadnos> so I see that there are many possible arcs that are tangent (thanks), but I'm not sure you can make any with a nonzero tool radius that doesn't gouge
[01:42:17] <jmkasunich> if the large circle is only slightly bigger than the tool, the set of points that are more than one tool radius from the large circle, and also inside the large circle, is a very small circle near the center
[01:42:48] <jmkasunich> not sure if my last sentence makes sense
[01:42:53] <SWPadnos> sure
[01:43:27] <SWPadnos> so the maximum radius of an entry move is the radius of that small circle (I think)
[01:43:48] <jmkasunich> in theory if you started with the tool at the exact center of the big circle, there is an arc (centered half way to the rim of the big circle) that will deposit the outside of the tool on the big circle where you want it
[01:43:55] <SWPadnos> but you can't move off the centerline far enough unless you're at the edge of the desired hole
[01:44:14] <SWPadnos> ok, sure
[01:44:16] <jmkasunich> oops, I got that wrong
[01:44:27] <SWPadnos> right - I think it would gouge
[01:44:49] <jmkasunich> lets say the big circle is 1" diameter, and the tool is 0.9"
[01:44:53] <jmkasunich> numbers are clearer
[01:45:00] <SWPadnos> you're thinking of a circle with half the diameter of the large circle, with its diameter along a radius of the large circle
[01:45:20] <jmkasunich> yeah, but that puts the tool center on the edge of the big circle, which is wrong
[01:45:29] <jmkasunich> I want to mill a 1" hole with a 0.9" cutter
[01:45:42] <SWPadnos> no, that's what you want to program, and you let compensation correct it
[01:45:49] <jmkasunich> stop
[01:45:53] <SWPadnos> heh - ok
[01:46:03] <jmkasunich> I'm describing the path I want, one that I know will remove the metal I want
[01:46:13] <jmkasunich> then I'm looking at why EMC won't let me do that
[01:46:17] <SWPadnos> sure
[01:46:28] <jmkasunich> so - what is physically possible - start at the center of the 1" hole
[01:46:54] <cradek> http://timeguy.com/cradek-files/emc/hole.png
[01:46:54] <jmkasunich> do a half-circle with a radius of 0.025, and its center 0.025 away from the center of the 1" hole
[01:47:16] <jmkasunich> tool winds up at 0.05 from the center, and edge of the tool is at the edge of the 1" hole
[01:47:33] <cradek> this is what I program for a hole that has to be right - probably can't use comp (but I think it's unnecessary complication in this case)
[01:47:38] <jmkasunich> the problem is the tight half-circle is less than the tool diameter, and emc won't allow it
[01:48:12] <jmkasunich> cradek: yeah, if you don't use comp, its easy
[01:48:31] <cradek> that leads us to an easy solution :-)
[01:48:37] <jmkasunich> I already wrote a generic g-code program for helical milling round holes
[01:48:52] <jmkasunich> then I wanted to mill a slot, and a curved slot, and a outside profile
[01:49:01] <SWPadnos> are the tool diameter/length available as parameters?
[01:49:11] <cradek> useful-subroutines.ngc also has (arbitrary) slots
[01:49:19] <jmkasunich> so I wrote a generic subroutine that will helix down, then run the profile, then helix down again, etc
[01:49:44] <jmkasunich> using comp so I can do a finish pass later without redefining the profile
[01:50:16] <jmkasunich> for some value of "arbitrary"
[01:50:21] <jmkasunich> curved slots"
[01:50:23] <jmkasunich> ?
[01:50:33] <cradek> straight slots arbitrarily rotated
[01:50:43] <jmkasunich> not what I'm trying to do
[01:50:49] <cradek> oh
[01:51:27] <jmkasunich> the tricky one is the curved slot, which is only slightly wider than the tool
[01:51:43] <Skullworks-PGAB> ( Hole finish size .6")
[01:51:43] <Skullworks-PGAB> ( tool dia. .5")
[01:51:43] <Skullworks-PGAB> ( pocket depth .2")
[01:51:43] <Skullworks-PGAB> (D1 = .525")
[01:51:43] <Skullworks-PGAB> (D2 = .500")
[01:51:44] <Skullworks-PGAB> (Hole center = x0 y0)
[01:51:46] <Skullworks-PGAB> G0 G40 G90 X0. Y0. Z.1
[01:51:48] <Skullworks-PGAB> G1 Z-.2 F10.
[01:51:50] <Skullworks-PGAB> G41 X.275 Y.025 D1
[01:51:52] <Skullworks-PGAB> G3 X0. Y.3 I-.275
[01:51:53] <jmkasunich> Skullworks-PGAB: please stop
[01:51:54] <Skullworks-PGAB> X0. Y.3 J-.3
[01:51:56] <Skullworks-PGAB> X-.275 Y.025 J-.275
[01:51:58] <Skullworks-PGAB> G1 G40 X0 Y0
[01:52:00] <Skullworks-PGAB> G41 X.275 Y.025 D2
[01:52:02] <Skullworks-PGAB> G3 X0. Y.3 I-.275
[01:52:04] <Skullworks-PGAB> X0. Y.3 J-.3
[01:52:06] <Skullworks-PGAB> X-.275 Y.025 J-.275
[01:52:08] <Skullworks-PGAB> G1 G40 X0 Y0
[01:52:10] <Skullworks-PGAB> G0 Z.1
[01:52:12] <Skullworks-PGAB> M2
[01:52:14] <Skullworks-PGAB> OK
[01:52:18] <cradek> I'm spoiled by Realize
[01:53:33] <cradek> all my 2.5d gcode comes from it, and it's so easy
[01:54:20] <jmkasunich> Skullworks-PGAB: you've got the first move G41 spec'ed so it doesn't cause any actual movement?
[01:54:25] <jmkasunich> (or very little)
[01:54:40] <SWPadnos> that's acceptable, as long as the programmed move is large enough, the effective move can be 0
[01:54:42] <SWPadnos> (I think)
[01:55:11] <Skullworks-PGAB> yes moves only .025
[01:55:28] <Jymmm> http://pastebin.ca/844640
[01:55:31] <Skullworks-PGAB> could do it with .002
[01:55:51] <jmkasunich> interesting trick, might work for me
[01:56:18] <jmkasunich> that avoids the need for an arc entry move, the arc entry is what makes it get big
[01:56:24] <Jymmm> you should be able to replay that in axis
[01:56:31] <cradek> but you really have to know the tool diameter - which sort of makes me think "what's the point"
[01:56:51] <jmkasunich> I can mic the tool diameter
[01:56:59] <cradek> I mean to write the gcode
[01:57:13] <jmkasunich> the tool diameter is an arg to the subroutine
[01:57:24] <jmkasunich> it does _not_ change the profile that I want to cut at all
[01:57:37] <cradek> I must be the slow one tonight
[01:57:45] <SWPadnos> heh - I don't think so :)
[01:57:52] <jmkasunich> I'm not conveying what I'm trying to do very well
[01:58:33] <jmkasunich> G100 = a subroutine that starts with G1 <startpoint>, then has any number of G1 G2, G3 which define the finished profile - convex, concave, doesn't matter
[01:59:07] <jmkasunich> all that matters is that it returns to the start point, and that at that point the path is along the Y axis and positive, with air to the left and metal to the right
[01:59:28] <jmkasunich> oops, not G100, O100
[02:00:04] <maddash> uhh, today is the seventh?
[02:00:11] <jmkasunich> O1000 = a subroutine that is passed the startpoint, and '100' (to identify that O100 is the path I want)
[02:00:59] <jmkasunich> it goes to a point slightly more than a tool radius to the left of startpoint, spirals down a bit, invokes O100 to run the profile, spirals down some more, invokes O100, etc
[02:01:14] <SWPadnos> if you're in Australia, then today is the 7th
[02:02:27] <Skullworks-PGAB> I have a sub that will make slot arcs around a given point that is all defined with variables if that might help
[02:02:49] <jmkasunich> never mind
[02:03:03] <jmkasunich> this isn't something that can be discussed without pencil, paper, and eyes
[02:03:11] <maddash> http://www.linuxcnc.org/irc/irc.freenode.net:6667/emc/2008-01-07.txt <--- why?
[02:03:23] <jmkasunich> GMT
[02:03:46] <maddash> oh, now I see that the timestamps are off as well
[02:04:09] <SWPadnos> they're within 20 seconds
[02:04:30] <SWPadnos> even better - within about 7 seconds
[02:04:32] <maddash> I meant different from my own time (EST)
[02:04:44] <SWPadnos> they're not off, they're from a different time zone ...
[02:04:48] <SWPadnos> (as you now know)
[02:06:19] <cradek> now I see why you were asking about O#1
[02:06:53] <jmkasunich> I'm about 99% there
[02:07:18] <maddash> I'm trying to figure out if my ucontroller is a viable platform for generic step generation; what kind of speeds (rpm) should one expect out of a stepper?
[02:07:30] <jmkasunich> it works, except for keeping all the entry, exit, and ramping moves inside the "pit" as I've been thinking of it - the area in which the tool is allowed to move as it goes up and down
[02:07:53] <SWPadnos> ig it isn't faster than ~100ksteps/second, then there isn't much reason to use that over software
[02:07:57] <SWPadnos> s/ig/if/
[02:08:11] <jmkasunich> if the profile is a hole or slot the pit has to fit inside it
[02:08:21] <cradek> some people with perverse setups think they want step rates in the MHz
[02:08:48] <SWPadnos> heh - the only people who can actually use that are people who should be using true servo (Yaskawa drives can take step rates up to 2 MHz, I think)
[02:09:05] <jmkasunich> Mariss has gotten steppers up to 3000 RPM or so, but they have almost no torque up there
[02:09:08] <cradek> yeah they're clearly doing it wrong, but still, they think they want that
[02:09:18] <jmkasunich> 1000-1500 is probably more reasonable
[02:09:37] <SWPadnos> as for step rates, the Geckos can't go faster than 300 KHz (for the new CPLD-based ones)
[02:09:39] <jmkasunich> the other issue is wild microstepping - there are 256x microstepping drives out there
[02:09:49] <cradek> yeah that's more the issue I think
[02:09:54] <skunkworks> jmkasunich: did you get all your leadscrews mapped?
[02:09:56] <cradek> or, step-servo drives
[02:10:04] <jmkasunich> skunkworks: Y is mapped
[02:10:22] <jmkasunich> X simply has backlash comp (and the scale tweaked)
[02:10:27] <SWPadnos> the gecko servo drives can only go up to 250 KHz at the moment (internal, after a multiplier if ther eis one)
[02:10:33] <maddash> SWPadnos: so ideally, the ucontroller should operate at > 600KHz, discounting the cycles used for motion calculations?
[02:10:39] <jmkasunich> Z has just scale tweaks - its a preloaded ballscrew, had negligable lash
[02:10:45] <SWPadnos> the new G380 may raise that to 300 KHz like the G210 did
[02:11:11] <SWPadnos> maddash, are you talking about the step rate or the clock?
[02:11:47] <SWPadnos> ah - I see. 300 KHz * 2 transitions
[02:11:48] <maddash> SWPadnos: the clock? I'm referring to the ucontroller
[02:12:10] <maddash> oh, ok, I see what you meant
[02:12:30] <SWPadnos> if that's an interrupt/cycle rate you're talking about, I'd want it to be significantly higher, or you end up with granularity problems
[02:13:03] <SWPadnos> (ie, 300 KHz top speed, 200 KHz is the next speed down, if you do a 33% / 66 duty pulse train)
[02:13:30] <maddash> you lost me at "granularity"
[02:13:59] <SWPadnos> if you have a 600 KHz "clock" for step generation, then you can only generate step frequencies that have a period of 2, 3, 4 ... clocks
[02:14:08] <SWPadnos> so the fastest is 2 clocks, which is 300 KHz
[02:14:14] <SWPadnos> 3 clocks gives you 200 KHz
[02:14:46] <SWPadnos> there is no way to generate a frequency between those two (though you can alternate between 200 KHz and 300 KHz to get the right average rate)
[02:15:21] <maddash> why isn't this problem apparent in emc?
[02:15:36] <SWPadnos> it is, at speeds close to the top speed possible
[02:16:09] <SWPadnos> it doesn't prevent the machine from working, but it's possible for the effective "high acceleration" to stall a motor, or sound bad
[02:16:33] <SWPadnos> see you later
[02:17:04] <maddash> so, at high speeds, it'd be difficult to adjust to the right speed, because the jumps between one level and the next grow progressively larger?
[02:17:15] <SWPadnos> yes
[02:17:22] <SWPadnos> it doesn't prevent the machine from working, but it's possible for the effective "high acceleration" to stall a motor, or sound bad
[02:17:25] <SWPadnos> (in case you missed that)
[02:18:09] <maddash> I did, but I've got the irclogs in my firefox
[02:18:19] <SWPadnos> ah, ok
[02:19:02] <maddash> it's quite surprising to see that no one has attempted an avr-esque stepgen yet, especially since a ucontroller can easily outpulse the parport
[02:19:53] <SWPadnos> it's not so easy when you consider that the AVR has to keep generating steps even while it's communicating on the parport
[02:20:22] <maddash> hm, no multithreading?
[02:20:29] <SWPadnos> I did make a pulse generator with an AVR, but it's a frequency reference - it uses hardware PWM
[02:20:35] <SWPadnos> heh - not really
[02:20:54] <SWPadnos> you can use interrupts, but that will skew the timing of software-generated steps or the parport comms
[02:21:03] <SWPadnos> or both
[02:21:52] <SWPadnos> actually, the hardware PWM could work, you can count the number of pulses with a trivial PWM interrupt routine
[02:22:30] <SWPadnos> but that still takes time - it's 4 cycles to vector to the interrupt, another 3 to return (or the other way around), plus 2 cycles to save the status register, and one to increment (2 if you use a register pair)
[02:22:33] <maddash> or, I could use multiple ucontrollers
[02:22:53] <SWPadnos> 11 cycles is close to .5 us, even at 24 MHz
[02:23:05] <SWPadnos> you can, but you still need communications
[02:23:33] <SWPadnos> you can use SPI or something, and poll for received data in the stepgen routine
[02:24:07] <SWPadnos> but having two timing-critical functions that hang off interrupts is a pain (and the main reason the PC sucks for step generation)
[02:24:25] <SWPadnos> well, there are other reasons, but the multitude of interrupt sources is a big issue
[02:25:28] <maddash> hot damn, it's been done before
[02:25:36] <SWPadnos> deskCNC, anyone?
[02:25:56] <SWPadnos> I think they used a PIC for rev1, AVR for rev2, and an FPGA (or a faster AVR) for rev3
[02:28:14] <maddash> 'true 4-axis interpolation'
[02:32:25] <eric_U> interesting story of an emc crash: http://www.cnczone.com/forums/showthread.php?t=49764
[02:38:05] <SWPadnos> I wonder if the dir line came undone
[02:38:21] <eric_U> I was thinking some kind of mechanical failure
[02:38:39] <eric_U> you would think that would become obvious
[02:38:43] <eric_U> fairly quickly
[02:39:03] <SWPadnos> from the description, it seemed that EMC was still running the profile
[02:39:09] <cradek> a newly set up stepper system ended up cutting in the wrong place? this is not news
[02:39:26] <eric_U> after 8 hours of proper operation?
[02:39:32] <SWPadnos> it's hard to tell though - he did say it had been running properly for 8 hours
[02:40:05] <cradek> maybe a computer problem too - like a realtime issue (screen saver?)
[02:40:11] <eric_U> maybe something finally overheated
[02:40:12] <cradek> he didn't say whether he got that error
[02:40:19] <cradek> we do a good job sensing that kind of problem
[02:41:11] <SWPadnos> EMC2 was still running "properly" - he said he hit the software E-stop button to kill it
[02:41:43] <eric_U> wouldn't the screen saver knock him a few steps out at worst?
[02:42:28] <SWPadnos> that's why I thought of a broken/stuck dir line - all X motion would continue to drive the motor into the side
[02:44:25] <cradek> no, one motor stall can put you off arbitrarily far
[02:44:38] <cradek> it won't start moving again until the next decel/accel
[02:44:53] <eric_U> ok
[02:46:21] <SWPadnos> but it should semi-recover though - once it's stalled against the side, the reverse motion should bring it back all the way "to the left", so it should just touch the edge on later passes (or grind a little, but then move back again)
[02:46:41] <SWPadnos> I'm assuming what he was cutting was rectangular, like something image-to-gcode would do
[02:49:14] <cradek> it's sad that he had limit switches but didn't hook them up
[02:49:22] <SWPadnos> heh - yeah
[02:49:49] <cradek> he would have known exactly what move did it
[02:50:01] <SWPadnos> and would likely have prevented the damage
[02:50:07] <cradek> yes
[03:06:04] <jmkasunich> well, finally got the program done
[03:06:13] <jmkasunich> can't run it yet though, gotta make some tooling
[03:06:25] <SWPadnos> just measure the tools you have ;)
[03:06:50] <jmkasunich> spacers to hold the work up off the table
[03:07:16] <SWPadnos> ah - workholding kind of tooling
[03:21:46] <jmkasunich> if at first you don't succeed, force the bugger!
[03:21:50] <jmkasunich> the is the rule, isn't it?
[03:22:03] <jmkasunich> * jmkasunich just ruined a drill bit
[03:22:10] <SWPadnos> I think it's "if at first you don't succeed, get a bigger hammer"
[03:22:14] <cradek> I thought it was: if at first you don't succeed, stop, no use looking like a damn fool
[03:22:57] <jmkasunich> well, that would have been a good idea
[03:23:16] <jmkasunich> then I might have noticed the hardened steel parallel I was trying to drill thru
[03:23:31] <cradek> oops
[03:24:06] <jmkasunich> * jmkasunich <-- looking like a fool
[03:24:31] <cradek> everyone's done it. at least you missed the vise.
[03:24:44] <jmkasunich> true
[03:25:04] <jmkasunich> trying to go too fasyt
[03:25:08] <jmkasunich> fast
[03:25:37] <cradek> if there's no blood on it, it was the good kind of crash
[03:26:44] <cradek> "People with pacemakers should consult their physician(s) before using this product" <- on my indicator base
[03:27:04] <SWPadnos> um - yeah.
[03:27:18] <SWPadnos> like just in case they try to stick it to their chest - you know - strong magnets and stuff
[03:27:20] <SWPadnos> ??
[03:27:30] <cradek> oh right, magnetic
[03:27:42] <cradek> I hadn't figured it out
[03:28:07] <SWPadnos> it doesn't seem like a mag base would be that strong, but who knows
[03:28:53] <SWPadnos> oh. lovely
[03:29:14] <SWPadnos> well, I guess I could look at this as an opportunity to re-organize my drill bits
[04:03:01] <BigJohnT> Ain't nothing cooler than seeing a parallel shoot out of the side of your vise when you drill into the edge of it...
[04:03:29] <eric_U> that's why I take the parallels out once the vice is set
[04:04:01] <BigJohnT> come on you need to live large and take some chances
[04:04:26] <eric_U> there's always the chance that I should have left the parallel in there
[04:04:33] <BigJohnT> If I can move the parallels then the work is not seated well
[04:04:59] <eric_U> mine are just that perfect
[04:05:06] <BigJohnT> cool
[04:05:13] <eric_U> I know
[04:51:42] <jmkasunich> I guess it just wasn't meant for me to run this part tonight
[04:51:49] <jmkasunich> started the spindle and blew the fuse again
[04:52:03] <eric_U> what's wrong?
[04:52:28] <SWPadnos> gotta turn the lights off when you start the spindle
[04:52:28] <jmkasunich> fuse too small (10A), crappy single phase motor on 120V, trying to accel a lot of inertia
[04:52:43] <eric_U> reactor
[04:52:50] <jmkasunich> bigger fuse
[04:52:57] <SWPadnos> penny
[04:53:09] <jmkasunich> its a tubular fuse
[04:53:14] <SWPadnos> bullet ;)
[04:53:16] <jmkasunich> drill rod would probalby work
[04:53:26] <SWPadnos> that's make a nice 30000A fuse
[04:53:31] <SWPadnos> that'd
[04:53:37] <jmkasunich> .22 is too small. .45 is to big, thats all I have here
[04:53:40] <eric_U> this is in your cabinet?
[04:53:47] <jmkasunich> yeah
[04:53:49] <SWPadnos> if only you could turn down a .45
[04:53:59] <eric_U> spun metal
[04:54:01] <jmkasunich> I do have a brass fuse in there already
[04:54:13] <jmkasunich> in the neutral pole of the three pole disconnect
[04:54:18] <eric_U> I have some fuses that have replaceable elements
[04:54:37] <jmkasunich> eww, those are the crappiest fuses around
[04:54:53] <eric_U> haven't used one yet
[04:55:06] <eric_U> they are at least one step up from a blown fuse :)
[04:55:07] <jmkasunich> lousy interrupting rating, non-current limiting
[04:55:21] <jmkasunich> I'll get some fuses tomorrow
[04:55:29] <eric_U> mcmaster didn't tell me any of that
[04:55:40] <jmkasunich> its late anyway, I have no business starting to run the part at 11:55 pm
[04:55:48] <eric_U> good point
[04:55:57] <jmkasunich> tell you what?
[04:56:10] <eric_U> lousy interrupting rating, non-current limiting
[04:56:26] <jmkasunich> got a mcmaster P/N?
[04:56:42] <jmkasunich> the ones I'm thinking of are pretty much obsolete, maybe mcm is selling something different
[04:57:26] <eric_U> trying to remember which part it is
[04:57:45] <jmkasunich> also, keep in mind that I'm a fuse snob - I work with high power stuff
[04:58:56] <eric_U> 7073K122 they look like that
[04:59:33] <jmkasunich> see - only 10KA interrupting
[04:59:52] <eric_U> what does that mean?
[05:00:15] <jmkasunich> it means that if the line can deliver more than 10000 Amps into a short, the fuse might blow up instead of just blowing
[05:00:31] <eric_U> is that a bad thing?
[05:00:41] <jmkasunich> on the previous page they have class RK1 fuses - 200KA interrupting rating
[05:00:56] <eric_U> I'll have to get some of those
[05:01:00] <jmkasunich> blowing up is always a bad thing
[05:01:05] <eric_U> the ones I got are the wrong size anyway
[05:01:11] <eric_U> tell that to the mythbusters
[05:01:23] <jmkasunich> if this is a residential application, you almost certainly have less than 10KA available fault current
[05:01:42] <eric_U> no, 3phase industrial setting
[05:01:48] <jmkasunich> 480V?
[05:01:53] <eric_U> maybe
[05:01:58] <eric_U> I can choose
[05:02:05] <jmkasunich> do you know how big the transformer feeding the circuit is?
[05:02:12] <eric_U> right now it's 480
[05:02:14] <jmkasunich> (probably a utility transformer)
[05:02:29] <eric_U> not sure I've seen it
[05:02:39] <eric_U> I think the one I've seen is for the 208
[05:02:55] <eric_U> I think they bring 480 into our building
[05:02:58] <jmkasunich> is it as big as a desk, or as big as an office?
[05:03:09] <eric_U> it's as big as a desk
[05:03:22] <jmkasunich> you probably get 480 from the utility and transform down to 208
[05:03:23] <eric_U> or maybe two
[05:03:30] <jmkasunich> that transformer might be a couple hundred kva
[05:03:31] <eric_U> that's what I'm thinking
[05:03:51] <jmkasunich> the utility one is harder to tell, depends on how many customers (and how big) are on one xfmr
[05:03:52] <eric_U> they are much happier when I use 480, I know that
[05:04:04] <eric_U> they generate electricity across the street
[05:04:08] <jmkasunich> the building I work at has a 2500 KVA transformer (two of them actually)
[05:04:39] <jmkasunich> quick calculation says my building has about 52KA available fault current
[05:05:04] <eric_U> so my fuse would explode
[05:05:23] <jmkasunich> might, if you had a sufficiently "short" short circuit
[05:05:44] <jmkasunich> put 50 feet of 6 gage wire in the loop and the wire alone might limit the current to under 10KV
[05:05:46] <jmkasunich> KA
[05:05:50] <eric_U> never blown a fuse, but I turned off the lights on half the building, twice
[05:06:17] <jmkasunich> I can beat that - our lab (which I was responsible for the power feed configuration) blacked out the whole building
[05:06:23] <jmkasunich> tripped a 4000A breaker
[05:06:26] <SWPadnos> heh
[05:06:40] <eric_U> turns out the 250A breaker was set to 30A
[05:06:43] <jmkasunich> oops
[05:06:49] <eric_U> not my fault
[05:06:51] <SWPadnos> try making a 10MW supply, and having some oscillation you need to find:)
[05:06:58] <SWPadnos> (not me, but a company I do work for)
[05:06:59] <jmkasunich> in our case, it turns out the jumpers on the main breaker were set wrong
[05:07:14] <eric_U> our breakers are little computers
[05:07:26] <eric_U> you hook up to them with rs232 and change parameters
[05:07:28] <jmkasunich> so even though it was set (on the front) for a 0.5 second delay to allow the branch breaker to trip first, the jumpers had it set on instantaneous
[05:08:02] <SWPadnos> it's even more fun when all the buildings down the line (for a few miles) get the brownout oscillations
[05:08:17] <eric_U> yes, that's much better :)
[05:08:20] <SWPadnos> (direct feed from the 13200V lines)
[05:08:40] <eric_U> although the head of the department of Mechanical engineering wasn't real understanding, the second time
[05:08:47] <SWPadnos> heh
[05:08:51] <SWPadnos> once is enough, after all
[05:09:12] <SWPadnos> I should bring a camera when I go in tomorrow
[05:09:28] <eric_U> the electrician just happened to be walking by when I tripped the breaker
[05:09:37] <SWPadnos> the "small" supply I've been working on is pretty cool looking - all stainless enclosure, pretty small for the power
[05:09:38] <jmkasunich> crap, mcmaster wants $10 each for a puny class CC fuse
[05:09:54] <eric_U> he checked my wiring, said it was ok, and then turned on my motor again
[05:10:23] <jmkasunich> and it tripped again?
[05:10:28] <eric_U> we laughed
[05:10:44] <jmkasunich> how big of a motor?
[05:10:48] <eric_U> 10hp
[05:11:04] <jmkasunich> ah - enough to draw more than 30A inrush
[05:11:15] <jmkasunich> not enough to even remotely budge a 250A breaker tho
[05:11:18] <eric_U> yeah, and it was under load too
[05:11:42] <jmkasunich> we have a dyne at work that is two 600HP motors coupled to each other
[05:11:49] <jmkasunich> we don't normally start it across the line
[05:11:51] <eric_U> they are very conservative
[05:12:07] <jmkasunich> but we did a couple times - it rattles the wires in the conduits
[05:12:16] <jmkasunich> 4000ish amps for a second or so
[05:12:18] <eric_U> how do you start it
[05:12:31] <jmkasunich> we test VFDs with it
[05:12:41] <eric_U> start on vfd only
[05:12:43] <jmkasunich> so normally the unit under test brings it up to speed
[05:12:58] <jmkasunich> and another VFD makes the second motor act like a generator to provide load
[05:14:49] <eric_U> I need to design a brushless servo amp for a project
[05:15:09] <jmkasunich> fun
[05:15:31] <eric_U> the EE's have these power stages that they buy, but I'm not sure they do what I want
[05:15:38] <jmkasunich> work project, home project, school project?
[05:15:50] <eric_U> work
[05:16:00] <jmkasunich> are you an EE?
[05:16:07] <eric_U> ME
[05:16:13] <jmkasunich> what power level?
[05:16:26] <eric_U> less than 2hp
[05:16:38] <jmkasunich> still, thats enough to be non-trivial
[05:16:46] <eric_U> yes
[05:16:49] <jmkasunich> high speed switching and PWM have plenty of gotchas
[05:17:11] <jmkasunich> I'd use a power stage if they're available, unless this is gonna be a high volume cost sensitive thing
[05:17:42] <eric_U> kinda tricky, I need to be able to fail power devices on demand :)
[05:18:00] <jmkasunich> thats not normally a goal
[05:18:03] <eric_U> money isn't all that important
[05:18:29] <eric_U> we work on some strange projects
[05:18:44] <SWPadnos> do you still need to provide as much power as possible if some devices have failed?
[05:18:54] <eric_U> no
[05:19:10] <eric_U> that's pretty ambitious
[05:19:14] <SWPadnos> ok, do you need to kep running?
[05:19:17] <SWPadnos> keep
[05:19:19] <eric_U> no
[05:19:26] <SWPadnos> ah, that's a lot easier
[05:19:49] <SWPadnos> the power supply I've been working on actually does keep operating as longa s at least half of the power stages are still working
[05:19:59] <SWPadnos> (10 out of 20)
[05:20:04] <eric_U> that's cool
[05:20:25] <SWPadnos> yeah - I'm curious how well it'll work with the inductive load they expect
[05:20:40] <SWPadnos> right now I think it goes from 0 to 15000A in something like 0.3 uS
[05:20:43] <eric_U> as long as your fuse doesn't explode like JMK just demonstrated mine will
[05:20:48] <SWPadnos> heh
[05:20:52] <eric_U> boom
[05:21:00] <jmkasunich> 0.3uS?
[05:21:05] <SWPadnos> yes
[05:21:12] <jmkasunich> what is the load?
[05:21:23] <eric_U> you're neighbors must love you when you turn that on
[05:21:33] <SWPadnos> right now they have a long loop of fat cable, and a big wound coil load
[05:21:41] <SWPadnos> like a space heater that takes up a wall
[05:21:51] <jmkasunich> with only 1uH of load and/or lead inductance, it would take 45KV to drive 0->15000A in 0.3uS
[05:22:14] <SWPadnos> I'm not sure what they're expecting (in numbers)
[05:22:25] <SWPadnos> I know they're pretty happy with the performance at the moment
[05:22:29] <jmkasunich> I seriously doubt that current slew rate
[05:22:53] <jmkasunich> they would have to go to extremes with load wiring to get the inductance down
[05:22:59] <eric_U> SWP suddenly realizes he's making the power supply for Saddam's long delayed rail gun
[05:23:08] <SWPadnos> heh
[05:23:14] <SWPadnos> no, for a big fat ECM machine
[05:23:24] <jmkasunich> even if the supply is 15Kv, your load inductance would have to be 0.3uH if you want the current to rise in 0.3uS
[05:23:44] <eric_U> to cut a hole through the earth for the rail gun, brilliant!
[05:23:54] <SWPadnos> I'm pretty sure that's what they said - I mentioned something about it going to high current in only 3 uS, and the guy corrected me "it's a lot faster than that"
[05:24:25] <SWPadnos> this runs from a 480V 3ph feed, I'm not sure what they have internally (it's only a 32V supply, so I wouldn't expect them to boost that internally
[05:24:43] <jmkasunich> if its only 32V output, there is no fscking way it can do that kind of dI/dT
[05:24:45] <SWPadnos> maybe that wasn't to 15kA - it could have been to 5 or 6 kA
[05:25:08] <SWPadnos> the output is programmable up to 3V, I don't know what the supply can actually generate
[05:25:10] <SWPadnos> 32V
[05:25:30] <jmkasunich> apply 32V to 100nH (a foot of even fat wire is more than 100nH), and the inductance will limit the dI/dT to 320A/uS
[05:25:54] <jmkasunich> thats simple V = L * dI/dt, basic physics
[05:26:02] <SWPadnos> I'll ask about those test results again. I may have something wrong
[05:26:40] <SWPadnos> I suspect they can apply a higher voltage to the output, to get the current up faster
[05:27:05] <jmkasunich> for kiloamps in microseconds, it would need to be a LOT higher
[05:27:14] <SWPadnos> there was supposed to be a learning feature to pre-emphasize the pulses, but it turns out to not be needed
[05:27:17] <SWPadnos> heh, yep
[05:29:59] <jmkasunich> I should go to sleep
[05:30:07] <SWPadnos> hmmm. an excellent idea
[07:25:52] <Jymmmmm> Gawde, eagle is "strange" in it's commands
[07:51:36] <fenn> you know you can make new symbols in kicad.. quite easily
[08:32:18] <Jymmmmm> fenn: is it a clusterfsck to learn?
[08:54:02] <alex_joni> morning y'all
[09:05:26] <lerneaen_hydra> morning alex
[09:05:30] <fenn> not as bad as eagle. the only really weird bit is moving parts around between libraries
[09:06:00] <lerneaen_hydra> kicad?
[09:06:03] <fenn> ya
[09:06:06] <lerneaen_hydra> any good?
[09:06:15] <fenn> i like it. but it needs some polish
[09:06:38] <fenn> and should come with import scripts so you can use other formats (the scripts are out there)
[09:07:04] <fenn> much easier to use than eagle or geda tho
[09:07:08] <lerneaen_hydra> what about component libraries?
[09:07:40] <fenn> it comes with a small set of components, but you usually have to make a few
[09:07:56] <fenn> there are more at kicadlibs.org, i dunno why they dont come bundled
[09:07:57] <lerneaen_hydra> oh ok, can you import eagle libs?
[09:08:02] <lerneaen_hydra> oh ok
[09:08:20] <fenn> yes i think so. i know you can import orcad and some other formats
[09:08:33] <fenn> but the scripts are floating around the net
[09:09:23] <fenn> kicadlib.org
[09:09:24] <lerneaen_hydra> oh ok I see
[09:10:51] <lerneaen_hydra> any benefits compared to eagle if you already know eagle?
[09:11:13] <fenn> hmm. depends how well you know eagle i guess
[09:11:19] <fenn> it's Free
[09:11:39] <lerneaen_hydra> that's always a plus
[09:11:42] <fenn> if more people used kicad, it would reduce the incentive to continue using eagle
[09:12:40] <fenn> honestly i'm not proficient enough in either program to give a "pro" user's perspective, but from a new user's standpoint kicad wins hands down
[09:13:03] <lerneaen_hydra> oh, well that always sounds good, not that it would be hard to be easier than eagle
[09:13:16] <fenn> ok glad i'm not the only one :)
[09:13:31] <fenn> er.. besides you jymmm :D
[09:14:36] <lerneaen_hydra> after you get used to eagle it's acceptable
[09:16:17] <Jymmmmm> I just want to draw some simple electrical diagrams, nothing fancy. It's been frustrating.
[09:17:06] <fenn> qcad has electrical symbols :D
[09:19:09] <fenn> apt-get install partlibrary
[09:20:32] <fenn> ...and half of them are named in romanized japanese
[09:21:40] <lerneaen_hydra> haha :D
[09:34:55] <archivist> Ive just started playing with kicad
[09:35:32] <archivist> and having spent 20+ years of pcb design, im biased
[09:36:18] <archivist> user interface needs a bit of work on it
[09:37:05] <archivist> especially in the schematic module
[09:38:10] <archivist> autorouter is as bad as any! it routed outside the board edge!
[09:38:36] <alex_joni> who uses autorouter anyways :P
[09:38:45] <archivist> no normal person
[09:38:58] <archivist> but I had to try it
[09:39:16] <alex_joni> I tried it on orcad a couple of times.. disappointed me every time
[09:39:30] <archivist> I hated it when I tried it
[09:39:40] <alex_joni> it needed 4 layers for simple things (which I did on one layer + some bridges)
[09:39:40] <archivist> Im so used to PCAD
[09:50:07] <archivist> hmm Ive got to make a better level shifter between my parport and drives
[10:17:49] <fenn> archivist do you use emc2 on your machine?
[10:18:13] <archivist> just getting it going yes
[10:19:30] <fenn> heh is it running on that fat little laptop?
[10:19:48] <archivist> drives need 3-10 volt in its inputs ant the parport it only giving about 2.5
[10:20:09] <archivist> no its on an old athlon box
[10:55:31] <archivist> fenn its a new build so using is not there yet!
[10:56:57] <alex_joni> archivist: use 2 x NOT
[10:57:02] <alex_joni> or a schmidt trigger
[10:57:14] <alex_joni> that will give you 5V
[10:58:20] <archivist> Ive got some ls14's somewhere
[10:58:58] <alex_joni> those are inverters .. but should be ok
[10:59:18] <alex_joni> they have 1.4-1.9V treshold voltage
[13:17:51] <steve_stallings> steve_stallings is now known as steves_logging
[13:26:38] <maddash> yeesh adding just one extra pci parport slows down base-thread by 8000 ns
[13:31:03] <SWPadnos> ~1 us per read or write ...
[13:33:27] <maddash> are you kidding? more like 5us
[13:33:43] <alex_joni> one read = 1 us, one write = 1us
[13:33:48] <alex_joni> + overhead
[13:34:00] <SWPadnos> no, there are three ports, one or two of which are accessed twice
[13:34:05] <maddash> I noticed that there's a write-/read-all -- is this supposed to be used for multiple parport ports?
[13:34:18] <alex_joni> maddash: yes, it gives a slight speed increase
[13:34:27] <SWPadnos> the control port and possibly the third one (whatever it's called) are read and written. the data port has one access
[13:34:43] <SWPadnos> that gives 1.6 us per access, including all overhead (which should be minimal)
[13:34:49] <maddash> because right now, I'm doing a straightforward, addf parport.n.read -(n+1), addf parport.n.write (n+1)
[13:35:11] <SWPadnos> you do however have several more cache lines to read, since there are an extra 25 or so variables to look at/set
[13:35:37] <SWPadnos> so you need to look at your memory speed to see what kind of hit that gets you
[13:36:25] <maddash> so for now, replace all instances of addf parport.*.read with addf parport.read-all?
[13:36:38] <SWPadnos> that won't help much
[13:36:50] <SWPadnos> there's very litle overhead to running a function in a thread
[13:37:14] <SWPadnos> most of the overhead is in actually reading and writing the port, and in accessing memory for the port pins and params
[13:38:09] <maddash> yeah, you're right. ~0 difference.
[13:38:23] <maddash> geeeeez.
[13:38:29] <SWPadnos> ah - status is the name of the other register :)
[13:38:41] <SWPadnos> is this a PCI parport?
[13:38:46] <maddash> so the bottleneck's in the port hardware, not software
[13:38:53] <SWPadnos> yes
[13:38:59] <maddash> one of them is PCI, the other is onboard
[13:39:13] <maddash> both have 5+-.2us speed
[13:39:35] <SWPadnos> ok. if you got a Mesa card instead, and just used it for simple I/O (not using any of the extra FPGA features), you'd see a pretty big speedup
[13:40:00] <SWPadnos> one reason is that 24 bits are read or written per access
[13:40:09] <SWPadnos> (you could make that 32 if you wanted)
[13:40:22] <SWPadnos> another is that it's PCI, which has a much faster cycle time, in general
[13:40:42] <alex_joni> even if the parport card is PCI there's a PCI<->ISA converter in it
[13:40:49] <alex_joni> so it won't run faster
[13:40:53] <SWPadnos> (though one chipset I'm using has the shittiest PCI controller ever made, and still takes nearly 1 us per individual access)
[13:41:05] <SWPadnos> right - I was asking if there's a PCI slot in the machine ;)
[13:43:02] <SWPadnos> incidentally, if you only need a few extra inputs or some outputs, but not both, you should be able to do only one of read and write
[13:43:33] <SWPadnos> ie, only call parport.0.read and parport.1.write
[13:44:10] <SWPadnos> but you may need to shuffle connections around, and you'll need to give up a few pins to do that (since some are fixed direction)
[13:55:19] <maddash> servo-thread's pretty loaded now
[13:56:24] <maddash> I edited the Makefile to use O3 instead of -O2, and I changed the hal_parport.c *_port() calls to inline
[13:56:43] <maddash> now I get a .8+-.2us increase
[13:56:48] <maddash> in base-thread, that is
[13:57:37] <gezar> is one of the ways tool builders get around latency issues is to use more accurate parts so they arnt having to send 200k+ pulses to perform a small amount of motion?
[13:57:53] <SWPadnos> you mean that O3 and inline = more execution time?
[13:58:02] <maddash> er, decrease*
[13:58:07] <SWPadnos> ah, ok :)
[13:58:25] <SWPadnos> gezar, uh - what? :)
[13:58:37] <archivist> gezar do it in hardware/or parallel controllers
[13:59:40] <gezar> ah yeah I guess, and the buss tying the drives together being fiber in most new cases
[14:00:15] <gezar> seimens most advanced control the 840D was built around a ppro cpu
[14:00:19] <SWPadnos> but internally, those controllers are using a fast microcontroller and/or hardware (FPGA or other) to actually move the motor
[14:01:11] <maddash> err, is it just me, or is the code in parport.c hardcoded to go now faster than 50us?
[14:01:28] <SWPadnos> where do you think you see that?
[14:01:38] <maddash> "tv.tv_usec = 50000;\nselect(0, 0, 0, 0, &tv);"
[14:01:58] <SWPadnos> select isn't used in the RT code - that could be sim
[14:02:02] <jepler> you're looking at the (now thoroughly atrophied) "userspace" driver support.
[14:02:15] <maddash> huh?
[14:02:17] <SWPadnos> oh - the userspace driver. I had forgotten about that
[14:02:27] <maddash> so hal_parport.c isn't the parport driver?
[14:02:46] <jepler> used to be you could compile hal_parport.c into a userspace binary, hal_parport. make it setuid, and do port access from userspace without timing guarantees.
[14:02:46] <maddash> oh geez
[14:02:52] <maddash> #else /* user space */
[14:02:58] <jepler> no, hal_parport.c is also the realtime driver
[14:03:15] <gezar> I guess what I mean is that, home brew we tend to use 10 pitch or greater screws, in some cases down to 5tpi balls, but on some of the newer cnc machines were talking 2tpi screw or so
[14:03:20] <maddash> yeah, I waas looking inside main() /* silly me */
[14:03:20] <SWPadnos> I wonder if that should be "fixed"
[14:03:41] <jepler> I don't see any problem with removing the "userspace" support from hal_parport
[14:03:41] <alex_joni> gezar: newer cnc machines don't use steppers.. do they?
[14:03:52] <alex_joni> SWPadnos: why?
[14:04:01] <SWPadnos> gezar, I think the big machines use low TPI because it allows high speed - I don't think there's any increase or decrease in precision from that (you just use a higher resolution encoder)
[14:04:04] <alex_joni> I see no reason against keeping the stuff there
[14:04:27] <maddash> source bloat?
[14:04:34] <maddash> source code, I mean
[14:05:02] <gezar> of course not, but In terms of system speed, instead of having 200k ticks for an inch they can, I showed up to the football game with a soccer ball again im sorry
[14:05:05] <SWPadnos> well, if it doesn't work, it probably doesn't need to be there
[14:05:46] <SWPadnos> gezar, with cheap hardware (a $5 FPGA), you can do 20 MHz steping/quadrature counting. I don't think pulse rate is an issue :)
[14:05:55] <maddash> $5 fpga?! where?!
[14:06:06] <SWPadnos> digikey, in 10000 quantity
[14:06:11] <maddash> haha.
[14:06:20] <gezar> I dont even know what fpga means right nwo
[14:06:34] <SWPadnos> Field Programmable Gate Array - programmable hardwarw
[14:06:36] <maddash> it's basically a reprogrammable IC
[14:06:38] <SWPadnos> hardware
[14:08:45] <alex_joni> is this a sherline in there? ftp://brochures:15099799@
[14:09:03] <maddash> heh, when DISPLAY=dummy, I get a 5+-1us decrease in servo-thread
[14:11:11] <alex_joni> whoa .. this is cool: http://www.youtube.com/watch?v=ghDhZxidomc
[14:11:17] <alex_joni> acemi: nice job :)
[14:13:57] <maddash> making '|_/-" == 'wire forming'?
[14:14:40] <alex_joni> maddash: exactly
[14:14:55] <maddash> huh? what e heck are those things, anyway?
[14:15:02] <maddash> the |_/-, I meant
[14:15:03] <alex_joni> the |_/- is probably programmable
[14:15:12] <alex_joni> so it depends what you need :)
[14:15:24] <alex_joni> some people actually need & use |_/- :P
[14:15:29] <maddash> hm, clever, then
[14:15:45] <alex_joni> I have no idea what those are supposed to be :)
[14:15:52] <alex_joni> but you can ask acemi when he's around
[14:16:45] <maddash> but the shape isn't arbitrary
[14:17:02] <alex_joni> my guess is that it's programmed
[14:17:09] <maddash> I mean, it is, but there are some shapes that can't be done
[14:17:29] <alex_joni> oh, of course
[14:17:42] <alex_joni> I guess they change the deformers for different jobs
[14:17:53] <alex_joni> for larger, smaller radiuses, etc
[14:17:59] <alex_joni> thicker/thinner wire
[14:18:20] <cradek> those look like paint rollers to me
[14:18:25] <cradek> brb
[14:27:19] <alex_joni> yay bipodkins: http://www.youtube.com/watch?v=DAPTdw_BTF0
[14:35:05] <maddash> sizeof(unsigned char)==1
[14:35:18] <SWPadnos> true
[14:36:24] <alex_joni> not always :)
[14:36:28] <jepler> yes always
[14:36:31] <SWPadnos> true enough
[14:36:41] <alex_joni> * alex_joni builds a new platform and compiler
[14:36:46] <alex_joni> just to be different
[14:36:54] <SWPadnos> always, unless alex is being a dweb
[14:36:56] <SWPadnos> dweeb
[14:36:59] <maddash> I'm trying to optimize read/writeport()
[14:37:09] <jepler> well you might have a compiler where sizeof(char) != 1, but it wouldn't be a compiler for ISO C
[14:37:13] <SWPadnos> using char storage won't do it
[14:38:00] <maddash> x-freakin'-86
[14:41:44] <maddash> 'miranda'?
[14:42:13] <jepler> " The sizeof operator .. 3. When applied to an operand that has type char, unsigned char, or signed char, (or a qualified version thereof) the result is 1.
[14:42:28] <jepler> " -- ISO/IEC 9899:TC3 (http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1256.pdf)
[14:43:06] <alex_joni> haha parking.. http://www.220.ro/Talent_la_parcare-40099-U129669.html
[14:43:11] <SWPadnos> heh - so the char may take more space, but sizeof will sitll return 1 ;)
[14:43:12] <alex_joni> jepler: it's true for ISO C
[14:43:38] <alex_joni> "For integral types of guaranteed sizes, ranging from 8 to 64 bits, ISO C provides the stdint.h header."
[14:49:17] <maddash> hm, I gained .1+-.02us in parport.0.read.time with my optimizations
[14:49:45] <SWPadnos> hopefully other HAL components can still read/write the HAL pins ...
[14:50:07] <maddash> are the gains significant to interest you devs?
[14:50:19] <maddash> heh, good point, lemme dblchk
[14:51:38] <alex_joni> maddash: depends how the code looks like
[14:51:39] <SWPadnos> I'd be curious to see a diff (on pastebin or something)
[14:51:46] <alex_joni> yeah, me too
[14:51:58] <SWPadnos> bbiab
[14:53:06] <fenn> alex_joni: i'll be impressed when the car can do that automatically
[14:54:09] <alex_joni> fenn: that might be easier than by a human
[14:54:33] <SWPadnos> 4 wheel steering
[14:54:38] <alex_joni> this is a bit harder: http://www.220.ro/Intrarea_in_parcare_cu_fata-8099.html
[14:56:06] <fenn> heh you mean doing that on purpose?
[14:57:38] <alex_joni> yeah
[15:02:49] <fenn> gezar: 17MHz $14 qty 1: http://www.usdigital.com/products/ls7266/body_index.shtml?noframes
[15:04:53] <alex_joni> those are very good :)
[15:05:05] <alex_joni> and at least 2 drivers for emc2 use them
[15:05:15] <fenn> oh and it appears they do 2 encoders at once?
[15:05:20] <alex_joni> yes
[15:05:26] <alex_joni> the 7166 only does one
[15:08:16] <jepler> alex_joni: there are?
[15:08:22] <jepler> (emc drivers)
[15:18:14] <maddash> * maddash givees up
[15:19:04] <maddash> I think I got my math wrong somehow
[15:21:03] <maddash> http://pastebin.ca/845225
[15:21:43] <maddash> basically, I'm trying to save the extra dereference from "->" in "*(port->status_in[b])""
[15:22:17] <maddash> multiplied by 5+8+4=17
[15:31:57] <SWPadnos> for some reason, my wife put this comic on our refrigerator: http://www.comicspage.com/comicspage/main.jsp?catid=1952&custid=69&file=20071124cpbss-a-p.jpg&code=cpbss&dir=/bliss
[15:32:42] <alex_joni> jepler: the STG uses the LS7266
[15:32:51] <alex_joni> and my board uses the 7166
[15:32:51] <jepler> alex_joni: interesting, I didn't know that.
[15:33:07] <alex_joni> although I'm not sure my board's driver works :)
[15:33:34] <alex_joni> hal_tiro
[15:34:09] <alex_joni> hat one should only be for up to 4 x 7166
[15:34:14] <alex_joni> connected to ISA
[15:35:47] <alex_joni> jepler: looking at the kinda old code, I see I have the params to outb reversed :D
[15:35:56] <alex_joni> rtapi_outb(CTRL(i), 0x03);
[15:36:41] <jepler> hah
[15:37:21] <alex_joni> I remember having to fix that for the STG driver when I started fixing it
[15:37:33] <alex_joni> but I didn't bother to fix it for the tiro driver
[15:56:46] <jepler> hm -- maddash's code was simply wrong pointer arithmetic. after correcting it, I can't measure a speed difference in a test harness. http://emergent.unpy.net/files/sandbox/optimization.c
[16:33:13] <alex_joni> acemi: hi
[16:33:43] <alex_joni> nice wire forming machine..
[16:34:07] <acemi> hi alex_joni
[16:34:21] <alex_joni> acemi: we were taking guesses at what the product is
[16:34:29] <alex_joni> cradek said paint roller
[16:42:00] <acemi> I have very bad internet connection today because a windows box which is in the network
[16:51:00] <archivist> why blame windows
[16:51:17] <archivist> I know it deserves blame
[16:51:41] <skunkworks> heh. because it is infected? still not windows fault ;)
[16:52:26] <archivist> * archivist has 3 windaz and one linux normally
[16:52:38] <acemi> there is no problem when the windows machine is closed
[16:53:05] <acemi> yes it is infected
[16:53:10] <alex_joni> acemi: what's the wire beding product?
[17:29:40] <alex_joni> bbl
[17:40:34] <maddash> jepler: hey, I just read the logs. could you tell me where I went wrong?
[17:41:26] <gezar> command for installing source packages for emc2?
[17:41:48] <gezar> i bet i can fanagle apt let me try that first
[17:42:03] <cradek> emc2 has complete source packages like any other debian package
[17:42:13] <cradek> apt-get source emc2 will give you the exact source used to build the package
[17:42:36] <cradek> or, you can use our public cvs to get whatever version you like
[17:42:37] <jepler> maddash: You make the mistake of thinking that, since pointers are 4 bytes on x86 systems, that you should add 4 to a pointer to get 'the next one' in an array. But pointer arithmetic is defined in terms of objects, not in terms of bytes.
[17:43:39] <gezar> im going to have to install some stuff first
[17:43:53] <gezar> dpkg-dev and probably gcc and gowd knows whatelse
[17:44:38] <jepler> build-essential, and the things installed by 'apt-get build-dep packagename' should be the only things required to build packagename (to paraphrase debian guidelines). If you find that is not true for emc, please treat it like a bug and let us know what package(s) are missing.
[17:44:42] <jepler> gezar: ^^^
[17:45:11] <jepler> maddash: it might be informative to consider this short program: http://pastebin.ca/845388
[17:45:25] <gezar> well, the source emc2 requires dpkg-dev from a raw install, you want me to document this and plop it on the wiki or?
[17:45:57] <jepler> gezar: see what I said above -- dpkg-dev is installed by build-essential, so not listing it in Build-Depends of emc2 is not a bug.
[17:46:40] <gezar> im not looking at this in terms of a bug, im just checking stuff out
[17:46:51] <jepler> OK I'm explaining why that particular package is not installed by 'apt-get build-dep emc2'
[17:47:40] <jepler> I believe the wiki already covers that you should install build-essential -- http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Installing_EMC2#Preparing_Ubuntu_to_compile_emc2
[17:47:50] <gezar> cool with me, im just flying from the hip here
[17:48:14] <gezar> need something to do for a few minutes is all, and I havnet done these bits :)
[17:48:52] <gezar> i just paid for school, got my id and my parking sticker
[17:49:22] <jepler> for an explanation of build-essential, see http://www.us.debian.org/doc/debian-policy/ch-source.html#s-pkg-relations
[17:52:43] <gezar> jepler: thank you :)
[17:54:21] <maddash> hm, this seems different from when I last used pointer arith, which was when I programmed a Boyer-Moore string search routine
[17:54:28] <maddash> on windows
[17:56:25] <maddash> jepler: if an array is declared -- say, int a[3] -- then a=the address of the array, right?
[17:56:43] <maddash> wow, this is shameful
[17:56:49] <cradek> yes
[17:57:22] <maddash> aren't arrays stored in a block of memory, with each element of the array in adjacent cells of the mem block?
[17:57:22] <jepler> http://www.amazon.com/Programming-Language-Prentice-Hall-Software/dp/0131103628
[17:57:43] <maddash> :(
[17:57:54] <cradek> a great book
[17:58:32] <gezar> I finally had to remove myself from the debian beowolf email lists
[17:59:06] <cradek> maddash: a[n] -> *(a+n)
[17:59:21] <cradek> <->
[17:59:21] <maddash> noooooooooooooooooo
[17:59:36] <cradek> yes
[17:59:46] <maddash> I declared b and c as hal_bit_t**
[18:00:29] <jepler> in fact you can modify the program I pastebinned to read:
[18:00:29] <jepler> printf("Distance between 0[x] and 1[x] is %d\n", &1[x] - &0[x]);
[18:00:34] <jepler> it still compiles and prints the number "1"
[18:00:41] <jepler> but only the perverse write that
[18:01:42] <jepler> bbl
[18:02:10] <maddash> so, analogous to jepler's example: http://pastebin.ca/845422
[18:02:31] <maddash> which means that I haven't gone nuts
[18:02:57] <maddash> b/c just before I pastebinned my patch, I changed the **b, **c declarations from hal_bit_t to void
[18:03:01] <maddash> er, vice versa
[18:03:49] <maddash> cradek, jepler: did that make sense?
[18:04:57] <maddash> cradek: the 'noo...' was sad realization of my mistake, not an objection to your remark
[18:06:26] <maddash> i=0; avg=0; while [ ${i} -lt 10 ] ; do avg=$[${avg}+`../bin/halcmd -k getp parport.0.read.time`]; i=$[${i}+1]; done; echo $[avg/10]
[18:09:47] <fenn> bash arrays :\
[18:10:11] <maddash> what array?
[18:10:27] <fenn> i dont see any array!
[18:10:43] <maddash> is there anyway to get the execution time of servo-thread w/o having to awk the output of "show thread"?
[18:12:02] <fenn> you could see how halcmd does it
[18:13:21] <Adam1> Adam1 is now known as MASEngr
[18:13:43] <MASEngr> Good morning everyone.
[18:14:01] <fenn> hello. a certain Gamma-X2 is looking for you
[18:14:11] <MASEngr> For me? Why?
[18:14:25] <fenn> he has an anilam crusader and was wondering what you did
[18:14:57] <MASEngr> Ah. That would be Adam. I'm not him.
[18:15:16] <MASEngr> Adam's in Bermuda right now, and he's not coming back.
[18:15:30] <MASEngr> I'd like to ask him a few questions as well.
[18:15:30] <fenn> i dont know whether to be envious or not
[18:15:37] <maddash> sweeeeeet. I increased traj_period by 200us and got a 30us decrease in servo-thread
[18:15:56] <maddash> traj_period doesn't have to be too low, does it?
[18:16:22] <MASEngr> Well, it was cold enough here that when I got in, I couldn't power up my PLC until the heat got the temperature above 0.
[18:16:47] <MASEngr> If you have to choose between that and Bermuda...
[18:16:56] <fenn> maddash: halcmd_commands.c line 1687 or so
[18:17:26] <fenn> i thought maybe he got abducted by aliens or something
[18:17:33] <fenn> or sea monsters
[18:17:42] <maddash> fenn: heh, thanks
[18:17:58] <MASEngr> His girlfriend moved down there too, so I guess you could say that. ;)
[18:18:46] <MASEngr> Anyway, it's broken down. The X axis stopped working this morning, which is why I'm here.
[18:19:06] <MASEngr> How do I find out which pin in the computer is connected to the X axis sensor? I want to find out where the problem is.
[18:19:33] <MASEngr> I'm using an m5i20.
[18:19:33] <fenn> start up emc, open a terminal, and type 'halcmd show X'
[18:20:09] <fenn> uh, show sig X*
[18:21:44] <fenn> unless it has strange naming conventions, should give you something like axis.0.pos-fb <= m5i20.mumble.**-in
[18:21:48] <MASEngr> Uh, should it show me something with the X*?
[18:22:03] <maddash> ehm, xemc goes WACKO when [TRAJaxis!=3
[18:22:03] <fenn> and several other lines
[18:23:17] <MASEngr> I am not getting anything with show sig X*. I get lots with show sig Y*.
[18:23:42] <MASEngr> All I get with show sig X* is the default template: cnc@cnc-desktop:~$ halcmd show sig X*
[18:23:42] <MASEngr> Signals:
[18:23:42] <MASEngr> Type Value Name (linked to)
[18:23:42] <MASEngr> cnc@cnc-desktop:~$
[18:24:04] <MASEngr> This has "long day" written all over it.
[18:25:16] <fenn> can you put the .hal and .ini files on pastebin?
[18:25:57] <MASEngr> Sure, just a moment.
[18:29:41] <MASEngr> Just m5i20_io.hal, m5i20.var, and m5i20_motion.hal, correct? Or do you want others?
[18:30:37] <fenn> the .ini file too
[18:30:49] <fenn> but maybe i'm getting ahead of myself
[18:30:56] <fenn> what seems to be the problem?
[18:31:20] <MASEngr> Well, uh...
[18:31:28] <fenn> does the axis move? go crazy? get following errors?
[18:31:30] <MASEngr> The problem seems to be heat-related.
[18:32:08] <MASEngr> It was stuck at -14.4960 and -14.4956
[18:32:20] <MASEngr> No matter how much you moved it, it would stay there.
[18:32:40] <fenn> and it would bounce between those two numbers when you turn it?
[18:33:16] <MASEngr> Yeah, so I thought there's a problem with the linear encoder, so I wanted to hook a scope up to the computer.
[18:33:25] <fenn> ah
[18:33:30] <MASEngr> But in the meantime, I put a space heater on the machine.
[18:33:36] <MASEngr> Like, right on the machine.
[18:33:40] <fenn> yes it sounds like one of the encoder wires is loose
[18:33:53] <fenn> or maybe a bad solder joint somewhere
[18:33:54] <MASEngr> Or there was condensation on the glass plate.
[18:34:14] <fenn> did the space heater "fix" it?
[18:34:17] <MASEngr> It was below 0 this morning. I couldn't turn on some of the machines or they'd break.
[18:34:25] <MASEngr> Yeah, but that seems a little weird.
[18:34:47] <fenn> if you have a bad solder joint, heat will make it expand and touch again
[18:35:04] <fenn> you can sometimes use a hot air pen to find bad joints that way
[18:35:19] <MASEngr> Yeah, I use cold-spray to find them most of the time.
[18:35:32] <MASEngr> There's no solder on this section, though.
[18:36:31] <MASEngr> It's a solid section of wire from the encoder to parts outs...
[18:36:53] <fenn> i mean in the encoder or on the m5i20
[18:36:59] <MASEngr> ...Ah, unless the bad joint is elesewhere and the residual heat has warmed up the rest of the room.
[18:37:40] <MASEngr> Yeah, I wouldn't be surprised, actually. They used a solder gun to do most of the work, no flux, only rosin core.
[18:37:54] <MASEngr> Ah, this has "long day" written all over it. :(
[18:38:10] <fenn> relax.. worrying won't fix it
[18:38:32] <MASEngr> I'm not worried. I'll either find it, or keep looking.
[18:39:01] <fenn> so, first thing i'd do is pull the connector off the linear scale and scope its outputs
[18:39:39] <MASEngr> We're working on that. The connector's almost as old as I am.
[18:39:53] <fenn> yum
[18:40:16] <MASEngr> That's what I came in to ask about the pins for - to scope the outputs to find out where the problem was.
[18:40:29] <MASEngr> Yeah, it's a pretty nifty connector.
[18:40:42] <MASEngr> I'll have to recalibrate the machine afterwards, won't I?
[18:41:10] <fenn> i dont know. how does homing work on that?
[18:41:58] <MASEngr> On a scale that's not reading? Not that well, I'd imagine.
[18:42:14] <MASEngr> We moved the X axis by hand and the machine didn't pick up on it.
[18:42:31] <MASEngr> I guess that's better than having everything cut in a straight line. :)
[18:43:14] <fenn> you could turn it into a lathe :0
[18:48:58] <MASEngr> That's a good plan, acutally. Turn it into a vertical lathe and sell it on eBay for $100k.
[18:49:09] <MASEngr> Then we could just buy a new CNC machine.
[18:49:51] <BigJohnT> might be able to buy some scales from Gamma-X...
[18:50:18] <MASEngr> "Amazing vertical lathe. Now you don't have to spend precious seconds reorienting vertical parts. They come out of the machine the right way up."
[18:52:34] <SWPadnos> what if they're meant for a conveyor belt?
[18:52:56] <bill2or3> you'll have to tip the machine on it's side, sorry.
[18:53:07] <SWPadnos> damn. at least it's small
[18:56:55] <fenn> i wonder why 5 pounds of potatoes cost the same as 5 pounds of organic orange
[18:56:57] <fenn> s
[18:57:21] <SWPadnos> I sonder why 5 pounds of corn flakes costs as much as 5 pounds of steak
[18:57:24] <SWPadnos> wonder
[18:57:54] <maddash> because the former has greater nutritional value?
[18:58:06] <SWPadnos> hmmm. not for humans
[18:58:27] <SWPadnos> I guess I'll go bhave a bowl of cereal. bbias
[18:59:00] <fenn> since you are what you eat, and cows are made from corn (usually) does that mean milk and cereal isn't kosher?
[19:00:34] <SWPadnos> no
[19:00:38] <SWPadnos> oy vey if that were true
[19:00:43] <SWPadnos> oy gott in himmel
[19:00:49] <bill2or3> what if it's pork-flavored cereal?
[19:01:04] <SWPadnos> as long as it's kosher pork flavoring, it should be OK ;)
[19:01:18] <bill2or3> whew!
[19:07:09] <alex_joni> heh
[19:14:33] <jepler> maddash: arithmetic on void* is a gcc extension; it is not standard "C". But it is more or less analagous to casting to char*, in which case you do have to always work in terms of bytes. but the point of pointers having a "pointed to" type is that you don't write casts and you don't refer to sizeof when doing pointer arithmetic.
[19:15:19] <jepler> (see info gcc "C Extensions" "Pointer Arith")
[19:18:26] <jepler> MASEngr: I didn't see whether you got an answer about your problem with 'halcmd show ... X*' but remember that in unix, the shell does wildcard expansion for filenames. If you are invoking 'halcmd show ...' from the shell, put quotes around any wildcards that you want to be certain are interpreted by halcmd: $ halcmd show pin "X*"
[19:19:22] <fenn> the wildcard is actually unnecessary
[19:20:26] <jepler> that's true too -- use the wildcard only if you want to match a variable part that is not at the end of the name.
[19:21:01] <jepler> this pastebin illustrates what I was talking about: http://pastebin.ca/845578
[19:22:49] <fenn> $ halcmd show sig XYZZY
[19:22:59] <fenn> (nothing happens!)
[19:24:43] <SWPadnos> halcmd show sig "*X*"
[19:25:06] <fenn> am i blind or is there no documentation on the regex stuff?
[19:25:16] <SWPadnos> man regex ;)
[19:25:31] <cradek> the shell does not use regex
[19:26:00] <SWPadnos> but it should try to glob *X*
[19:26:02] <SWPadnos> ?
[19:26:03] <cradek> and I believe neither does halcmd
[19:26:13] <fenn> no i mean the ** stuff halcmd does
[19:26:14] <SWPadnos> halcmd uses something like regex
[19:26:18] <jepler> halcmd uses fnmatch() which is similar to shell glob
[19:26:53] <SWPadnos> I've noticed that some of the fancier stuff doesn't always work, bu I figured it was my typing or improper quoting
[19:27:02] <cradek> shell glob != regex
[19:27:03] <SWPadnos> like *[xX]*
[19:27:07] <jepler> 'man 7 glob' should be an accurate reference for halcmd patterns
[19:27:07] <SWPadnos> I understand
[19:27:11] <SWPadnos> ok
[19:28:59] <gezar> im making chips with the shaper:)
[19:29:42] <fenn> your nano-mill?
[19:30:09] <gezar> i got some aluminum blocks from a shop and im squaring them up
[19:30:29] <fenn> aluminum on aluminum ways dont work so good
[19:31:26] <fenn> (unless you anodize them)
[19:32:27] <gezar> the more i think about it, the more im wanting to make the ways out of brass or steel
[19:32:53] <bill2or3> brass?
[19:32:55] <fenn> btw why brass leadscrews on plastic nuts?
[19:33:00] <bill2or3> isn't that awfully soft?
[19:33:10] <gezar> where i basically make an L shape out of the other material, and then mill or shape a slot to drive the L into
[19:33:20] <fenn> brass is harder than aluminum usually
[19:33:29] <bill2or3> ahh, ok.
[19:33:36] <gezar> its just to have something, nothing fancy but just to have something
[19:34:23] <gezar> brass will deform some with plastic, and they appered to be of superior quality compared to the steel screws at the store
[19:34:43] <gezar> that and they look cool
[19:34:52] <bill2or3> you're making a small benchtop mill?
[19:35:00] <fenn> a palmtop mill
[19:35:09] <gezar> if by small you mean fits in shirt pocket yes
[19:35:12] <bill2or3> really? that sounds neat.
[19:35:25] <bill2or3> you'll make a fortune counterfeiting quarters.
[19:35:42] <fenn> dunno if i mentioned before but i've got a palmtop hexapod in the works
[19:35:50] <bill2or3> any pictures up?
[19:36:13] <gezar> 20 hours to machine 1 quarters face, 40hors/ quarter, the power to do it would cost more then a quarter
[19:36:28] <fenn> nah electricity is cheap
[19:36:35] <fenn> and a nano-mill would hardly use any
[19:36:58] <gezar> i dont think its going to have the power to machine metals
[19:37:15] <bill2or3> you could make dollar coins instead, you'll be rich!
[19:37:17] <gezar> hell it might, I think my steppers are like 2oz inch if that
[19:37:29] <fenn> dont need much power with small tools and small removal rates
[19:38:01] <bill2or3> are you using steppers from cdrom drives, or something?
[19:38:21] <gezar> I could wack apart one of thse dremel atatchments wands or whatever, as a spindle and a small motor to drive it, that way I sorta have a tool change
[19:38:36] <gezar> yeah, those little steppers that move the optics around
[19:38:39] <fenn> cd-rom's have a nice little acme threaded rod in them
[19:38:44] <bill2or3> that is a tiny mill.
[19:38:54] <bill2or3> yeah, I always save that part when thowing out old drives.
[19:38:56] <fenn> and since the stepper already is attached to it..
[19:39:06] <gezar> fenn its not quite that
[19:39:08] <bill2or3> I want to make a cd-labeling plotter, eventually.
[19:39:43] <fenn> bill2or3: polar coordinates?
[19:40:03] <bill2or3> nah, it'll take hpgl input.
[19:40:34] <gezar> how does brass on aluminum sound, same metal fatigue issues?
[19:40:46] <fenn> i mean, you keep the read-head and turntable assemblies, and put a pen in place of the lens
[19:41:28] <bill2or3> I'd use two leadscrew assemblies.
[19:41:33] <fenn> but instead of going around really fast in a spiral, you gear down the turntable so you can move in a coordinated fashion
[19:42:01] <gezar> monarch makes an uber mill with that sort of configuration
[19:42:15] <fenn> really, not a drill press?
[19:42:16] <bill2or3> I hadn't really considered that way. I've beeh working on some X-Y plotter code for another project, so I'll reuse that code.
[19:42:17] <gezar> y z and a rotary table
[19:42:44] <gezar> Im talking uber 75hp spindle
[19:43:22] <fenn> bill2or3: hpgl is quite similar to g-code, and so you could use hp2xx to convert to g-code and use emc's kinematics to translate to r/theta at the motors
[19:43:51] <gezar> back to the ways though, I dont know if I have an effective way method, maybe if I put brass inserts in the moving part, to ride on the brass way?
[19:44:54] <gezar> yeah, i think inserts would be fine
[19:45:41] <fenn> you could use 5 ball bearings
[19:48:29] <fenn> you could use hard maple and lots of bacon grease
[19:49:35] <fenn> gezar: seriously though, if you have a swivel vise for the shaper you should do a tapered gib
[19:50:19] <fenn> cut the taper first, then set the vise back to square, superglue your gib onto the taper, and cut both sides of the dovetail
[19:51:03] <fenn> or you could find some other way to hold the piece off-square, since the angle doesnt really matter
[20:05:16] <gezar> lets see, if I make L brackets, Ide have to make 6 of them and on top of that make them so I can screw them into a slot, I cant just press them in
[20:05:58] <gezar> still thinking here
[20:06:11] <gezar> its all going to be about .1 inch wide at most
[20:07:58] <gezar> maybe dove tail type blocks would be better, that way I screw in the dovetails, and then I can drive in a flat way surface onto one part
[20:08:53] <gezar> then with mini screws jack the flat down, to adjust the gig?
[20:09:04] <gezar> gib
[20:09:27] <gezar> no that has nightmare written all over it
[20:09:48] <gezar> if I do L blocks Ill need C blocks as well
[20:10:20] <gezar> that seems more doable
[20:11:31] <fenn> what's a C block? box ways?
[20:12:19] <gezar> the C fits into the L so that I cant lift the surfaces off each other, they have to slide together
[20:12:48] <gezar> C7 lift the c up into the -- part of the 7
[20:13:15] <gezar> yeah, block ways
[20:13:42] <gezar> |_-| |-_|
[20:13:43] <fenn> well if you've got a shaper... dovetails seem easier
[20:14:24] <gezar> i agree, its making things small enough to be good
[20:14:45] <gezar> without haveing to bathe them in oil
[20:15:39] <gezar> thats why im on the drafting phase, and ive got to go do more math reading for school prep work...ill try to have something soon as far as an easy way to way
[20:15:56] <fenn> just make one sliding way
[20:16:07] <fenn> then you'll look at it tomorrow and realize how terrible it is
[20:18:03] <skunkworks> I would want ball bearings of some kind.
[20:19:06] <Jymmm> I missed the first part, what are you trying todo gezar
[20:19:11] <fenn> this is your competition gezar http://www.craftsmanshipmuseum.com/images/Jordan06.JPG
[20:20:27] <skunkworks> some people have way too much time on their hands..
[20:20:32] <Jymmm> fenn: Is that functional (less electrical) ?
[20:20:48] <fenn> Jymmm: yes and the electrical stuff works too
[20:20:55] <Jymmm> ah, cool
[20:21:01] <gezar> yeah, that guy is uber
[20:21:14] <gezar> i just want function
[20:21:41] <fenn> kinda reminds me of feynman talking about nanotech
[20:21:43] <gezar> nothing fancy, but I need a way system that works, and that I can machine out of simple materials
[20:22:00] <skunkworks> gezar: are you actually wanting to machine sugar cubes? or is there something else you have in mind?
[20:22:05] <BigJohnT> what about square ways?
[20:22:11] <fenn> first you make a pair of robotic hands.. then you build a smaller set of hands with those, repeat ad infinitum
[20:22:58] <gezar> square is fine if I can get a lip, im going to go study and then draw some, ill be back in a few hours
[20:23:48] <maddash> fenn: does that thing actually cut?
[20:25:06] <fenn> maddash: yep more pics here http://www.craftsmanshipmuseum.com/Jordan.htm
[20:32:40] <fenn> i bet he gets a lot of backlash in the leadscrew
[20:32:42] <maddash> [sigh] so awesome, yet so pointless
[20:32:47] <maddash> what's backlash again?
[20:33:03] <BigJohnT> it's what your mamma use to do...
[20:33:18] <BigJohnT> when you didn't mind
[20:34:14] <SWPadnos> yo mama fight! http://www.milkandcookies.com/link/63279/detail/
[20:36:06] <maddash> rofl the floating chalk
[20:36:10] <SWPadnos> heh
[20:36:21] <SWPadnos> and the star-wars-esque "background music" :)
[20:38:02] <SWPadnos> here's my favorite: http://www.adultswim.com/video/?episodeID=8a25c392132b05a201132b098c6d0008
[21:09:28] <maddash> hm, start-stop-daemon's (ssd) -b option doesn't work with scripts/emc
[21:13:19] <jepler> not only that, but cpio won't accept emc's output as a valid cpio file.
[21:14:18] <maddash> 'cpio'?
[21:14:31] <maddash> rtfm-ing
[21:14:44] <cradek> I think he's making fun of you
[21:15:24] <jepler> It's an oblique way of saying that emc is not a daemon program
[21:15:59] <SWPadnos> I have a script that works as an init script to start/stop a HAL app
[21:16:00] <jepler> just like it's not a program for creating archives of files
[21:16:19] <SWPadnos> it's kind of ugly - I'd like to not have to hard-code the location of the hal files, but oh well
[21:16:41] <maddash> scripts/emc is just another bash script, so there's no reason why it shouldn't work
[21:16:59] <SWPadnos> it starts a number of processes, I'm not sure that s-s-d handles that correctly
[21:18:10] <jepler> it's possible you could enhance the emc script to 'trap' certain signals and, if they're delivered, to try to kill the user interface process after which the script will naturally exit
[21:19:01] <jepler> but then you'll find that the user interfaces don't respond to a regular signal interface because they are not daemons...
[21:19:04] <jepler> bbl
[21:19:08] <SWPadnos> heh - in my case, the application is a bare HAL app, which also creates a CPU-hog to improve latencies
[21:19:24] <SWPadnos> I never bothered to figure out how to get that to go away with halapp stop
[21:19:35] <SWPadnos> (halapp is the name of my script, in case you're wondering)
[21:23:50] <maddash> meh w/e. it works.
[21:24:19] <SWPadnos> cool. what options did you end up needing?
[21:24:38] <SWPadnos> also, do you have the computer set to auto-login a certain user?
[21:25:53] <maddash> no, this is a simple /etc/init.d/ script that executes 'start-stop-daemon --start -b --pidfile $PIDFILE --exec ${HOME}/emc2/scripts/emc ${HOME}/emc2/configs/stepper/stepper_inch.ini\
[21:26:02] <maddash> er, sans trailing \
[21:26:24] <SWPadnos> ok, so it isn't meant to run EMC at startup?
[21:26:30] <maddash> no, it does
[21:27:10] <SWPadnos> hmmm. so it should need X to be running, and someone logged in, no?
[21:27:31] <maddash> dammn, you're right -- I keep forgetting that I'm ssh -X
[21:27:34] <SWPadnos> actualyl, it'll start X if needed, but the login thing still has me puzzled
[21:27:41] <SWPadnos> *actually
[21:28:35] <maddash> why login? just 'startx' manually to bypass the DM
[21:28:57] <maddash> hm, my method doesn't even work with DISPLAY=dummy -- the script just returns
[21:29:26] <SWPadnos> -b means "background", andit can't check any error status in that case (form a manpage for ssd)
[21:29:37] <SWPadnos> are you trying to do a headless system?
[21:29:47] <maddash> yeah, kinda
[21:30:23] <maddash> I don't really need a GUI or keyboard b/c I've got external jogs, feedknobs, and led readout
[21:30:58] <maddash> er, not headless
[21:31:35] <SWPadnos> just no GUI
[21:31:37] <SWPadnos> ?
[21:31:48] <maddash> that's correct
[21:33:06] <maddash> ah, fixed the dummy display issue
[21:33:18] <SWPadnos> ok, that'll be tough with the EMC run script. it launches a program (DISPLAY) and waits for it to exit, at which time it unloads the RT system and cleans up
[21:33:36] <SWPadnos> but if the program forks, that looks like an exit to the run script, I think
[21:33:39] <maddash> moral of the story: 'read foo' does not block when issued in a forked script
[21:33:39] <cradek> wonder if you could use DISPLAY=halui with a bit of hacking to the run script
[21:33:45] <SWPadnos> I was thinking that
[21:33:54] <SWPadnos> does halui fork?
[21:34:00] <cradek> doubt it
[21:34:00] <SWPadnos> I'd assume it does
[21:34:04] <maddash> does it matter?
[21:34:09] <SWPadnos> yes
[21:34:11] <maddash> all the other GUIs work fine
[21:34:13] <jepler> I don't believe it does
[21:34:28] <jepler> halcmd is where the smarts are to start userspace components 'in the background'
[21:34:30] <SWPadnos> ok - does halcmd fork for loadusr then?
[21:34:32] <SWPadnos> ok
[21:34:33] <maddash> oh, didn't read carefully. no, why should halui fork?
[21:34:43] <SWPadnos> nevermind - halcmd does it for you
[21:35:03] <maddash> cradek: are you incharge of scripts/emc?
[21:35:04] <SWPadnos> the reason is that you want it to keep running, but return control to the terminal
[21:35:08] <SWPadnos> heh
[21:36:35] <jepler> cute trick to find out who is most to blame for a particular source file: cvs annotate emc.in | awk '{print $2}' | sort | uniq -c | sort -n
[21:37:00] <jepler> (counts how many lines of the current revision were most recently touched by each author)
[21:37:24] <fenn> maddash: cat /dev/zero ?
[21:37:26] <maddash> haha
[21:37:35] <maddash> fenn: huh?
[21:37:47] <fenn> it never exits
[21:38:12] <cradek> jepler: or who's most foolish about running indent or using a bad editor
[21:38:26] <jepler> cradek: that fits the definition of "to blame" IMO
[21:38:51] <maddash> hot damn, 'while [ 1 ] ; do sleep 1 ; done' won't keep scripts/emc up properly
[21:40:21] <fenn> maddash: can you just run keystick or is that too much
[21:42:00] <SWPadnos> trouble is you need a terminal for any UI
[21:42:17] <SWPadnos> I don't know where that would come from before a login, during startup
[21:43:30] <maddash> fenn: that could work, I guess, but it'd be hackish
[21:44:52] <jepler> when DISPLAY= is not one of the values that gets treated specially, it is assumed to be a program or script in bin/; write your program that sleeps forever as a script in bin/, make it executable with the right #!-line, and I would fully expect it to work
[21:51:26] <fenn> keystick works much better with ncurses installed..
[21:52:18] <jepler> also whatever program is invoked has to accept a -ini argument
[21:53:14] <SWPadnos> if you havea core 3 duo, I recommend using `while true ; do echo "nothing" > /dev/null ; done` for your "runs forever" script
[21:53:19] <SWPadnos> err - a core 2 duo that is
[21:53:27] <fenn> oh, its not ncurses, it's because keystick is running in a separate xterm rather than on the same console where error messages are printed
[21:53:34] <jepler> this two-liner seems to work:
[21:53:34] <jepler> #!/bin/sh
[21:53:34] <jepler> while sleep 86400; do true; done
[21:53:42] <jepler> though I didn't wait 86400 seconds to test it :-P
[21:53:50] <SWPadnos> heh
[21:53:53] <jepler> the [DISPLAY]DISPLAY=halui seems like a good idea too
[21:53:58] <SWPadnos> c'mon - it's only a day
[21:54:01] <jepler> particularly since you could enhance halui to have a "shut down" button
[21:57:17] <jepler> fwiw http://cvs.linuxcnc.org/cvs/emc2/scripts/emc.in#rev1.82
[21:59:56] <maddash> do I get a prize for fixing the keystick problem?
[22:00:07] <SWPadnos> did you fix the keystick problem?
[22:00:50] <fenn> i think keystick should suppress stderr messages on the terminal it's being displayed on - how to do that?
[22:01:12] <fenn> or "take over" like less or pico
[22:01:31] <cradek> exec 2>/dev/null
[22:01:56] <fenn> i knew that
[22:02:23] <jepler> less and pico don't do what fenn wants either. observe the behavior here: (sleep 3; echo "ha ha ha") & less /etc/fstab
[22:02:39] <jepler> (or echo "ha ha ha" 1>&2, same diff)
[22:04:02] <fenn> i guess you could run it in screen :)
[22:06:50] <fenn> hmm that doesnt work either
[22:09:05] <maddash_> quickie question -- what is '$?" ?
[22:10:06] <bill2or3> in perl? the return value from the last back-ticked system() call.
[22:10:37] <SWPadnos> I think it's the return value from the last program executed (in bash)
[22:11:28] <fenn> Expands to the status of the most recently executed foreground pipeline.
[22:11:35] <fenn> whatever that means
[22:11:46] <SWPadnos> the return value from the last program run ;)
[22:11:51] <SWPadnos> in most cases
[22:12:00] <fenn> why dont they just say that
[22:12:07] <SWPadnos> I suspect it could be the result of an internal test as well
[22:12:20] <SWPadnos> like [ or while
[22:16:10] <maddash_> conclusion: start-stop-daemon is fine for starting a fork of scripts/emc, but useless for stopping it
[22:16:19] <maddash_> use pkill for the latter
[22:16:51] <SWPadnos> yeah - it's not clear (to me at least) which PID ssd would pick up from EMC - there are several programs that get run
[22:17:06] <fenn> maddash_: why not just stick emc in /etc/init.d?
[22:17:24] <fenn> with appropriate symlinks of course
[22:17:28] <maddash_> fenn: because it blocks
[22:18:05] <Gamma-X2> vfd came woohoo! and my vise, my other stuff comes tomorow
[22:18:10] <fenn> uh, wrap it with a script that calls emc &?
[22:18:24] <fenn> i think its past my bedtime
[22:19:41] <maddash_> fenn: why didn't I think of that?
[22:19:52] <maddash_> geez, all that wasted time
[22:21:06] <maddash_> now, let's see if I can replicate this keystick problem
[22:26:42] <fenn> what no backplot in keystick??!
[22:26:59] <fenn> * fenn breaks out the libnethack
[22:27:20] <SWPadnos> try for aalib-backplot
[22:27:28] <fenn> eesh googling 'libnethack' brings up #emc
[22:27:34] <SWPadnos> heh
[22:29:38] <maddash_> wow
[22:29:42] <maddash_> google updates fast, then
[22:30:05] <fenn> no it's just my brain stuck in a rut
[22:30:37] <maddash_> ...or not
[22:30:55] <maddash_> freaking aol webmail
[22:31:42] <fenn> hmm keystick really needs tab completion for opening files
[22:31:56] <maddash_> who the heck uses keystick anymore?
[22:32:11] <SWPadnos> you should, after all that complaining
[22:32:13] <SWPadnos> :)
[22:32:37] <maddash_> I was complaining?
[22:32:47] <SWPadnos> maybe
[22:32:52] <SWPadnos> did you fix keystick?
[22:33:05] <maddash_> no, I'm still trying to replicate the problem
[22:33:18] <SWPadnos> oh. what was the problem?
[22:33:20] <SWPadnos> or is
[22:35:26] <fenn> i'd use keystick if it worked on a 16 character LCD
[22:35:35] <fenn> maybe that's a bit much to ask
[22:36:55] <maddash_> ahhh, I see
[22:43:06] <maddash_> btw, both keystick and xemc go shit crazy when AXES!=3
[22:43:52] <Jymmm> I like keystick actually
[22:44:37] <SWPadnos> keystick has a very instructive typedef:
[22:45:14] <maddash_> jepler: fixed
[22:45:17] <SWPadnos> typedef enum {
[22:45:19] <SWPadnos> AXIS_NONE = 1,
[22:45:21] <SWPadnos> AXIS_X,
[22:45:22] <SWPadnos> AXIS_Y,
[22:45:24] <SWPadnos> AXIS_Z
[22:45:25] <SWPadnos> } AXIS_TYPE;
[22:45:30] <maddash_> http://www.pastebin.ca/845868
[22:45:49] <maddash_> jepler: super hack, though.
[22:47:28] <maddash_> so, doI get points or what?
[22:52:14] <fenn> makes sense to me
[22:52:23] <maddash_> yayz.
[22:52:33] <maddash_> now, someone patch me in!
[22:52:44] <maddash_> * maddash_ is gleeful b/c he's finally contributed
[22:52:54] <maddash_> er, formally, that is
[22:53:34] <maddash_> fenn: now you can run keystick in console
[22:53:47] <maddash_> fenn: i.e., w/o X
[22:54:21] <fenn> uh, you could do that already
[22:54:48] <fenn> have to mess with scripts/emc
[22:55:10] <fenn> unless that just got fixed in 1.82
[22:55:37] <maddash_> fenn: actually, you ccan't, b/c of the nml buffer delay problem
[22:56:57] <fenn> xterm-bin: DISPLAY is not set
[22:57:53] <fenn> oh you're right
[22:59:42] <maddash_> hell, whoever hardcoded 'xterm' into scripts/emc should be dunced
[23:00:18] <maddash_> anyway, kill off that "Xterm ..." prefix, leaving "$EMC_DISPLAY ..."
[23:00:23] <maddash_> and you're done
[23:00:53] <fenn> * fenn is suffering from screen/virtual desktop/virtual terminal overload
[23:08:49] <maddash_> did jepler die?
[23:08:53] <maddash_> maddash_ is now known as maddash
[23:12:03] <maddash> nooooooooooooooooo kernel bug
[23:12:14] <fenn> dont panic!
[23:15:46] <maddash> wtf? it only panics when I "su ${non-root user} -c ${HOME}/emc2/scripts/emc ..."
[23:16:08] <maddash> weird
[23:17:28] <maddash> argh 32 min and still no CVS revision
[23:19:56] <gezar> im going with aluminum on aluminum way surfaces
[23:20:11] <gezar> its a proto type machine, and I want to keep thigs simple
[23:26:55] <Gamma-X2> anyone good with schematics?
[23:26:59] <Gamma-X2> eric_U u alive?
[23:27:06] <Gamma-X2> or perhaps available?
[23:34:06] <Gamma-X2> BigJohnT whats up man.
[23:34:13] <Gamma-X2> i got my vfd and other nice things .
[23:34:19] <maddash> jepler: can you pleeeeeasse commit my patch?
[23:34:26] <maddash> jepler: http://www.pastebin.ca/845868
[23:38:00] <BigJohnT> Gamma just getting in
[23:38:18] <BigJohnT> hooking up the slave side for the X axis on my plasma
[23:39:11] <Gamma-X2> nice.
[23:39:13] <gezar> heh, my shaper is loving the work its getting, it even sounds cool
[23:39:37] <BigJohnT> gezar you making ways?
[23:40:01] <maddash> if you can't commit, you must acquit
[23:42:31] <fenn> * fenn retires to his bedchamber
[23:42:42] <maddash> ADIOS.
[23:42:49] <dmess> that a boy gezar:.. run'er hard...
[23:42:55] <gezar> making blocks to get back into machining
[23:44:05] <gezar> im about to tell 24 people im sick of playing world of warcraft with them, I cant do that sheet no more
[23:46:49] <Gamma-X2> lol
[23:47:25] <Gamma-X2> i havnt played that game in years
[23:47:31] <BigJohnT> Gamma you get your VFD?
[23:47:34] <Gamma-X2> anyone usin a vfd
[23:47:37] <Gamma-X2> this thing is insane! lol
[23:47:45] <Gamma-X2> great minds think a like!
[23:47:55] <Gamma-X2> i thought it would be so much bigger
[23:48:20] <eric_U> Gamma-X2: what you want?
[23:48:23] <Gamma-X2> hitachi sj200-022nfu2
[23:49:02] <BigJohnT> I've used a bunch of VFD's Gamma
[23:49:11] <Gamma-X2> eric_U i got a schematic of the pin layout u think u can make out what it is? im kinda lost with a schematic
[23:49:21] <eric_U> can you post it?
[23:49:26] <Gamma-X2> sure
[23:51:11] <Gamma-X2> where can i post a pdf?
[23:51:58] <Gamma-X2> anyone?
[23:52:53] <Gamma-X2> eric_U id also like to see how with viewing the other schematics for the machine, how can i intergrate this to it does not conflict with the other wiring in the machine
[23:53:45] <Gamma-X2> if u want i can email it to u.