Posts made by 3hristian

undefined

Oh, yes. Of course it's the D2450!

I just connected the SSD input to the PS_ON output. (I had completely forgotten about that port - thanks for pointing out!)

With this I can workaround the broken transistor for the important fan of my machine. I'll just run the other fan as always on fan from now on (it's just an aesthetic and not a functional flaw for my machine).

Thanks for the help and your offer with which I do not want to bother you now. It's fun to be (a small) part of such a community and to buy products from a company with this kind of customer support!

Best regards!
Christian

undefined

Thanks for the great offer dc42! Before I might come back to that offer I may have another idea:

Because a possible workaraound (although not as nice) that might make my machine useful (even if with restrictions) again, could be the following:

I have a mains powered heated chamber in my printer. I control the heaters for that with a SSD relay (crydom A2450), which draws a maximum of 12 mA as input current. At the moment I also use a fan output to control the relay.

I could free the IO_5 port on my machine (which is able to generate a pwm signal). But I think that the direct connection of the relay (without additional transistor stage) is not possible, because the 12 mA are too much for a general IO port on the Duet3 MB 6HC? (I could not find any information about this.)

Am I correct at this assumption? Or asked in another way (for others maybe an even more helpful information): How much current can an IO_X port on the duet deliver?

Best regards and thank you very much!
Christian

undefined

Thanks for the quick reply dc42! I am from Germany :). Unfortunately the DMT6018LDR seems to have a lead time of a year or so at the well known distributors here...
Also thank you for the short description of how this component might be replaced.

Best regards
Christian

undefined

Hello,

