One has to be careful here not to spec in a 10 ton dump truck for that once a 
year 500 lb utility trailer load of peat moss for the garden.  For one thing 
they are hard to parallel park and really expensive for fuel.
 
There already exists, and will for some time, systems that can handle multiple 
spindles, closed loop control of the encoders back to the PC along with 
multiple FPGA controlled I/O and smart serial motor control for these 
retrofitted large commercial milling machines.  Those users will never ever 
install a BBB with a cape that has slow HMDI screen updates and limited I/O.
 
So forget them.
 
By the same token, the customers who are using Ardunio based duos or whatever 
the latest flavour is for their 3D printers are also of no interest.  If they 
were we'd have seen the Replicape on a BBB become the standard with Machinekit 
or Linux as the backbone.  Hasn't happened.  Won't happen.  Not sure why.  
Probably price.
 
So what is the target market for this type of product?  Well who is buying the 
ready to go $200 to $500 CNC boxes in China and for what machines? 
 
If I were to venture a guess I'd say the ones that are about this size:
https://www.grizzly.com/products/Grizzly-7-x-27-1-HP-Mill-Drill-with-Stand/G0704
 
They come in all sorts of flavours.  They are generally driven open loop with 
stepper motors and require only a spindle sensor for quadrature and maybe a 
second quadrature input for an MPG control although those can be had pretty 
inexpensively as USB devices.  And to tell you the truth I really like my 
ShuttleExpress over the USB MPG pendant. 
 
As along as the BoB has a FAULT input, which I forgot to put on my previous 
list, you can even use intelligent drives like the step-servos that close the 
loop but provide a FAULT output when something goes wrong.  My STMBL, Bergerda 
and HP_UHU drives all have that.  I think the GECKO I have on the KNEE also 
does but I'm not using it at the moment.  All open collector outputs that pull 
the signal low when a fault occurs.
 
Anyway, that size of a machine and the price tag associated with it will set 
the price of the CNC conversion.  Most of the cost is in the mechanics and the 
electricals.  
 
So two PRU accessed quadrature inputs are more than enough to close the loop 
for power tapping as long as the spindle speed control is responsive.
 
About the only limitation I see in my list is that 500kHz stepping is really 
fast.  I used that number because that's the step rate for the Bergerda AC 
servos with the 2500 line encoder.    That math works out to 10,000 edges per 
revolution and 3000 RPM is 50 RPS which means a 1:1 ratio is 500kHz.  The 
Bergerda can scale the step pulses in order to match the encoder with slower 
step rates.  I don't know if the STMBL AC Servo drive can do that.  Pretty sure 
the HP_UHU with the dsPIC can or almost can.
 
But for this target market, using standard stepper motors with micro-stepping 
drives we're back to 25kHz max before we see the motor torque drop off to a 
point where step speed doesn't matter.  And if you are using the step-servos 
the selection of the encoder will determine what's required.
 
So I'll agree with Chris that it's the I/O on the BBB that is the limiting 
factor.  But 10MHz SPI bus could take care of that. 
 
What I would do is use the PRU to load the DMA device to write two bytes to and 
read two bytes from the SPI port at a 1MHz rate.  It's the BBB's main 
processors responsibility to keep this filled or to stall it with step levels 
low and dir at last used value.  
 
The trajectory planner is responsible for setting the step pulses ON within the 
two byte packet to send out the SPI port.  The next two bytes hold the 
direction and drop the STEP.  Any other outputs on that buffer will also be 
left as is.  
 
Now you have hardware generating 6 pairs of step/dir as high as 500kHz.  The 
amount of time the 8th pair is ON and OFF is dependent on the PWM frequency and 
PWM pulse period within that frequency.   It's a simple matter of keeping the 
queues with this information full and default values when they aren't.
 
John Dammeyer
 
 
 
From: [email protected] [mailto:[email protected]] On 
Behalf Of Chris Albertson
Sent: March-12-20 3:33 PM
To: Jason Kridner
Cc: Machinekit
Subject: Re: [Machinekit] Seeed to design and build Machinekit focused Cape for 
BeagleBone Black/AI
 
 
 
Isn’t that something the Beagle is strong at with the eQEP and PRUs?
 
 
Strong only until you hit up against the limited number of I/O pins.  A PRU 
based solution is cheap and simple but can't scale.
 
In general TI's idea to place a small microcontroller on the same chip as their 
ARM Cortex-A was good and we see others doing this too but a big machine tool 
like a 5-axis mill with tool changer and cooling and saftey interconnects is 
going to need something bigger than a PRU.  FPGAs work well as wold an STM32 
tht had on order about 100 pins.
 
-- 

Chris Albertson
Redondo Beach, California
-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/machinekit/CABbxVHs5uknWtEY-sP-hxfb13LNZ8CWBxxK30TiBn%3DOQ820K%2BA%40mail.gmail.com
 
<https://groups.google.com/d/msgid/machinekit/CABbxVHs5uknWtEY-sP-hxfb13LNZ8CWBxxK30TiBn%3DOQ820K%2BA%40mail.gmail.com?utm_medium=email&utm_source=footer>
 .

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/09d301d5f8ca%244521c160%24cf654420%24%40autoartisans.com.

Reply via email to