On Thursday 20 March 2008, Gary Fixler wrote:
>> [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.
And that will u$ually break the mirror and let the $moke out of the driver$.
The motors must be connected with dependable, solid, no intermittents allowed
cabling as long as the drivers are powered up. They can be disconnected of
course, but only when the driver power is off. That of course would defeat
the purpose. Some drivers have an enable input, my xylotex drivers do, which
would remember this, but I don't have that hooked up. Eventually? The
problem is that if the motor is turning when the disable comes in, it will
coast out of position.
I have left it running, turned out the lights and gone to bed, not coming back
till noonish the next day on a couple of projects and have gotten away with
it. As far as pausing it, with my setup the motors aren't reduced when
stopped, so they do get warm, but no warmer than when running, and have never
gotten hot enough to make me worry, most motors can run at 125-150F with no
problems. My long term concern when I do the lights out thing is the cooling
fans in my xylotex driver housing. The box is a long cube, long enough to
hold a 4 axis board, 3.5" square, with a 12 volt ex psu fan in each end, one
blowing in, the other out, and they are running on about 18 volts. Not all
of those fans will take that sort of abuse, but its been my experience here
that if it lasts an hour, it will last for years, one of them is probably 10
years old now! They are noisy at that speed though. And zero chance of my
drivers overheating which is the real criteria. :)
>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?
>
Are you thinking emc uses a serial port? Not normally since there is little
that is real-time about serial. Most use a parport interface.
>> 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?
emc does have the inputs. If your box doesn't have them available due to a
lack of breakouts, thats fixable. All 17 usable pins on a parport are either
used by xylotex, or are present as passive terminals on the edge of the
xylotex board, take 'em wherever. I'm running 4 axis's & the spindle ATM,
and still have about 5 pins I could use for other things leftover, but I
don't have home/limit switches setup yet either.
>
>Thanks so much for all this great information, fenn! I'm starting to finally
>feel a bit more in control of my setup.
>-Gary
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Rome was not built in one day.
-- John Heywood
-------------------------------------------------------------------------
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
