Posts made by Chorca

@chrishamm It appears to be happening much less with 3.5.1, though I was able to trigger a SPI reset; it happened after about 40 moves instead of one or two.

Instead it appears the data capture is being cut off somewhere, as the received data should be 1 second long but i am only getting around 150-350ms of data back for each run. Once in awhile (about every 10 runs) I get a complete data log.

Here's a screenshot showing my settings and the returned data:

EDIT: Looks like I spoke too soon, it seems to be resetting just as often on longer moves (100mm+).
I also validated that the endstop wasn't the culprit by unplugging it after homing, it still seems to reset without that connected.

@NeoDue It is indeed a 250Mhz scope and I tested at a few speeds and triggers, to see if there was any detectable spikes.
I saw mentioned in another thread to verify if NC endstops are used, so i'll double-check that too.

Spent some more time on this tonight.

I disconnected everything not necessary from the Duet board, leaving only power, 1 endstop, and the Z stepper motors, along with the CAN bus and SPI cable. Curiously I saw a reset or two happen without movement.

I hooked up a logic analyzer to the SPI lines and checked those. I also enabled debug logging via the USB port.

I checked the Duet's 3.3v line for any issues, spikes, noise, etc, but it is very quiet and during motor movements I saw no noise on it, so I feel like I've ruled out a brownout on the processor. I looked at some other lines but similarly didn't see much noise at all on them.

Curiously, with debug enabled, the reset errors became much less frequent, which makes me wonder if there's a race or something that's causing a reset of the board.

I've included a CSV of the SPI logging, and a text log from the Duet's serial output while the issue happened. The reset is at the end of the files, I stopped logging right after it died. I have the Saleae Logic file which I can send on request as the forum doesn't support that filetype.

mini5_reset_log.txt
mini5plus_reset.csv

A bit more info as I went through attempting to tune the motors again today.. it seems if the motor is oscillating a bit, i.e. running a low P (<20) with all other parameters set to zero, the resets happen more often and i can't get more than about 300ms of data from the board, but setting to higher values seems to make it happen less. An odd thing for sure.

@NeoDue Sadly, the change here was to move to closed-loop stepper control via the 1HCLs, and the closed-loop tuning is what seems to be instigating this issue, as I've never had this error occur outside running the closed loop tuning commands, so it seems like it's been narrowed down to something going on here.
I appreciate the help!

@NeoDue I was running a "Record" command from the Closed Loop tuning plugin with these settings:

Upon clicking Record, there's about a 20% chance the move will begin, and while the move is taking place, the printer will stop moving and the board resets.
After going through plenty of motor tuning, the settings here don't seem to have any effect on the SPI errors. I'm assuming it may have to do with the motor data being transferred out of the controller to the Pi, but not sure if that would cause a reset or some other error may cause it.

I don't have any physical reset buttons installed anywhere, just the board itself.
Would any CAN bus commands from other boards cause a reset of the main Duet board?

@chrishamm I've validated that the 1HCL boards do NOT have the termination jumpers connected, and the 1LC board DOES have it's jumper soldered.

I attempted to grab a M122 as fast as possible after the reset this time, and I sent the command 1 second after the notification popped up on the screen.

console.txt

@Phaedrux
Sure thing:

@NeoDue
A good suggestion!
I just went through and made sure all power supplies have their negative rails connected together, and tied the connected negative rails to earth ground at the closest power supply to the frame. I ensured all grounds are tied together star style, and are connected to earth ground via the outlet. I tied the frame to ground as well and validated that it has low resistance to ground. Each board's negative is tied to ground now and I added a 5V 10A MeanWell supply to the Raspberry Pi to ensure it's getting it's own clean power supply that's also at the same ground potential.

After doing all that, I am still getting the SPI errors while performing moves while in the Closed Loop plugin.

I've attached the M122 from the current instance of the issue, but I assume it's similar to the first one.
m122-2.txt

@chrishamm
I don't have any heaters or anything nearby.. The only steppers the Mini5 is controlling is the Z axis, the heaters are being controlled up on the toolhead, and the bed heater is controlled via an SSR (both are off during this process)
The part fan is also connected here, but is off during the tuning process. The 1HCLs are about 12" away from the board, along with their power supply, near the stepper motors driving the X/Y.
I've included a couple photos to show the setup, and added the M122 output here:

m122.txt

