New RepRapFirmware 3.0 early beta

deckingman

There seems to be a typo in the instructions that you've linked to. For M305 the text says "........you must replace each M305 command by a similar M308 command..........". But the example new code is:..................

M305 S0 P"bed_temp" Y"thermistor" T100000 B3950 ; define bed temperature sensor
M305 S1 P"e0_temp" Y"thermistor" T100000 B4725 C7.06e-8 ; define E0 temperature

Methinks those M305s should be M308s.

Edit. Looks like @wilriker and I were typing at the same time and he got there first.

wilriker

What is the equivalent for

M305 P101 S"TMC" ; Virtual heater for TMC driver over-temperature state

?

gtj0

@dc42 seeing M308 being used reminded me about the explicit heater control I proposed (which also used M308) in https://forum.duet3d.com/topic/8387/fine-grained-heater-control/17

Any further thoughts on that for RRF3?

Also "Future Direction" doesn't seem to be a category you can select from the Categories list. The only way to get to this thread is from Unread or Recent, for me anyway.

dc42

@wilriker said in New RepRapFirmware 3.0 early beta:

I just fixed the documentation of M308 at the GCode Wiki (all formatting was broken and I think "Additional parameters for PT100 sensors" actually meant PT1000) and also documentation of M305 in RepRapFirmware 3 overview (there in the "New code" block it still said M305). @dc42 Can you please check if everything is correct now?

Thanks, it looks correct now.

@wilriker said in New RepRapFirmware 3.0 early beta:

What is the equivalent for
M305 P101 S"TMC" ; Virtual heater for TMC driver over-temperature state

Pick a sensor number for the TMC driver temperature warning. If you use it to control a fan, it must be not greater than 31. Then define it using M308. Example:

M308 S10 A"TMC" Y"drivers"

You can use that sensor number in the H parameter of M106 commands.

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.