Unable to read tmc uart 'stepper_y' register IFCNT

[Peurif]

Basic Information:

Printer Model: Ratrrig Vcore 31
MCU / Printerboard: Octopus Pro + Fytsec H36
Host / SBC rPi4
klippy.log

Fill out above information and in all cases attach your klippy.log file (use zip to compress it, if too big). Pasting your printer.cfg is not needed
Be sure to check our “Knowl
klippy.log (6.4 MB)
edge Base” Category first. Most relevant items, e.g. error messages, are covered there

Describe your issue:

Hi,

The day before yesterday, the printer was working correctly… and yesterday I performed “maintenance” work on it, which consisted of replacing the CAN board.

Today I adjusted the configuration to the new CAN board… but when I went to “test” the axis motors, I received that error.

I googled for a while, and the only thing I could find was that the pins were in UART mode. It was done. It worked before…

What could it be?

Note: About a week ago (aprox), I updated the TMC2209 drivers from version 1.2. to version 2.0, but after changing them, I’ve made several prints with the previous configuration.

…

[Peurif]

Add more info…

I remembered to install the TMC autotune plugin, but since I didn’t like it, I disabled it…

Think the UART pin has changed from v1.2 to v2.0…
But… what surprises me is that I was able to print with the TMC 2209 v2.0 drivers without changing the configuration.

[Peurif]

Well, that’s fixed, it’s moving again…

Don’t ask me why, that’s what puzzles me the most… I just know that the printer is moving again.

I’ll explain the steps I followed, in case you can find any logic, and I’ll include the logs with the movements.

1- To test, I decided to go back to the previous TMC 2209 v1.2 drivers.
2- The first test consisted of removing all the TMC2209 v2.0 drivers, and I clicked Homing. Obviously, it didn’t work, but the error I got was the same as with the “cracked” drivers.
2- I installed the first driver, a TMC 2209 v1.2, and tried homing… same error (I assume that driver corresponds to the Y axis, not the X axis, which is the first one that tries to move when you homing). IT DIDN’T WORK
3- Seeing that that didn’t work, I tried installing TMC 2209 v1.2 drivers for X and Y
4- I tried homing (and to my surprise, IT WORKED), so I changed all the drivers to the previous version, TMC 2209 v1.2. I didn’t let it finish the test and it reached homing in Z, and I interrupted it before.
5- I installed all the previous drivers, all 5, and tried homing again. It worked, this time I did let it start homing in Z.
6- Seeing that the tests were going well, I went ahead and removed the TMC 2209 v1.2 drivers from the X and Y axes, and I installed the TMC 2209 v2.0 drivers. I left the three Z-axis drivers with the TMC 2209 v1.2 drivers.
7- I pressed homing, and again, to my surprise, IT WORKED.
8- Finally, I changed all the TMC 2209 v1.2 drivers to the new TMC2209 v2.0 drivers, and I tried homing; it worked.

In short, I DON’T KNOW WHY THIS error occurred, except that the “WINDOWS” troubleshooting method of restarting everything worked in this case.

I’m attaching the new log in case you can see anything that indicates what happened, but in short, it now works with the TMC 2209 v2.0 drivers, just like the day before yesterday. I haven’t touched anything in the configuration files, just removed drivers and installed drivers…

[mykepredko]

I just looked at your klippy.log and noticed that your rPi is running v0.13.0-154-g9346ad19-dirty with the “dirty” part being important. Your “MCU” is running v0.12.0-394-g7f89668d-dirty.

My recommendation is to resolve the “dirty” issues with your base version of Klipper and then reflash your Octopus Pro and Fytsec so that everything is running v0.13.0-154-g9346ad19 (NOTE: no “dirty”).

I’m pretty sure things will run fine after that.

---

Can I ask a question?

When you updated Klipper, you would have gotten the window:

Personally, I think this is very clear. However, this is the fourth time this week that I’ve seen somebody having problems with Klipper that just the “day before yesterday, the printer was working correctly…” without mentioning that they updated Klipper and when I looked at their klippy.log I can see that their MCU(s) are running v0.12 while the host is running v0.13.

My question to you is, why didn’t you first try to reflash your MCUs when you had problems immediately after you updated Klipper?

I’m sure I’m coming across as judgmental but clearly this window with, what I think is, a pretty explicit warning along with the demand that you click to indicate that you “understand the risks” is not doing its job.

