On Thursday 09 January 2014 00:00:26 Andy did opine: > > Date: Mon, 6 Jan 2014 10:29:55 +0000 > > From: andy pugh <[email protected]> > > Subject: Re: [Emc-users] Ramped feed rate, unlurking... And new > > > > request for assistance > > > > To: "Enhanced Machine Controller (EMC)" > > > > <[email protected]> > > > > Message-ID: > > <CAN1+YZXNHvL1BppEKzzXmLcDwqozRbyKVX- [email protected]> > > > > Content-Type: text/plain; charset=ISO-8859-1 > > > > On 6 January 2014 03:54, Andy <[email protected]> wrote: > >> however I've been wondering how I could tie the feed rate to the > >> motor load. I'll try to get my head around this as I move forward > >> on my project. > > > > If you can find a way to get motor current data from the spindle drive > > into HAL then LinuxCNC has adaptive feed capability built-in. > > The difficulty here is that there isn't a huge range of analogue-input > > hardware for LinuxCNC. > > What are you using to generate the step pulses? > > Andy, pardon my ignorance, what /would/ be generating the pulses? The > PC is a Gigabyte E350N mini_ITX feeding a break-out board. > > >> http://www.automationtechnologiesinc.com/wp-content/uploads/downloads > >> /2012/06/KL-8082H.pdf > > > > That says 10uS step length and 200kHz. Which doesn't add up really. > > (200 kHz is 5uS combined step + dir) > > direction setup is quoted as 5uS, though if it was my machine I think > > I would be tempted to configure it in CC/CCW mode rather than > > step/dir. > > Hmm. Had not ever considered that, trying to understand implications > now... What is your thinking? > > The machine seems to be working when I use 10ns for step and 5ns for > direction. I am just not completely comfortable without knowing those > values are optimum. In the interim I will push on with those values. > Is there any safety to be had by doubling those? The reply to my > questions with the supplier, Automation Technologies, do not provide > useful information. I hope I am not being unfair to this vendor, but my > impression is that he does not want to be bothered by Linux users. > > > These drivers are supposed handle the encoder feedback and do any > > necessary travel corrections. As I understand, LinuxCNC has the > > capability to use the encoders, so maybe I would be better off with > > Geckos and wiring the encoders back to EMC2? > > LinuxCNC can handle the encoders, but only at quite low count rates > > unless you add extra hardware. Parallel-port counting tops out at > > about 20kHz, which with a high-count encoder can be rather a low motor > > speed. > > > > You can view the drive/motor combination as a conventional stepper > > drive, except one that can detect stalls and that will never > > (mechanically) miss a step rather than a servo system. > > Agreed, that is how I see it. In its application, I am not really > asking much of this system. At most, I am moving two axes at once, and > no blazing speeds. I just want it to be reliable. It is extremely rare > that my existing open-loop system has an issue, but I went this > direction for assurances that I wouldn't ever miss/lose steps. I had > thought that even an error with stoppage (rather than a dynamic > correction) would suffice. > > Thanks for the information!
How much margin you have (and I AM assuming an opto-isolated input in your motor drivers) will probably depend on the speed of the opto's involved. I am using a generic 2M542 driver kit, nominally $50 a motor, in 6 circuits these days, and have my parport reset set for 2.3 u-s on both machines. I have not been able to detect any miss-counts. But be aware, there are quite a few opto isolated gismo's out there with 10+ microseconds response time. Feed them a fast pulse train, and they WILL lose their place in the lunch line. What I need to do because I would like to define that down to a set of time requirements on my own, is write a 10 line gcode loop that moves it far enough to hit maxvel, and back, with small pause to read a dial indicator the table is tapping at one end of the travel. Start out obviously wide and make sure its happy, always returning the dial to the same spot after at least a minute of the wiggle. Once happy the lashup runs, stop, edit the reset time to 50% less, rerun lcnc and test it again. when it finally barfs, creep back up in 25% steps, when that works again, triple the reset time in case of future component aging and run with it. Your interface of course should be able to hit the opto's hard enough. The C1G's I used have fast cmos outputs, and can bang the opto's with 0 or 5 volts in much less time than that, and hit the leds in the opto's with 24 milliamps of source _or_ sink. Not too many optos can ignore that. Interfaces using std TTL outputs won't be so happy, and chances are you'll have to use them as sinks, tied to the opto's - pin, while the 5 volt rail is fed to the + pins. TTL can sink the current, but its not so hot at sourcing the current. But that is just good practice anyway. Oh, and post the results, naming the interface and the driver packages. 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) Genes Web page <http://geneslinuxbox.net:6309/gene> Dammit Jim, I'm an actor, not a doctor. A pen in the hand of this president is far more dangerous than 200 million guns in the hands of law-abiding citizens. ------------------------------------------------------------------------------ CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk _______________________________________________ Emc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
