Stall Guard reporting

dc42

@core3d-tech said in Stall Guard reporting:

I'm currently playing with stall gaurd detection and am running in some issues. The stall guard I define is assigned to the U axis (which does it's own little thing, not seen before).

I've implemented homeu.g and it executes but I can't tell for sure if stall guard actually triggered. The motor stopped (in most cases)...

if the motor stopped when it hit the hard endstop, then stall detection worked. Otherwise it would try to keep moving the motor until the total movement that you specified in the G1 S1 command has been done.

... but rehome.g is NOT executed, which makes me wonder if it did.

File rehome.g is only executed if a stall occurs during an SD card print, and not if it was executing a macro (for example, a homing file) at the time.

Is there a way to get driver status (including stall gaurd info) on the TMC Chips (M122 in marlin gives me load of info on my TMC2130 chips).

The TMC2660 drivers don't provide as much info as TMC2130s do, but a summary of the status of each driver is included in the M122 report. Note, the "stalled" status is suppressed when the motor speed is below the threshold set in the M569 command, because stall detection is unreliable at low speeds.

core3d.tech

@dc42 Thanks you. Actaully I don't really need the rehome.g but, changing the current in that file (different, so I'd see a change) seemed the only way to validate stall worked.

Is there a way to capture stall information as part of logging?

In the list below, should I be seeing stalled instead of standstill?

Supply voltage: min 21.6, current 24.2, max 25.0, under voltage events: 0, over voltage events: 0
Driver 0: standstill, SG min/max 35/284
Driver 1: standstill, SG min/max 51/272
Driver 2: standstill, SG min/max 56/277
Driver 3: standstill, SG min/max not available
Driver 4: standstill, SG min/max 0/944
Date/time: 1970-01-01 00:00:00

If I understand correctly, if it rattles when it hit the wall, it means stall didn't work. Can any damage occur (other than ripping apart the machine) to the motors/drivers when it tries to push through till the end of the operation but can't?

core3d.tech

Got it working!! I run 200 step motor at 80 steps per Unit (200 * 16 / 80) = 40mm/sec = 2400mm/min. So if I home at higher than F2400 it should register

Playing with the sensitivity, I can get the motor to stop (not because it hit something, it just stops). For example

M915 U F0 S17 R3 ; the motor reaches the end and rattles (assuming stall guard not working)
M915 U F0 S11 R3 ; the motor stops!! when it reaches the end (no rattling)

I assume the latter worked but there is no trace of it in M122

MCU temperature: min 32.8, current 33.2, max 33.5
Supply voltage: min 21.7, current 24.2, max 25.0, under voltage events: 0, over voltage events: 0
Driver 0: standstill, SG min/max not available
Driver 1: standstill, SG min/max not available
Driver 2: standstill, SG min/max not available
Driver 3: standstill, SG min/max not available
Driver 4: standstill, SG min/max 0/902
Date/time: 2018-11-21 16:01:50
Slowest loop: 173.28ms; fastest: 0.08ms
=== Move ===
Hiccups: 0, StepErrors: 0, LaErrors: 0, FreeDm: 240, MinFreeDm 239, MaxWait: 548064ms, Underruns: 0, 0
Scheduled moves: 28, completed moves: 28

I was initially getting a homing failed but that's because I put in M18 U. Once I removed it, it worked again.

Thanks!!!

core3d.tech

Follow up question. I will be using the Delta Smart Effector with it's z homing feature. With that in place, can I still add stall guards on X Y and Z for other bumps it may encounter? Thx

dc42

@core3d-tech said in Stall Guard reporting:

Follow up question. I will be using the Delta Smart Effector with it's z homing feature. With that in place, can I still add stall guards on X Y and Z for other bumps it may encounter? Thx

Yes you can. Is your printer a delta then? On a delta some of the motors are typically moving slowly (below the stall detection threshold) and they often reverse direction within a single move. Also, high current low inductance motors are favoured for delta printers, but these produce lower back EMF than the low current high inductance motors that the Prusa i3 uses. Both of these make stall detection (other than for homing) more difficult on a delta.

core3d.tech

@dc42 Thx, I wouldn't be using it for any homing but in case it literally crashes into something it would like to detect it. Unfortunately it will be moving very slow when it does crash so stall gaurd may not be the best option here.

I have the E endstop connectors still available. Is there any way I can assign "it" to an action (in a macro). Something like
g91
while 4th Endstop not triggered g0 Z-50 (i.e go down 50 unless you hit 4th endstop).

I apologize if I'm asking stuff outside the realm of ordinary printing. Trying to add a feature (that I would like to show at MRRF2019). Still missing some pieces on the software front (that I either haven't found yet or never will).

Thx

dc42

@core3d-tech said in Stall Guard reporting:

I have the E endstop connectors still available. Is there any way I can assign "it" to an action (in a macro). Something like
g91
while 4th Endstop not triggered g0 Z-50 (i.e go down 50 unless you hit 4th endstop).

Currently the only way I can think of do to that would be to use M558 to temporarily use that endstop switch as the Z probe, and use a G30 command to lower Z until the switch is triggered.

core3d.tech

@dc42 If I can assign a e endstop to Z (temporarily) that should actually do it. Running a macro so I can switch to and back. Thanks!!

core3d.tech

@dc42 tested that one out but it won't really work as I can't use the G30 for the action I'm looking for (also when I tested and triggered stop, Z rushed up and almost took out the top of my printer, how far does it shoot back?).

