Re: Corexyuv vs corexy idex

This is a short discussion of a novel design conversion done to a CoreXY system, turning it into an IDEX or independent extruder system. The only additional mass added to the Y gantry is the weight of the new U carriage. Almost all of the original CoreXY components remain the same or very similar. This approach infers a lower complexity and mass on the gantry than all the IDEX systems available today. A Duet style mother board is required.

I have always loved the design of a CoreXY machine for its scalability, precision, and speed. It is a truly great design but it only supports a single X carriage or single extruder. If the desire arises for dual extrusion, the conversion ideas that I have researched have been very complicated design modifications. They consist of tool changer systems, or a new motor on the Y gantry (added mass), or a complete duplicate set of belts, pulleys and motors. I have used dual extruders on a single carriage before and the results were not predictable and often too sloppy with smearing. I need independent extruders (IDEX) for the work I do. I spent most of my “Covid pandemic time” perfecting what I think is a reasonable path for conversion of most CoreXY machines into what I will call CoreIDX, or a modified CoreXY machine that becomes an IDEX system.

Figure 1: CAD version of a CoreIDX gantry system

My original design criterion was to create a very good CoreXY machine on a fairly large frame (~350x350x500mm print area); but this was really a fall back position if my IDEX idea didn’t work. I did not want to be wasteful so I reused as much of the original CoreXY components as possible. This concept reutilizes almost all of the original hardware by keeping the Core XY belts, pulleys and motor placements without additional motor weight to the Y gantry, only the U carriage weight is added. Figure 1 represents what I created based on a basic HEVO frame kit and design ideas found on Thingiverse.

X and U Drive
Figure 2 shows the pulleys, belts, and motors are the exact same as a CoreXY design. This conversion of a standard Core XY into a modified Cartesian IDEX is done by splitting the single X carriage into two carriages, X and U. These are now X&U belts and X&U motors .

Figure 2: One belt attaches and the other passes through on the X and U carriages

Each of them now attached to only one of the two pre-existing Core XY belts allowing the other belt to freely pass through it as shown in the circled area of Figure 2.

Figure 3: Bottom view X & U carriages showing belt attachment and pass-through areas

Figure 3 shows how the separation of the belts between the two new carriages was accomplished allowing a belt to attach to one carriage while passing through the other one.

This design maintains the rigidity and alignment of the Y gantry in a similar manner as the CoreXY design since belts, pulleys tensions remain the same but they no longer drive the gantry in a Y direction. Each carriage is free of the other and driven by the original X and Y motors now repurposed as X and U drive motors driving either carriage in the X directions only.

Fig 4: Y motor, shaft, and belts all mounted horizontally on top

Y Drive
The Y gantry is no longer driven or controlled by either of the two original motors. One additional motor is now required to drive the Y gantry back and forth. It is accomplished by adding the new Y motor to the back of the frame as shown in Figure 4. It drives a shaft with drive pulleys that push/pulls the Y gantry fore and aft just like many typical Cartesian printer designs. Adjustable belts pulleys are added to front of the machine to provide adjustment for the Y belt loops. This means the only added weight to the Y gantry is the weight of the additional U carriage and the attachment points for the belts and no additional motor mass since all positional drive motors are frame mounted.

Kinematics
This design maintains CoreXY belt tensions but does require modified kinematics not available to Marlin based HW/FW. The new X and U drives accurately move the two carriages in the +/- directions in a normal Cartesian manner but not the Y drive. If the Y gantry moves it will affect both X & U carriage positions. If the new Y gantry is moved, the X & U carriages either move diagonally together or apart. This means any Y movement of the gantry has to be countered by an equal movement of both the X & U motors (in opposite directions) in order to maintain their current position. This design requires hardware/firmware combination that allows for easily modified kinematics. Marlin and that class of hardware/firmware as far as I know can not accomplish this task. I do not have the programming skills to tackle C++ and/or Python therefore my logical choice was to move to a Duet style motherboard which runs RepRap firmware and capable of what I needed. With this motherboard the kinematics g-code command used is:

M669 X1:0:0:0 Y-1:1:0:1 Z0:0:1:0 U0:0:0:1.

