Printer stops sporadically and then no longer responds

michaxy

Rejoiced too soon, I tried to print a certain file again today and it reset again, despite grounding from the hot end.

I can not get rid of the feeling that it is the GCode, last time I took another file, it worked.

dc42

@michaxy if it always stops at the same place in that file then it's likely that RRF is having trouble with the GCode at that point. If it stops randomly than ESD or some other type of transient is likely to be the problem.

I suggest you add a connection between Duet VIN- and the mains ground that you connected the hot end metalwork to. I normally make this connection at the PSU by linking the mains ground terminal to one of the negative output terminals.

michaxy

The hot-end is connected to the GND connector at the power-in on the mainboard

michaxy

So, I deleted the firmware and reinstalled again, currently a print has been running for an hour, without stopping.
I assume in my up and downgrade attempts, I have screwed up something. I will continue to monitor the matter and report.

gumby

@michaxy I was having similar mystery problems at first, and it was always associated with a low voltage error.

Could it be a power supply issue? Do you have a spare you could test it with?

Cheers,
Gumby

michaxy

@gumby
I have no spare, unfortunately, voltages are monitored and from a voltage drop of 0.5 volts, the print is paused.
With me, however, everything has reset and partly I had to turn the printer off and on again, so that I can operate the again.

michaxy

Hello, sorry that I have not been in touch for so long, but family and work have left me little time for hobbies.

For whatever reason, I had commented out the acceleration sensor during the last firmware upgrade or downgrade (probably because the firmware version did not yet support the sensor) and since then it has been quiet, it has printed as if nothing had ever happened.
A few months ago I planned further upgrades, such as a conversion from 2 to 4 drives etc. I also added a Raspberry PI 5 . First I wanted to put the Pi into operation with firmware V 3.5.2 and test a few things and what can I say, it happened again. I started printing and after a few layers the device stopped.
The error message was “SPI connection has been reset”, M122 gave me a similar diagnosis as previously posted in this topic.
What I noticed was that a “daccViol” or “iaccViol” was repeatedly set in line 13 of the diagnosis.
I then downgraded to stand alone V3.5.2, same error pattern.
Finally I commented out the acceleration sensor and disconnected it, since then it works again.

Conclusion: either my wiring of the sensor is faulty or the sensor itself.

droftarts

@michaxy Can you post your config.g and response to M122? You say you have a 6HC, and that you disabled "the acceleration sensor". Do you mean the accelerometer? Are you running a 1LC toolboard as well (if so, which version), or external accelerometer?

Ian

michaxy

Unfortunately, the printer is currently out of order due to various modifications.

These lines were entered in the config for the sensor

“M955 P0 C “spi.cs3+spi.cs2” I16”
“M593 P “zvd” F45”

This was an external sensor that was connected to the temp daughterboard connector

The mainboard is a 6HC V1.01

I also have the same sensor running on a modified Ender with RepRap and it doesn't cause any problems there.

droftarts

@michaxy What is the sensor? Only LIS2DW12, LIS3DH and LIS3DSH are supported, ADXL345 is not supported.

I would guess that your wiring is incorrect or is picking up interference. I have updated the wiring guide since last year, please check yours if you have a supported accelerometer: https://docs.duet3d.com/en/User_manual/Connecting_hardware/Sensors_Accelerometer#wiring

Ian

michaxy

It was a LIS3DH, but that doesn't matter now, because it will no longer be used, a Roto-Toolboard is currently installed, but not yet fully connected, which should then work without any problems .

But I will check the wiring from the LIS3DH again later, just to know if it was this one.