Hey all, have been attempting to do some motor tuning with the 1HCL boards, but more often than not I am getting "SPI connection has been reset", usually in the middle of the motor performing a tuning move with data collection.

This is on a Mini 5+ with a Pi4 running all latest updates. The Mini is on 3.5.0-rc.3 along with a TOOL1LC, and two EXP1HCLs which are running the X and Y for the CoreXY motion of this RatRig.
The Mini 5 is running on a 24V mean well supply, and the 1HCLs are on a 48V supply, both of which are tied together with a common ground. The Pi is running the Duet Pi image so it has the wifi fixes integrated.
The motors are StepperOnline 1000CPR Nema17 steppers and have been working fine through calibration and numerous prints. However, a few times now I've been trying to tune these motors (which seem to respond oddly to tuning) and many times when I command a move with the Closed Loop plugin, during the move I receive the above error.

I've tried swapping Pis, re-orienting the cable, reseating it and a few other things, but it still seems to have the same issue. Not sure where to go here, as I've tried the troubleshooting guide but gotten nowhere.

Here's my config file, I perform the motor startup calibration in the homeall.g
config.g
homeall.g

Adding to this discussion a little. If I manually post each line from my homeall.g command to the console and execute them in sequence, they seem to work properly. However, if I generate a macro with the 3 commands:

G1 H1 X-625 Y605 F3800
G1 H1 X-625
G1 H1 Y605

the board seems to no longer pause when each endstop is triggered, almost like it's executing them all instantly. The endstop monitor plugin shows each endstop being triggered, however when X is triggered, for example, the feed does not stop in the X direction and continues until the full move has been completed.

This was after an upgrade from 3.4.4 to 3.4.5

I'll try and get a bugreport filed for this then. Thanks!

@gavatron3000 said in Filament out warning always present:

Yeah it says that but for me to remove the popups I only enable them when a print is active

Ah, so sounds like you're running into the same issue then. Ideally the popup should only happen once and then once the print is resumed, clearly the error is no longer necessary.

Yep, both filament sensors show filament present via M591 D0 and D1.

The alert that pops up doesn't seem to signal a current condition; the printer still operates fine, and this issue only comes up if the printer has run out of filament while printing at least once since powering on.
The issue appears to be cosmetic only, hence posting in the web interface area, because while the popup shows, the printer continues printing just fine. This alertbox only happens after a filament runout condition has occurred, even if the print has been resumed without issue.

@gavatron3000 said in Filament out warning always present:

Make sure you only enable them at the start of a print and disable them at the end again.

According to the wiki as posted above, with firmware 1.19 and later, this is not required. The sensors are only active during a print session and are ignored otherwise, so I shouldn't need to enable/disable the sensors between prints, M591 should be able to go in the config.g file and then work normally. (Please correct me if I'm wrong here, that's how the page seems to read. It seems a bit unnecessary to enable/disable hardware configuration between prints as well)
Either way, even if a runout has occurred during the current print, the dialog keeps popping up (on page load ONLY) for the rest of the print.

I created a quick video to show what's happening, just to help further illustrate the problem.
https://youtu.be/KmbHqct-HjI

I stress this seems to be only cosmetic as there's no effect to the current print when it pops up on the load of the page.

Yep, that's what I used to configure it.
It doesn't seem to be firmware-related because the printer keeps right on printing correctly, the message just keeps coming up whenever the page is refreshed. If I leave it open, it doesn't come back up, only when the page is first opened and loaded.
Seems like a bit is set in the web interface that isn't unset and reloading the page triggers that to show up.
Firmware version is 2.03beta1

; Runout sensors
M591 D0 P2 C3 S1 ; Extruder 0, Active-low switch, Pin E0 Endstop, Enable
M591 D1 P2 C4 S1 ; Extruder 1, Active-low switch, Pin E1 Endstop, Enable

So far the Duet has been working flawlessly, but after setting up a simple filament out switch for long prints (which I've used several times) I've noticed that the dialog never really goes away. After clicking the OK button and reloading filament and resuming the print, a reload of the web interface on any computer shows the 'Extruder 1 reports no filament' alertbox again and I have to close it.
Doing an e-stop or manually resetting the board seems to clear it out.

This is not a huge thing, but annoying to have to do anytime I load a page especially on things like my Chromebook or phone which get turned off and lose sync with the board, needing a reload of the interface to display accurate data.