New RepRapFirmware 3.0 early beta

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.

wilriker

@dc42 Small hijack here: I realized that tool offsets are not applied for G32 when doing manual bed leveling assist. Is that how it is supposed to be?

wilriker

(I think) I found a bug with PID tuning. When I try to run M303 Hn Snn it will always give me

Error: Heater is not ready to perform PID auto-tuning

I tracked it down to Heater.cpp:CheckGood() where it says

return GetMode() == HeaterMode::fault && CheckProtection();

and I think the first comparison should be != or the heater is only good it if actually is in fault state.

P.S.: Recompiled with != and at least it started the PID tuning - not sure if it will stop heating before the thermal cut-off will activate though, yet.

EDIT 2:
I more or less successfully ran a PID tune for my heated bed. But: in the end it gave me

Warning: Auto tune of heater 0 failed due to bad curve fit (A=238.4, C=854.2, D=0.5)

This was the misleading result of Heater.cpp::SetModel() returning GCodeResult::warning due to the "heater appears to be overpowered" fact but LocalHeater::CalculateModel() only checks for GCodeResult::ok or anything else and in the latter case (including the GCodeResult::warning) it will issue the above warning message to DWC.

And one more EDIT: it did not output the

Warning: heater 0 appears to be over-powered. If left on at full power, its temperature is predicted to reach 263C.

as part of the Auto-Tuning procedure.

smoki3

@dc42 said in New RepRapFirmware 3.0 early beta:

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.

That change I now, as you can see in my script they already include G53 commands in the tfree.g

But the problem is:

Look at the last movement of my tfree.g: It move to G53 Y165 (no tool offset)
Then the script is finished. Then it starts with the G1 X76 in the tpre (still no tool offset)

What I then expect is that the printer is just moving form G53 X0 (from the tfree.g) to the G1 X76.
But it is also moving in the Y axis.

For me it sound like more that it is a bug of this change:

What new:

Restore points (created by G60 and created automatically at the start of a pause or a tool change) now have their coordinates stored independently of any workplace offsets. So if you create a restore point and then change the workplace offsets, when you go back to the restore point it will go back to the same machine position regardless of the change in workplace offsets.

It seem like it is restore the old positions from the tool coordinate system during a tool change. Because also tries to restore the Z position during the tool change.

Means if you positioned the tool with G53 Y165 in the machine coordinate system then the tool stays at Y210 (depending on the tool offset) in the workplace coordinate system. Then you drop the tool! With the next movement of the tpre.g it tries to move with the machine cordnatesystem to Y210. Which is wrong at this point because for the tpre.g no tool offset is applied and it should just move in the axis you are calling.

There is a workaround for this issue:
If you put in the tpre.g the same command (G53 G1 Y165 F25000) on the first place then the printer is just restoring the Z position and the you can start with the tool change

dc42

@wilriker said in New RepRapFirmware 3.0 early beta:

I tracked it down to Heater.cpp:CheckGood() where it says
return GetMode() == HeaterMode::fault && CheckProtection();
and I think the first comparison should be != or the heater is only good it if actually is in fault state.

Thanks, I've corrected the source.

dc42

@smoki3 said in New RepRapFirmware 3.0 early beta:

That change I now, as you can see in my script they already include G53 commands in the tfree.g
But the problem is:
Look at the last movement of my tfree.g: It move to G53 Y165 (no tool offset)
Then the script is finished. Then it starts with the G1 X76 in the tpre (still no tool offset)
What I then expect is that the printer is just moving form G53 X0 (from the tfree.g) to the G1 X76.
But it is also moving in the Y axis.
For me it sound like more that it is a bug of this change:

Please clarify. Are you saying that the G1 X76 command in tpre causes a move in the Y direction too? If so then this is certainly a bug. The coordinates stored in the tool change restore point should only be relevant at the end of the entire tool change sequence.