[Coco] [coco] coco CNC

[Gene Heskett]

On Thursday 14 February 2008, George Ramsower wrote:
>Got the lead screw, nut and motor in place, calibrated and working fine.
>I just now finished making the pilot holes in the slide to drill and tap for
>the screws to mount the working table onto.
>Next, I'll secure the table with double sided tape and re-run the program
>with the Z axis moved up to the table and make the pilots for that.
>Tomorrow, I'll drill and tap the slide and drill the table.
>
> Then comes the hard part... I need to mill out the holes in the table so
>that a standard machine screw will see a flat surface inside the holes. This
>means I have to mill a CIRCLE!!
> That's the real bottle neck on this system. Using SIN and COSIN is
>painfully slow. However, being as the circle only has to be about .375 inch,
>it won't be all that bad except that it takes several passes to make each
>hole and I have four holes to do.
> I started thinking on this yesterday and I think it's time to start using
>the cassette relay to turn the dremmel on and off so I don't have to listen
>to this thing scream while the thing is moving from point to point.
> When I did the pilot holes on the slide tonight, it was a pain to wait for
>the dremmel to get close to the designated point of drilling(actually, I
>used a .030 end mill) and then turned the dremmel on to make the hole as it
>approached the designated spot. A person could fall asleep waiting for the
>"rapid move".
> I have the OS9 Motor on and off routine, so I'll work on that later to
>incorporate into this system. UGH! A RELAY! I hate relays.  Maybe later, I
>finger out a way to put an SCR on the thing.

I don't think the cassette relay's contacts are up to a: switching line 
voltage, and b: the amp or so the dremel draws.  That means a booster relay, 
or a triac.  There are probably 500+ circuits to use a triac available on the 
net, and the cassette relays contacts would last 3 days past the rapture.  
The triac could even be driven from a flip-flop that would be another address 
on your 1 of 16 decoder as there are triacs with only 50 microamps of gate 
current required available from several src's.

> A machine language routine to do a rapid move would be ideal, except I have
>no clue how to do that. So... I have to bear with it.

A machine language routine could do that at a high enough step rate that you 
could hear the interference in the motion caused by the clock IRQ.  This CAN 
become a problem causing loss of steps if the motor is moving fast enough to 
become ballistic.  OTOH, if 60 half steps a second, in step with the clock 
IRQ would suffice, the clock module itself could be re-assembled with an 
output to the motors routine that it executes as part of the clocks IRQ.  
That would about double the processing each clock IRQ would need to do and is 
quite doable time wise.  The question then becomes where in the zero page, do 
you find room for the motors 'how far' and 'which direction' controls.  You 
would need two contiguous bytes, with the MSB being the direction bit, for 
each motor.  I don't think there are 8 spare bytes in the whole zero page 
though.  Make that 9 bytes cuz you'd need to be able to preload those values 
and then enable the motion.  Then, to vector on angles other than straight or 
45 degrees, a third integer per motor would be needed to control the 
individual speeds and go at any angle, but then the speed goes away if you 
have to count down from 46 for one motor while the other is counting down 
from 7 to move at such and such an average vector.

That means this would have to be divorced from the clock modules 60 per IRQ, 
and tied somehow to an IRQ every x number of hsyncs, and this reload number 
could be varied by B09 to control the overall speed.  And this then becomes a 
syscall to map a block of memory so its available both to B09 to write these 
numbers to, and at the same time also mapped into the address space the IRQ 
service routine the gime drives so that the data written by B09 is available 
for this IRQ to drive the motors with.

The linux program I use, EMC, has 3 more or less independent loops.  The RTAI 
driven motor driver runs about every 35 u-secs, getting its data from the 
servo loop which runs at a sub-multiple of that, usually around a 
millisecond, and it takes its cues from the trajectory planner which runs 
every 10 to 15 milliseconds, and the display is the last to be updated, every 
100 milliseconds or even slower as it gets only the leftover cpu time.  They 
are all (except for the display update) locked to multiples of the fast base 
loop so everything stays in step.  I think the approach is a good one when 
there are motor ballistics to contend with, but for no faster than you might 
be going I don't think acceleration profile control would need to be done.  
So you'd have B09 doing the trajectory stuff and saving to memory someplace, 
and the background high speed gime timer driven loop then using that data to 
actually drive the motors, and it should be 10 to 100 times faster at the 
motors I'd think.  Does that drive a wish to learn os9 assembly? ;-)

> Future projects shouldn't reveal this problem as I won't be moving four or
>five inches to make the next cut. This current project is unique inasmuch as
>I'm building the machine with the machine. Go figure.

That is what it seems we all do, build the next machine, or an improvement to 
the machine, with the machine.

>George
>
>
>
>
>
>--
>Coco mailing list
>Coco at maltedmedia.com
>http://five.pairlist.net/mailman/listinfo/coco



-- 
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)
If all else fails, lower your standards.