New RepRapFirmware 3.0 early beta

dc42

@clearlynotstef said in New RepRapFirmware 3.0 early beta:

M574 Y1 S0 P"ystop,e1stop" ; Y min active high endstop switches

I'm sorry, it should be:

M574 Y1 S0 P"ystop+e1stop" ; Y min active high endstop switches

mihaitintea

Hi

Sorry for asking, please can you help me with a link for "DSF" ?

Thanks

dc42

@mihaitintea said in New RepRapFirmware 3.0 early beta:

Hi

Sorry for asking, please can you help me with a link for "DSF" ?

Thanks

DSF is only for Duet 3.

deckingman

@dc42 David, could you elaborate on the format to use to address things that are plugged into expansion boards - the Wiki is a little sketchy.

As an example, my current M584 starts with X0:3:6. On gen 3, the first motor is likely to be on the third of 3 expansion boards and the other 2 will be plugged into the main board somewhere - let's say drivers 0 and 1. In that scenario, what would the start of that M584 look like?

Thanks

dc42

@deckingman said in New RepRapFirmware 3.0 early beta:

@dc42 David, could you elaborate on the format to use to address things that are plugged into expansion boards - the Wiki is a little sketchy.

As an example, my current M584 starts with X0:3:6. On gen 3, the first motor is likely to be on the third of 3 expansion boards and the other 2 will be plugged into the main board somewhere - let's say drivers 0 and 1. In that scenario, what would the start of that M584 look like?

Thanks

Each board has an address. The Duet 3 main board always has address 0. Each expansion board must be set to a different address using the on-board DIP switches. So you would typically give your expansion boards addresses 1, 2 and 3. Your M584 command would look like this:

M584 X3.0:0:1

Driver 3.0 is driver 0 on the board with address 3.

deckingman

@dc42 Thank you. I wasn't sure if the board identifier would be single digit or multi-digit as in "01" rather than 1" but you have clarified perfectly.

deckingman

I note that some commands use the forma P"pin_name" (eg. M308, 574, 577 etc) and others use the format "C"pin_name" (e.g. M950,452.453 etc), presumably because some commands use either "P" or "C" for something else.

Just out of curiosity, why wasn't some other letter (e.g. "N") chosen to precede the "pin_name"? It would be more consistent and thus reduce likely errors when we are devising or editing our configuration files.

dc42

@deckingman said in New RepRapFirmware 3.0 early beta:

I note that some commands use the forma P"pin_name" (eg. M308, 574, 577 etc) and others use the format "C"pin_name" (e.g. M950,452.453 etc), presumably because some commands use either "P" or "C" for something else.

Just out of curiosity, why wasn't some other letter (e.g. "N") chosen to precede the "pin_name"? It would be more consistent and thus reduce likely errors when we are devising or editing our configuration files.

Because there are very few letters free. Letter N is used to include line numbers in Gcode. Letter O is free but easily confused with digit 0, also one of the GCode dialects uses it for conditional commands.

C was already used as the endstop input number in a few commands, so I changed it to mean port number in those commands. But C is an axis name in some commands such as M574 so it isn't always available.

I guess it would have been possible to use Q.

wilriker

Not sure if this is intentional but I just realized that

M308 S4 Y"mcutemp" A"MCU"
M307 S5 Y"drivers" A"TMC"

both fail because they need an explicit P"nil".
I also found

constexpr const char *DefaultHeaterPinNames[] = { "nil" };

in Pins_xxx.h but it does not seem to be used anywhere.

deckingman

@wilriker You know far more about this that I do but don't those two commands have to have an M950 first? And if so, does the pin name default to "nil" in that command? Just a thought and I'm mostly likely wrong...........

wilriker

@deckingman Unfortunately your assumption to be wrong is correct.

Temperature sensors of any kind will be initialized solely with M308. And whenever you define a heater with M950 then the corresponding temperature sensor has to be defined before that via M308, i.e.

M308 Sn ...   ; temperature sensor for heater x
M950 Hx ...   ; heater x using temperature sensor n

The special types mcutemp, drivers and drivers-duex don't need a pin because the user can only enable or disable them and the data-line used internally cannot be repurposed by the user anyway.

deckingman

@wilriker said in New RepRapFirmware 3.0 early beta:

@deckingman ............. your assumption to be wrong is correct.

Ah well - no big surprise there then.

I knew that one command had to come before another so I was close (or maybe no - not even close).

dc42

@wilriker said in New RepRapFirmware 3.0 early beta:

Not sure if this is intentional but I just realized that
M308 S4 Y"mcutemp" A"MCU"
M307 S5 Y"drivers" A"TMC"
both fail because they need an explicit P"nil".

Thanks, I'll log that as a bug to be fixed.

I also found
constexpr const char *DefaultHeaterPinNames[] = { "nil" };
in Pins_xxx.h but it does not seem to be used anywhere.

I'll remove that.

smoki3

@dc42 said in New RepRapFirmware 3.0 early beta:

withdrawn

what are the pin names on duet wifi for the temperatur sensor pins?

dc42

@smoki3 said in New RepRapFirmware 3.0 early beta:

@dc42 said in New RepRapFirmware 3.0 early beta:

withdrawn

what are the pin names on duet wifi for the temperatur sensor pins?

They are e0temp and e1temp, as labelled on the board.

smoki3

It seems that build has an issue with the tool offsets if you use an tool changer.

If I do a tool change directly from T1 to T2 for example then the printer crashes because it want to recover his old position.
If I do a tool change from T1 to T-1 and then to T2 everything is fine.

It looks like if I do a direct change there is a issue when the tool offsets is deleted or applied. I am not 100% what wrong

smoki3

So I think I figured out the problem:

It seems that between the last move of tfree0.g and the first move of tpre1.g it is doing a recovery of the old position ( G1 R2).

@dc42

dc42

@smoki3 said in New RepRapFirmware 3.0 early beta:

So I think I figured out the problem:

It seems that between the last move of tfree0.g and the first move of tpre1.g it is doing a recovery of the old position ( G1 R2).

@dc42

Does it behave differently from firmware 2.03? There shouldn't be a difference.

smoki3

@dc42
It was definitely not like this on 2.02 and the older 3.0.

And its a really wired behaviour. Because I use:

; tfree0.g
; called when tool 0 is freed
;
; generated by RepRapFirmware Configuration Tool on Wed Sep 19 2018 21:12:53 GMT+0200 (Mitteleuropäische Sommerzeit)
G91
G1 Z10 F7200
G90
G53 G1 X0 F25000 ;XPOS
G53 G1 Y190
G53 G1 Y195 F5000
M400
M98 P"/macros/Toolhead/1. Toolhead unlock"
G4 P320
G53 G1 Y207 F5000
M400
G53 G1 Y165 F25000
M400

; tpre1.g
; called before tool 0 is selected
;
; generated by RepRapFirmware Configuration Tool on Wed Sep 19 2018 21:12:53 GMT+0200 (Mitteleuropäische Sommerzeit)
G1 X76 F25000
M400
G1 Y192
M400
M98 P"/macros/Toolhead/1. Toolhead unlock"
G4 P400
G1 Y207 F5000
M116 P3
M400
M98 P"/macros/Toolhead/2. Toolhead lock"
G4 P260
G1 Y150 F15000

The I only expect that only a X movement is done while the start of the tpre1.g but it first moves in X and Y.

dc42

If you read the firmware update motes for 2.03 you will see that tool offsets are now applied during tfree and tpost (but still not in tpre). Does that explain the issue? You can use G53 to prevent tool offsets being applied.