CoreXY neither X nor Y moving

Nemesis1782

@droftarts Yes that is by design. The reason for that is that I'm going to be using three independently driven Z motors. The Default mapping is just that a default mapping.

If you check the GCode guide you'll see that this is a example:
M584 X0 Y1 Z2:3 E4:5:6 ; Driver 0 controls the X motor, 1 controls Y, 2 and 3 control Z motors, 4 5 and 6 control E motors

I do now realize that I defined 2,3,4 for Z initialy, however in this config have not reinitialized it. As per this note that might be a issue, so 'll be testing that tomorrow:
VERY IMPORTANT! Assigning a drive using M584 does not remove its old assignment. Therefore, if you assign a drive that defaults to being an extruder drive, you should also assign the extruder drives explicitly as in the above example. Failure to do so may result in unexpected behaviour.

Nemesis1782

@Phaedrux I'm sorry I tried using the configurator and it does not work correctly!

When choosing RRF3+ I get the following config for the endstops: M574 X1 S0 P"!zstop" ; configure active-low endstop for low end on X via pin !zstop

This does not work because S0 is no longer supported for RRF3+. It should' vv e been: M574 X1 S1 P"!zstop" ; configure active-low endstop for low end on X via pin !zstop

Also it sets: M667 S1 ; select CoreXY mode
Which according to documentation should be (for RRF3): M667 K1 ; select CoreXY mode

I understand you'd like people to use the tool provided. However atm it provides more issues then it solves atm.

Nemesis1782

I got the motors working correct now.

I still do have one confusing thing in the config and that has to do with assigning the drivers.
My physical connections: X is on 0 (Normally used for Z), Y is on 1, Z is on 2 (Normally used for X) [I did this because I will be using 3 and 4 for Z as well and it makes more sense having the Zs in order]

