Just another bug with 3HC

Veti

there is a timing problem being worked on.

you need to add a delay G4 S2 (2-25 seconds before the first command accessing any pints on the extension board)

jrockland

Look like it worked, thank

deckingman

@jrockland I reported a very similar problem a few days back. https://forum.duet3d.com/topic/21219/extruder-runs-backwards-power-cycle-restores-correct-operation/5

In my case, it's simply powering up the printer which causes it and a power cycle will often fix it. Also, in my case, I already had a delay of 2 seconds. I've since increased it to 5 (after noting that the expansion boards sync within about 2 to 3 seconds) but that hasn't fixed it. I was told t run M98 P"config.g" as a workaround despite the fact that I said in my OP that I had already tried doing that and it doesn't work either.

dc42

@jrockland said in Just another bug with 3HC:

3HC controlled stepper will go backward after a config.g update/reset, then goes back to normal after a M112. latest firmware 3.2. Just saying.

As @Veti says, we believe this is a timing issue with system startup. There are at least the following factors in play:

RRF 3.2 runs much faster on MB6HC than it did before. This makes it more likely than before that following power up, a command in config.g that refers to a device on an expansion board (for example, M569 to set the driver direction) will be sent to the expansion board before the expansion board is ready to process it. If the first command to be sent to any expansion board is a M569 command to reverse the direction of a motor, then the motor will run in reverse.
Error messages generated when running config.g after startup are not normally seen because the web interface is no connected yet. So even though the failed command will provoke a "CAN receive timeout" message, it won't be seen.
Additionally, a small number of EXP3HC boards take much longer to start up than they should when running 3.2 firmware. This is because of varying crystal oscillator startup times, which if they are very long cause new code in 3.2 to fail. On these boards, when powering up the 3HC there will be a noticeable delay between the power LEDs on the 3HC illuminating, and the status LED starting to flash.

I am working with three users who have EXP3HC boards that have this third issue. The most recent fix I provided works for two of them.

@deckingman, I am surprised that re-running config.g via M98 wasn't a successful workaround for you, assuming that you did not receive any "CAN receive timeout" messages. Next time you power on your printer, please can you do the following:

