On Monday 04 April 2016 17:20:36 John Dammeyer wrote: > I'm sure you are going to have lots of fun with this. I suspect you > might be over simplifying it too. > > It's not really that important that you can generate 1 Mhz stepping > frequencies using the hardware timer on the micro-processor. Nowadays > that's probably a first or second year college lab assignment -- > rather trivial really. I'd be more concerned about dealing with > synchronizing steps between motors or a spindle. > > For example. Say you have a spindle turning 100 RPM. That's > 1.6666666666666666... revolutions per second (RPS). You want to cut a > thread pitch that matches the lead screw pitch so the lead screw has > to turn the same RPM as the spindle or also 1.66666666... RPS. > > Assuming you are using a stepper drive with 8 MicroSteps/step onto a > 200 step per rev motor. That's 1600 steps per revolution. So your > step frequency is 2,666.666666... Hz. (1600 steps per revolution x > RPS) Nowhere near that 1Mhz top end. > > Now if your counter circuit has a 2MHz input frequency it's pretty > easy. Divide by 750 to get that frequency. Simple so far. Right? > > Now your spindle drops to 99 RPM which is 1.65 RPS so let's make the > stepper turn 1.65 RPS which is a step rate of 2640 Hz. Now all you > have to do is program your counter to divide by 757.575757575757... > Oh wait a sec. It's probably an integer divider. So you will be out > by 0.57575757575 Hz. Not a big deal I guess. Only about 0.08%. Or > maybe it is. I wouldn't accept it. > > Now use that same approach trying to move three motors to move a tool > on a curve through 3D space and since each motor will run various > speeds through this path you will find all sorts of rounding and > truncating errors. > > And I haven't even touched on accelerating/deceerating from a stopped > position and maintaining synchronization. > > John Dammeyer
To me, a bigger need is to precalculate the time it will take the following axis, which may not be Z as I've already used a situation where it was X that had to track the spindle positions. I might add as a huge thank you to the guys who wrote that code, that substituting X in the G33.1 commanded motions, worked flawlessly for me. So a huge thank you to the folks who worked on that code goes out from me. But what we need, is to waste a turn of the spindle while waiting for the index pulse to come along, is to do a decent estimate of the accel to lock time, so that on the next revolution, the start of the following axis's movement is started that many encoder pulses BEFORE the index so that the lockup actually is accomplished within an edge or maybe 2 of the index, coming out of the encoder so that the following axis motion has a consistent relationship to the index pulse even if the rpms are ajusted. The current situation is that the spindle angle vs index is locked, but its locked at whatever angle the spindle is at when lock has been achieved, which works well indeed, at arbitrary but fixed speeds. But if you liked how it worked going slow, and crank up the spindle revs, that does not crank up the accel, so the thread is then out of time with the previously cut at a lower speed thread, wrecking the thread already cut. I see two ways to approach this, 1st being to calc what the accel time is for the rpm and see if it can be synched on the same turn by doing a dummy calculation to see when the rpms, and the ever lengthening accel to the faster speed is, and use this rpm where the accel time=1 rev as a max spindle revs limit. Then if the actual rpm requested is less, ask for a slower accel to lock at the next index, and start the following at the index so its just up to speed and locked one rev later at the next index pulse. Nice gentle, no steps missed accelleration. If the asked for rpm exceeds that 1 rev lock time rpm, then bitch and exit just like it does for a non-existent but perceived arc error now. I like the above idea better than allowing a more than 1 turn accel time, although thats not a hard rule. The idea is to put a witness mark on the spindle, fire a strobe at the index pulse, and be able to change the spindle speed while the witness mark remains fairly stationary when executing either a g33.1 or a g76. The g33.1 does a resynch on every plunge so the speed could be adjusted slowly if this calculation was done at every peck. G76 could probaby use the same code as it resets to the start position and waits for the index, so it could also be sped up by a small amount per stroke and get away with the speed change too if this was recalculated on each resynch. A third way might be to diddle the following axis's waiting for index starting point by the few thou difference the changing speed creates. In any event, I would love the ability to create 2 threads that when assembled, would match exactly for screwed home positions even if done an different spindle speeds. Today, even at fixed speeds, there seems to be enough error that I can't bore a thru hole thru both parts any way but after they are assembled at the final torque. Food for thought. I'm that beggar looking for a horse to ride again... :) > > -----Original Message----- > > From: Nicklas Karlsson [mailto:[email protected]] > > Sent: April-04-16 12:22 PM > > To: [email protected] > > Subject: [Emc-users] Stepper generator > > > > > > I am currently implementing a stepper generator on micro controller > > which may output square waves with clock frequency accuracy with use > > of built in timer peripheral. It may generate square wave probably > > up to at least in > > the > > > MHz range and be extended downwards as far as needed by some > > adjustment in software. It seems to work great and it should only be > > finnished off. I currently use relatively expensive micro controller > > but > > cheap > > > available for around $1 in large quantity should also work just as > > fine > > since it > > > have the same peripheral I used. > > > > It no problem to output a sequence of square pulses or with a > > certain frequency. Linuxcnc seems to output step velocity and read > > back accumulated number of steps generated. > > > > What puzzle me is period may vary. As is now I start to use values > > as soon > > as > > > they are received via Ethernet. I have used other networks like CAN > > before there everything is synchronized with "broad casted" with a > > high priority sync message. Do anybody have a clue how > > synchronization should be done for mesa Hostmot cards via Ethernet? > > Or more generally in Linuxcnc? > > > > > > Nicklas Karlsson > > ---------------------------------------------------------------------- >------ -- > > > _______________________________________________ > > Emc-users mailing list > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/emc-users > > ---------------------------------------------------------------------- >-------- _______________________________________________ > Emc-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/emc-users Cheers, Gene Heskett -- "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> ------------------------------------------------------------------------------ _______________________________________________ Emc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
