Optic_ is now known as Optic
if it's an infinite loop, (axis, hide) won't allow the preview to finish loading
that's what (AXIS,stop) is for
[01:22:14] <jepler> http://linuxcnc.org/docs/html/gui_axis.html#r1_11_7
and I think the capitalization and lack of space may be important -- put them in your ngc file exactly as shown in the docs
(AXIS,hide) (AXIS,show) (AXIS,stop)
(hm, the docs show it once with a space .. I should figure out whether that works, and fix the docs if not..)
i just hit escape alot
For all you old farts... http://jimwarholic.com/2009/04/fdd-floppy-disk-drive-emulators.php
tomp is now known as tomp4
so.. everyone ready for the fest?
(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)
(but this is irc, not the google search)
we have a !google in #mysql which does http://letmegooglethatforyou.com/?q=udiv.exe
This week is going to fly by.
don't they all?
some more than others
some less than others
we adjust till on time, but we are clockmakers :)
oh boy I get to use my thread mill today
LawrenceG: Good weekend?
with things I'd like to do
comments (humorous or serious) are welcome!
mshaver: looks like a good list to me
us stuck elsewhere will watch from afar
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.
enjoy the sights on the way
sounds fun to me
stop at HGR and buy some crap for us?
visit some museums on the way
Beagle 128MB ram and 256MB flash... doens't seem like a lot of room for EMC
mostly think about how to patch the ARM kernel with ADEOS...
256MB RAM I think + an SD card
Well, storage I suppose, but SD/CF/etc all have limited write cycles.
adeos is the thing that rtai uses in the kernel
GIless sounds interesting, but would scare the shit out of me safety wise
it does run a full linux distrib with gui
Maybe, but add in REAL-TIME might be a factor - no ida
that is the current challenge
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)
If the option to have a heartbeat was there and throughly tested might be a different sotry
mshaver: does the beagle have a bios to it?
we'll have to see what happens. obviously, there would be an estop system
sort of, there a built in monitor type program in the onboard flash. I haven't messed with it yet.
mshaver: Can you install run a linux distro on it?
basic debian, dsl, etc?
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
I was able to get debain on mine
cradek: GUi or console?
really! that's pretty cool!
[16:12:20] <Jymmm> http://linux.onarm.com/index.php/Main_Page
I have only used the serial console so far. It could run X if I would install it.
I went straight for X, and it worked, but compiling took probably (I didn't stay the whole time) 10+ hours
you going to try to get RTAI going?
This is cool http://www.cnczone.com/forums/showthread.php?t=81125&highlight=cpld
marris cpld 101
I'm using mine for an emc-unrelated application (if I can pull it off)
I think Jeff was going to try to apply the low latency patches (Ingo Molinar's stuff I think)
yeah, but my level of success is not great: 300us latency is typical
cradek, wish list for me is jog keys in axis for axis 5
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
archivist: you can do that today in ~/.axisrc if you can figure out what keys to use
archivist: easy if ... yeah what he said
[16:21:23] <jepler> http://mid.gmane.org/20090204155539.GD25310@unpythonic.net
I don't see any good keys though
you know you can poke 4 (I think 4) and then use -/= right?
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!
cant try anything yet its cutting
sometime ignorance is the only thing that let's me attempt big things!
if I knew what I was doing, I wouldn't try.
I didn't know there was an existing arm port of rtai - that definitely sounds like a good starting point.
what I/O hardware would you use?
my impression was that different arms might use even less common code than i386/x86_64, so I went a different route
please dont make me remember ARM programming
well, there's /rtai-3.2/base/arch/arm/ in the rtai tarball, but nothing specific for the beagleboard or OMAP cpu
i think arm is actually a definition of a minimum instruction set
and there's this: http://download.gna.org/adeos/patches/v2.6/arm/
there are supersets but there shouldn't be subsets
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!
patch and cross compile, what you got to loose ;->
cradek: There a 28 pin "EXPANSION" header on the board. I figure that's where things will (somehow) hook up.
its a USB host as well isn't it?
mesa has USB based boards ;-?
if you can get a beagleboard running a headless EMC with a really good latency score I can see it being a good thing
I'd buy one ;->
oh well bed time for me
steves_logging is now known as steve_stallings
steve_stallings is now known as steves_logging
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.)
uhm.. wrong chan.. but still hi ;)
(paul_c is the guy heading up tuxcnc)
(broke from the emc project)
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.
it will just spins up, then turns off after EMC starts up.
set it to a defined state
which variable is that?
I think I read this somewhere too.
I just can't remember
actually " turns off after EMC starts up" would impl you are doing that
yep. it is doing the right thing. I don't know if more can be done.
can you say more precisely what it's doing? when does it turn on and off?
it is just scary when the spindle will turn on by iteslf.
you should really have a hardware enable switch for that
OK. the spindle is controlled by a phase controller (0-5V -> 0-120VAC).
the 0-5V is coming on a pin controlled by EMC.
using the PWM mode, and a low pass filter.
the speed control is working.
it may have a separate enable you can hold externally
this is mesa hardware?
OK, so that's the only way to do it. it isn't something I can program or I programed wrong.
everyone please stop and let him fully explain the setup
so, that's the hardware to control the spind.e
now, when I start up the system, I turns on the power to the stepper motor and spindle power controller.
the stepper will hold their position, and the spindle will not turn.
then, when I launch EMC
the spindle will starts spinning at full speed...
I can't remember if it was after EMC successfully launched, or after I open the configuration file, the spindle will stop
let me try again now.
ok. this is bad.
EMC is not running, and when I turn on the power to the stepper and spinle, the spindle turns.
the spindle will keep turn after lancuhing EMC
and after I select the configuration file I use with the machine, the spindle will stop
the spindle turns means there is a 5V on the pin to the phase controller.
"EMC is not running, and when I turn on the power to the stepper and spinle, the spindle turns."
clearly this is the problem you need to fix
there cannot be a software fix for what happens before you start the software
that's what I want to make sure.
it isn't something I didn't do right.
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.
as you said, the software is clearly setting the pin to 0V after it starts.
perhaps you need something like a charge pump, so a solid 0V and a solid 5V both cause no output
then I better recheck the wiring.... so it should be 0V unless you start using the port?
the parallel port pins are in an indeterminate state before EMC runs (though they may usually be consistent from run to run)
I see. let me look into that.
this is what charge pumps are for - they require the software to be active before ANY of your hardware enables
I probably should set the procedure of turning on the software before turnning on the power to the CNC machine.
(before the machine will come out of estop, usually)
that is a solution but obviously not the safest one
some moron will do the reverse order
I can see some undergrads sticking their hands there. :)
the drive needs to be in stop as well
I can put another switch to the power of the spindle as well.
it should be defaulting to stop mode on power on
that may be another/quicker way.
actually, it does. the stop mode is set by the e-stop switch.
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.
you should re-enable the system when everythign is ready.
ok. I'll do the charge pump way.
working on a completly cut down livecd
that litterally just loads straight into emc
no window manager
think im getting there :D
neat colin__ :-)
im building a system for other people to use
so the less they can access to break the better :D
and it makes it seem more like a dedicated cnc controller
than just a pc running some program
would the GCode Feedrate override the limit set by the *.ini file?
nope. The .ini file limits are the final word.
hummm. then if the 2 axis have different max rate, it will follow the slowest one, right?
yes it will always obey all constraints specified in the ini file
then I think I need to look at the machine again.
yes. in a multi axis move the feed rate of the slowest axis constrains the tool tip velocity.
I am missing steps on one of the screw after it reaches steady state
i type too slow...
or I jump in too fast
no, it's me!
I just get excited when I actually know the answer to a question
haha. for me, that usually is a math question.
like what's sqrt(2)/2?
I think I am missing step because of too high feedrate.... but I tested that rate using stepconf.
unforeseen mechanical binding of the axis maybe?
do you think it would be easy enough to build a updated emc for the old puppy linux version ?
but manually slowing the speed by feedrate override solve the problem.
or will it need updated rtai and kernel
I think I just need to set a lower speed limit.
that's the cure-all with stepper systems usually. either slower speeds, better step pulses, or my personal favorite, higher voltage!
on axis, the "Vel:" indicator is velocity, right?
I can increase the motor torque current as well.
I don't think I am at the limit, but I try not to do that so I don't overheat the driver.
weird! the "slow" axis is running at the "fast" axis
see I type too fast too.
weird! the "slow" axis is running at the "fast" axis's max speed
if Vel: is indicating the velocity, then the system is really going fast on the wrong axis.
and they do go at different rate. ;p
x is going at 640 mm/min, whle y is going at 700mm/min
Vel: can be wrong
I hope so!
it's controlled by [DISPLAY]MAX_LINEAR_VELOCITY I think
at least that's what I have observed
when I cut a square, x (the slower one) is running at a higher speed than Y (the faster one)
I better actually time it to see if it is going faster or slower.
you can see the difference in speed?
yes, time it
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.
I do hope it goes at a different rate, because y is a better screw and it can go faster.
I just need to figure out which limit is screwing up. :)
but doesnt the max speed thing only come into play if both axis are moving at the same time ?
if its just an individual axis move then it will be at the max of that axis wont it
I think so.
so that's problem 1
problem 2 is to make sure the limits are set right (for me)
your just gonna have to make sure your setting a feed rate lower than your slowest axis for machining to get a cosntant speed
just use the max per axis on rapids
I thought I did that. I need to hand check it and make sure I convert the unit right.
let me do that again.
but for sure, right now, Vel: is showing the slow is going fast and the fast is going slow.