>
> [TRAJ]
> DEFAULT_LINEAR_VELOCITY =
> DEFAULT_ANGULAR_VELOCITY =
>
Interesting. I don't have DEFAULT_LINEAR_VELOCITY, but I do have
DEFAULT_VELOCITY, which seems to be the same. Has the name changed, or does
EMC accept either?
I had been skipping over those ini values, because they're wildly different
from what I see as the startup values in EMC. Now I see why. The ini file
should be IPS, whereas EMC's sliders show IPM. That's why I was getting in
the 1300s in EMC for my DEFAULT_VELOCITY = 22. That doesn't explain why it's
1312 in EMC (22 * 60 = 1320), but at least it's close, and I can set more
realistic values now. Awesome.
Also, are any values NOT in the default install? I seem to recall in my
travels finding some variables that weren't anywhere in my config file. It
makes me wonder what cool features I might be missing. Maybe there's a list
I haven't found yet?
> delete /usr/share/axis/images/axis.ngc or set the environment variable
> AXIS_OPEN_FILE to the ngc you want to open as default
It doesn't seem to be respecting my environment variable here, even if I
immediately run '$ emc' after setting it in the same shell. I haven't tried
the file delete trick yet, but am glad to know where it resides now. Thanks.
> > Sadly, the EMC2 AXIS default file is also set to run at a higher speed
> > than my sad little machine can handle
>
> This isn't a problem with EMC2. Your machine's MAX_VELOCITY is configured
> wrong. The machine should not be able to lose steps simply by being
> commanded too fast. Why would you want to command the machine to move
> faster than is physically possible?
>
I wouldn't! I just haven't managed to understand all of the settings yet.
I've read a lot, and have toyed with things like MAX_VELOCITY (which is at
30 currently - no wonder it seems limitless! That's 1800 IPM!), but I've
gotten such strange results for so many things, I haven't yet learned to
trust myself, or any of the settings yet. That's why I'm here, though. You
guys have been extremely helpful already. I'm considering giving back
eventually (when I know enough) by writing up very simple explanations for
simple folk like me, who feel a bit overwhelmed in the beginning.
I'm thinking now that a lot of my troubles, and strange occurrences in this
particular area have been me incorrectly assuming that the conf settings are
supposed to be in IPM (or forgetting that I read otherwise, as now it does
sound familiar). I guess IPS just doesn't make sense to me, and as such I
wouldn't presume it, because my mill has trouble moving just 1IPS. What's
the use counting in floating points <1? :)
The hissing noise is due to 'noise' believe it or not. Check your setup
> for ground loops and capacitive coupling and all that good stuff. Or maybe
> you should just buy some stepper drivers of higher quality.
Step 1 for me now is to figure out what ground loops, and capacitive
couplings are! I don't think I can afford any more stepper drivers. I have
Sherline's only offering, and it was $600. Being a total newbie, and having
decided I liked, and could afford their 5400 CNC package (completely
non-profit, hobby use only), I've for simplicity, and guaranteed
work-togetherness limited my purchases to their catalog. Still, $600 did
seem very high, and it's missing things that I've since assumed come with
other, possibly cheaper packages. For example, I have no option for a 5th
axis, encoder inputs, servo anythings, a probe, actual e-stop button,
spindle on/off, coolant on/off, that coffee maker attachment someone
mentioned in here this week...
How do people normally add things like contact stops, and probes? Are these
part of better driver systems? I've also wondered if there was anything that
could be done in-line. For example, the Sherline box would plug into another
box, which would then plug into the serial port. That box could insert codes
into the stream for the missing features above. This is probably an insane
notion, and might quickly overflow any buffers it encounters along the way
with too much data.
If other drivers do all of this cool extra stuff, maybe I should just
upgrade, and sell the Sherline box to someone who will undoubtedly then show
up in here at some point, with all of my same problems, and I can instruct
him to sell the box, and get something better. The circle of life continues.
To keep the steppers cool, you can rig up some CPU fans to blow on them.
> But you really shouldn't leave the machine unattended. You can pause and
> resume if you need to leave in the middle of a job. If you must turn the
> drivers off, you can stop the program at a convenient place, and then edit
> the g-code file so that it starts there next time. (run-from-line is not
> quite ready yet.)
I'm excited that a run-from-line is even in the works! It was one of the
features I've already wished for, several times. I've taken to jotting down
a sensible number from the scrolling lines, killing out, and then deleting
everything before that line, and saving out as a new, partial file from
which to complete things. I imagine I'm not alone in this.
It's also just occurred to me that I could leave the PC, and driver box on,
and just unplug the motors until I'm ready to go again. I'm not sure how bad
that would be for the system. My thoughts turned toward things like
back-EMF.
Yes, EMC does this already, look at <path to your config dir>/position.txt
>
I've done a find on my entire home directory. I don't have anything with the
word 'position' in it. Maybe I don't have something flagged on somewhere?
The problem is that your stepper drive does not remember the position
> between power cycles.
I see. It hadn't occurred to me the driver box had anything to do with it. I
think I wasn't really thinking it through, but had somewhere in the back of
my head assumed that EMC was sending which of A-D to be on. IIRC, it just
sends a direction to step, though, and the box figures out which one is next
in that direction. Is this correct? If so, how are microsteps handled?
That's been another thing on my mind lately - how, and where is precision
handled? I typically hand-create g-code out to 0.001", but when I recently
wrote some Python - using Numeric - it kicked out values to a far higher
precision, and at first, I was worried about how that would be interpreted,
but it seemed to just work. How is the driver box smart enough to handle the
16, or so decimal places, or does EMC round it down somewhere along the way?
Also, is the precision settable?
> A better method is to set up home switches, since this will calibrate the
> motor position in the case they were moved while the machine was off.
>
I'd love to do this, but again, my box hasn't the inputs necessary. It does
bring up some questions, though. How fast can you encounter a home switch?
Do you home in this way at feed, or rapid speeds? Does it simply not matter,
because it's always going to trip at the same moment when pressed, and thus
will always home to the same, say, 0.001"? How repeatably accurate are they?
Thanks so much for all this great information, fenn! I'm starting to finally
feel a bit more in control of my setup.
-Gary
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users