Confirm that your config.g file contains a M569 Pn.nn Sn command for the driver that sometimes runs in reverse, to set the direction. [If it doesn't, then we are looking at a different issue.]
Tell me whether that command in config.g is the first command that refers to any CAN-connected devices, excluding M584.
After power up, send M569 Pnn.n (and no extra parameters) where n.nn is the ID of that driver.
If the direction reported by that command is not the direction that you specified in config.g, then run M98 P"config.g" and check that no errors are reported from that command. Then send M569 Pnn.n again and see if the direction is correct now. Please report your findings.

deckingman

@dc42

I'll shake the mothballs out of my printer and remove the dust cover when there is another stable firmware to try.

Meanwhile, here is the first part of my config.g

M111 S0 ; Debugging off
G21 ; Work in millimetres
G90 ; Send absolute coordinates...
M83 ; ...but relative extruder moves

; ------------------- Network -----------------------------------

M550 P"CoreXYUVAB" ; Set machine name

M552 S1 ;Turn networking on

M552 P***.***.*.*** ; Actual IP address has been replaced with "*" for this post

M555 P2 ; Set firmware compatibility to look like Marlin

;----------------------Dwell-------------------
G4 S5

; ------------------- Drives and axes -----------------------------

M584 X3.2 Y3.1 Z3.0 U0.0 V0.1 A0.2 B0.3 E1.0:1.1:1.2:2.0:2.1:2.2 R0 P7; XYZ on ex board 3, UVAB on main board, extruders 0 to 2 to ex board 1, extruders 3 to 5 on exp 2.
M669 K8 A0:0:0:0:0:1:1 B0:0:0:0:0:1:-1; CoreXYUV plus AB force cancelling gantry

M569 P3.2 S0 ; Drive 0 goes backwards - Lower left XY Alpha
M569 P3.1 S0 ; Drive 1 goes backwards - Lower Right XY Beta
M569 P3.0 S1 ; Drive 2 goes forwards - Z
M569 P0.0 S0 ; Drive 3 goes backwards - Middle left UV Alpha
M569 P0.1 S0 ; Drive 4 goes backwards - Middle right UV Beta
M569 P0.2 S1 ; Drive 6 goes forwards - Upper Left AB Alpha
M569 P0.3 S1 ; Drive 7 goes forwards - Upper Right AB Beta
M569 P1.0 S0 ; Drive 8  Extruder 0 Bondtech (Front Left)
M569 P1.1 S0 ; Drive 9  Extruder 1 Bondtech (Mid Left)
M569 P1.2 S1 ; Drive 10 Extruder 2 Bondtech (Back Left)
M569 P2.0 S0 ; Drive 11 Extruder 3 Bondtech (Back Right)
M569 P2.1 S1 ; Drive 12 Extruder 4 Bondtech (Mid Right)
M569 P2.2 S1 ; Drive 13 Extruder 5 Bondtech (Front Right)

M350 X16 Y16 U16 V16 A16 B16 Z16 I1; Configure XYUVABZ  microstepping with interpolation 
M350 E16:16:16:16:16:16 I1 ; Configure extruder microstepping

........etc

dc42

Thanks. Can you tell me which of the 6 extruder drivers (1.0, 1.1, 1.2, 2.0, 2.1, 2.2) has the issue with sometimes running backwards after power up?

deckingman

@dc42 said in Just another bug with 3HC:

Thanks. Can you tell me which of the 6 extruder drivers (1.0, 1.1, 1.2, 2.0, 2.1, 2.2) has the issue with sometimes running backwards after power up?

The config file for the single input hot end has just the one tool definition

M563 P0 S"SingleInput" D0 H1 ; Define tool 0

So that's the first extruder driver which is board 1, driver 0.

But nothing came out of the dual extruder when I tried printing with that. At the time, I didn't investigate the cause - just assumed that there was a problem with the hot end because that was the first time I had tried it. So it's highly likely that the cause was both extruder motors running backwards. The tools for the dual input hot end use driver 1 on board 1 and driver 1 on board 2 in mixing mode.

It's possible that all 6 extruders have the same problem or that some combination of them does.

If I can motivate myself, I'll try the 6 extruder configuration. That uses 3 extruders connected to each of two expansion boards. So if I try that, we'll be able to see if it's just one driver (extruder), or many drivers and if it's just one board or many boards that are affected. Until now, there seemed little point in doing so, but now that I have your attention, it might be worth my time....

dc42

Thanks, Ian. If you do decide to power up your machine, what I am particularly interested in knowing is:

Whether after power up, M569 Pxx.x reveals that the directions of some of the drivers is not what you set in config.g. If that is the case, it may be just the first driver that is addressed by a M569 command in config.g that is affected.
If you are able to see the LEDs on the affected expansion board(s), whether after power up the status LED starts blinking immediately, or there is a delay of more than half a second between the power LEDs lighting and the status LED lighting for the first time. But if you can't see the LEDs because they are hidden behind extruders etc., don't worry.

I am waiting for responses to two other threads to see whether my recent changes to the 3.3beta firmware have resolved slow startup issues with other EXP3HC boards. If I get confirmation then I plan to back-port the fix to the 3.2 firmware branch.

deckingman

@dc42 I'll let you know - busy with other things right now.

In the meantime, I can say that the first M569 is the XY alpha motor which is on expansion board 3 (as per the config I posted above) and that when I tried a print with the dual input hot end (which did not extrude any filament), I did not notice any untoward carriage motion. So it's unlikely to be the first M569 for any expansion board driver, but might be the first M569 for an extruder .

I did take note of the sync led on the expansion board with the known affected extruder and I'd say that it takes 2 to 3 seconds before it is flashing in sync. That's why I increased the pause in my configuration file from 2 to 5 seconds. I did not observe the sync leds on the other 2 expansion boards or the main board so can't say if they are are better or worse or the same.

dc42

@deckingman said in Just another bug with 3HC:

@dc42 I'll let you know - busy with other things right now.

In the meantime, I can say that the first M569 is the XY alpha motor which is on expansion board 3 (as per the config I posted above) and that when I tried a print with the dual input hot end (which did not extrude any filament), I did not notice any untoward carriage motion. So it's unlikely to be the first M569 for any expansion board driver, but might be the first M569 for an extruder .

I'm sorry, I didn't make myself clear. I meant that if the issue occurs on a board, it may only affect the first driver on that board. This is because the additional delay while the main board times out waiting for the first response may be sufficient for the second M569 command to be received. We already know that only some 3HC boards are affected, because none of the three 3HC boards that I used in my testing showed this problem when testing the 3.2beta series firmware. Also, if the first M569 command commands forward movement and doesn't change any other parameters, then it won't matter if it is not received and executed, because forward motion is the default.

I did take note of the sync led on the expansion board with the known affected extruder and I'd say that it takes 2 to 3 seconds before it is flashing in sync. That's why I increased the pause in my configuration file from 2 to 5 seconds.

With 3.2 it's normal for the LED to flash quickly for 1 to 2 seconds before flashing slowly to indicate sync, because the sync requirements are more strict. Even before it establishes sync, it will still respond to CAN configuration commands while the LED is blinking rapidly. What isn't normal is for the LED not to start flashing at all within half a second of the board being powered up - that indicates that the expansion board is suffering from the slow startup issue.

deckingman

I don't know if this is significant at all, but I'll mention it just in case ......

These pre-production expansion boards do have a known fault. I don't remember all the details but when you checked them over prior to sending them to me before the TCT show, you said that they could not be used with the pt100 or thermocouple daughter boards. I have no requirement to use daughter boards so that's not an issue as far as I'm concerned, but I mention it in case it has any bearing on what's happening now with RRF3.2.

oozeBot

This may or may not be related, but I'd like to add that we recently saw this behavior on a Duet 3 ( no expansion board) running 3.2 between prints. A print finished, a new print was kicked off, and it homed Y backwards. Rebooting corrected the issue.

dc42

@deckingman said in Just another bug with 3HC:

I don't know if this is significant at all, but I'll mention it just in case ......

These pre-production expansion boards do have a known fault. I don't remember all the details but when you checked them over prior to sending them to me before the TCT show, you said that they could not be used with the pt100 or thermocouple daughter boards. I have no requirement to use daughter boards so that's not an issue as far as I'm concerned, but I mention it in case it has any bearing on what's happening now with RRF3.2.

Thanks for mentioning that, I had forgotten. However, I don't think that being pre-production boards has any bearing on this issue, given that the boards worked with firmware 3.1.1, and that the problem you are having with 3.2 sounds similar to the slow startup issue that we already know affects a proportion of EXP3HC builds that use the original 12MHz crystals.

dc42

@deckingman, I have put a candidate 3.2.1 firmware for the EXP3HC at https://www.dropbox.com/sh/1lwimb98k6hzz3z/AAApVr_P6roUjnya4riDbGAba?dl=0. This fixes the slow startup issue in all but one of the 3HC boards experiencing the issue that it has been tested on. I am hopeful that it will resolve the issue of the extruder running in the wrong direction after power up, even with the delay in config.g reverted to 2 seconds which AFAIR is what you were using before.

@jrockland, you may wish to install this version too, in case the issue you experienced is not solely caused by the faster startup of the MB6HC with firmware 3.2.