Extruder runs backwards, power cycle restores correct operation
-
Dear God, how is this even possible!!!
Firmware RRF 3.2
Hardware 1 Gen main board, 3 gen 3 expansion boards. Extruders connected to expansion boards.I really needed to print something so I took the dust sheet off my mothballed Duet3 equipped printer. I have to manually home the printer because my normal homing macros produce "Homing failed" errors since "upgrading" to RRF3.2. Having managed to get the printer into a state where it might actually work, I tried to print something. Nothing came out of the nozzle! Thinking there must be a blockage, I aborted the print. On investigation, I discovered that the extruder was running backwards! That is to say, the filament retracts when an extrude command is sent and extrudes when commanded to retract.
This happened yesterday. I checked config.g and nothing had changed. Eventually, I cycled the power, tried again , and this time the extruder worked as it should. Thinking this was just a one off, I shrugged and printed the part I needed.
I tried again today and exactly the same thing happened. That is to say, after powering the printer, the extruder was running backwards (I'm running a single input hot end). This time, I ran M122 on the main board and all 3 expansion boards. I then ran M98 P"config.g" and tried to extrude but it was as if only one pair of coils were being energised. So I cycled the power, tried again and this time, the extruder ran in the correct direction.
This is coincidental with "upgrading" to 3.2.
The situation is dire - my printer has become a useless pile of junk because of firmware issues which just seem to get worse.
I've uploaded the M122 outputs my Google drive - link here https://drive.google.com/drive/folders/1nbkOX1qewuW4hb123gSexzON0r5xNQe_?usp=sharing
You should be able to open them with notepad++
-
i think dc42 said that this can happen because the expansion board take a bit longer to initialise.
adding a delay of a few seconds before the config of any extension pin should make this work reliable.hope that helps
-
@Veti I already have a G4 S2 before the first command which references anything on an expansion board which is my M584. I did see that another user, with different issue, had to use a delay of 25 seconds!
-
@deckingman said in Extruder runs backwards, power cycle restores correct operation:
had to use a delay of 25 seconds!
some of the big cnc machines for glass cutting (many axes, all motors are on a "bus", no clue what type of a bus, can or something else never checked) takes a good 5 minutes to "boot up" and the identical PLC that's inside boots up in under a second on other machines so for some reason it takes 5 minutes to configure all the motors on the bus and all the io cards with sensors.
-
@arhi said in Extruder runs backwards, power cycle restores correct operation:
@deckingman said in Extruder runs backwards, power cycle restores correct operation:
had to use a delay of 25 seconds!
some of the big cnc machines for glass cutting (many axes, all motors are on a "bus", no clue what type of a bus, can or something else never checked) takes a good 5 minutes to "boot up" and the identical PLC that's inside boots up in under a second on other machines so for some reason it takes 5 minutes to configure all the motors on the bus and all the io cards with sensors.
How is that relevant? Never had this problem before - it's only happened since changing (I can't bring myself to say "upgrading") to RRF3.2. The Duet "team" haven't mentioned that we now have to wait 5 minutes or more, after applying power before attempting to move anything. In any case, it was considerably longer than 5 minutes after power up before I attempted a print because it takes longer than that to heat the bed. And it doesn't explain why a power cycle corrects the problem.
-
@deckingman said in Extruder runs backwards, power cycle restores correct operation:
How is that relevant? Never had this problem before - it's only happened since changing (I can't bring myself to say "upgrading") to RRF3.2.
Relevance is that IMHO more functionality being added to the CAN boards means it takes longer to configure said CAN boards. The more boards you have, the more total time it takes to configure them all. Now the "5 minutes" is the bootup time of the machine that's few orders of magnitude more complex than your printer (that's at least an order of magnitude more complex than most of the 3d printers out there
and can't be looked at as a "simple/average example") so I doubt RRF will ever need "5 minutes" but some seconds are to be expected IMHO.it was considerably longer than 5 minutes after power up before I attempted a print because it takes longer than that to heat the bed
I don't think that's relevant, I'm not talking about when you start the work, I'm talking about bootup time, time taken for configuration and self check, time before you are allowed/able to start the work. I did not look at the source of RRF3 and how the CAN thing works really but I assume configuration is done at the beginning and time from then to you executing your code is irrelevant as nothing is happening during that time (except for keeping everything in sync).
And it doesn't explain why a power cycle corrects the problem.
I am probably wrong but in my experience that usually means you are on the edge, sometimes it works sometimes it does not, power cycle solves a problem etc.. that's in 99% cases a timing issue. Probbly if you up that 2 second delay to 3 seconds you won't have any more issues.
Simple example (no clue if it applies or not but is a possible case for some design), you turn on "cold machine", motherboard boots up first and start configuring external boards, external boards have beefy caps and low current usage at the setup stage so they boot up slower till the caps get the charge, motherboard start configuring boards and f*s up as the boards are not fully up when it start doing so, you have your reverse move and who knows what %$@#^ else. You power cycle, your external boards are now hot, caps are full, they boot up instantly, configuration from motherboard starts when external boards are fully up, they get configured properly, voila problem solved... makes sense? Is it a bug - IMHO yes, protocol must be such that motherboard must know the external board is up, ready to properly receive the configuration, after configuration is sent external board need to send the configuration back so motherboard can confirm that's it (or send a checksum or...). Does this apply to RRF/Duet3 -> I have no clue, don't have d3 nor know RRF source but it is possible explanation giving also a possible solution (make sure you boot all your boards before you turn on duet3 board for e.g.)
-
-
The machine was powered up for at least 15 minutes before I even attempted to start a print.
-
The problem never happened in any previous firmware version. The Duet hardware is unchanged and has remained the same for over 18 months.
-
The problem never manifested itself with any other version of firmware prior to 3.2
-
The Duet "team" have never made any mention of the fact this it might be necessary to leave the machine for 5 or more minutes before it can be used.
-
Most importantly, by his own admission, DC42 does not read every post. So the more "diluted" this thread becomes, the less likely it is that he will read my original description of the problem.
-
-
upgrading to duet3 and toolboards has been certainly an adventure for me... I don't find it to be "production ready" (compared to the duet2+duex) but at least it is evolving fast
-
@matt3o said in Extruder runs backwards, power cycle restores correct operation:
upgrading to duet3 and toolboards has been certainly an adventure for me... I don't find it to be "production ready" (compared to the duet2+duex) but at least it is evolving fast
I'm afraid I cannot agree with the part about it evolving fast. It's been over a year and half for me and even without these problems with RRF3.2, I still don't have the basic functionality that I had with Duet 2 prior to July 2019.
-
Bump. @dc42 have you seen this thread? Have you read my first post? Your signature requests that people do not contact you directly so this forum is the only way to bring firmware issues to your attention.
-
@arhi said in Extruder runs backwards, power cycle restores correct operation:
Relevance is that IMHO more functionality being added to the CAN boards means it takes longer to configure said CAN boards.
The main reason is that better utilisation of the cache memory on the Duet 3 MB6HC in RRF 3.2 has made the main board faster to start up. However, there is a separate issue that causes a small number of EXP3HC boards to take longer than normal to start up when running firmware 3.2 and/or bootloader 2.0 or later.
-
@deckingman said in Extruder runs backwards, power cycle restores correct operation:
Bump. @dc42 have you seen this thread? Have you read my first post? Your signature requests that people do not contact you directly so this forum is the only way to bring firmware issues to your attention.
Yes I saw your first post and Veti's reply yesterday, and I considered that reply was sufficient. That was before you made your second post.
I suspect that the expansion board in question has a crystal that is slow to start up, similar to the other board that takes 25 seconds to start up. I can't remember whether the status LEDs on the expansion boards are visible in your machine, but if they are then you may notice that board taking longer than 2 seconds before the LED starts to flash.
I am working to resolve the issue with that other board, and I consider it likely that the fix will resolve it on your machine too. Meanwhile as a temporary workaround, if you run M98 P"config.g" after powering up your machine, this will re-send the M569 command to that extruder, or report an error if it is unable to do so.
Duet WiFi hardware designer and firmware engineer
Please do not ask me for Duet support via PM or email, use the forum
http://www.escher3d.com, https://miscsolutions.wordpress.com -
@dc42 said in Extruder runs backwards, power cycle restores correct operation:
@deckingman said in Extruder runs backwards, power cycle restores correct operation:
Bump. @dc42 have you seen this thread? Have you read my first post? Your signature requests that people do not contact you directly so this forum is the only way to bring firmware issues to your attention.
Yes I saw your first post and Veti's reply yesterday, and I considered that reply was sufficient. That was before you made your second post.
I suspect that the expansion board in question has a crystal that is slow to start up, similar to the other board that takes 25 seconds to start up. I can't remember whether the status LEDs on the expansion boards are visible in your machine, but if they are then you may notice that board taking longer than 2 seconds before the LED starts to flash.
I am working to resolve the issue with that other board, and I consider it likely that the fix will resolve it on your machine too. Meanwhile as a temporary workaround, if you run M98 P"config.g" after powering up your machine, this will re-send the M569 command to that extruder, or report an error if it is unable to do so.
The status LEDs are visible. I've just checked and would estimate that particular expansion board takes around 2 to 3 seconds before it flashes in sync with the main board. I will increase my G4 S2 to S10 which should be more than sufficient.
Ref running config.g as a work around - I said in my first post that I tried that and it didn't work - it was as if only one pair of coils were being energised - the motor had hardly any power (but it did seem to be trying to move in the correct direction). Only a power cycle would work.
Where would you suggest is the best place to put the G4 delay? I currently have it after the network section and before the first M584 which is the first reference to anything connected to an expansion board.
-
@dc42 well he is not the only one with a "slow crystal" because since 3.2 I'm having the same issue.
-
@jrockland said in Extruder runs backwards, power cycle restores correct operation:
@dc42 well he is not the only one with a "slow crystal" because since 3.2 I'm having the same issue.
It's not a slow crystal - at least not in my case. The expansion board led flashes in sync after about 2 to 3 seconds. I changed my delay from 2 to 5 seconds but that hasn't cured the problem. Neither does running M98 P"config.g" - but I said that in my OP (not that anyone took any notice of that fact).
