Topics created by gate546

@gate546 said in DAMNED CRASH - Stuck in spin loop:

@dc42 said in DAMNED CRASH - Stuck in spin loop:

@gate546 said in DAMNED CRASH - Stuck in spin loop:

One more info, the involved gcode file is over a normal SD card that is installed on the 7" Panel and NOT on the micro SD Card that is inside the Duet Wifi board

That may be very relevant. The SPI link to the SD card on the PanelDue doesn't have the same hardware timeout mechanisms as the interface to the micro SD card. Also if the ribbon cable is too long then the signal integrity may be degraded. For best reliability, I recommend printing from the micro SD card.

Do you have any other SPI-connected devices, for example a PT100 or thermocouple daughter board?

@dc42

the cable is very short, 25cm plus or minus and yes there is a PT100 daughter board installed.
You suggest to use the micro SD instead? I have some doubts with the micro SD Card due to their structure....
@dc42
David, just for information, to close the circle.
The same long print that caused the crash I wrote before, ended happily without any kind of problems ☺
Same machine, same SD card, all the same, the difference is that I never tried to connect to printer with the browser. ☠
Perhaps we should investigate very well in this field.

I use this on a corexy, I have a mechanical homing switch at Z-max (bottom) of the machine, which is setup so that Home Z and Home All home to this switch. Connect it to z-endstop on duet. I also have various z probes all over the machine on test, which are connected to the Z probe port on the duet, and which can be used to home Z but using G30 rather than G28 (+/-) Z, and for mesh height map, bed levelling etc…

I think there is a lot to be said for this approach.

As for how to set it up, my home z and home all, are not quite the "proper" way to do it, there was a thread on homing recently where the correct gcode was given, or see the wiki.

@Whitewolf:

@dc42:

On a delta, I don't allow ordinary moves before the printer has been homed. I've considered adding this restriction to other printer geometries, but I am not sure whether all users would like it. On a Cartesian printer, users may wish to jog the axes before homing. What do other users think?

I would hate it if I could not jog axis when not homed…. think of an estop event where the IR probe failed to trigger (happened to me yesterday) I have an optical endstop located just above which triggers an estop event but I then need to jog the bed back down before I can home the machine. There are other times when I jog around when not homed as well and love the estop feature that has saved my butt a couple of times 🙂

If you can disable it in firmware yes. I have to use this all the time with my printer cause I'm constantly making changes to parts and have to recalibrate axis dimensions.

@dc42:

If all the LEDs went off including the blue one, then the power to the Duet kept failing. Possibly causes include:

Bad power in connection. Check that the VIN terminal block screws are tight. Something drawing more that 30A shortly after power up. But I would expect you to see signs of charring if anything on the Duet was doing this. A fault in the PSU causing its overload protection to trigger falsely.

Hello Mr. David,
Your suggestions are all right, in fact these are the first things I thought and controlled, unfortunately I find nothing unusual and then, as I wrote before, I launched a test print and everything worked well.
So I guess there's no log, right? If I enable debugging in the firmware what happens?
Do you completely exclude a possible bug under certain conditions?
Are you aware of the slight anomalies with the web interface?

Thank you anyway for support
Dommy

@my67nova:

Dommy I could be wrong but I have the exact same setup and had same issue. I zoomed in on your photo and if you take out the sd card cable and look underneath you might see 2 pins, compared to mine yours appears to be offset by 2 pins. I thought I was wrong before but I was mistaken…... 🙂

Paul

Hy Paul,
Thank you very much.
After your post I made a double check and I have discovered that you are right.
My fault was also for another reason, unfortunately one of the channel is broken…... and than my tests was falsify.
Any way, now I have at least one channel that work well.
Thank you again Paul, and thank you to all....
Dommy

I'll re-test it in firmware 1.18.1.