Topics created by NeoDue

@droftarts Thanks! I can only state that it did indeed work on my old printer as well (on 3.3 or an early 3.4 release). Let's see what some testing will yield.

@droftarts you are right, "elif" works as well - and is easier. Thanks!

But I would add the note nevertheless, in case someone relies on the input variable for something else.

@NeoDue I've increased the maximum length of that string in the source code. In the next release it will be limited only by the maximum GCode command length, which is currently 256 characters.

@NeoDue I have now added this change to the upgrade notes at https://github.com/Duet3D/RepRapFirmware/wiki/Changelog-RRF-3.x#reprapfirmware-351-stable-changes-since-346.

@dc42 Issue is created: https://github.com/Duet3D/RepRapFirmware/issues/979

One offtopic question, if I may: from your standpoint, is there anything I might add/contribute to clarify or increase understandability of https://github.com/Duet3D/RepRapFirmware/issues/915? I just want to make sure that the feature request contains everything that might be of help in case it might be chosen for implementation some time in the future.

When I had created that one, I had several other issues to fight with, therefore I admit I do not consider that data I presented there to be really optimal.

Braintoe created this issue in Duet3D/RepRapFirmware open [FeatureRequest]: allow more than one keep-out zone #979 Braintoe created this issue in Duet3D/RepRapFirmware open [FeatureRequest]: Add "suppress message" G30 probe option #915

@dc42 I see, and M30 as it is is probably originating from Marlin, right? Then i I guess they will stay both and it is up to the user to use them. Thank you!

@dc42 3.5 has gone stable AND you already managed to fix that??

Thanks a lot - and congratulations! That was some really hard work for you and the whole Duet team! If I remember correctly, 3.5. had the longest beta / RC phase of all the RRF versions I saw and used in the last seven or so years.

(edit - after upgrading the printer yesterday, I just took the chance to test the updated function: crash detection works, and now U behaves exactly as X did - i.e. U does not crash into the endstop any more, but the X carriage ends up at places where it should not go. But that bug is just an inconvenience, not critical for the printer)

@Thalios

That's the answer i was looking for!

Glad I could help. Apropos your ”dumb question”: obviously, my prose was just waiting for the perfect question to be asked 🧐

@dc42 I have been watching for half an hour now using the initial daemon.g code - no more 2000°C spikes with the new firmware!

Now that was a supersonic bugfix! 🚀

Thanks! 🙂

will be released with 3.5.0-rc9.

@gloomyandy said in How to use M915 T parameter:

@NeoDue What makes you think the default value is 0? 0 is and was the default value for COOLCONF, but the "default" value (i.e. the value that RRF will set when it boots) for TCOOLTHRS. The value set by RRF is equivalent to setting a M915 H value of 200 (which ends up being the hex value 0xea).

You are right, I had your post https://forum.duet3d.com/post/332054 in mind, but that one is about COOLCONF.

As I mentioned above I'm not sure that it is a good idea adjusting these values unless you understand exactly what the consequences are. This is particularly true given that you are seeing layer shifts. I think you did test for layer shifts with the M915 settings removed, but if not it would probably be a good idea to do so.

Yes, I fully understand that, and as I had noted in the layer shift thread, I did testing without these as you had asked me in this post. (Apart from that, this value does only affect StealthChop behaviour, therefore it should be ignored as soon as I switch to Spreadcycle)

Technically, I see this setting as follows...
The datasheet says:

TCOOLTHRS ≥ TSTEP ≥ THIGH: - CoolStep is enabled, if configured - StealthChop voltage PWM mode is disabled TCOOLTHRS ≥ TSTEP - Stall output signal (DIAG0/1) is enabled, if configured

CoolStep and Stall output is not configured on my printer, therefore these two settings are not of interest.
But since thigh is set to 5 on my printer to ensure TSTEP ≤ THIGH does not happen (again, I had disabled this for the input shaping test when you asked me to), I need to set tcoolthrs to a value below 5 to ensure the case "StealthChop voltage PWM mode is disabled" never happens. This seems to be the same behaviour as the TMC2209 of the original controller board works (edit for clarification: but there, without having to set tcoolthrs) - tcoolthrs works different there if I trust the datasheet.

@OwenD @dc42 thank you!

I think I found another way: the main reason for the timestamp is that it is unique. Now if I create a global variable which I save persistently in a macro file and recall that file within config.g as I do with the xy offset and z axis calibration data and increment that value whenever config.g is executed, I can count all config.g executions (roughly equal to "reboots") in a number and use that in the file name. That should suffice.

@dc42 thank you very much for the info!

@NeoDue I'm glad the new version fixed it for you. Thanks for reporting.

@gloomyandy thanks for pointing that out - I did not keep that sentence in mind when I read this page.

Then I consider this question answered for now... the only open question is: why does it work as it should after the slow-motion exercise?

Edit: in case someone stumbles upon this: this thread here (https://forum.duet3d.com/topic/18010/duet-3-stealthchop-2-tuning-for-nema23/27) describes the problem in more detail (sadly, no real solution there as well from what I can see, just a nice video where @fractalengineer got his stepper to croak the Star Wars melody 🤣 )

2nd Edit: Instead of following the advice "all three values equal" on https://docs.duet3d.com/User_manual/Connecting_hardware/Motors_tuning I used the following values:

M569 P0.0 D3 H5 V25 ; H set to a low value to keep microstepping active (5 simply worked fine for me...), V set to a value *above* the maximum printer speed (check with M569 P0.0) M915 P0.0 T1 ; T set to a low value to disable CoolStep

@fcwilt No, sorry... Some basic things such as batch programs or conditional gcode is okay, but everything else is over my head - otherwise I would have already tried to compile my own version or add a parameter to G30 in Github...

Thus, I think that would require much more than I can do. Apart from that, I have to admit I don't really like having to switch between two displays.

@dc42 final update for this: your suggestion works like a charm, thanks a lot! 😃

@NeoDue

duhhhhh .... sorry about that, I thought I had discovered something .... alas, all I discovered that I can't read 😞

Update: in case someone might need it, this request is partially solved thanks to the new M308 U and V parameters - at least if the required switching speed between the areas can be slow enough to be handled by daemon.g.