I have found many topics related to Duet2 mosfet repairs and possible part numbers for replacements. There is even an article in the Duet3D Documentation.
(In case someone is searching for that: https://docs.duet3d.com/en/User_manual/Troubleshooting/Parts#fan-mosfet)

Thanks for that great community support by the way!

In my case, unfortunately I probably have a blown fan mosfet on my Duet 3 MB6 HC (v1.0) board for fans 6 and 9. This guess comes from the fact that both fans are now permanently on and not responding to control instructions.
Now I would like to replace the mosfet, but I am having a hard time finding a suitable replacement part. Apart from that, I haven't tried to replace such small SMD components yet either and would be grateful for any tips. Otherwise I would probably try a tweezer soldering iron first.

Specifically, I'm talking about the 3x3mm Fairchild Dual Mosfet Q27. Printed on the component is the text "T18 1915".

It would be great if someone can give me a hint
for a reference source and a part number or similar. In the long term, maybe also the existing documentation could be expanded accordingly.

Many thanks and best regards!
Christian

undefined

I have tested the resurrect behaviour in different situations now (with different tools selected and with different temperatures): Everything works as expected now.

Best regards
Christian

undefined

Hi dc42,

I just tested the 2.04RC4+1 build from your dropbox. Now it seems to work as it should work. The same test procedure (of my previous post) now produces the following resurrect.g file:

; File "0:/gcodes/interruptRRF2.04RC4+1.gcode" resume print after print paused at 2019-10-21 21:05
G21
M141 P0 S0.0
G29 S1
T-1 P0
G92 X71.344 Y104.773 Z0.300
G60 S1
G10 P1 S200 R0
G10 P0 S225 R225
T0 P0
M98 P"resurrect-prologue.g"
M116
M290 X0.000 Y0.000 Z0.000 R0
T-1 P0
T0 P6
G10 L2 P1 X0.00 Y0.00 Z0.00
G10 L2 P2 X0.00 Y0.00 Z0.00
G10 L2 P3 X0.00 Y0.00 Z0.00
G10 L2 P4 X0.00 Y0.00 Z0.00
G10 L2 P5 X0.00 Y0.00 Z0.00
G10 L2 P6 X0.00 Y0.00 Z0.00
G10 L2 P7 X0.00 Y0.00 Z0.00
G10 L2 P8 X0.00 Y0.00 Z0.00
G10 L2 P9 X0.00 Y0.00 Z0.00
G54
M106 S0.00
M106 P2 S0.00
M106 P3 S0.00
M106 P4 S0.00
M106 P5 S0.00
M106 P6 S0.00
M106 P7 S0.00
M106 P8 S0.00
M116
G92 E0.00000
M83
M23 "0:/gcodes/interruptRRF2.04RC4+1.gcode"
M26 S11594 P0.000
G0 F6000 Z2.300
G0 F6000 X71.344 Y104.773
G0 F6000 Z0.300
G1 F3200.0 P0
G21
M24

During the next days/weeks I will test the behaviour in different situations (e. g. with T1 selected instead of T0 during pausing). I will inform you if I notice a strange behaviour.

Thanks a lot and have a nice evening!

undefined

Hi dc42,

thanks for the response and the work you put in the conversation to the community and also this issue!

To make sure I have not messed up something during my test I tested the behavior again (also two times) and also checked that the tool (T0) was selected during some steps of the test. But the generated resurrect.g file stays the same and the tool selection in front of calling the resurrect-prologue.g is still missing.

But my test scenario was a little bit different to yours. That is the case because I personally want to use the resurrect function for controlled shutdowns so that I don't have to leave the printer unattended during printing (for safety reasons).

My test scenario was:

Starting a print
Wait for a few strand depositions
Pressing pause (on the paneldue) - (I checked: T0 is still selected as indicated on the paneldue and in DWC)

My pause.g file is the following (but should not matter because I don't deselect the tool):

G91         
M83           	 	
G1 Z3 E-5 F3000 	
G90            		
M98 Pmovetopurge.g
G91            		
G1 Z-3 F360     	
G90

My movetopurge.g file is the following (for the sake of completeness):

G1 X220 Y240 F15000
G1 X240 Y240 F15000	
G1 X240 Y260 F15000 
G1 X220 Y260 F15000

Pressing cancel (my cancel.g file is empty) - (I checked: T0 is still selected as indicated on the paneldue and in DWC)
Turn the printer off / pull the mains plug
Wait for about 10 seconds
Plug in the mains plug / turn the printer on
Open the resurrect.g file over Duet Web Control 2.0.2

So maybe the function / behaviour doesn't work for a controlled shutdown (at the moment)? Maybe you can test my procedure on your machine?

Best regards
Christian

undefined

Hi again,

I just tested the RRF 2.04 RC4 according to the problem I explained above. Unfortunately the new behaviour is still faulty: Now the temperatures are restored (as they should be) but the tool that was active at the print-interruption is not selected (as in RRF 2.03).

So this is the resurrect.g file that is generated by my printer (with RRF 2.04 RC4):

; File "0:/gcodes/interruptRRF2.04RC4.gcode" resume print after print paused at 2019-10-20 21:12
G21
M141 P0 S0.0
G29 S1
T-1 P0
G92 X183.690 Y105.250 Z6.300
G60 S1
G10 P1 S200 R0
G10 P0 S210 R220
M98 P"resurrect-prologue.g"
M116
M290 X0.000 Y0.000 Z0.000 R0
T-1 P0
T0 P6
G10 L2 P1 X0.00 Y0.00 Z0.00
G10 L2 P2 X0.00 Y0.00 Z0.00
G10 L2 P3 X0.00 Y0.00 Z0.00
G10 L2 P4 X0.00 Y0.00 Z0.00
G10 L2 P5 X0.00 Y0.00 Z0.00
G10 L2 P6 X0.00 Y0.00 Z0.00
G10 L2 P7 X0.00 Y0.00 Z0.00
G10 L2 P8 X0.00 Y0.00 Z0.00
G10 L2 P9 X0.00 Y0.00 Z0.00
G54
M106 S0.00
M106 P2 S0.00
M106 P3 S0.00
M106 P4 S0.00
M106 P5 S0.00
M106 P6 S0.00
M106 P7 S0.00
M106 P8 S0.00
M116
G92 E0.00000
M83
M23 "0:/gcodes/interruptRRF2.04RC4.gcode"
M26 S39166 P0.000
G0 F6000 Z8.300
G0 F6000 X183.690 Y105.250
G0 F6000 Z6.300
G1 F600.0 P0
G21
M24

As you can see there is no tool selected before calling resurrect-prologue.g.
The problem with this behaviour is that you have to guess which tool was active during the job interruption. In my example Tool 0 was active during the iterruption (you can see it at the temperatures):

G10 P1 S200 R0
G10 P0 S210 R220

So in my example the generated code of resurrect.g should look like this:

[...]
G10 P1 S200 R0
G10 P0 S210 R220

T0 P0

M98 P"resurrect-prologue.g"
M116
[...]

Of couse this is only a problem when your printer has multiple tools, but because that is one of the strengths of the Duet3d /RRF combination it would be great to solve this (minor) issue. Or is there something I am missing?

Best regards
Christian

undefined

Hi again,

I just updated to RRF 2.04 RC3 and tested the new behavior. Unfortunately it's still not possible to undo a retraction in a way you should do it. The problem is (as I guessed in my previous post), that the temperatures of the interrupted build job are not restored. So you can't handle the extruder in a proper way in the resurrect-prologue.g file because you don't know the correct temperatures. So the new behavior doesn't help e.g. if you have a machine that is capable of handling different materials.

Here is a code example of the resurrect.g file that is generated by my printer (with RRF 2.04 RC3):

; File "0:/gcodes/interruptRRF2.04RC3.gcode" resume print after print paused at 2019-10-09 16:27
G21
M141 P0 S0.0
G29 S1
T-1 P0
G92 X87.900 Y117.723 Z0.300
G60 S1
T0 P0
M98 P"resurrect-prologue.g"
M116
M290 X0.000 Y0.000 Z0.000 R0
G10 L2 P1 X0.00 Y0.00 Z0.00
G10 L2 P2 X0.00 Y0.00 Z0.00
G10 L2 P3 X0.00 Y0.00 Z0.00
G10 L2 P4 X0.00 Y0.00 Z0.00
G10 L2 P5 X0.00 Y0.00 Z0.00
G10 L2 P6 X0.00 Y0.00 Z0.00
G10 L2 P7 X0.00 Y0.00 Z0.00
G10 L2 P8 X0.00 Y0.00 Z0.00
G10 L2 P9 X0.00 Y0.00 Z0.00
G54
G10 P1 S200 R0
G10 P0 S220 R220
T0 P6
M106 S0.00
M106 P2 S0.00
M106 P3 S0.00
M106 P4 S0.00
M106 P5 S0.00
M106 P6 S0.00
M106 P7 S0.00
M106 P8 S0.00
M116
G92 E0.00000
M83
M23 "0:/gcodes/interruptRRF2.04RC3.gcode"
M26 S20136 P0.000
G0 F6000 Z2.300
G0 F6000 X87.900 Y117.723
G0 F6000 Z0.300
G1 F4800.0 P0
G21
M24

So why don't you restore the temperatures before resurrect-prologue.g is called?
Is there a way to get the temperatures of the interrupted build job to handle the extruder in resurrect-prologue.g?

Thanks again in advance!

undefined

Thanks for the response!
Hopefully also the temperatures for at least the active tool will be selected before resurrect-prologue.g is called?

If that is the case all I have to do is to wait for RRF 2.04 RC3 and thank you very much! If that is not the case I would wish for that or an option to access the last active temperature that was used for the active tool before the build job was interrupted.

Thanks a lot for the support and the great products you are developing together with the community.

Best regards
Christian

undefined

Hi,

I am running RRF 2.03 on a Duet 2 Ethernet (v1.04). I have a self-built machine with 2 extruders and a problem when recovering from a controlled shutdown.

With the current firmware it seems not to be possible to undo a retraction that was made during shutdown with the "resurrect-prologue.g" makro, as mentioned in the wiki (https://duet3d.dozuki.com/Wiki/Setting_up_to_resume_a_print_after_a_power_failure) :
"If your power fail procedure in the M911 command retracts filament and your printer has a single nozzle, you may wish to undo the retraction."

In my case I want to undo the retraction from a controlled shutdown, so M911 was not called. But that should make no difference.

The reason I can't undo the retraction is, that I can't perform a retraction in resurrect-prologue.g when no tool is selected (or heated). Because in the current firmware the sequence of the commands in resurrect.g have changed. As mentioned in the changelog for RepRapFirmware 2.03 (released 13 Jun): https://github.com/dc42/RepRapFirmware/blob/dev/WHATS_NEW.md
The relevant bulletpoint is:

In resurrect.g, the current tool is now selected after running resurrect-prologue, and its tpre and tpost files are run (for tool changer)

Just for clarification. This is the resurrect.g file that is generated by my printer:

; File "0:/gcodes/interrupted_print.gcode" resume print after print paused at 2019-10-03 22:23
G21
M141 P0 S0.0
G29 S1
T-1 P0
G92 X76.986 Y100.320 Z3.100
G60 S1
M98 P"resurrect-prologue.g"
M116
M290 X0.000 Y0.000 Z0.000 R0
G10 L2 P1 X0.00 Y0.00 Z0.00
G10 L2 P2 X0.00 Y0.00 Z0.00
G10 L2 P3 X0.00 Y0.00 Z0.00
G10 L2 P4 X0.00 Y0.00 Z0.00
G10 L2 P5 X0.00 Y0.00 Z0.00
G10 L2 P6 X0.00 Y0.00 Z0.00
G10 L2 P7 X0.00 Y0.00 Z0.00
G10 L2 P8 X0.00 Y0.00 Z0.00
G10 L2 P9 X0.00 Y0.00 Z0.00
G54
G10 P1 S200 R0
G10 P0 S215 R215
T0 P6
M106 S0.00
M106 P2 S0.00
M106 P3 S0.00
M106 P4 S0.00
M106 P5 S0.00
M106 P6 S0.00
M106 P7 S0.00
M106 P8 S0.00
M116
G92 E0.00000
M83
M23 "0:/gcodes/interrupted_print.gcode"
M26 S2285966 P0.000
G0 F6000 Z5.100
G0 F6000 X76.986 Y100.320
G0 F6000 Z3.100
G1 F2133.3 P0
G21
M24

As you can see the used tool is selected and heated after resurrect-prologue.g was called.

Now my question / bug report / wish for the next release:
Is there a way to work around that issue? Is there a way to select the right tool (of the interrupted print), set the right temperatures (for the interrupted print) and undo the retraction before resuming the print?

Thanks a lot and best regards
Christian