Although the subject talks about SeeedStudio let's leave that part alone for a moment and discuss what the Beagle's part is in all this. I'd like to take everyone back to geometry learned in school. SQRT(X^2+Y^2) = hypotenuse of a right angle triangle. When we look at velocity we can use the same math. If both X and Y axis are moved at 12 IPM then the movement along that path happens at 16.97 IPM. SQRT(144+144). So when you set a G-Code value of F12 and execute a move with G1 set then X and Y will _not_ move at 12 IPM. First the distance of each axis is determined. Assume for this example it's the same distance of 12". That means the total distance moved along the hypotenuse is 16.97" and as we move along that path we want that to be done at 12 IPM because of the F12. Well that's (144) = (X^2+Y^2) or in this case because we have a 45 degree angle with equal X and Y it's SQRT(144/2) = SQRT(72) = 8.48 IPM. So both X and Y will be moved at 8.48 IPM. (in really we use the cos and sin of the angle to proportion the speed to achieve the F speed value. It's more complicated than that if the acceleration for each motor is different. So the simple path planner will use the lowest acceleration and make both motors accelerate at that speed so they move at the same rate per second per second to reach the velocity. Same with deceleration. Once this has been calculated the next question is how to translate a real world velocity (IPM) into steps per second. Once again not really hard if the reduction drive on each axis is identical. A bit harder if one uses 4:1 and the other uses 3:1. Now the software has to decide when to create each step pulse. Assuming both axis require the same number of steps to move 1 inch (0.2" per rev and 10 uSteps/Step = 2000 steps per rev = or 2000 steps to move 0.2") We're asking for 12 IPM which is 0.2" per second so that's 2000 steps per second. That's a step pulse every 500 uS. Our DMA clock is set to run at 1MHz spitting out the 16 bits into the SPI device so we get a 1uS long step pulse. Or in simple terms we get one 16 bit packet, with X and Y STEP pins both set high and another packet with X and Y STEP pins set low . Then the next 498 packets do not change the X and Y step pins. So for one second of data we need at 1000 byte array with 500 values where only one of those has X and Y set high. We need a second 1000 byte array with 500 values for the next 1 second worth of messages. The trajectory planner has one second to populate the array. The DMA controller signals when it switches to the next array and we ping pong back and forth. When there isn't any motion the array just has the DIR pins and the COOLANT pins set to their previous values. The output doesn't appear to change even though the SPI hardware is loaded by the DMA hardware to spit out new data at a 10Mhz rate. The question is…who and what populates the array and when and how. John Dammeyer From: machinekit@googlegroups.com [mailto:machinekit@googlegroups.com] On Behalf Of John Dammeyer Sent: March-12-20 4:59 PM To: 'Machinekit' Cc: beaglebo...@googlegroups.com Subject: RE: [Machinekit] Seeed to design and build Machinekit focused Cape for BeagleBone Black/AI 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: machinekit@googlegroups.com [mailto:machinekit@googlegroups.com] 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 machinekit+unsubscr...@googlegroups.com. 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> . -- 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 machinekit+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/machinekit/09d301d5f8ca%244521c160%24cf654420%24%40autoartisans.com <https://groups.google.com/d/msgid/machinekit/09d301d5f8ca%244521c160%24cf654420%24%40autoartisans.com?utm_medium=email&utm_source=footer> . -- 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 machinekit+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/machinekit/09ea01d5f8d4%24d7601090%24862031b0%24%40autoartisans.com.