CoreIDX Summary
The CoreIDX machine has performs flawlessly and there are no plans to revert back to CoreXY. I have successfully used it for over a year commercially with amazing results. Besides great two color printing it has been utilized in duplicate and mirror mode operation too.

It has been over a year since I posted my IDEX project and decided I needed to provide some updates. (https://forum.duet3d.com/topic/27864/coreidx-conversion-of-a-corexy-printer-into-an-idex/7?_=1685127576825) . The machine has gone through multiple minor modifications but the CoreIDX design has remained the same. Here are several additional drawings to aid in explaining the differences between CoreXY, CoreIDX and HaqXY or Dual Markforge belt arrangements. Thank you to Haggan90 and dc42 as referenced by sonderzug, for setting up the kinematics for this back in 2019.

CoreXY

CoreIDX

First I wanted to show how close the physical layout is between a CoreXY and a CoreIDX. Basically just splitting the X carriage into X and U carriages and adding a Y drive. Of course one must add an additional endstop for U and modify the system software files for the kinematic changes plus it must be setup as an IDEX system.
CoreIDX belt system

Dual Markforge belt system

Next is a quick discussion about the differences between "Dual Markforge" (which is HaqXY) and CoreIDX. They both use the same or very similar kinematics formulas as far as Duet RepRap firmware is concerned but the belt configuration is different and significant. The CoreXY belt pattern is superior to the Markforge configuration because the CoreXY belt tensions hold the gantry alignment. Note the only changes between these two belt systems are the routing of the belts and the placements of two pulleys (shown with "*"s) . The CoreIDX moves the pulleys off of the gantry and onto the opposite corner of the back frame (diagrams above) positioning pulleys like a CoreXY. That alteration makes all the difference in whether or not the gantry holds its proper right angle alignment to the frame. CoreXY theory states the gantry is held perpendicular to the Y axis, reference Ilan E. Moyer 2012 http://corexy.com/theory.html because of the pulleys and belt routing. This is true whether a single carriage (CoreXY), double carriage (CoreIDX), or no carriage (straight edge as is the case with a drafting table). The tension on the gantry presented by one CoreXY belt is countered by the tension of the other belt and gantry alignment is established by their tensions, as explained by Mark Rehorst in his “Core Belt Tensioning myths” https://drmrehorst.blogspot.com/2022/07/the-corexy-belt-tuning-myth.html If the belts are tightened to the point where the gantry is square to the printer frame and tight enough for precision movement, the gantry will be constrained by the CoreXY belts and remain perfectly aligned through all movements. That is true if the CoreXY system was designed properly in the first place. The CoreIDX belts do the same, with the new Y belts providing additional constraint.
All HW changes shown in red

Here is CoreIDX with its latest updates that include moving from one to two Y motors for the Y drive, new carriage designs with Sailfin extruders and print cooling fans, and a new triple Z drive.
G3d CoreIDX

Soon to be released on a Thingiverse near you,

@droftarts , Yes I realize that now. I found feature request #959 and want to add my voice to the ones requesting this modification. I feel this change could add significant flexibility to M291 by opens up many different options regarding how a query is responded to, or not. Note that is my case I don't even need or want the extra cancel box, but I would live with it if I could get the cancel/timeout to work the way I want it to.

My reason for this request is that I want to reduce the amount of machine cycling as I call macros that contain activity that has already been done and has set flags as to have been completed. The idea is to go ahead and do the extra cycling if there is no response to the query, as a safety mechanism.

@oliof the Y drive happens to be a dual shaft single stepper that is a bit larger than my U 8 X motors. It was something I had in my spares.

Oliof, the machine has been build and fully operational for about 18 months although several of the components have been redesigned several times. I'm not sure about your question on steppers. There are two carriages (X & U) each with a single hotend. They are located on the Y gantry. The extruders which drive the filaments can be located on the carriages (like BMG) or located on the frame in a bowden arrangement. Let me know if I answered your question or not.

@sonderzug, I appreciate your input as I have not been following the latest IDEX designs concepts since about January of 2020, but I had seen a post back in 2019 that had a standard CoreXY design with Markforge carriage and pulleys added to it, and that was part of my inspiration. I believe, ( I'm not a mechanical engineer, just electrical) that the CoreXY style belt routing provides less raking of the Y gantry. Note that I also designed and build a Gli3DR style to see if it would work but I could not get the precision of the CoreXY especially if you are working with a large frame (520 x 510 mm interior) so I settled on this design. I am not surprised that others have found similar ways to implement independent extruders, but since my machine has been operational for 2 years now, I finally decided to basically publish the design and implementation of what I came up with. Better late than never. Here is a photo of the system after it completed a 2 color print

@fcwilt Exactly what I needed to get past my mental roadblock. Some small code blocks doing just what I need. Now to refine the hardware to go with it. Most appreciated Gilly

@fcwilt
Yes, when I echo, that is the number I want to store as a temp variable then use in calculations of tool offsets.

echo "it is", move.axes[0].machinePosition
it is -118.088

Thank you for your guidance. I believe I 've got it from here.

@Strider007 Ok, now studying M409, and I think I got this working.

Thanks all

@zuoyan
Its a long list, and I've looked through it multiple times. I probably should have mentioned that. That's when I found the two suggestions that fcwilt gave me but no success so far. Thanks

@fcwilt Thanks,
Ok, tried all combinations of your suggestions and only got error messages as follows:

move.axes[0].machinePosition
Error: Bad command: move.axes[0].
Error: Bad command: machinePosition

I had hoped that would work and had tried it already. What am I missing here?

I

@fcwilt Yes, I send a "G38.2 X10 F100" command, the machine moves until the sensor is tripped and stops. I want that exact X coordinate where it stopped as a number to be used in in alignment calculations.

I need to be able to take an unknown X or Y coordinate and set it as a variable in a macro.

I'm using the G38.2 command to find an edge for use in a calculation. The G38.2 command works as expected and stops correctly at the location it is triggered. I can see the X and Y locations on the DWC or by using a M114 command but I do not understand how to change that into a variable I can use in a macro for a calibration calculation.

With a G30 command I can get the Z coordinate using
"global.autoz_tempx0 = sensors.probes[0].lastStopHeight

How can I accomplish this with the G38.2 command, having it provide the X or Y coordinate?

Any help or direction would be greatly appreciated.

@Phaedrux
Thank you. I currently use Cura 5.5.0. I will look over the several files that have exhibited this issue today but I run those same files on two other machines with no bed heater issues. Only this machine exhibits the unreported fault. That is the reason I believe it is something with this specific motherboard rather than the files. It does have driver0 damage; perhaps an EOS event hurt the processor.

Can anyone suggest any diagnostics I could run while printing that might catch this fault? I'm assuming there is a latch or memory location that holds the "heater active" data. Can that be monitored, and capture what's going on?

Yes Cura calls Reprap during file generation.

@jay_s_uk
I considered that but the same gcode files print fine on my other two machines. It is only this machine that has this issue. This totally random. Some times it holds and performs normally, other times, it will switch the bed to standby before the print starts. I have done several prints where it dropped to standby multiple times. Setting bed standby to 94C is all that saves my prints.

I have an Ultimaker clone, with a used Duet 2 WIFI. The heater appears rock solid viewing DWC until it switches to standby. I see the temp drop on DWC or if looking at the PanelDue, the normally red indicator turns yellow. I get no heater fault, or message. If I use either the PanelDue or the DWC I can easily reset the bed temp back to active. I've been saving my prints by setting my bed standby temp to 93C (2 degrees below my desired active temp). So far it has not slipped past the standby temp but what is going on.

Note, the motherboard was purchase used from Europe and shipped over.It is a clone, and driver 0 was blown. Since I only need 4 drivers I just programmed around that issue.

The system runs on a 12v supply but the bed heater is powered by mains with a SSR-25 controlling it so I don't believe it to be momentary PS sag. Possibly a memory issue? Running RRF3.5.1. Here is my config for this system.

; Configuration file for Duet WiFi (firmware version 3.5.1)
; executed by the firmware on start-up
;

; General preferences
M575 P1 S1 B57600                              ; enable support for PanelDue
G90                                            ; send absolute coordinates...
M83                                            ; ...but relative extruder moves
M550 P"U-2"                             ; set printer name

; Network

; WIFI on for home network
M552 S1                                        ; enable network
M586 P0 S1                                     ; enable HTTP
; No WIFI for stand alone, network off
; M552 S0                                      ; disable network
; M586 P0 S0                                   ; disable HTTP

M586 P1 S0                                     ; disable FTP
M586 P2 S0                                     ; disable Telnet

; Drives
;  Driver P0 is not functional
M569 P1 S0                                     ; physical drive 1 goes backwards
M569 P2 S1                                     ; physical drive 2 goes forwards
M569 P3 S1                                     ; physical drive 3 goes forwards
M569 P4 S0                                     ; physical drive 4 goes backwards
M584 X1 Y3 Z2 E4                               ; set drive mapping
M350 X16 Y16 Z16 E16 I1                        ; configure microstepping with interpolation
M92 X80.00 Y80.00 Z1600.00 E400.00             ; set steps per mm
M566 X900.00 Y900.00 Z60.00 E120.00            ; set maximum instantaneous speed changes (mm/min)
M203 X6000.00 Y6000.00 Z180.00 E1200.00        ; set maximum speeds (mm/min)
M201 X500.00 Y500.00 Z20.00 E250.00            ; set accelerations (mm/s^2)
M906 X900 Y900 Z900 E490 I30                   ; set motor currents (mA) and motor idle factor in per cent
M84 S90                                        ; Set idle timeout

; Axis Limits
M208 X-98 Y-120 Z0 S1                         ; set axis minima
M208 X112 Y90 Z300 S0                         ; set axis maxima

; Endstops
M574 X1 S1 P"!xstop"                            ; configure switch-type (microswitch) endstop for low end on X via pin xstop, active low
M574 Y2 S1 P"!ystop"                            ; configure switch-type (microswitch) endstop for high end on Y via pin ystop, active low
M574 Z1 S1 P"zstop"                            ; configure switch-type (Optical) endstop for low end on Z via pin zstop, active high

; Z-Probe
M558 P0 H5 F120 T6000                          ; disable Z probe but set dive height, probe speed and travel speed
M557 X-90:90 Y-90:90 S20                       ; define mesh grid

; Heaters
M308 S0 P"bedtemp" Y"thermistor" T100000 B4138 		; configure sensor 0 as thermistor on pin bedtemp
M950 H0 C"bedheat" T0                          		; create bed heater output on bedheat and map it to sensor 0
M307 H0 R0.766 K0.379:0.000 D2.01 E1.35 S1.00 B0	; Auto tune provided values for PID mode 11-2022
M140 H0                                        		; map heated bed to heater 0
M143 H0 S100 A2										; shut heater off temporarily if tripped
M143 H0 S110 A0                                 	; set temperature limit for heater 0 to 110C, set fault if tripped
M308 S1 P"e0temp" Y"thermistor" T100000 B4138  		; configure sensor 1 as thermistor on pin e0temp
M950 H1 C"e0heat" T1                           		; create nozzle heater output on e0heat and map it to sensor 1
M307 H1 R2.371 K0.338:0.000 D10.03 E1.35 S1.00 B0 V11.8		; parameters derived from Autotune on 11-2022 PID mode.
M143 H1 s250 A2										; shut heater off temporarily if tripped
M143 H1 S260                                   		; set temperature limit for heater 1 to 250C

; Fans
M950 F0 C"fan0"                                 ; create fan 0 on pin fan0 and set its frequency
M106 P0 S0.0 H1 T45                             ; set heatsink fan 0 value. Thermostatic control is turned on at 45C
M950 F1 C"fan1"                                 ; create fan 1 on pin fan1 and set its frequency
M106 P1 S0.0                                    ; set part cooling fan 1 value. Thermostatic control is turned off

; Tools
M563 P0 D0 H1 F1                               ; define tool 0
G10 P0 X0 Y0 Z0                                ; set tool 0 axis offsets
G10 P0 R0 S0                                   ; set initial tool 0 active and standby temperatures to 0C

; Custom settings are not defined
M501											; Use settings in override file that were dervived from Auto tuning system

Any insight would be appreciated.