I’d be interested in your insights as to why you didn’t take the message into account when you had problems?

[Peurif]

@mykepredko

see that their MCU(s) are running v0.12 while the host is running v0.13.

My question to you is, why didn’t you first try to reflash your MCUs w

i am going to try this, thx

[Peurif]

One thing I don’t understand… I don’t know what version of Klipper I have installed…

If I type in the console:

m115 → FIRMWARE_VERSION: v0.13.0-154-g9346ad19-dirty

I check it in KIAUH:

v0.13.0-154

But… if I check it in Fluidd (in the system tab):

Version (in Octopus) - v0.12.0-394-g7f89668d-dirty-20241206_075803-raspberrypi
Version (in Canboard) - v0.13.0-154-g9346ad19

What version do I have installed?
How do I remove the “dirty”?

[Peurif]

aaaa… one is the Octopues version and the other its Rpi version

[mykepredko]

@Peurif

How do I remove the “dirty”?

I don’t know about Fluidd, but in Mainsail the “Update Manager” notes that the Klipper version is dirty and gives you the option to fix it.

[Peurif]

I managed it. It may NOT be the best system, but I removed “dirty.”

I connected with an FTP client, went to the directory, and deleted the files…
I also updated Klipper on the MCU (Octopus446)… but the error persists. When I try to move an axis other than the extruder, the printer restarts…

[mykepredko]

Are you sure you put everything back the way you had it? You did a lot of swapping around.

Check your jumpers to make sure they’re working with the jumper modules you’re now using.

If it all looks good, try to run and, if it fails, post the latest klippy.log.

[Peurif]

I can’t think of any other tests to run…

A) I installed the previous drivers, and it worked for a while… but then the same thing…

B) I changed the position of the drivers, without any success.

The only thing I get is that each time I change the driver, the error refers to a different driver… but the error is random, since if I only send homing to x and y, the error says it’s one of the Z steppers.
klippy.log (6.4 MB)

[mykepredko]

Your screenshots above look like everything’s correct, but when I look at your klippy.log, the last instance (actually every instance in the log) of the MCU version is still v0.12 and dirty:

Now, I think I’m seeing in the klippy.log what you’re reporting - errors in Z axis stepper responses:

But, earlier than this, I do see TMC responses which look good.

I don’t know the homing code (along with how Beacon affects things) well enough to be able to comment on why Z axis steppers are throwing errors when you are trying to home on X & Y.

What I would do in this situation (and it has happened to me more than once) and suggest that you do is:

• Copy your printer.cfg and any other files you’ve generated for the printer onto a PC for later use
• Shut down your machine and pull the SD Card currently in the Raspberry Pi and put it in a marked envelope
• Create a new SD Card image and document every step you take and any responses that do not match expected
  – Since you are running with CAN, I would expect that you are following the Esoterical Guide
  – Same comment with setting up your beacon probe
• Put back in the printer.cfg and any other files that you saved in the first step
• Make sure your Octopus Pro and Fytsec H36 are at the same Klipper level as what’s running on the rPi
• Try a print and report on the result
• If it fails, we can compare what happens with the new SD Card image to the old one and even pull out the old one to compare the results.

Sorry, I wish I had a better answer for you. There is a lot of complex software here that all has to work in harmony and if something gets out of step you’re going to have problems and it’s very difficult to figure out where the problem lies.

I’ve got my fingers crossed that when you create a new SD Card things will start working again.

[Peurif]

I was afraid I’d have to do something similar, a soft reset. I wanted to avoid it because it’s a lot of work… But I see I have no choice… that and crossing my fingers…

The strangest thing is that everything else works: the bed heats up, the extruder heats up, the fans work, the extruder works (I even extruded some filament to test it).

The only thing left to think about is that a few days ago, I installed a Klipper plugin to tune the motors (autotune steppers) or something like that. Maybe I’ve messed up something…

Thank you, I will continue to report on my progress or lack of progress…

[Peurif]

Today, while I had time, I started wiping the printer.
And now that I’ve corrected all the configuration errors, I can access the printer with Fluidd and have partial control over it…

The first thing I tried was homing, and I still couldn’t do it. I got an error… but it’s different. The error is:

“Unable to read tmc uart ‘stepper_z’ register GSTAT
Once the underlying issue is corrected, use the
“FIRMWARE_RESTART” command to reset the firmware, reload the
config, and restart the host software.
Printer is shutdown”

