Well i want to stay small so i have to look what speed in mm/min i will get out of it maximum
anyways thanks for the explanation Am Montag, 12. Juni 2017 17:44:02 UTC+2 schrieb Chris Albertson: > > This sounds like a job for an FPGA. 1MHz loops are hard to do in > software. Even with custom PRU code, if it worked yours have job for > life maintaining it as new versions of the CNC software, OS and toolchain > come out over the coming years and decades. > > Mesa cards are not that expensive and other FPGA cards can be 1/2 their > price. So, just move the 1MHz loop into hardware. > > One problem with software is that when you look at results at the > sub-microsecond level differences is the dynamic code path lengths matter. > For example does it ALWAYS requires 15 clock cycles to turn on a bit? > No, likely there is an "if" statement some place where one branch is > longer. At low speeds this is a 0.01% effect at higher speeds this might > be a 10% effect. You don't know the magnitude of the problem until after > you write the code and see if you were able to make every execution path > the same length. Likely not so you have jitter at the XX% level. > > This is where FPGAs work best because you can clock the output pluses > relative to a divided down crystal oscillator > > On Mon, Jun 12, 2017 at 7:03 AM, Charles Steinkuehler < > cha...@steinkuehler.net <javascript:>> wrote: > >> On 6/10/2017 1:06 PM, Sag ich Dir nich wrote: >> > Hello, >> > >> > if i want to drive 5 axis with each 1 MHZ steprate, do i need to reach >> 5 MHZ >> > Stepgen or 1 MHZ? >> >> You need to a 2 MHz base thread (or 500 nS PRU period) which will give >> you a 1 MHz maximum step rate (1 thread period high, one thread period >> low). >> >> This is very easy to do if you're using hardware, but not so easy in >> software. I doubt an x86 can run interrupts anywhere close to that >> fast, and an ARM certainly can't. >> >> The PRU on a BBB can probably be coerced into running this fast, but >> you'll need to optimize the code. The existing hal_pru_generic was >> written for flexibility more than absolute speed, and probably won't >> go faster than several hundred KHz step rates with 5 stepgens. To get >> into MHz step rates, you'll probably need to hard-code the PRU logic >> (instead of building a chain of "tasklets" as is done now) and keep >> all of the state information in registers. It should be fairly simple >> to do, but you still might not quite make it to a 1 MHz step rate (the >> 500 uS task period only gives you 100 instructions to do step/dir >> generation for 5 channels, or 20 instructions per channel. The >> step/dir code isn't super complex, but is more than 20 instructions >> through the worst-case path, and some of the instructions take more >> than 1 clock (5 nS). Getting rid of the memory accesses (required for >> the current "tasklet" structure) and putting everything in registers >> ought to get you close to the required speed. >> >> -- >> Charles Steinkuehler >> cha...@steinkuehler.net <javascript:> >> >> -- >> 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+...@googlegroups.com <javascript:>. >> Visit this group at https://groups.google.com/group/machinekit. >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > > 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. Visit this group at https://groups.google.com/group/machinekit. For more options, visit https://groups.google.com/d/optout.
