On Wed, 19 Mar 2008, Gary Fixler wrote: > 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.
This granularity is probably from the fixed number of pixels in the slider widget. > 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? http://linuxcnc.org/docs/html/config_ini_config.html The ini file is supposed to be described completely here^^, however sometimes people forget to write documentation. Did I just hear you volunteering? :) >> 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. just tested this and it works: export AXIS_OPEN_FILE=/home/fenn/sandbox/cxf_splash.py emc > 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. When you're ready: http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?BasicSteps > 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? :) I agree. The configuration file should allow you to specify in furlongs per fortnight if you so desire, but the .ini file format makes this impossible, or at least not worth the extra complexity. > 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 I'm not sure how you managed to acquire a sherline CNC for $600 as the base price is $2450 (which seems high to me). I would expect the factory setup to not hiss, catch fire, electrocute you, etc. You should call them and find out what the problem might be. > 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. This doesn't work, because rs-232 is not fast enough, and has unpredictable latencies, and needs special drivers for the device on the end of the cable. There are similar problems with most other networking technologies. This doesn't mean it's impossible, but it starts to diverge quickly from what EMC is really all about, a PC based machine control. (edit: i probably misunderstood you here. sherline uses a parport connector and simple logic signals, no codes or buffers or data) There are several interface cards you can add to the PCI bus, although for most people the parallel port connection they drive the steppers with has enough spare I/O for some switches and spindle control. You could tap into the parport line before it goes to the sherline driver card/box. interface cards: http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?EMC2_Supported_Hardware > 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. Some fancy motion control systems can cost up to 10 times (or more) what you paid for the whole system, and are overkill for this application. However, you can probably improve what you have if you learn a little bit. Maybe another sherline user can chime in here? > 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. run-from-line has been around for a long time, but due to some arcane code and unintended consequences like being unable to start the spindle, it's almost unusable at the moment. > 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. This would probably kill your drivers. >> 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? this is set with [TRAJ] POSITION_FILE = position.txt it's probably not documented... and it's not in many of the sample configs either. > 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? Microstepping is a way of dithering between two full steps such that the motor balances part-way. It smooths out the torque applied by approximating a sinusoidal waveform. The number of microsteps * the number of full steps/rev * motor revs per leadscrew rev * leadscrew revs/inch = the resolution of your system. Balancing the units is left as an exercise for the student, or you can use the handy dandy stepconf program. In any case, EMC sees this as the INPUT_SCALE value, which corresponds to the number of steps per distance unit. EMC will round off to within one step. The driver box never sees any numbers, only a direction signal and a step pulse. Presumably there are some jumpers in the drive that determine the number of microsteps. Note that the situation is completely different for servo drives. *scowl* >> 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? please RTFM http://linuxcnc.org/docs/html/config_ini_homing.html Homing velocity should be less than one step per servo cycle (1ms default) A standard microswitch is quite repeatable, at least over short time spans. Chris Radek reports repeatability to within .0001" iirc. ------------------------------------------------------------------------- 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