What I'm looking for is to use an endstop connected to E1 that will stop all motors when triggered and continues on with macro.

so the sequence would be

G91

;while (Endstop E1 not triggered or move ended)
G1 Z-500

;continue with Macro

any ideas? TIA

dc42

You could use M574 to change the Z endstop type to "Z probe", then use a G1 S1 Z-500 command. Then use M574 to change it back again.

core3d.tech

Not sure I fully understand. Currently I have 3 end stops (X,Y,Z) at the top of each tower.

I have a 4th endstop that needs to test if something else reaches the end.

How do I assign the 4th end stop (currently connected to E1 endstop, I'm open to other connections) as a new Z-probe?

This does make me think about another (less desirable approach) which is

Let probe find bed (has it's own issue, that will be resolved once I can store parameters)
move to Z0
From there I know how far the bottom of the printer is move it all down.

G28
G30
G1 Z0
;"grab bed with magic move"
macro_grabBed
;Home again slowly
G28
G91
G1 S2 Z-1210
; release bed/clamp onto frame

The only problem with this approach (which is why I need some of the parameter storage) is:
The printer when starting up, doesn't know the current position of the bed so when running G30 it doesn't know how far to go down to start probing.

What I really need is for an endstop trigger (other than X/Y/Z) to stop all motors but continue with macro. Worst case I could code it into the firmware (using spare g-code)

dc42

I have a 4th endstop that needs to test if something else reaches the end.

Please can you explain what the "something else" is. What type of movement command will you use that will result in the 4th endstop being triggered, and what do you want to happen when it is triggered?

core3d.tech

@dc42 I was trying to keep it a reveal at MRRF2019 but I just posted this video of what I'm building. My Delta (in progress) has a build volume of 330DIAx1250mm. Most of the time I won't be printing that high so I build a mechanism that allows the bed to move up and down. I use the belts that drive the effector to move the bed up and down (via a macro that does some stuff to grab on to the belts and release the frame and vice versa.

Right now the macro are pretty static. "Move bed Up 500" "Move Bed Down 500".

When it moves down it shouldn't be able to go lower than 0 but at the moment I have no means of stopping this from happening. A 4th end stop could help here.

youtube of moving bed

This is also why I've been asking about the parameters and stored values in other posts as I currently have no way of persisting the current position of the bed. The next time the printer turns on it doesn't know if the bed is at 0, 500 or 1000 (or maybe some dynamic height in the future).

The current macro for moving the bed down is below. If I were to run this macro while the bed is down without some stop mechanism you can imagine what happens.

;Home XYZ first
G28
; switch to relative
G91
;Move down 10 on Z (little more for wiggle room)
G1 Z-10
;Grab on to belt
G1 U85 F2400
;Move Z up 5mm to release frame
G1 Z5
;wait to make sure it released
G4 P200
;lower current motors in case it rams into something
m906 X1000 Y1000 Z1000
;Move bed down 500 (slow as it has to lift a lot)
G1 Z-500 F500
; release belt
G1 U-85 F2400
;Move Z down 8mm to release belt
G1 Z-8
;refine printer dimensions; not fully worked out yet as I have no knowledge of last position of bed.
M665 H1210
;turn up current motors again
m906 X2100 Y2100 Z2100
;home again
G28
;turn off Bed Motor
M18 U
;recalibrate bed
;G30
;back to absolute
G90
...

dc42

It sounds to me that the bed is an additional axis. So create a 4th axis called U using M584. It will use the E0 endstop connector. You can use E1 for your filament monitor.

core3d.tech

I'm already using the 4th Axis U. U (P4) runs the motor that switches the XYZ belts to operate the bed. Watching the video may clarify that a bit better https://youtu.be/L9pTHMi5SP8.

The bed is a "virtual" 5th axis. it is moved by XY and Z (P0, P1, P2) when the 4th endstop is triggered X Y and Z need to stop.

The other issue I run into is that trying to use the E0 or E1 endstop can not be managed by M574 (only 1.16 and below). these seem to be only usable as Z-probes now (using M558)

It would be nice to be able to assign a gcode file to specific endstop (TriggeredE1.g) in which I can do what I need. Kinda like homeu.g is there for homing axis U.

dc42

@core3d-tech said in Stall Guard reporting:

The other issue I run into is that trying to use the E0 or E1 endstop can not be managed by M574 (only 1.16 and below). these seem to be only usable as Z-probes now (using M558)

The E0 and E1 endstop inputs will be used for the first 2 additional axes you create using M584, if you have the endstop type for those axes set to S1 or S2.

core3d.tech

@dc42 That is good to know. Since the motion I'm trying to capture is driven by X Y and Z, I'm still not sure if that can help me. When the end stop hits X Y and Z need to stop simultaneous.

As an enhancement request would assigning an end stop to a g-code be possible? triggerU.g TriggerV.g, .....

dc42

@core3d-tech said in Stall Guard reporting:

@dc42 That is good to know. Since the motion I'm trying to capture is driven by X Y and Z, I'm still not sure if that can help me. When the end stop hits X Y and Z need to stop simultaneous.

As an enhancement request would assigning an end stop to a g-code be possible? triggerU.g TriggerV.g, .....

You can already set up triggers on any endstops. The fact that you are using an endstop for homing doesn't stop you using it for a trigger as well.

core3d.tech

@dc42 that's excellent. ~~Where do I look for more info on that?~~ nm, found it M581. That should do the trick for me.