>
> > 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.


Interesting! I've done quite a bit of UI stuff in scripting environments for
work, and play, and they usually allow explicitly setting a value. Once you
touch the slider, you mess it up, of course, and trap yourself in the
discrete steps of the slider, but often the slider will include an editable
int field for being more explicit than the slider itself. It probably
doesn't matter, however. I'm never going to notice the difference between a
few IPM.

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? :)
>

Oh no! What have I done!? :) Yeah, I'll help out where I can, when, and as I
can.

just tested this and it works:
> export AXIS_OPEN_FILE=/home/fenn/sandbox/cxf_splash.py
> emc
>

I'll give it a shot, but meanwhile, I can open Python scripts in 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
>

Cool, thanks!


> 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.
>

Ha! You've put things in perspective for me. I'll get over myself, and just
remember from now on that it's IPS in the .ini file.


> 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.
>

Oh no, the cnc-ready mill was indeed a few thousand. It didn't come with a
control box, though, and their offering was $600:

http://www.sherline.com/8760pg.htm

> 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)
>

You know, it's been so long since I've been behind the machine, I totally
forgot it's parallel. I've been working with microcontrollers, too, and am
using serial with them, and got my wires crossed. Now it comes back to me. I
had to special order a part for my Shuttle XPC to give me back the missing
parallel port.

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
>

Thanks for the link. Now that I'm reminded it's a parport interface, I'm a
bit excited. I suppose it all just comes down to telling the system (via
HAL) which pins should be connected to what. The shrouds of mystery are
being peeled away, slowly. Also, thanks for the link.

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?
>

True, I can't spend loads of money, as this isn't a financial investment.
It's all for fun. Also, I have at least a dozen other hobbies, the current
most expensive involving building up my woodshop out in the garage. I think
I stand a pretty good chance of proving to the world that money can indeed
buy great happiness, if I only I could find someone with deep pockets
willing to take me up on this wager.

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.
>

Who's palms do we gotta grease to make this happen? I have at least 4 kinds
of grease here :)


> > 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.
>

Well then forget that.


> >> 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.
>

Thanks! I'll see what happens. I don't know how you guys know all of this
stuff, but I'm glad you do.

Balancing the units is left as an exercise
> for the student, or you can use the handy dandy stepconf program.


I had quite bad luck using that, mostly because the only directions I could
find for it were severely out of date, and nothing matched up, and just
wishing really hard to help me understand what I was looking at. Oh, and I
recall now that the axis 'test' feature was broken. It would cause the
motors to quietly wiggle in place until I escaped the process. It may have
had something to do with the messy state of my .ini file at the time. It
might be time to give it another shot, to either make it through, or drum up
some clearer reports on my issues.


> 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.
>

Interesting, and it makes sense if it's only sending step, and direction
pulses. The driver box would have no idea about microstepping, and would
thus need to be set to to do so internally somehow. That said, I'm not sure
if my motors are being microstepped, but it seems like they might be.
They're the standard 200 steps/rev 1.8ยบ NEMA 23 deals. My screws are 20TPI.
To get an inch out of EMC, I've had to set the scales to (+/-)16000, but
20TPI * 200 steps/rev is only 4000. Wouldn't that mean my motors are making
3 microsteps between whole steps, for a total of 4 times the usual number
(800 steps/rev)?

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.
>

It looks like it's being done how I'd imagined it could/should be done.

Thanks for all this great info!
-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

Reply via email to