Core_XY_kins running on the CRAMPS, albeit poorly atm. Please dont bash the mockup. It has loads of errors I know, and was mainly a quick experiment to understand coreXY better.
Gonna be fun trying to trouble shoot all the interesting things coming from LinuxCNC to printing. @Charles_Steinkuehler
“Please dont bash the mockup.” – Seriously, mockups are the best. Shows you’re doing something! Hack away!
Nicely Done!!! It is all about persistence. Just keep swimming😅
Belt alignment is the key.
Your mockup is great! You should see the cardboard mockup of Wally I made from floppy drive head stepper motors and some old boxes from Mouser. At least yours moves properly! The floppy drive steppers didn’t have enough torque, and at the time I didn’t have extra stepper motors to play with. 
Was just playing with the INI file got it running up to 12000mm/min in straight lines with no following errors. First time I go at an angle though it throws errors.
Ick @ mm/min. For those of you out there who want better numbers, that’s 200mm/sec
Yup. There’s something wrong in the linuxCNC config. That and the fact that I think I’m one of three people in the world using it to drive coreXY its gonna be fun.
For the record I was pushing 500mm/sec in this mockup with my azteeg. Which is where I would like to be comfortably when my next machine is done.
Someone has to be first! 
I’ll be joining you soon with the CoreXZ once Nicolas gets back from the KC Maker Faire and cuts me some parts. One issue might be your microstepping and step rates. The default PRU setup uses a 10 uS task period which is very safe, but limits you to 50 KHz step rate max. You should be able to safely drop to 3-5 uS for the PRU task period which would substantially increase the top-end step rate. What steps/mm are you running to get 500 mm/s on the azteeg?
160 steps/mm. This whole controller is interesting. I never went outside what the stepper config wizard said in linuxcnc so going in and hand modifying the INI is new.
At 160 steps/mm you will be limited to ~312 mm/s at the maximum 50 KHz step rate unless you drop the PRU task period. I suggest dropping to 4 uS which will let you hit 500 mm/s with some headroom and should still be very safe on the PRU side (the 10 uS is hugely conservative, measured PRU execution time for a typical 4-axis setup is around 1.5 uS). So 4 uS should be fine unless you’re driving a bunch more step/dir generators.
You can change the PRU task period by adding a “pru_period=4000” to the hal_pru_generic load line in your hal file (4000 is the time in nS, or 4 uS).
loadrt PRUCONF prucode=$(LINUXCNC_HOME)/PRUCONF PRUCONF pru_period=4000
Is this the correct line Charles?
Yes, that’s the correct HAL line, and your change looks OK.
Oh, you should also turn the backplot display off (select the DRO tab). If I knew more about UI development vs. low-level programming, I’d rip the 3D view out (at least until the 3D GPU drivers work on the 'Bone with a Qt UI and Xenomai kernel). Without 3D acceleration the backplot sucks a bunch of performance from the CPU (although that has nothing to do with your following errors).
that helped some. What is a sane amount of FERROR and MIN_FERROR? From the manual looks like it should be as close to zero as possible.
FERROR = 30.0
MIN_FERROR = 10.25
This seems to work pretty well. But seems like a huge error window. At this point I can get up to almost 30kmm/min before the following error shows on 45degs
Migrated to the Macinekit list…
Thanks others can certainly benefit from this discussion
Does the core-xy have an advantage over the hbot scheme? It looks pretty similar except it’s got those crossing belts.
Yes its the same kinematic model, but the CoreXY takes the 45deg pulls that Hbot has out of the equation so the frame can be far less ridgid.
