#emc | Logs for 2009-06-06

Back
[01:35:10] <jeshua> i created a stepconf file using the wizard, is it possible to edit the stepconf to assign +5V to a pin?
[01:42:38] <cradek> in your custom hal file, you can set an unused pin high
[01:43:00] <cradek> there's no guarantee your computer will give 5v in that case - not sure if you are asking for a high signal, or a power source to use for something
[01:43:58] <jeshua> it is a powersource for my gecko G320
[01:44:36] <SWPadnos> uh - the G320 can't usea 5V power source for anything
[01:44:39] <jeshua> i bought a controller all wired up, and the person who built it was using pin 5 for +5V and pin 24 for -5V
[01:45:04] <SWPadnos> is that for the enable inputs to the G320s?
[01:45:29] <SWPadnos> (called ERR/RES, I think)
[01:45:57] <jeshua> the Gecko manual says:
[01:45:59] <jeshua> "The encoder must be a digital quadrature TTL output type that operates on a single +5VDC power supply. The power
[01:46:01] <jeshua> supply current rating must be less than 50 mA. "
[01:46:28] <SWPadnos> the G320 provides a 5V output for encoders, you don't have to feed it 5V for that
[01:46:38] <SWPadnos> and there's no -5V used anywhere
[01:46:52] <SWPadnos> (that's probably a typo for 5V return or something)
[01:48:22] <jeshua> hmmm - this wire digram shows +5V and -5V: http://OpenOSX.com/GeckoG320Wiring.pdf
[01:49:05] <jeshua> my controller is wired like this: http://OpenOSX.com/geckos.png
[01:49:55] <SWPadnos> I don't see -5V anywhere on that diagram
[01:50:41] <jeshua> above the parallel port
[01:50:58] <jeshua> says ground from PC P.S.
[01:51:18] <SWPadnos> ok, that's not -5V, that's the - (minus) side of the 5V supply :)
[01:51:40] <jeshua> sorry - I am noob
[01:51:45] <SWPadnos> no problem
[01:52:38] <SWPadnos> so, in the geckos.png image, are the red lines that say "5" and "10" connected to the parallel port pins 5 and 10?
[01:52:56] <jeshua> yes
[01:53:24] <jeshua> and 24 to parallel port pin 24 (ground)
[01:53:39] <SWPadnos> does the pdf file describe anything in your system, or was that for reference info?
[01:54:03] <jeshua> that was just reference
[01:54:12] <SWPadnos> ok, phew
[01:54:15] <jeshua> trying to figure out my controller
[01:54:50] <jeshua> when I used the generic stepper conf, the Y motor would spin (in 1 direction only)
[01:55:02] <jeshua> and the X and Z would barely move
[01:55:26] <SWPadnos> and you have a physical "emergency stop" button?
[01:55:39] <jeshua> yes - that much works
[01:56:00] <SWPadnos> ok. it's a weird setup, that's for sure
[01:56:14] <jeshua> i had to invert pin 10 in the step conf wizard
[01:56:16] <SWPadnos> don't leave the e-stop on for long, or you'll probably burn out your parallel port pins
[01:56:30] <jeshua> yea - I wouldn't know ;)
[01:56:40] <jeshua> oh - thats lame!
[01:57:07] <SWPadnos> it looks like they just short pins 5 and 10 to ground when you hit the switch, which prevents step pulses from getting to the geckos
[01:57:20] <cradek> uhhhh
[01:57:39] <jeshua> i was thinking it broke the +5v circut?
[01:57:54] <SWPadnos> it breaks it all right
[01:57:56] <SWPadnos> eventually
[01:58:00] <jeshua> hahaha
[01:58:06] <SWPadnos> unless that diagram is wrong, which is also possible
[01:58:20] <jeshua> i drew it by looking at the system
[01:58:24] <SWPadnos> oh, ok
[01:58:31] <SWPadnos> it's still possible :)
[01:58:43] <jeshua> it represents my best understanding of what I have ;)
[01:58:47] <SWPadnos> do you have a spare USB port?
[01:58:55] <jeshua> yes
[01:59:03] <SWPadnos> ok, here's my suggestion
[01:59:11] <jeshua> cool
[01:59:38] <SWPadnos> 1) sacrifice a USB cable, and use that for a 5V supply (USB is current limited to 100 mA unless a device asks for more, so you won't hurt anything)
[01:59:50] <jeshua> nice
[02:00:08] <SWPadnos> 2) disconnect pins 5 and 10 from the controller - they will now become available for something else later
[02:00:20] <jeshua> cool
[02:00:30] <SWPadnos> stick the E-Stop button in series with the 5V from the USB cable
[02:00:41] <toastydeath> man, e-stop
[02:00:44] <SWPadnos> it doesn't need to connect to pin 24 any more
[02:00:52] <jeshua> ok
[02:01:08] <jeshua> so where does the ground from USB go?
[02:01:09] <SWPadnos> check the switch though, it may not be a real e-stop switch
[02:01:30] <SWPadnos> ground from USB doesn't need to connect anywhere, it's the same as the parallel port
[02:01:31] <jeshua> its a big red button - looks real to me :)
[02:01:35] <toastydeath> we have a machine whose e-stop does nothing
[02:01:39] <SWPadnos> you could connect it to pin 24 if you like
[02:01:40] <toastydeath> its just a button
[02:01:45] <toastydeath> connected to nothing
[02:01:47] <SWPadnos> (just make absolutely sure it's ground first ;) )
[02:02:14] <SWPadnos> a real e-stop switch will have closed contacts when it's "out" (or safe), and will open the contacts when you hit it
[02:02:16] <jeshua> it just has two connections - looks like a switch as far as I can tell
[02:02:34] <SWPadnos> that way, if a wire breaks, the system acts as though the e-stop switch has been hit
[02:03:03] <jeshua> i will test it right now
[02:03:25] <SWPadnos> how do you reset it once it has been pressed?
[02:03:35] <SWPadnos> (usually you have to twist it or pull it out)
[02:04:22] <jeshua> when it is out it is ON - when it is pushed in it is OFF
[02:04:34] <SWPadnos> ok, that's good
[02:04:46] <SWPadnos> off meaning that you get no continuity?
[02:04:53] <jeshua> correct
[02:05:03] <SWPadnos> ok, that should be good then
[02:05:25] <SWPadnos> actually, that's all you need to do to "fix" what you've shown us
[02:05:50] <jeshua> so it is pretty simple huh, just use +5v from usb, and disconnect the other pins?
[02:05:52] <SWPadnos> you'll get a couple of extra I/Os, and you'll have a better e-stop system
[02:05:57] <SWPadnos> yep
[02:06:04] <jeshua> awesome!
[02:06:26] <jeshua> and use the estop to make the USB +5V connection right?
[02:06:30] <SWPadnos> yep
[02:06:36] <jeshua> sweet!
[02:06:43] <SWPadnos> that's probably the easiest way to do it.
[02:06:45] <jeshua> you rock!
[02:07:09] <SWPadnos> you can optionally add a couple of resistors to the estop setup that can let EMC2 know when you've hit the button
[02:07:22] <jeshua> thanks so much for helping someone so clueless!
[02:07:33] <SWPadnos> no problem. everyone's got to start somewhere
[02:07:42] <jeshua> where would those resitors go? like 1k?
[02:07:45] <SWPadnos> and you're not so clueless - you can use a multimeter :)
[02:08:00] <jeshua> hahah - no it is a flashlight :D
[02:08:05] <SWPadnos> heh
[02:08:34] <jeshua> i need a new multimeter - last one got fried :)
[02:08:59] <jeshua> my buddy tested his car battery with it in unfused mode - it smoked
[02:09:08] <SWPadnos> lemme see - you'd want to choose an input pin (check the manual to see the parport pinout), connect a 4.7k (or so) resistor from that pin to ground
[02:09:38] <SWPadnos> then conect that pin to the switched side of the e-stop switch
[02:10:03] <SWPadnos> when e-stop is "OK", the pin will be at 5V (with a milliamp or so wasted in the resistor)
[02:10:11] <jeshua> i see
[02:10:20] <SWPadnos> when the estop is hit (not OK), the resistor will bring the pin to ground
[02:10:31] <jeshua> neat!
[02:10:35] <SWPadnos> then select that pin as "ESTOP In" in stepconf
[02:10:42] <jeshua> got it
[02:10:52] <jeshua> man I love parallel ports!
[02:10:56] <SWPadnos> heh
[02:11:07] <jeshua> too bad they are "archaic"
[02:11:27] <SWPadnos> there are many better ways to drive a machine, but few cheaper
[02:11:35] <jeshua> parallel forever
[02:11:42] <jeshua> and as easy
[02:11:47] <toastydeath> if one of you shows up with a parallel port tattoo
[02:11:48] <SWPadnos> I wouldnt' take that bet
[02:11:49] <toastydeath> hero forever
[02:12:01] <jeshua> hahaah
[02:12:07] <jeshua> yes!
[02:12:14] <toastydeath> v. 8-bit
[02:12:55] <jeshua> btw: toastdeath, did you learn anything to make your estop actually work? might be slightly more effective if it actually did something!
[02:13:33] <toastydeath> the machine moves so slowly it isn't necessary
[02:13:43] <jeshua> ahh
[02:14:04] <jeshua> ever see the movie "A fish called Wanda"?
[02:14:47] <SWPadnos> uh oh
[02:14:50] <jeshua> in the end of the movie, someone is run over by a steam roller - pretty funy
[02:14:57] <jeshua> uh oh?
[02:15:03] <SWPadnos> and he gets pissed off about it too :)
[02:15:10] <jeshua> hahaha
[02:15:49] <jeshua> i guess I would be pretty pissed too ;)
[02:16:00] <SWPadnos> or something
[02:16:06] <jeshua> hahah
[02:16:21] <jeshua> I would try this USB +5v out now, but I need some fuses, and I live in a one horse town :(
[02:16:25] <SWPadnos> heh
[02:16:35] <SWPadnos> it's bedtime for me anyway. good luck with it
[02:16:46] <jeshua> thanks a million SWPadnos!
[02:16:51] <SWPadnos> sure
[02:16:57] <jeshua> happy machining!
[11:51:47] <anonimasu> morning
[11:53:07] <anonimasu> jeshua: you should look at the geckodrive site for the proper diagram
[11:59:34] <anonimasu> hmm.. did anyone build a interfeometer yet ?
[11:59:35] <anonimasu> ^_^
[12:19:06] <BigJohnT_> BigJohnT_ is now known as BigJohnT
[14:01:20] <anonimasu> http://www.io23.net/ul/files/TcPlate.png
[14:20:50] <alex_joni> anonimasu: you didn't put dimensions for the top M10 holes, how far from the edge they are
[14:31:43] <anonimasn> ah yeah
[14:33:02] <anonimasn> alex_joni: though that's not so critical, they are to be mirrored about the other holes
[14:33:11] <anonimasn> at +/-/30mm
[14:33:45] <alex_joni> the others aren't either :P
[14:35:47] <anonimasn> * anonimasn nods
[14:39:54] <anonimasn> http://www.io23.net/ul/files/TcPlate.png
[14:39:56] <anonimasn> updated
[14:42:38] <alex_joni> closer ;)
[14:42:58] <alex_joni> the bottom 2 should be 50 and 20 ?
[14:44:08] <anonimasu> which ones?
[14:45:40] <anonimasu> no
[14:45:44] <anonimasu> 19 and 49
[14:46:07] <anonimasu> it's for a support beam /
[14:46:25] <anonimasu> for the plate that connects it to the vertical axis
[14:46:35] <anonimasu> they only need to be relative to the top holes, so that it adds up
[14:46:38] <anonimasu> err mathces
[14:47:59] <anonimasu> they will be moved later
[14:48:24] <anonimasu> I'm gonna calculate how much force it'll apply to the axis with 12 toold stuck in the changer
[14:49:00] <anonimasu> and move it so the motor weight compensates for it :)
[14:49:02] <anonimasu> a bit
[14:52:30] <alex_joni> ah, cool
[14:52:45] <alex_joni> it looked like you dimensioned from the bevelled line, not the side
[14:55:56] <anonimasn> alex_joni: another pic of the thing(if you want to have a look)
[14:56:17] <anonimasn> http://www.io23.net/ul/files/changerAndWheel.png
[14:56:48] <anonimasn> the wheel is a tad bit too large
[14:58:19] <anonimasu> there goes a toothed belt wheel between the wheel and the plate
[14:58:48] <anonimasu> and I'll probably cut a polygon shape on the shaft to make the wheel lock :)
[14:58:50] <lerman_> anonimasn: you asked about interferometers. I have all of the parts sitting in my office. I'm just missing the electronics.
[14:59:16] <anonimasu> isnt it just a laser and a few mirrors you need?
[14:59:27] <lerman_> So many projects; so little time. (Only 168 hours in a week.)
[15:00:10] <anonimasu> :)
[15:00:42] <anonimasu> or do you need a drive for the laser?
[15:00:43] <lerman_> Not just any laser (to do it right). The right way uses a laser that lases at two frequencies separated by a few megahertz and orthogonally polarized.
[15:01:20] <anonimasu> that ends up complex
[15:01:59] <anonimasu> :)
[15:03:10] <lerman_> The electronics I need inputs two signals and counts the edges of one relatively to the other. Ideally, it would measure the fractional offset of the edges of one with respect to the edges of the other. It's an FPGA job, I think.
[15:03:11] <lerman_> It could be done with a mesa card, or a pluto board, or some such.
[15:03:49] <anonimasu> oh you are gonna use them for measuring for positioning?
[15:03:56] <anonimasu> or just calibrating?
[15:04:11] <lerman_> For testing/calibrating. (For fun.)
[15:04:14] <anonimasu> :]
[15:05:08] <lerman_> Stuart showed us a gadget at fest that can measure with a precision of .003 inches inside a forty foot cube.
[15:05:50] <anonimasu> I see :)
[15:05:52] <lerman_> That might be useful to check the calibration of my interferometer when I get it done.
[15:06:22] <anonimasu> yep
[15:07:01] <anonimasu> though 0.003 is like a mountain with a interferometer
[15:08:59] <lerman_> Yes. But if I'm within .003 over a distance of 10 feet that would indicate that my interferometer is working reasonably. If I'm not; that would indicate that I have a problem.
[15:10:02] <anonimasu> * anonimasu nods
[15:19:23] <tlab> does this look right for the output for the x step from a parallel port? http://imagebin.ca/view/uyaZ_1bi.html
[16:50:13] <tomp> tomp is now known as tom3p
[16:52:49] <jmkasunich> tlab: no, but it is possible thaqt you are undersampling
[16:53:25] <jmkasunich> what is the desired step rate? what is the desired step width? what rate is the scope sampling at?
[16:55:25] <jmkasunich> the internet says the TDS2024B has a memory depth of 2500 samples. If you spread that over 10 divisions at 2.5mS per div (per your image), the sample rate is only 10Ks/s
[16:55:32] <jmkasunich> or one sample every 10uS
[16:55:46] <jmkasunich> if your step pulses are less than 10uS long, you will miss some of them completely
[16:56:23] <jmkasunich> you should switch to faster sampling (make the seconds per div smaller)
[16:56:42] <tom3p> Lerman_ what was this 'gizmo Stuart showed at the Fest that msrd to .003" in 10 foot cube' ?
[16:57:07] <jmkasunich> at a hundred nanoseconds per div or so, you'll be able to see the actual width of a single step pulse
[16:57:24] <jmkasunich> at a few microseconds per div, you'll be able to see the spacing between pulses
[16:57:40] <jmkasunich> at a few milliseconds per div, your scope is lying to you
[17:05:48] <lerman_> tom3p: It had a laser on a motorized mount that would follow a corner reflector as you move it. And it was a (I think) 40 foot cube. It has less accuracy at 100 feet. :-)
[17:08:28] <tlab> at 2.5us I can see a single step
[17:08:57] <tlab> but does the overal look right? the duty cycle suppose to look like that?
[17:12:30] <tlab> I guess this all depends on how I setup the step time, etc etc... and what the motor driver needs... this should be fun since I'm making my own motor driver
[17:15:53] <bjt-plasma> how do I tell linux to look in /home/jet for programs so I don't have to type in the ./myprog
[17:21:59] <anonimasu> add it to your config
[17:22:01] <anonimasu> NC_FILES
[17:22:52] <bjt-plasma> * bjt-plasma looking
[17:25:57] <murdoc> hello all.
[17:26:09] <murdoc> murdoc is now known as bogie
[17:26:17] <bogie> erhhh
[17:26:47] <bogie> since today i'm getting a "joint 0 (1) following error"
[17:27:13] <bogie> only on files generated by dxf2gcode.
[17:27:28] <bjt-plasma> anonimasu not for EMC but for typing a command in a terminal window :)
[17:27:43] <bogie> on a simple linear movement by G1 x+() y+()
[17:28:26] <bogie> what can it be? google has only one thread about it. and help does not help :(
[17:28:41] <bjt-plasma> stepper or servo?
[17:28:58] <bogie> stepper
[17:29:21] <bogie> i switch off all steppers but it appears anyway
[17:29:45] <bogie> seem to be an internal error or something
[17:31:14] <bjt-plasma> http://www.linuxcnc.org/docview/html//common_Stepper_Diagnostics.html#r1_2_1
[17:31:18] <bogie> there's nothing special in this displacement, just another linear step
[17:32:47] <bogie> yep. but strange thing that all other gcode programs work
[17:34:48] <bjt-plasma> is the feed rate different between programs?
[17:36:00] <bogie> i tried different and same but it didn't help
[17:36:41] <bogie> i do not
[17:36:59] <bogie> i am not out of range in linear limits
[17:38:45] <bjt-plasma> can you do a rapid move without any problems
[17:39:34] <bogie> yes
[17:39:45] <bogie> definetely
[17:39:59] <bogie> g0 you mean
[17:41:25] <bjt-plasma> yes
[17:42:08] <bogie> what is Stepconf Wizard? i mean how can i run it?
[17:42:10] <toastydeath> the program does need a feed rate
[17:42:14] <bogie> from http://www.linuxcnc.org/docview/html//common_Stepper_Diagnostics.html#r1_2_1
[17:42:19] <toastydeath> g1 x2. y2.
[17:42:22] <toastydeath> for example
[17:42:31] <toastydeath> should freak without a feed rate if it's the first feed in the program
[17:42:44] <bjt-plasma> stepconf is on the cnc menu
[17:43:02] <bogie> toastydeath, of corse
[17:43:10] <bjt-plasma> have you added backlash compensation?
[17:43:16] <bogie> i used it in the previous line
[17:43:24] <bogie> bjt-plasma no
[17:44:05] <bogie> i didnt do anything just generated gcode with "dxf2gcode"
[17:44:16] <bogie> and tried to use it
[17:44:21] <bjt-plasma> what line in the code generates the error
[17:47:58] <bogie> i can't reproduce it precisely but it was like G1 X+1.456 Y+1.347
[17:48:05] <bogie> very simple
[17:50:39] <bjt-plasma> so if you type that in the MDI window you get the error?
[17:51:30] <bogie> oh, i didn't try it.
[18:00:05] <bjt-plasma> nap time here
[18:42:08] <JanVanGilsen> I got the puma homing working!
[18:42:22] <JanVanGilsen> *happy dance*
[18:59:53] <cradek> cool!
[19:01:21] <anonimasu> ^_^
[19:07:00] <JanVanGilsen> now I'm going to set some comparators to check the potentiometers and link them to the limit switches :) that gives me some protection when I'm not homed
[19:07:18] <cradek> good idea
[19:07:52] <cradek> is your work useful to other people with some kind of absolute encoder setup? is it something that could be generalized enough to be put in the main emc2?
[19:12:01] <JanVanGilsen> We could start a wiki page to collect ideas about this kind of homing and how it could be implemented in emc2
[19:12:13] <cradek> that sounds great
[19:15:20] <JanVanGilsen> I assume the code will need some kind of "offset ready" signal, to allow manual input, or wait until a slow adc is read
[19:18:10] <cradek> is the general problem to somehow get an input that says what the next index means, and then use that as the value that you get at index time?
[19:18:47] <cradek> for instance I'm imagining an axis with barcodes along it - you move far enough to read a barcode that says which index is next, and then get an index
[19:19:11] <cradek> seems like you have the same thing, but reading from an adc instead
[19:19:12] <JanVanGilsen> since i'm going to use a multiplexer, the 12 bit adc (32 clock cycles) the position will only be read every +/- 200 thread cycles
[19:19:41] <cradek> yeah a lot of setups might not be fast
[19:20:13] <cradek> I'm trying to understand what would be the most general implementation that would allow you to do all different things
[19:20:38] <Jymmm> Silly Putty?
[19:20:53] <JanVanGilsen> In my case I find the next index, then read the potentiometer
[19:21:07] <cradek> oh ok
[19:22:36] <JanVanGilsen> else if i'm just behind an other index then i'm homing to, the offset is unkown
[19:24:21] <JanVanGilsen> if i calculate the offset while I'm at the index, i can use a round function instead of a ceil or floor function
[19:24:36] <anonimasu> http://www.io23.net/ul/files/shaft.png
[19:25:07] <JanVanGilsen> acctually im using ceil(x-0.5) wich is the same as round(x)
[19:37:28] <anonimasu> I wonder how well machining a polygon on a shaft like that will work ^_^
[19:52:53] <SWPadnos> JanVanGilsen, is your ceil() call equivalent to round() for negative numbers?
[19:56:14] <cradek> skunkworks: thanks again for the tapes! I'm using one now.
[19:57:05] <JanVanGilsen> yes, e.g. x=-1.2 then ceil(-1.7)=-1 if x=-1.6 ==> ceil(-2.1)=-2
[19:57:43] <SWPadnos> it seems that it shouldn't be symmetric, but maybe it is
[19:58:17] <JanVanGilsen> i tedet it and it works :)
[19:58:26] <SWPadnos> then there you go :)
[20:00:46] <JanVanGilsen> *tested
[20:02:18] <JanVanGilsen> maybe this would also work: int(x + 0.5)
[20:02:43] <SWPadnos> int(x) should always truncate toward 0
[20:03:03] <SWPadnos> ceil always gives the greater (I think), which is why I thought it wouldn't work right for negative numbers
[20:03:19] <SWPadnos> in one case you're goign away from 0, the other case toward 0
[20:03:22] <SWPadnos> going
[20:04:45] <JanVanGilsen> -2 is greater than -2.1 :)
[20:07:55] <SWPadnos> but 3 is also greater than +2.1
[20:08:17] <eric_unterhausen> depends on the number system
[20:08:18] <SWPadnos> so maybe the subtraction (always toward -INF) is canceled out by the ceil() (always toward +INF)
[20:09:41] <eric_unterhausen> can an ebay seller and buyer agree to cancel a completed auction?
[20:09:44] <JanVanGilsen> wikipedia suggests using floor(x+0.5) this differs from ceil(x-0.5) wen x=n.5
[20:10:13] <JanVanGilsen> *when
[20:13:34] <JanVanGilsen> SWPadnos: yes 3 is greater than, 2.1 but x would be 2.7 and ceil(2.7-0.5)=3
[20:13:54] <JanVanGilsen> That would be 2.6 :p
[20:14:22] <SWPadnos> yep. I think the subtraction and ceil() cancel each other out (in terms of which direction they go)
[20:22:01] <alex_joni> good night all
[20:22:10] <motioncontrol> good evening.i see the python program for grill or engrave.This program fuction ok on axis interface, but on xemc no fuction.i load in idle python the module and run the module, the grafical interface is ok , but i don't can save the program in xemc or in exsternal file.Is possible modification this python program ?
[20:36:32] <BigJohnT_> sure go ahead and modify it
[20:36:48] <BigJohnT_> BigJohnT_ is now known as BigJohnT
[20:40:39] <SWPadnos> wouldn't "python grill.py > myfile.ngc" do it?
[20:40:49] <SWPadnos> (or whatever it's called)
[20:41:07] <BigJohnT> you can copy it to the clipboard then paste in into a .ngc file
[20:44:18] <BigJohnT> there is a button for that if you run it from a terminal
[20:50:38] <BigJohnT> heck he left pretty fast
[20:53:34] <mozmck> ok, now I have emc running on ubuntu 9.04 with realtime
[20:53:52] <mozmck> how do I make it so I can run it as a normal user?
[20:54:07] <SWPadnos> sudo make install should do it
[20:54:19] <SWPadnos> or sudo make setuid for run-in-place
[20:54:24] <mozmck> that's what I did...
[20:54:50] <mozmck> hmmm, maybe I forgot the make setuid this time.
[20:55:25] <mozmck> my max jitter on this machine is 6439 so far...
[20:55:46] <mozmck> Athlon 64 X2 5800+
[20:55:53] <SWPadnos> nice
[20:56:47] <mozmck> I'm thinking dual core (or more might be the way to go. The RTAI docs describe a way to tell the linux kernel not to use some of the cores at all.
[20:57:19] <SWPadnos> right. the normal kernel has that feature, it's called cpusets
[20:57:46] <SWPadnos> and you can also direct specific IRQs to certain sets of CPUs, I believe
[20:57:51] <mozmck> I might play with that at some point and see what the results are. I noticed that rtapi already only uses the last core on an SMP machine
[20:58:24] <SWPadnos> yes, the idea is that you can use isolcpus= on the kernel boot command line, and that core can be reserved for RTAI only
[20:58:38] <mozmck> yeah, I didn't read the file thoroughly, but I think they were saying that the used cores wouldn't even get interrupts
[20:58:41] <tlab> anyone have an example of the digital signal of a directional step looks like from emc?
[20:58:47] <mozmck> I think that's what they were talking about
[20:59:03] <mozmck> isolcpus... that may be easy to try
[20:59:16] <SWPadnos> there are two methods, one is isolcpus, the other (more advanced) is cpusets
[21:00:15] <SWPadnos> tlab, http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Stepgen has ascii art of the generated waveforms and what all the timing parameters are
[21:00:36] <BigJohnT> tlab: http://www.linuxcnc.org/docview/html//hal_rtcomps.html#sub:Stepgen-Step-Types
[21:01:21] <mozmck> it looks like it is already pretty good compared to the single core machine I have on my router table. I think it is 3 ghz. and had latencies twice or three times as high
[21:02:03] <SWPadnos> the experimental 8.04 SMP kerrnel seemed to perform better as well
[21:02:36] <SWPadnos> try running a CPU hog script and see what happens :)
[21:02:49] <mozmck> where do I find one?
[21:02:59] <SWPadnos> while true ; do echo "nothing" > /dev/null ; done
[21:03:49] <SWPadnos> I don't think it will do anything on the AMD chip, but I'm curious to find out
[21:03:59] <mozmck> I'll try it. I'm running firefox, eclipse, openoffice and I was running glxgears while I had the latency test going.
[21:04:01] <SWPadnos> it helps core2 duo chips a lot
[21:04:13] <mozmck> I'm running axis right now jogging around
[21:04:44] <SWPadnos> oh. I did the cpu hog thing with the RTAI latency test, and maybe the EMC latency test
[21:06:12] <mozmck> latency jumps to 8983 now
[21:06:28] <mozmck> I was running the script you sent, then I started glxgears
[21:06:35] <mozmck> that's when it jumped
[21:07:24] <SWPadnos> yeah. I think it doesn't make a difference with AMD chips
[21:07:34] <SWPadnos> the cores have separate L1/L2 caches
[21:07:44] <SWPadnos> (I think it's a cache effect that does it)
[21:08:16] <mozmck> the cpu hog *helps* core2 chips?
[21:08:23] <SWPadnos> yep. a lot
[21:08:28] <mozmck> i.e. reduces latency?
[21:08:32] <SWPadnos> yes, a lot :)
[21:08:37] <mozmck> interesting
[21:08:54] <SWPadnos> one system I set up had ~200 ns, with spikes to ~2000 or so with the CPU hog
[21:09:10] <SWPadnos> without, it was 6000 or more all the time
[21:09:37] <mozmck> so for those systems we need a cpu hog script in emc i guess!
[21:09:42] <SWPadnos> heh
[21:10:21] <SWPadnos> this system is a HAL-only, no graphics thing, so I added the hog script to my realtime app script in init.d
[21:10:25] <mozmck> it jumped again to 9406 when I shut down glxgears
[21:10:40] <mozmck> I see. I'm running just about everything on this machine.
[21:10:47] <SWPadnos> yep. clicking on the window or starting to drag it should give a spike
[21:11:12] <mozmck> I didn't notice that it did before, but I have more running now.
[21:12:07] <SWPadnos> I'm sure it depends on drivers and other things, so YMMV
[21:13:12] <mozmck> It's good enough for testing for me. This is my main computer, so I won't be running an actual machine with it (i don't think)
[21:14:07] <tlab> why is the stepspace so much larger than the steplen?
[21:17:01] <SWPadnos> tlab, usually, the minimum step duration is a couple of microseconds, but you don't need to do 100000 steps/second
[21:17:10] <SWPadnos> so you have a short step, then a long space before the next step
[21:18:03] <mozmck> hmmm, I did a make setuid and the make install and I still can't run emc as a normal user...
[21:18:23] <tlab> ya I'm showing maybe 3.5us
[21:18:24] <SWPadnos> make setuid is only used for run in place
[21:18:40] <mozmck> oh. what do I do for an install then?
[21:18:43] <tlab> but the stepspace seems rather long
[21:18:55] <SWPadnos> make install should make it usable for all users, but it's possible that make setuid before make install screws things up somehow
[21:19:03] <SWPadnos> make install isn't very well tested
[21:19:21] <mozmck> I'm testing it now I guess! found one bug already
[21:19:22] <SWPadnos> tlab, you can set those to whatever you like, within the timing constraints of your PC
[21:19:41] <SWPadnos> make uninstall is also a problem :)
[21:20:34] <tlab> so step_space is the down side of the duty cycle, what is step time? the whole cycle?
[21:20:44] <SWPadnos> yes
[21:21:09] <SWPadnos> but the actual step time will depend on both the steplen/stepspace settings and the needed step rate
[21:21:13] <tlab> then why is step time and step space set the same length?
[21:21:23] <SWPadnos> when you need steps slower than the max possible, the steplen will be increased
[21:21:36] <SWPadnos> you set them, so make them whatever you want
[21:22:02] <tlab> I only set the negative duty cycle and the whole time yes?
[21:22:08] <SWPadnos> no
[21:22:56] <SWPadnos> you set the minimum step length, the minimum step space, the minumum direction hold, and the minimum direction setup times
[21:23:27] <tlab> so step length is the positive duty cycle
[21:23:32] <SWPadnos> yes
[21:23:37] <tlab> ok
[21:23:40] <SWPadnos> minimum positive step pulse length
[21:24:05] <tlab> so if I should have a 50% duty cycle square wave out then, yes?
[21:24:18] <SWPadnos> you won't get a 50% duty cycle most of the time
[21:24:30] <SWPadnos> do you actually need that?
[21:24:51] <tlab> no, I was just looking to see what I was getting so I had a better understand of it
[21:24:58] <SWPadnos> ok
[21:24:58] <tlab> but I gotta run, thanks for help
[21:25:04] <SWPadnos> sure. see you
[21:25:30] <mozmck> where do I look for the install stuff? I'm not very familiar with the auto* tools
[21:25:38] <SWPadnos> it's in the makefile
[21:25:52] <mozmck> the Makefile is generated by the ./configure script isn't it?
[21:26:09] <SWPadnos> I think the makefile isn't, but makefile.inc is
[21:26:23] <SWPadnos> not sure though, I'm not so familiar with that stuff either
[21:26:55] <mozmck> hmm. I know many packages don't even ship with a makefile, the auto* stuff creates it.
[21:27:11] <mozmck> I'll look later. I need to get some other stuff done.
[21:27:58] <SWPadnos> yep, Makefile is included, Makefile.inc is generated
[21:28:03] <SWPadnos> http://cvs.linuxcnc.org/cvs/emc2/src/
[21:28:53] <mozmck> ok. thanks!
[21:29:11] <SWPadnos> sure
[22:22:06] <tomp> tomp is now known as tom3p
[22:27:40] <tom3p> i have to program some fairchild 27c512's.
[22:27:40] <tom3p> my emp-21 programmer handles NM27C512s and i have FM27C512s.
[22:27:40] <tom3p> I see the FMs go to 90nS (mine are 90 suffix)
[22:27:40] <tom3p> think it'll work to program them ?
[22:27:40] <tom3p> (argh too much electronic stuff becomes ancient too soon!)
[22:28:39] <tom3p> the NMs dont go faster than 120nS
[23:33:18] <servant74> quick question ... image-to-gcode ... I got an array mismatch error when trying to convret a gif to gcode. ... does someone know of an known issue?
[23:45:11] <servant74> scaling gcode