#emc | Logs for 2009-05-18

[00:35:31] <Optic_> Optic_ is now known as Optic
[01:21:44] <jepler> if it's an infinite loop, (axis, hide) won't allow the preview to finish loading
[01:22:10] <jepler> that's what (AXIS,stop) is for
[01:22:14] <jepler> http://linuxcnc.org/docs/html/gui_axis.html#r1_11_7
[01:22:44] <jepler> and I think the capitalization and lack of space may be important -- put them in your ngc file exactly as shown in the docs
[01:22:50] <jepler> (AXIS,hide) (AXIS,show) (AXIS,stop)
[01:23:15] <jepler> (hm, the docs show it once with a space .. I should figure out whether that works, and fix the docs if not..)
[02:27:22] <renesis> heh
[02:27:28] <renesis> i just hit escape alot
[02:29:46] <Jymmm> For all you old farts... http://jimwarholic.com/2009/04/fdd-floppy-disk-drive-emulators.php
[02:30:54] <tomp> tomp is now known as tomp4
[03:49:22] <Optic> moo
[09:15:22] <piasdom> g'mornin all
[12:37:27] <skunkworks> so.. everyone ready for the fest?
[12:37:38] <jepler> oh mostly
[12:37:39] <archivist> I wish
[12:39:39] <jepler> udiv.exe
[12:39:44] <jepler> oops
[12:40:58] <jepler> (udiv.exe is apparently a program which, given a constant divisor, finds a clever multiplication that gives the same result as the unsigned integer division)
[12:41:12] <jepler> (but this is irc, not the google search)
[12:42:40] <archivist> we have a !google in #mysql which does http://letmegooglethatforyou.com/?q=udiv.exe
[12:47:15] <skunkworks> This week is going to fly by.
[12:50:19] <jepler> don't they all?
[12:50:29] <skunkworks> some more than others
[12:53:21] <alex_joni> some less than others
[12:54:36] <archivist> we adjust till on time, but we are clockmakers :)
[13:14:35] <BJT-Work> oh boy I get to use my thread mill today
[13:25:45] <Optic> moo
[15:38:53] <skunkworks> LawrenceG: Good weekend?
[15:42:17] <mshaver> updated http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?EMC_Fest_2009 with things I'd like to do
[15:42:40] <mshaver> comments (humorous or serious) are welcome!
[15:45:43] <cradek> mshaver: looks like a good list to me
[15:49:00] <skunkworks> Neat!
[15:51:55] <archivist> us stuck elsewhere will watch from afar
[15:54:42] <mshaver> well then, I'll be heading out from Ann Arbor, MI tomorrow morning on a little (14.5 hour) drive to Wichita, KS. This will, given my advanced age and frail condition, probably take 2 days with some sleep in between.
[15:55:17] <archivist> enjoy the sights on the way
[15:55:27] <cradek> sounds fun to me
[15:55:43] <cradek> stop at HGR and buy some crap for us?
[15:56:09] <archivist> visit some museums on the way
[16:00:46] <Jymmm> Beagle 128MB ram and 256MB flash... doens't seem like a lot of room for EMC
[16:01:27] <mshaver> mostly think about how to patch the ARM kernel with ADEOS...
[16:01:40] <Jymmm> unless GUI-less
[16:01:47] <Jymmm> ADEOS?
[16:02:35] <mshaver> 256MB RAM I think + an SD card
[16:03:32] <Jymmm> Well, storage I suppose, but SD/CF/etc all have limited write cycles.
[16:03:34] <mshaver> adeos is the thing that rtai uses in the kernel
[16:04:33] <Jymmm> GIless sounds interesting, but would scare the shit out of me safety wise
[16:04:39] <Jymmm> GUI-less
[16:05:12] <mshaver> it does run a full linux distrib with gui
[16:05:44] <Jymmm> Maybe, but add in REAL-TIME might be a factor - no ida
[16:05:52] <Jymmm> idea
[16:06:12] <mshaver> that is the current challenge
[16:07:42] <Jymmm> mshaver: Well GUI-less has potential, alot less overhead to deal with, but scares the shit out of me due to the fact that the remte can disconnect and it still keeps going (no heartbeat)
[16:08:28] <Jymmm> If the option to have a heartbeat was there and throughly tested might be a different sotry
[16:09:05] <Jymmm> mshaver: does the beagle have a bios to it?
[16:09:23] <mshaver> we'll have to see what happens. obviously, there would be an estop system
[16:10:00] <mshaver> sort of, there a built in monitor type program in the onboard flash. I haven't messed with it yet.
[16:10:24] <Jymmm> mshaver: Can you install run a linux distro on it?
[16:10:39] <Jymmm> basic debian, dsl, etc?
[16:11:14] <mshaver> I was able to recompile the Angstrom linux distribution and copy the image to a blank SD card and boot it into the X desktop
[16:11:37] <cradek> I was able to get debain on mine
[16:11:59] <Jymmm> cradek: GUi or console?
[16:12:07] <mshaver> really! that's pretty cool!
[16:12:20] <Jymmm> http://linux.onarm.com/index.php/Main_Page
[16:12:21] <cradek> I have only used the serial console so far. It could run X if I would install it.
[16:13:28] <mshaver> I went straight for X, and it worked, but compiling took probably (I didn't stay the whole time) 10+ hours
[16:14:03] <mshaver> you going to try to get RTAI going?
[16:15:56] <cradek> not me
[16:16:44] <skunkworks> This is cool http://www.cnczone.com/forums/showthread.php?t=81125&highlight=cpld
[16:16:52] <skunkworks> marris cpld 101
[16:16:55] <cradek> I'm using mine for an emc-unrelated application (if I can pull it off)
[16:18:13] <mshaver> I think Jeff was going to try to apply the low latency patches (Ingo Molinar's stuff I think)
[16:18:39] <seb_kuzminsky> hi matt
[16:19:37] <jepler> yeah, but my level of success is not great: 300us latency is typical
[16:20:27] <archivist> cradek, wish list for me is jog keys in axis for axis 5
[16:20:36] <jepler> even if that was good enough for servo-only systems (and I'm not convinced it is), I still have to do a new rtapi port
[16:21:05] <jepler> archivist: you can do that today in ~/.axisrc if you can figure out what keys to use
[16:21:13] <cradek> archivist: easy if ... yeah what he said
[16:21:23] <jepler> http://mid.gmane.org/20090204155539.GD25310@unpythonic.net
[16:21:33] <cradek> I don't see any good keys though
[16:21:44] <cradek> you know you can poke 4 (I think 4) and then use -/= right?
[16:23:35] <mshaver> there are ARM ports of RTAI, but not for the beagleboard or it's processor. My thinking is that it may be easier for me to get RTAI going than to adapt RTAPI to something else. Of course I'm speaking about things I know practically nothing about!
[16:23:50] <archivist> cant try anything yet its cutting
[16:24:06] <mshaver> sometime ignorance is the only thing that let's me attempt big things!
[16:24:31] <mshaver> if I knew what I was doing, I wouldn't try.
[16:24:32] <cradek> I didn't know there was an existing arm port of rtai - that definitely sounds like a good starting point.
[16:24:55] <cradek> what I/O hardware would you use?
[16:25:12] <jepler> my impression was that different arms might use even less common code than i386/x86_64, so I went a different route
[16:26:12] <archivist> please dont make me remember ARM programming
[16:30:42] <mshaver> well, there's /rtai-3.2/base/arch/arm/ in the rtai tarball, but nothing specific for the beagleboard or OMAP cpu
[16:31:19] <Valen> i think arm is actually a definition of a minimum instruction set
[16:31:35] <mshaver> and there's this: http://download.gna.org/adeos/patches/v2.6/arm/
[16:31:40] <Valen> there are supersets but there shouldn't be subsets
[16:32:48] <mshaver> unfortunately, I don't yet have enough of an understanding of how the rtai stuff work to even begin to evaluate how much trouble this is going to be!
[16:33:28] <Valen> patch and cross compile, what you got to loose ;->
[16:34:23] <mshaver> cradek: There a 28 pin "EXPANSION" header on the board. I figure that's where things will (somehow) hook up.
[16:34:59] <Valen> its a USB host as well isn't it?
[16:35:08] <Valen> mesa has USB based boards ;-?
[16:35:43] <Valen> if you can get a beagleboard running a headless EMC with a really good latency score I can see it being a good thing
[16:35:52] <Valen> I'd buy one ;->
[16:36:23] <Valen> oh well bed time for me
[16:36:26] <Valen> nighty night
[17:37:17] <steves_logging> steves_logging is now known as steve_stallings
[18:06:25] <steve_stallings> steve_stallings is now known as steves_logging
[19:46:05] <skunkworks> To see the collection of prior postings to the list, visit the Tuxcnc-dev Archives. (The current archive is only available to the list members.)
[19:48:29] <roh> HA
[19:48:47] <skunkworks> ;)
[19:48:51] <skunkworks> Hi paul
[19:48:53] <skunkworks> ;)
[19:49:47] <roh> uhm.. wrong chan.. but still hi ;)
[19:50:29] <skunkworks> (paul_c is the guy heading up tuxcnc)
[19:51:01] <skunkworks> (broke from the emc project)
[19:57:28] <NewType> is there a way to set the initial state of the pin (high or low) during the launching of EMC? (Not sure if I am asking the right question...) I have a small problem with the spindle spins up during the launching of EMC.
[19:57:47] <NewType> it will just spins up, then turns off after EMC starts up.
[19:57:50] <archivist_attic> set it to a defined state
[19:58:03] <NewType> which variable is that?
[19:58:31] <NewType> I think I read this somewhere too.
[19:58:39] <NewType> I just can't remember
[19:58:49] <archivist_attic> actually " turns off after EMC starts up" would impl you are doing that
[19:59:22] <NewType> yep. it is doing the right thing. I don't know if more can be done.
[19:59:25] <cradek> can you say more precisely what it's doing? when does it turn on and off?
[19:59:31] <NewType> it is just scary when the spindle will turn on by iteslf.
[19:59:34] <BJT-Work> you should really have a hardware enable switch for that
[20:00:02] <NewType> OK. the spindle is controlled by a phase controller (0-5V -> 0-120VAC).
[20:00:21] <NewType> the 0-5V is coming on a pin controlled by EMC.
[20:00:32] <NewType> using the PWM mode, and a low pass filter.
[20:00:37] <cradek> ok
[20:00:39] <NewType> the speed control is working.
[20:00:48] <archivist_attic> it may have a separate enable you can hold externally
[20:00:57] <skunkworks> this is mesa hardware?
[20:01:12] <NewType> OK, so that's the only way to do it. it isn't something I can program or I programed wrong.
[20:01:39] <cradek> everyone please stop and let him fully explain the setup
[20:01:54] <NewType> OKOK.
[20:02:01] <NewType> so, that's the hardware to control the spind.e
[20:02:30] <NewType> now, when I start up the system, I turns on the power to the stepper motor and spindle power controller.
[20:02:50] <NewType> the stepper will hold their position, and the spindle will not turn.
[20:02:59] <NewType> then, when I launch EMC
[20:03:13] <NewType> the spindle will starts spinning at full speed...
[20:03:48] <NewType> I can't remember if it was after EMC successfully launched, or after I open the configuration file, the spindle will stop
[20:04:08] <NewType> let me try again now.
[20:04:48] <NewType> ok. this is bad.
[20:05:09] <NewType> EMC is not running, and when I turn on the power to the stepper and spinle, the spindle turns.
[20:05:17] <NewType> so...
[20:05:49] <NewType> the spindle will keep turn after lancuhing EMC
[20:06:09] <NewType> and after I select the configuration file I use with the machine, the spindle will stop
[20:06:39] <NewType> the spindle turns means there is a 5V on the pin to the phase controller.
[20:06:45] <cradek> "EMC is not running, and when I turn on the power to the stepper and spinle, the spindle turns."
[20:06:53] <cradek> clearly this is the problem you need to fix
[20:07:13] <cradek> there cannot be a software fix for what happens before you start the software
[20:07:30] <NewType> that's what I want to make sure.
[20:07:38] <NewType> it isn't something I didn't do right.
[20:07:50] <cradek> since (I assure you) there is no PWM output on that pin before EMC is running, your circuitry or wiring is doing a wrong thing when there is no PWM.
[20:08:00] <NewType> as you said, the software is clearly setting the pin to 0V after it starts.
[20:08:32] <cradek> perhaps you need something like a charge pump, so a solid 0V and a solid 5V both cause no output
[20:08:57] <NewType> then I better recheck the wiring.... so it should be 0V unless you start using the port?
[20:09:10] <cradek> the parallel port pins are in an indeterminate state before EMC runs (though they may usually be consistent from run to run)
[20:09:23] <NewType> I see. let me look into that.
[20:09:37] <cradek> this is what charge pumps are for - they require the software to be active before ANY of your hardware enables
[20:09:50] <NewType> I probably should set the procedure of turning on the software before turnning on the power to the CNC machine.
[20:09:53] <cradek> (before the machine will come out of estop, usually)
[20:10:06] <NewType> I see.
[20:10:17] <cradek> that is a solution but obviously not the safest one
[20:10:22] <NewType> right
[20:10:41] <NewType> some moron will do the reverse order
[20:10:54] <NewType> I can see some undergrads sticking their hands there. :)
[20:11:12] <archivist_attic> the drive needs to be in stop as well
[20:12:05] <NewType> I can put another switch to the power of the spindle as well.
[20:12:08] <archivist_attic> it should be defaulting to stop mode on power on
[20:12:14] <NewType> that may be another/quicker way.
[20:12:36] <NewType> actually, it does. the stop mode is set by the e-stop switch.
[20:12:43] <cradek> I suggest creating an estop setup that does not allow anything on the machine to activate until the software is running. like I said, a charge pump is the usual way. you also get the benefit of the machine stopping if the software crashes or the computer gets turned off or whatever.
[20:12:55] <NewType> you should re-enable the system when everythign is ready.
[20:13:11] <NewType> right.
[20:13:21] <NewType> ok. I'll do the charge pump way.
[20:59:32] <colin__> sweet
[20:59:43] <colin__> working on a completly cut down livecd
[20:59:52] <colin__> that litterally just loads straight into emc
[20:59:55] <colin__> no window manager
[21:00:03] <colin__> think im getting there :D
[21:03:41] <seb_kuzminsky> neat colin__ :-)
[21:04:36] <colin__> im building a system for other people to use
[21:04:45] <colin__> so the less they can access to break the better :D
[21:05:01] <colin__> and it makes it seem more like a dedicated cnc controller
[21:05:06] <colin__> than just a pc running some program
[21:23:51] <NewType> would the GCode Feedrate override the limit set by the *.ini file?
[21:25:38] <mshaver> nope. The .ini file limits are the final word.
[21:26:08] <NewType> hummm. then if the 2 axis have different max rate, it will follow the slowest one, right?
[21:26:37] <cradek> yes it will always obey all constraints specified in the ini file
[21:27:05] <NewType> then I think I need to look at the machine again.
[21:27:19] <cradek> heh
[21:27:22] <mshaver> yes. in a multi axis move the feed rate of the slowest axis constrains the tool tip velocity.
[21:27:25] <NewType> I am missing steps on one of the screw after it reaches steady state
[21:27:31] <mshaver> i type too slow...
[21:27:48] <cradek> or I jump in too fast
[21:27:55] <NewType> hahaha.
[21:28:04] <mshaver> no, it's me!
[21:28:08] <cradek> I just get excited when I actually know the answer to a question
[21:28:40] <NewType> haha. for me, that usually is a math question.
[21:28:48] <NewType> like what's sqrt(2)/2?
[21:29:16] <NewType> I think I am missing step because of too high feedrate.... but I tested that rate using stepconf.
[21:29:18] <NewType> that's wrid.
[21:29:20] <NewType> werid
[21:31:03] <mshaver> unforeseen mechanical binding of the axis maybe?
[21:31:26] <colin__> hmm
[21:31:49] <NewType> may be.
[21:31:55] <colin__> do you think it would be easy enough to build a updated emc for the old puppy linux version ?
[21:32:07] <NewType> but manually slowing the speed by feedrate override solve the problem.
[21:32:25] <colin__> or will it need updated rtai and kernel
[21:32:28] <NewType> I think I just need to set a lower speed limit.
[21:34:08] <mshaver> that's the cure-all with stepper systems usually. either slower speeds, better step pulses, or my personal favorite, higher voltage!
[21:34:40] <NewType> on axis, the "Vel:" indicator is velocity, right?
[21:35:01] <NewType> I can increase the motor torque current as well.
[21:35:14] <NewType> I don't think I am at the limit, but I try not to do that so I don't overheat the driver.
[21:36:36] <NewType> weird! the "slow" axis is running at the "fast" axis
[21:36:45] <NewType> opps
[21:36:49] <NewType> see I type too fast too.
[21:37:00] <NewType> weird! the "slow" axis is running at the "fast" axis's max speed
[21:37:25] <NewType> if Vel: is indicating the velocity, then the system is really going fast on the wrong axis.
[21:38:01] <NewType> and they do go at different rate. ;p
[21:38:26] <NewType> x is going at 640 mm/min, whle y is going at 700mm/min
[21:39:16] <mshaver> Vel: can be wrong
[21:39:29] <NewType> I hope so!
[21:40:15] <mshaver> it's controlled by [DISPLAY]MAX_LINEAR_VELOCITY I think
[21:40:28] <mshaver> at least that's what I have observed
[21:40:36] <NewType> when I cut a square, x (the slower one) is running at a higher speed than Y (the faster one)
[21:40:59] <NewType> I better actually time it to see if it is going faster or slower.
[21:41:07] <mshaver> you can see the difference in speed?
[21:41:12] <mshaver> yes, time it
[21:41:37] <NewType> I think I see the same thing as what's disp on axis. but I can be wrong because I am at a bad angle to watch the machine.
[21:42:11] <NewType> I do hope it goes at a different rate, because y is a better screw and it can go faster.
[21:42:24] <NewType> I just need to figure out which limit is screwing up. :)
[21:42:49] <colin__> but doesnt the max speed thing only come into play if both axis are moving at the same time ?
[21:43:03] <colin__> if its just an individual axis move then it will be at the max of that axis wont it
[21:43:15] <NewType> I think so.
[21:43:27] <NewType> so that's problem 1
[21:43:46] <NewType> problem 2 is to make sure the limits are set right (for me)
[21:43:58] <colin__> your just gonna have to make sure your setting a feed rate lower than your slowest axis for machining to get a cosntant speed
[21:44:06] <colin__> just use the max per axis on rapids
[21:44:23] <NewType> I thought I did that. I need to hand check it and make sure I convert the unit right.
[21:44:29] <NewType> let me do that again.
[21:45:45] <NewType> but for sure, right now, Vel: is showing the slow is going fast and the fast is going slow.