New RepRapFirmware 3.0 early beta

wilriker

@dc42 said in New RepRapFirmware 3.0 early beta:

M308 S10 A"TMC" Y"drivers"

Y"drivers" was the part I was missing, thanks!

I also extended the description on the GCode wiki page to include mcutemp, drivers and drivers-duex.

Additionally, I realized that the wiki page lists max31865, max31855, max31856 whereas the source code looks for rtdmax31865, thermocouplemax31855 and thermocouplemax31855 respectively. I guess the wiki is wrong in this regard, isn't it?

And for anyone wondering: support for DHT22 sensors is temporarily disabled.

clearlynotstef

Switching conversation into new thread (or let me know if you want me to delete and start my own thread for this issue)
@dc42
To recap:
*Me: I'm stuck. I've used your gcode above, omitting the z line as I'm using a probe.
M584 X0 Y1:4 Z2 E3
M574 X1 S0 P"xstop" ; X min active high endstop switch
M574 Y1 S0 P"ystop,e1stop" ; Y min active high endstop switches

I've switched the S1 to S0 (but tried it both ways).
The machine properties window lists X, Y, Z, E0 for endstops. X works as expected. The Y axis (as a reminder, two motors and two end stops) does not. The respective indicators on the board light up when the endstop is triggered, but machine properties never switches to Yes. Interestingly, if I remove one of "ystop" or "e1stop" from the second M574 command, machine properties switches to Yes for the Y axis upon pressing the endstop that remains (Y axis turns to Yes if I remove e1stop from the command and press the ystop endstop, or if I remove ystop from the command and press the E1 endstop), but if I keep both, Y never turns to Yes if I press either or both endstops.

any ideas?

is it the even desired behavior that Y turns to yes in the machine properties window if any of the endstops belonging to that axis are triggered (or both?) Why is E0 showing as an endstop in that list?

Thanks as always!*

David:
Are you definitely running RepRapFirmware 3 beta?

Yes, definitely, settings page reflects this as well.

A Former User

@clearlynotstef said in New RepRapFirmware 3.0 early beta:

Switching conversation into new thread (or let me know if you want me to delete and start my own thread for this issue)

https://forum.duet3d.com/topic/5909/guide-for-posting-requests-for-help/1

Maybe that holds the answer

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