I’ll look into what this error is… I think I’ve seen it before…

I’m attaching the new log… it will have dozens of errors, because the printer is halfway through its reconfiguration… but the error that interests me most is the one I posted above.
klippy.log (6.4 MB)

Suggestions are welcome

[mykepredko]

@Peurif

The first thing I tried was homing, and I still couldn’t do it. I got an error… but it’s different. The error is:

“Unable to read tmc uart ‘stepper_z’ register GSTAT
Once the underlying issue is corrected, use the
“FIRMWARE_RESTART” command to reset the firmware, reload the
config, and restart the host software.
Printer is shutdown”

This is strange because when I look at your latest klippy.log, the only read errors I see are for stepper_y like:

There are GSTAT reads for stepper_z (and stepper_z1 and stepper_z2), but they’re all fine:

Question for you - is the X axis homing working correctly now? If it is, then we should look at the differences between its hardware/jumpers/configuration and that of the Y axis.

[Peurif]

No… Any axis I send the homing command to… It gives that error. It causes the printer to immediately reset.

[mykepredko]

@Peurif

It causes the printer to immediately reset.

Okay, I see the events in the latest klippy.log.

The one constant I’m seeing here is Beacon. I’m not sure why the IFCNT register of stepper_y is being flagged but, in all the cases that I see, Beacon has been called before the “Unable to read” event.

Could you comment out/disable Beacon and see if you can do a G28 X or G28 Y command?

I presume that right now if you try either one of these you’ll get the failure.

What happens when Beacon is out of the picture?

[Peurif]

My latest tests…

I reinstalled Klipper and Fluidd from scratch, and I’ve configured the printer to a minimum so it can access the Fluidd interface.

I haven’t installed Beacon; for now, I’ve set the Zprobe to a random free pin on the Octopus board.

But… the same thing, as soon as I give it the homing command, regardless of the axis (homing on X, homing on Y, homing on Z), I always get the same error:

"Unable to read tmc uart ‘stepper_y’ register IFCNT
Once the underlying issue is corrected, use the
“FIRMWARE_RESTART”

I’ve looked at the log a bit (I don’t understand it much), and it seems there’s a queue of undelivered UART messages… I can’t be sure because I don’t understand the log very well.

Any ideas?

I’ll upload the new klippy.log
klippy.log (1.1 MB)

[mykepredko]

I just looked through the newest klippy.log and noticed that you have specified your printer as a corexy. I would like you to try this experiment:

1. In your printer.cfg, change your printer statement to:

[printer]
kinematics: cartesian
max_velocity: 1000
max_accel: 1000

2. Manually move your toolhead to the corner where it will move the shortest distance to hit your endstop sensor - looking at your klippy.log, I believe this is the left rear corner (if 0,0 on the printer is in the front and to the left).

3. Execute a G28 X command in the console window and record the results, both the movement of the toolhead as well as what’s displayed on the console. I’d also appreciate an updated klippy.log.

4. If there is no problem with the G28 X, then I would like you to try G28 Y and record the movement of the toolhead as well as what’s displayed on the console. As always, a klippy.log would be appreciated. The toolhead should still be in the left rear corner and the homing command should run without issue.

By going to “cartesian” coordinates, I’m separating your X and Y steppers so they can be tested individually. I want to understand if the problem you’re having is endemic to the system or just the Y axis.

Sorry for tearing everything apart on your printer.

[Peurif]

@mykepredko

kinematics: cartesian
max_velocity: 1000
max_accel: 1000

Any ideas are appreciated…

I’ve tried what you told me, or something similar…

I changed the printer type to Cartesian, with the speed values ​​you told me… but the same thing.

I homed on X, and the error, this is something new, was on X: “VTMC ‘stepper_x’ reports error: GSTAT: 00000001 reset=1(Reset)
Once the underlying issue is corrected,…”

I restarted and homed on Y, the error was on Y: “TMC ‘stepper_y’ reports error: GSTAT: 00000001 reset=1(Reset)
Once the underlying issue is corrected, …”

I didn’t need to move near the endstop; it didn’t move even 1 mm. What I can hear is as if the motor is about to start moving, maybe 1 step…
klippy cartesiana.log (3.1 MB)

i have see in the log that “kinematics = none”

In case you’re interested, another test I’ve done is to disconnect the motors from the board… leaving the board alone with the stepper… but the same thing happens, as soon as I send it the homing command… it stops.