@dc42 Yes the disconnections are due to Timeout.
I have noticed that I do not have a M350 Set micro stepping entry in config. So the default must be used which I believe is 16x. I have now made the entry just in case.

@flyingscot Apart from all the usual improvements and bugfixes that come with every new version of RRF the upgrade to 2.x also brought RTOS as a basis. This stands for Real-Time Operating System and allows tasks to be very strictly constrained in when and how often they need to run, e.g. to have a very close and strict check on temperatures.

@dc42 Thank You Sir. Got to this IP screen, could not for the life of me describe this accomplishment, just grateful it has occured and yes I belive in a higher power! 0_1532715442412_2018-7-267 Duet on IP success..jpg Will proceed with details.

@dc42 Thanks for the Help! Got it working how we want it. M552 S2 working like a charm, didn't know about S2.

Hi,

Thank you for the prompt response.

The first approach (uploading DWC.ZIP) worked fine.

Much appreciated.

Frederick

I have to agree with David. H300 will instruct the machine to try to begin 300mm above the probing point, which is unnecessary, might be impossible given the z height available and will be time consuming. Sure setting it to 50 (or 20) might make sense if you've just changed something which affects the max Z height, such as slid in a new bed of differing thickness or changed delta arms etc... and this will ensure head crashes are less likely. Also probing from 300mm above relies on your machine to be extremely accurate and repeatable over that 300mm.

Also consider changing G31 P1000 to P100 this is for digital probes a debounce interval and it need not be as long as that.
Many are getting better results with M558 P8 which removes the debounce filtering altogether.

I have found using the latest builds, the multitouch probing options offer a greater sense of accuracy, in that it will throw an error and abandon calibration if multiple probes of each point are not consistent. This prevents a problem such as a loose probe or wobbly bed, generating a nonsense calibration and the resulting craziness that can ensue.

M558 P5 I1 R0.4 F1000 X0 Y0 Z0 H7 A5 S0.02 B1

F1000 - 1000 mm/min travel speed between probing points
H7 - dive height 7mm, enough if things basically stay the same between probing sessions
A5 - probe each point 5 times at most
S0.02 - Tolerance so if probe 2 is within 0.02 of probe 1 then the firmware moves to the next probing point, otherwise it tries again up to 5 times (A5)
B1 - turn off bed heater when probing. Seems to make a difference for some - I haven't made my mind up yet.

I am now seeing filament triggers occurring when the filament does not actually run out. Doing nothing other than hitting resume seems to palate it for a while. How long is unpredictable. I thought it might be related to my Tool Change gcode including the filament sensor config on every tool change but that does not seem to be the case...

It only happens on one extruder and not the other that is being used. Best I can tell the switch is properly closed and even biased beyond closed so even if the filament moves around a bit it could not conceivably open the switch.

The only times I've observed these issues are when I do not reset the machine between prints that have completed, but not necessarily every time.

My start.g has this section:

;Disable the filament out triggers
M591 D0 S0
M591 D1 S0
M591 D2 S0
M591 D3 S0

then the slicer tool change gcode calls a macro for the proper filament trigger when a tool is selected, this is redundantly repeated at every tool change. M98 P/macros/<EXT>_Config_T<EXT>_Trigger

;Configure the E3 Endstop input

M591 D2 P2 C5 S1
;M591 D2 S0

The expand a bit:

1st Generation Duets are called 0.6 and 0.8.5
2nd Generation Duets are DuetWifi and DuetEthernet, and recently the Duet Maestro.

https://duet3d.dozuki.com/Wiki/Hardware_Overview#Section_Version_History

I think you may want to use workplace coordinates. See the descriptions of G10 (subfunction L20) and G53-G59 in the GCodes page of the wiki.

@dc42 said in connection issues:

r best results, configure Octoprint not to wait for OK after sending each command. I know someone did a patch to make this possible many months ago but I don't know whether it is a standard feature of the current release

THANK YOU!!!!!!

M555 P2 did the trick!! Wow what a quick response 🙂 Again, much appreciated!!

Thanks for your report. On the Duet rev 1.04 we should be able to tell the difference between a watchdog reset and the reset button, but on the older Duets we can't. Unless something is fouling the reset button on your Duet, it's probably a watchdog reset. What's odd is that there is a second watchdog that normally goes off before that one, and it hasn't in this case.

@mlaustin6 said in Downgrading firmware:

Does this still apply if you are on firmware 2.01 beta 2 and want to go back to 2.0 non beta? Same with the web software? Wifi server seemed unchanged.

No. The two cases where firmware upgrade/downgrade isn't straightforward are:

On the Duet WiFi, changing between 1.18 or earlier and 1.19 or later (because the wifi server was moved off the WiFi module on to the main processor in 1.19).

On the Duet WiFi and Duet Ethernet, changing between 1.20 or earlier and 1.21 or later (because the firmware filename expected by the firmware changed to Duet2CombinedFirmware in 1.21).

My bad: I did have a call to my end.g macro from Slic3r, but for some reason, the profile was corrupted...

Thanks.

Yes, please try 2.02beta2.

Ahhh... great point guys. I was not clear about UPDATING from the SD. I phrased like you can just moved the card and that puts the firmware on the new board... not true.

So, to re-summarize: (everybody probably gets this... but just in case... )

config.g is loaded from SD every time a board power cycles or otherwise boots.

config-override.g is loaded from SD every time an M501 is executed, and therefore would be loaded at power cycle and/or boot ONLY if the config.g contains an M501 (preferably somewhere near the end)

Other "whatever.g" files are loaded from SD as various events occur, like tool change, or print cancel, or...

Therefore, swapping an SD around different boards effectively "instantly updates" all the various ____.g files on the SD.

Duet/Reprap Firmware is on the SD. However, firmware RUNS (executes) from Processor flash.
Similarly, WiFi Firmware is on the SD but runs from flash in the WiFi module.

Updating Processor and/or WiFi flash can be accomplished via:
A) Uploading a properly named file via Duet Web Control (and clicking "yes" if prompted)
B) Placing a properly named file in the /sys directory of the SD card, and then issuing specific M commands.
C) Using a combination of USB, SAM-BA, and hardware reset/erase buttons.

The required names and exact steps are detailed in the various "Fallback procedures".

Yup dead sdhc. New card is working appropriately. Thanks.

I have added DWC 1.21.2-b2.zip to this beta release. I had already removed DWC 1.21.1-b1 from it.

I received a new duet wifi and everything works fine. The sd card reader was not functioning.
In an other thread new problems with the router I used. The card is fine.