Suddenly GSTAT Error 00000001 reset=1

Basic Information:

Printer Model:

  • modified/redesigned HevOrt

MCU / Printerboard:

  • BTT Octopus v1.1 / stm32f446xx
  • Version: v0.12.0-272-g13c75ea87

Host;

  • Raspberry Pi 3
  • Version: v0.12.0-272-g13c75ea87
  • OS: Raspbian GNU/Linux 11 (bullseye)
  • Distribution: MainsailOS 1.0.0 (bullseye)

klippy.log (270.8 KB)

Describe your issue:

I suddenly encountered a GSTAT Error 00000001 reset=1 and don’t have a clue, what this error message tells me, nor having an Idea how to solve the issue.

gstat

I have encountered those errors quite a year ago and have read a lot of topics regarding this error. Mostly those Topics ended without a solution and since i have changed every piece of electronic and cabling to hunt down that issue without effort i can understand why. My final solution was to buy a new printerboard. Since then everything worked fine, but now the error pops out of nowhere again.

I need to understand, when this error message is thrown and which problem it is pointng at.

Thanks for any advice and kind Regards
limefrog

Next topic with your printer. :frowning:

Check this here:

Thanks,
yes, these Topics are mostly already known. But all these are about curing the symptoms.

At the Moment my concern is, to understand what this error Message is about. As far as i have understood, this is not generated by Klipper, but handed trough from the stepper driver.

I want to know, what effect or circumstance makes the stepper driver to throw the message?

I’d like to approach to the root of the whole evil.

What you call the symptoms are the root causes. The symptom is the error message GSTAT Error 00000001 reset=1. This means that something is dragging your driver in a permanent reset condition.

The causes why this potentially happens are listed in the link given by @LifeOfBrian

Yes, i want to understand how this is happening. What are the triggers?

Does there exist a specification which explaines what boundary conditions initiate the message?

If you had read these threads, you would have noticed that this error is not raised by Klipper but by the TMC drivers, which are a product by Analog Devices.
Klipper just passes on this message and considers it (rightfully) as important enough to halt the currently running processes.

As for the reasons and resulting potential solutions, again a quote from the already mentioned thread:

This is the current knowledge regarding this topic.

1 Like

We are checking that together and I pointed again towards wires and respective contacts but as first step swapping X and Y stepper drivers.

@Sineos This is crystal clear. I do not blame Klipper for this behavior.

The extreme resistance and cumbersomeness of this problem and sisyphean exertion which everybody has invested, who is affected by this, is impressively described in the mentioned Topics.

Well, sometimes you are lucky and someone reads your topic, who has more insight in the subject in question - maybe a developer of Analog Devices or elsewhere but with vital background knowledge.

So, if the error-handling behind is better understood, the avoidance of pitfalls in hunting down this error might be made easier and more reliable.

Not being the expert, but I’m afraid the “simple” answer that you are looking for, does not exist.

  • The error is more or less generic
  • The reasons that has so far been discussed and also validated are as well unspecific:
    • Defect hardware that has somehow an impact on the SPI bus communication (one issue I had myself: A defect MAX31865 step-stick module had dragged my stepper drivers into this issue)
    • Grounding topics and effects of ESD
    • Defect stepper motors
    • Defect drivers
    • Defect printer board
    • Problems with the wiring
    • Without probably a statistic significance: Some boards seem more prone to it than others
  • Hard to diagnose due to the multitude of sources

Just take your own issue: Your system apparently was running well, until suddenly this issue popped up. IMO this strongly points to some defect in hardware. Stepper drivers can die, motors can die, cables can break etc.

At the moment it seems i can add a new approach:

  • I intentionally made a complete power drain for 10 hours, to discharge any capacitor and let every Transistor compensate from residual charges.

Whilst yesterday it was impossible to finalize the first round of Z-tlting, i was able to start a print instantly now.

It seems in my case the problem might be a kind of electronic interlock.

I’ll observe and report…

… The problem isn’t gone. So the power relief is not the final solution.

But i’ m able to observe a correlation between the temperature inside the housing and the tendency to throw the error message.
So the power relief is not the solution, but temperature relief has influence.

If the machine became completely cool over night, a print starts instantly without problem. After printing 2-3 small parts the Z-tilting suddenly stalls and keeps on stalling repeatedly.

Cooling down for half an hour does nothing. Despite all sensors reach 22°C the problem is persistent. After reaching 21°C the position where the stall happens moves to homing the X-Axis (way before the Z-tilting starts).

Waiting for approximately another three hours, keeping all sensors around 21°C a new attempt has a good chance to be successful.

This points to a larger temperature coefficient. So the problem zone has to be or to be in contact with a larger mass or it has to be in a separate housing, keeping that heat.

This leads to either the extruder-stepper (mass) or the CR-Touch (housing). XY-stepper are outside the housing. These are the only devices (apart from the ADXL which is not covered) residing inside the housing.

Since it is not the extruder-stepper being mentioned by the error message, i tend to blame the CR-Touch. I always had problems with the CR-Touch at higher temperatures (btw. im printing ABS) regarding to not lower the probe and inaccuracies (poor repeatability).

Since i have not a second CR-Touch at hand to replace it, i’ d like to reach out to you: Has anybody experienced strange behavior in conjunction with either CR-Touch or BL-Touch causing an issue?

A TMC 'stepper_x' reports error: GSTAT Error 00000001 reset=1 error indicates that the TMC Driver has spontaneously reset itself.

During startup, Klipper communicates with each tmc driver and configures a particular setup (microsteps, run current, etc.). During a print, Klipper periodically checks the status of the tmc drivers. If it finds that a driver has reset itself then Klipper reports the above error. That is, the driver is indicating that it has discarded its requested configuration and has reverted back to its unconfigured state. Thus the driver no longer properly responding to movement requests issued by Klipper.

The obvious question is - why did the tmc driver spontaneously reset itself? Alas, the driver doesn’t tell us that - the common reasons are the ones outlined by Sineos above.

Cheers,
-Kevin

2 Likes

Thanks a lot for the concisely explanation. That helped at least to understand the underlying mechanism.

I’ ll investigate further in thermal dependencies, but the machine kept cold for the last days, since i’ m in other Topics at the moment.

Kind regards
limefrog

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.