Just want to second John here Sam. You videos are awesome!
I have learnt a whole bunch of Hal from your videos. On Mon, Feb 17, 2020, 1:28 PM Sam Sokolik <[email protected]> wrote: > Technically it should be able to do about 20khz (with reset added to the > pi_gpio component - SMOP). This is playing within the constraints of the > RT_Preempt realtime kernel... This kernel doesn't usually have very low > latency. It is what it is. > > I really wasn't expecting the PI to do any software stepping. But 20khz > would be a decent solution for a lot of people. > > If you need more - buy external hardware like mesa. It also runs it well. > > I am glad you enjoy the videos - I like making them. I hope to make many > many more. > > On Sun, Feb 16, 2020 at 6:12 PM John Dammeyer <[email protected]> > wrote: > > > Hi Sam, > > Nice. But it does seem to support my premise on isolating LinuxCNC from > > the hardware control. > > > > For example, way back a Pentium 386-66 with WIN-95 and MACH2 CNC was able > > to do this at 25KHz stepping. > > > > A BeagleBone Black with Machine Kit has PRUs to do the stepping and it's > > what, 4 years older than a RPi4? > > > > You’ve already shown that for a 1GHz+ LinuxCNC system that with an > > external Ethernet Hardware engine you can now get faster stepping rate . > > > > But only 10K steps/second on a 1GHz+ Pi? > > > > Since very slow PCs with limited memory could do this as well as the > > slower PRU processors on the BBB, I'd venture a guess that if a Pi4 can't > > do at least 50kHz stepping while also doing trajectory planning and > screen > > updates there is something really 'off' with LinuxCNC. Maybe too many > > hardware abstraction layers? > > > > If I do the math. The RISC processors generally run one instruction per > > clock cycle and if that's really true there are 20,000 CPU cycles between > > each step at 50kHz. Coming from the embedded world where I work that’s > > huge. And generally the trajectory planners create FIFO buffers that > hold > > a step and a direction bit for 4 axis in one byte. Each byte, sent out > at > > 50Hz, either has a step signal nor not. At the end of the 5uS step pulse > > time as you said, the step levels are set off again. > > > > So as long as you can keep the buffer filled it's the interrupt routine > > that places it out to a parallel port. And filling the buffer is the job > > of the trajectory planner which does the co-ordinated accel, velocity, > > decel for all axis to be able to maintain a specific feed rate in 3 or 4 > > dimensions. > > > > I'd say being able to 10kHz stepping and being happy with that might be > > setting the bar very very low. > > > > BTW, I really do enjoy your videos. > > > > John Dammeyer > > > > > > > -----Original Message----- > > > From: Sam Sokolik [mailto:[email protected]] > > > Sent: February-16-20 3:27 PM > > > To: Enhanced Machine Controller (EMC) > > > Subject: [Emc-users] RPI4 is pretty close to a decent machine control > > > solution... > > > > > > software stepping... > > > > > > https://www.youtube.com/watch?v=LKjNOVHhHio > > > > > > Ethernet > > > > > > https://www.youtube.com/watch?v=2SEB7TuCUR0 > > > > > > I don't have an spi solution to try.... > > > > > > sam > > > > > > _______________________________________________ > > > 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 > > > > _______________________________________________ > 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
