Need Help Adding Synchronized Secondary CoreXY System Inside VCore 3.1
Full Story
Hey everyone! I’m working on a super niche project and could really use your collective expertise. Imagine this: I’ve got a RatRig VCore 3.1-300 (which is amazing, by the way!), and I’m trying to integrate a smaller, custom CoreXY system inside its build volume. This secondary system uses the same CoreXY belt/pulley setup and routing as the VCore but has a smaller (250x250) area and no Z-axis—it’s purely for synchronized X/Y motion. Think of it like a "printer inside a printer" that needs to mirror the primary nozzle’s movements.
Hardware Setup
- BTT Octopus V1.1 F446 (Motor3/Motor4 unused, free endstop pins available and connected to PG10 and PG11).
- Use Motor3/Motor4 for the secondary CoreXY, keeping RatOS’s primary stepper_x/stepper_y intact.
Challenge
- Use native CoreXY kinematics (gcodes and not manual_stepper hacks).
- Mirror the primary system’s X/Y movements via standard G-code (e.g., G0 X100 Y100 moves both systems).
- Avoid conflicts with RatOS’s existing stepper_x/stepper_y config.
What I’ve Tried
[Manual_stepper] Works for basic moves but requires manual CoreXY math (A=X+Y, B=X-Y) and does not use the standard gcode. Not usable for absolute coordinates or complex paths. Movements are sequential, not simultaneous.
Constraints
- RatOS’s primary stepper_x/stepper_y cannot be modified or reused.
- The secondary system must use absolute coordinates (but the endstops positioning of each corexy willhave an offset).
Questions
- Is there a way to define stepper_x2/stepper_y2 with independent CoreXY kinematics?
- Can ACTIVATE_PRINTER or RatOS’s multi-printer tools enable real-time mirroring?
- Has anyone successfully sync’d dual CoreXY systems on a single Octopus?
This project is equal parts thrilling and maddening, any guidance would mean the world! Whether it’s a config snippet, a reality check, or a “this isn’t possible,” I’d deeply appreciate your thoughts. Thanks for being an amazing community!
5 Replies
Beyond my abilities, but there was someone else in here a few months ago looking to do something very similar. There use case was printing liquid metal and using an electromagnet below the bed to affect how the metal came out or something. I'd search the discord for that discussion and maybe contact them for what they've tried.
Thanks for the information! I actually did reach out to that person already but unfortunately wasn't successful in getting a solution.
My current challenge is specifically about the steppers' definition of the secondary CoreXY system. The main issue I'm facing is that while [manual_stepper] definitions work, they don't use proper CoreXY kinematics and Gcode. This means I can only move diagonally right now, as the steppers move sequentially (one motor at the time) instead of simultaneously with coordinated movements.
What I really need is a way to give the secondary motors a similar definition to the standard [stepper_x] and [stepper_y] configuration that RatOS uses, but without conflicting with or overwriting the primary system. With CoreXY kinematics, the system would automatically calculate when both motors need to move together for straight X/Y movements instead of just diagonal paths.
You may be up against klipper limitations
I definitely defer to others that know more about klipper, but my initial thought is can you define that you need 2 motors for x and y, have them both move the same number of steps, and then for the smaller printer, just use gearing to change the movement to be smaller?
for example, the bigger printer "X" motor needs to move 3 steps, the smaller printer "X" motor would also move those 3 steps, but because of gearing it down it would physically move less.
this would allow you to follow a similar setup to the AWD configuration where they are using multiple motors all working together
I just found Dmitry Butyugin's modified Klipper with "generic_cartesian" kinematics: https://klipper.discourse.group/t/new-generic-cartesian-kinematics-incl-corexyu-corexyuv-generic-idex-and-awd/17510
This implementation allows defining multiple CoreXY systems simultaneously and most likely possible to link both systems that need to move together. I'd like to install this as an add-on without breaking RatOS functionality, ideally being able to switch between:
1. Standard RatOS [stepper_x] config for normal prints
2. generic_cartesian for my dual-system project
I've tried several approaches to install but can't get it working with RatOS. Has anyone successfully integrated modified klipper extensions like this for RatOS or have suggestions for a modular implementation that preserves RatOS's stability?
Klipper
New generic_cartesian kinematics (incl. CoreXYU/CoreXYUV, generic I...
A follow-up from the thread in the PR regarding inverted hybrid corexy kinematics. As per discussion there I went ahead and implemented a new generic_cartesian kinematics class (code available here). This new kinematics class allows one to define in a pretty flexible manner an arbitrary Cartesian-style kinematics. In principle, the regular carte...