Bug 2: RRF 3.3beta2 Axis hanging after M584 re-assignemnt

DocTrucker

@fcwilt trying to make use of all of the additional features that are available to an extrusion axis. For this application the argument for using RRF over other Linux CNC is that it is designed and a large amount of its testing is based on systems that squirt a viscous liquid. Loose those and LinuxCNC makes more sense.

Besides, this post is predominantly raising the bug that I found after following an approach suggested by @dc42. An extruder axis often has limit switches for out of, or stuck filament. It seems odd that the E axis is behaving differently to the others. My abnormal operations may just be highlighting a usually well hidden bug that can now be addressed.

DocTrucker

@deckingman @fcwilt thanks for the questions though, rethinking from different angles helped me find the M84 E0 work around.

fcwilt

@DocTrucker said in Bug 2: RRF 3.3beta2 Axis hanging after M584 re-assignemnt:

@deckingman @fcwilt thanks for the questions though, rethinking from different angles helped me find the M84 E0 work around.

I was thinking that if super fast homing is not needed you could use the conditional code feature of v3 firmware to "home" an extruder axis without messing with the swapping and encountering the "bug".

Frederick

DocTrucker

Is this a confirmed bug in 3.3beta2?

DocTrucker

@dc42 @droftarts @Phaedrux @T3P3Tony

Is this a confirmed bug in 3.3beta2?

dc42

@doctrucker, not it's not a known bug. Are you able to provide a GCode file that when run, provokes the undesired behaviour, without using triggers?

DocTrucker

@dc42 No triggers on the example I gave on the 20th of march:

@doctrucker said in Bug 2: RRF 3.3beta2 Axis hanging after M584 re-assignemnt:

So the following sequence of gcodes fails with a hung command...

G1 E25 F500
G1 E25 F500
M584 E4 B3
M574 B1 S1 P"xstop"
G91
G1 H1 B-100 F400
G90
M83 ; this has no effect on this problem 
G1 E25 F500 ; this command not executed.

But the following works fine...

G1 E25 F500
G1 E25 F500
M584 E4 B3
M574 B1 S1 P"xstop"
G91
G1 H1 B-100 F400
G90
M84 ; STOP IDLE HOLD
G1 E25 F500
G1 E25 F500

DocTrucker

@dc42 Further to the above in the example where the machine hangs if you wait (probably for the stepper idle current timeout) for a while I suspect the motors will run.

Wouldn't of expected the drive assignment to be something that is actually written to the stepper driver chip?

dc42

@doctrucker, I think one of the main causes of the problem is that you have declared a new B axis and a new extruder in the M584 command in your sequence of GCodes (your config.g file declares neither an extruder nor the B axis), but after creating them you have not set the motor current, or the steps/mm, or the microstepping. The microstepping should be OK because it will default to x16 with interpolation, but you certainly need to set the motor current and the steps/mm for both B and E after they have been created and before you move then.

DocTrucker

@dc42

@doctrucker said in Bug 2: RRF 3.3beta2 Axis hanging after M584 re-assignemnt:

@deckingman afternoon Ian. Calling M584 outside of the config file or dynamically is certinally not common and I think the comment in the gcode docs is only really concerned with the initial startup. I was concerned about that and created a macro called set_syringe_settings that set all of the commands that should be set after M584, and called it in the config file. It is in the first post.

I tried calling this in the macros that are called dynamically when a syringe hits empty but it didn't seem to help. I will double check though.

I did however do empty calls to all of the M/G codes listed in set_syringe_settings after swapping the E/B drives around using M584 and it didn't seem to effect any if the values reported.

As above, tried repeating the calls to set current etc and it had no effect on the hang. The motors are identical, and move as expected without overheating after re-assignemnt. I did empty calls to the gcode that sets the steps per mm and current and none of it was changed by the drive re-assignment.

DocTrucker

@dc42

As above here is the macro I tried calling after re-assignement with no effect on the hang:

@doctrucker said in Bug 2: RRF 3.3beta2 Axis hanging after M584 re-assignemnt:

set_syringe_settings.g

; Setup e0stop and e1stop inputs to trigger trigger2.g and trigger3.g
M950 J0 C"^e0stop"                     ; Input 0 uses e0Stop pin, pullup enabled
M950 J1 C"^e1stop"                     ; Input 1 uses e4Stop pin, pullup enabled
; Define triggers
M581 T2 P0 S0 R0                       ; Run sys/trigger2.g on falling edge on input 0 at any time.
M581 T3 P1 S0 R0                       ; Run sys/trigger3.g on falling edge on input 1 at any time.
; Drive Settings
M350 E16 B16 I1        ; configure microstepping with interpolation
M92 E400 B400          ; set steps per mm
M566 E450 B450         ; set maximum instantaneous speed changes (mm/min)
M203 E1200 B1200       ; set maximum speeds (mm/min)
M201 E450 B450         ; set accelerations (mm/s^2)
M906 E2000 B2000 I30   ; set motor currents (mA) and motor idle factor in per cent
M208 B0:300            ; Set axis limits

dc42

@doctrucker, I hadn't spotted that you create the extruder and B axis in the macros that you call from config.g.

Right now I am finding that extrusion doesn't work at all, it just makes a high pitched sound from the motor, as if the steps/mm is set extremely high. I will continue to investigate.

DocTrucker

@dc42 No problem. I'm quoting for you convenience, rather than being sarky.

I wondered if just swapping X&Y axis would have the same effect, but if memory serves somethign along the lines of "M84 B" fixed the hang rather than "M84 B E0", implying there might be something special/odd about the B axis.

Nothing on the A axis in these examples. I'd done some work for the same project where this is rotational, and had kept it free to thread that work back in. Not sure if this could be due to the absent A axis?

dc42

@doctrucker, I have worked out what is going on. When you reassign drivers, RRF doesn't work out the enabled/disabled status of the new driver. So if a drive such as E0 was enabled before the reassignment, it assumes it is still enabled after the assignment.

The workaround I suggest is that every time you reassign drivers, immediately before the M584 command that reassigns them, disable those drivers using M18 or M84. For example:

M18 B E0
M584 E4 B3

That way, after a M584 command, RRF will always know that the reassigned drivers are disabled, and will enable them before moving them.

DocTrucker

@dc42 Great, that makes sense. So is this issue closed as far as you are concerned, or are you looking to add lines to the code that force disable the M584 newly assigned drives?

dc42

As it's an unusual situation and code space is very tight on the Duet WiFi, I don't plan to add extra code to disable the original drivers. It's necessary to reset the motor current and microstepping after reassigning axes/extruders anyway, so I don't think it's much additional effort to disable the drives first. I have documented it at https://duet3d.dozuki.com/Wiki/Gcode?revisionid=HEAD#Section_M584_Set_drive_mapping.

DocTrucker

@dc42 That's fine. I've marked it solved and will stop watching it for updates. Didn't realise we were that close to the limit on the Duet2.