Topics created by mikeabuilder

@mikeabuilder thanks for confirming.

@mikeabuilder also look at M32.

@chrishamm - thanks for the response and the github pointer. I took a look at the description and see it's just the same as what I found. Some of the description is beyond my knowledge, but it's good to know I'm only 2 years behind the leading engineers in finding things. 🙂

@mikeabuilder I'm glad you got it working. I have updated the documentation.

@mikeabuilder this issue (fixed n RRF 3.6.0) may be relevant https://github.com/Duet3D/RepRapFirmware/issues/1117.

dc42 created this issue in Duet3D/RepRapFirmware closed RRF incorrectly executes commands while waiting for blocking user input #1117

Final (I hope) follow-up on this issue - Further testing today showed that my implementation of a timer to try to prevent de-bouncing was not adequate - I still had a few multiple-starts of macros. I implemented a new method for de-bouncing that seems to be working better. I created a global macro to use as a token. I have one per macro that I want to de-bounce. When the macro starts, the first thing it does is try to "grab the token" by checking the state of the global variable (false means the token is available, true means it is already taken". If the state is false, the macro grabs the token by setting it to true and proceeds. Any other instances of this macro that start will find the value of the token to be true and that triggers them to exit. At every exit point of the macro, it needs to "release the token" by resetting it to false. No timers.

@mikeabuilder as we have a new screen under development, we don't plan any further development on PanelDue except for bug fixes and essential updated to retain compatibility with future firmware versions. So I think your choices are:

Modify PanelDueFirmware yourself. Once you are set up to build the project, it should be straightforward to increment the displayed tool numbers.

Number your tools from 1 in RRF. Then configure a post-processing script in PrusaSlicer that replaces T0 by T1, T1 by T2 etc. You will probably need to replace the tool number parameter in a few other commands, e.g. M104, also G10 with P parameter if PrusaSlicer uses that.

Thanks @chrishamm. Reading your response made me realize that I not only mistyped "SBC" but also that I was backwards about it. My system is NOT running in SBC mode, it's stand-alone. So thanks for answering that version of the question.

I'm restating your "never supported NPT" comment to see if I understand the implications for a machine running in stand-alone mode:

The stand-along RRF will not "know" the time until a client connects. This means all log entries will have a timestamp based on the machine's uptime (time since boot).

If/When a client connects, if that client is DWC, then DWC will set RRF's date-time.

If a client other than DWC connects, and it connects using rr_connect with the time option, then RRF will update with the time from the client.

This explains a lot of unexplained macro errors I've observed over the past three years. And I can see now that I'll need to rewrite all the macros to not use state.time for measuring duration. I'll convert them all over to using state.upTime rather than state.time.

I think I'll also look into making an Rpi pico that powers up with my system and that does the rr_conenct function.

@dc42 - Thanks for confirming Ian's response. I'm definitely going to add a segment to my tfree.g macros to adjust my tool Z offset by the baby steps amount and reset the baby steps to zero. This way my users will be able to fine tune each tool as it's first layer is printed. Of course, this give no help if a tool is not used on the first layer, but subsequent layers should be more forgiving of tiny errors.

@gloomyandy - thanks for your thoughts on this topic. I would really like to understand the state changes in the system through the tpre and tpost execution steps. It's not clear (at least to me) in the documentation.

My advantage in putting all my operations into tpost is slight - simplification of the macros I need to maintain, and teach to others to maintain. And I'm one of those people that wants to understand why.

Reading the current documentation, it isn't clear that tpre operates with state.currentTool = -1, which I believe is required for moves to be in machine coordinates and not tool coordinates (hence my obtuse question about "selected"). As a result, in my tpre, I preface all moves with G53 to force machine coordinates to be used.

And about aborting tool changes and the system assuming tpre has completed - I currently have no abort logic, though I've been thinking about adding some inputs to detect successful tool capture. I'll need to think some more about what to do in an abort situation. These may be the good reason to use tpre.

Just when I think I know the meta commands...

abort <opt-expression>

This causes all nested macros and the current print file (if any) to be terminated.

RTFM. Thanks @jay_s_uk

@mikeabuilder According to https://docs.duet3d.com/User_manual/Connecting_hardware/Heaters_tuning#running-auto-tuning

When tuning, auto tuning will perform a number of phases (heating, settling, fan off, fan on), cycling between the target temperature and 5C below it. It measures the heating and cooling rates on the last 3C each cycle, and accumulates the mean and standard deviation. Typically it will cycle heating/cooling 8 times, but can be as many as 30, if the readings are not consistent (noisy thermistor, or a large thermal mass). You can use the Y parameter to alter the hysteresis.

It's worth looking at the temperature graph as tuning is happening. If the tuning cycles are 'inconsistent', it can point to a number of problems, beyond 'noisy thermistor, or a large thermal mass':

A tuning cycle that speeds up could indicate inadequate cooling of the hot end cold side Poor thermistor contact can give variable readings thermistor very close to heater, so the local area heats up, but the rest of the hot end is still cold (common with silicone heaters with the thermistor embedded) draught on heater from cold side cooling inconsistent heater heating (poor wiring, failing heater) poor thermistor wiring, or interference, would generally show up as spiky readings.

There's probably plenty of other causes of inconsistency that one could imagine. I'm pretty sure this isn't a firmware issue!

Ian

@droftarts - Ian, thanks for the clarification and additional info. I always learn something from this forum. Knowing that the endstops are ignored on all but H0 helps me understand more clearly how it works.

The more important thing I learned is that there can only be one end stop per motor and the design we are using does indeed have two NC endstop switches wired in series. We have recently been contemplating separating these to two inputs because in normal use, this motor is at rest with one of them triggered. In this situation, we can only know which end of travel we are at rest on by keeping track of it in sw - a risky proposition that a second input would eliminate. Now we know there will be additional macro work to do if we follow that path (re-define the endstop before making any moves). That'll be something for us to really look hard at.

@mikeabuilder extruders don't have position limits. The recommended way to wait for motion to stop is to use M400.

Thanks doc!

@fcwilt - Thanks for the G92. I did not realize that this would mark the axis as homed, but it does make sense. I'll just add it to the end of my homeall.g and that'll do it.

@dc42 - thanks for the pointer. I'll look into the ESP-32 (I actually prefer the RPi pico). I have the hw to build out the micro. If I can;t find any, I may come back and ask for some pointers to references for the USB connection and protocols for sending commands to the Duet.

Meanwhile, I'll use M905 to set the RTC in my config.g to a default starting point and know that it'll be overwritten with a real datetime if I've got the Duet connected. That will give me a timer (and bogus timestamp in the even log).

@mikeabuilder

Not sure if it helps - but my understanding of prusaslicer is that if you include heater settings in Printer Settings --> Custoem G-Code then prusaslicer will not emit its own.

I don't have time to check now, but I recall that the current prusaslicer beta (2.6.0) includes an option to specifically inhibit heater gcodes (even if you do not set them yourself as Custom G-Code).

@mikeabuilder Thanks, I could just identify another issue. We'll see if my upcoming change fixes your problem, too.

@dc42 - Thanks for adding your thoughts. First (in case you are busy) - we replaced the cable to the X endstop switch and the symptoms have gone away. So we are back in business.

But to your question - yes, the tool heaters showing a temperature of 2000C was part of our collection of symptoms. In the end we were able to make the problem occur consistently by setting the end stop to be an M581 T0 trigger and then activating the switch. This caused a machine halt that and also included the 2000C display. We're assuming that the 2000C is a byproduct of the halt and not part of the failure mechanism.

We were also able to cause the halt by commenting out all of the tool configuration (made us happy that this is in a separate macro) for both tools. We still forced the halt as expected.