The working config is: M584 X2 Y1 Z0 E3:4; set drive mapping (With this config I would assume X is on the third driver however it isn't! It is on the first...)

According to the documentation: M584: Set drive mapping
Parameters

Xnnn Driver number(s) for X motor(s)
Ynnn Driver number(s) for Y motor(s)
Znnn Driver number(s) for Z motor(s)

So why doesn't it work when I say: M584 X0 Y1 Z2 E3:4; If I do this it treats the Z motor on driver 2 as the X, can anyone confirm if this is a bug?

@Phaedrux The Configuration tool generates old type config when selectin RRF3+. Specific issues I had:

(generic issue) you select inversion when selecting the endstop for the axis and you select if it is NC or NO in the next menu. This is redundant and confusing.
M574 Command sets S0 when selecting a NO endswitch type. This is incompatible/depricated on RRF3
M667(669) Command when on RRF3 it should set M669 K1 instead of M667 S1

droftarts

@Nemesis1782 i explained this before, but without the driver numbers. The board has the drivers physically labelled on the PCB as:
ZA/ZB, Y, X, E0, E1
Driver numbers associated with these are:
2, 1, 0, 3, 4
In older firmware, these were automatically assigned. With RRF3, there are no default assignments, but the physical order of the drivers, and their assigned number, persists.

See https://duet3d.dozuki.com/Wiki/Choosing_and_connecting_stepper_motors#Section_Stepper_Driver_Numbering

Ian

droftarts

@chrishamm See above. Please check endstop S parameter assignments when NO selected with RRF3 in the config tool.

And use of M667/M669.

Ian

Nemesis1782

@droftarts Ah, then I misunderstood what you said. My apologies. Yes I see the documentation and even though I already this it took you pointing it out for me to comprehend So thnx for the patience and pointing it out so clearly

I just made the assumption that the drives were numberred 0 to 4 in a (for me) logical manner.

So out of curiosity, why are the steppers numberred this way. There must be a logical reason behind it I'm not seeing.

I would like to mark the issue resolved since my config is correct (how do I do that?) and it works as expected. My initial test show that 100mm move in either X or Y gets a good result (measured with a precision of 0.1 mm for now)

@droftarts @Phaedrux thnx for your input and patience

droftarts

@Nemesis1782 said in CoreXY neither X nor Y moving:

So out of curiosity, why are the steppers numberred this way. There must be a logical reason behind it I'm not seeing.

I’m really not sure! The earliest Duets v0.6 used the same order but with only one extruder, but earlier electronics like the Melzi and Sanguinololu didn’t. So I’m not sure where it came from. Maybe @T3P3Tony or @dc42 knows?

Ian

droftarts

Thinking about it, it may be due to heat dissipation. The assumption is that the the X and Y driver would work hardest, so having the most copper around them makes sense, so put them in the middle.

Ian

Nemesis1782

@droftarts Ah yeah that would actually make sense. In that case I might actually move the assignments back since my X and Y motors are NEMA23's which will run at 1500mA. Can anyone confirm this is the case?

dc42

@Nemesis1782 said in CoreXY neither X nor Y moving:

@droftarts Ah yeah that would actually make sense. In that case I might actually move the assignments back since my X and Y motors are NEMA23's which will run at 1500mA. Can anyone confirm this is the case?

At 1500mA you don't need to worry about stepper motor cooling on a Duet WiFi or Ethernet. So use whichever driver assignment is convenient.

I don't know the reason why the drivers were laid out in that order on the original Duet, but @T3P3Tony might.

Nemesis1782

@dc42 Thnx for the reply. The Duet is mounted vertically and will be fitted with a low RPM fan. (Is it possible to have the FAN be controlled by Duet and Driver temperatures?)

Phaedrux

@Nemesis1782 said in CoreXY neither X nor Y moving:

(Is it possible to have the FAN be controlled by Duet and Driver temperatures?)

Yes.

https://duet3d.dozuki.com/Wiki/Mounting_and_cooling_the_board#Section_Cooling

You can tie the fan speed to the MCU temperature as a proxy for the drivers, you can add a seperate thermistor to a driver chip and use that, you simply set a fixed fan speed in your slicer start gcode and then turn it off again in the end gcode, or you can tie it to the hotend/bed temp to turn on when printing.

Nemesis1782

@Phaedrux Thnx mate, The Start/Stop GCode is actually a good idea. However, the RRF3 example is exactly what I want!

It would be nice if you could set variable frequencies though, preferably a frequency curve. That way instead of the fans turning on at a high speed intermittently they would ramp up and down as needed and thus much less annoying.

deckingman

@Nemesis1782 said in CoreXY neither X nor Y moving:

It would be nice if you could set variable frequencies though, preferably a frequency curve. That way instead of the fans turning on at a high speed intermittently they would ramp up and down as needed and thus much less annoying.

That can be already be done. Instead of setting a fixed temperature you specify a range. For example, you could use something like M106 Pn Snnn T50:80 Hn. This would start the fan turning when the temperature reached 50 deg C, ramping up proportionally to full speed at 80 deg C. You may find that at temperatures close to 50, the fan might make an annoying "buzzing" sound when PWM is at a low value. If this is the case then you can use at "L" parameter to set a minimum speed. i.e you could have say M106 Pn Snnn L125 T50:80 Hn. In this example The fan would be completely off at below 50 deg C. At 50 deg it would start to run at half speed and would stay at half speed until the temperature reached mid way between 50 and 80 (so 65) and from 65 to 80 it would ramp up from half speed to full speed.

You can also use the "X" parameter to set the maximum speed, the "B" parameter to "blip" the fan. There isn't much that you can't do. https://duet3d.dozuki.com/Wiki/Gcode#Section_M106_Fan_On

Edit. But you can only do that when there is an actual temperature which can be read. The MCU and driver temperatures are simply digital "flags" set when a certain value is exceeded.

droftarts

@deckingman said in CoreXY neither X nor Y moving:

The MCU and driver temperatures are simply digital "flags" set when a certain value is exceeded.

True of the driver temperature: see note in https://duet3d.dozuki.com/Wiki/Gcode#Section_M305_Set_temperature_sensor_parameters

Channel 1001 represents the temperature warning and overheat flags on the TMC2660, TMC2224 or other smart drivers on the Duet main board. It reads 0C when there is no warning, 100C if any driver reports over-temperature warning , and 150C if any driver reports over temperature shutdown.

But the MCU is a proper temperature sensor. It may need calibrating, however; see https://duet3d.dozuki.com/Wiki/Gcode#Section_M912_Set_electronics_temperature_monitor_adjustment

Ian

Nemesis1782

Thnx for the help guys, I'll tinker around bit with thos settings. @Calibration needed if the temp is off a few degrees that isn't a problem I'll make sure to err on te side of caution.

deckingman

@droftarts said in CoreXY neither X nor Y moving:

........................ But the MCU is a proper temperature sensor. It may need calibrating, however; see https://duet3d.dozuki.com/Wiki/Gcode#Section_M912_Set_electronics_temperature_monitor_adjustment

Ian

Of course it is - my bad.

(What is even worse is that I used to use MCU temp with a fan to cool the board when I had Duet2 - my memory just keeps getting worse the older I get).