I just noticed that I often get an invalid password message when it disconnects. I disabled the password and this has stopped. Now, I am getting "Network error, failed to get file list." Or just "Connection Interrupted Network Erro."

Over the last couple of weeks I have been having difficulty with my Duet Ethernet dropping connection. I have frequently updated the firmware to development and release versions. I just updated to the newest V2 release this morning, including the appropriate DWC. Below is a diagnostic output. I have tried both Chrome and Edge with the same problem. Oddly, I am able to upload large files from the Cura addon but not able to complete uploading of any files through DWC. I have not seen any packet loss when trying to ping the printer either. I have a ticket in with the IT department here to see if there are any network related issues as well but thought I would see if there is anything obvious here too.

I can establish a connection for a short period of time (maybe 10 seconds) and then it drops, reconnects, and repeats.

11/4/2019, 11:05:33 AM M122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 2.04 running on Duet Ethernet 1.02 or later + DueX5
Board ID: 08DDM-9FAM2-LW4SD-6JTDL-3S86R-KJW3X
Used output buffers: 3 of 24 (19 max)
=== RTOS ===
Static ram: 25680
Dynamic ram: 93868 of which 0 recycled
Exception stack ram used: 440
Never used ram: 11084
Tasks: NETWORK(ready,628) HEAT(blocked,1176) DUEX(suspended,160) MAIN(running,3768) IDLE(ready,200)
Owned mutexes:
=== Platform ===
Last reset 00:03:54 ago, cause: software
Last software reset at 2019-11-04 11:01, reason: User, spinning module GCodes, available RAM 11108 bytes (slot 3)
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0441f000 BFAR 0xe000ed38 SP 0xffffffff Task 0x4e49414d
Error status: 0
Free file entries: 8
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest block write time: 0.0ms, max retries 0
MCU temperature: min 26.9, current 27.1, max 27.4
Supply voltage: min 24.2, current 24.4, max 24.5, under voltage events: 0, over voltage events: 0, power good: yes
Driver 0: standstill, SG min/max not available
Driver 1: standstill, SG min/max not available
Driver 2: standstill, SG min/max not available
Driver 3: standstill, SG min/max not available
Driver 4: standstill, SG min/max not available
Driver 5: standstill, SG min/max not available
Driver 6: standstill, SG min/max not available
Driver 7: standstill, SG min/max not available
Driver 8: standstill, SG min/max not available
Driver 9: standstill, SG min/max not available
Date/time: 2019-11-04 11:05:32
Cache data hit count 540492097
Slowest loop: 2.63ms; fastest: 0.07ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
=== Move ===
Hiccups: 0, FreeDm: 160, MinFreeDm: 160, MaxWait: 0ms
Bed compensation in use: none, comp offset 0.000
=== DDARing ===
Scheduled moves: 23, completed moves: 23, StepErrors: 0, LaErrors: 0, Underruns: 0, 0
=== Heat ===
Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1
Heater 0 is on, I-accum = 0.0
Heater 1 is on, I-accum = 0.7
=== GCodes ===
Segments left: 0
Stack records: 4 allocated, 1 in use
Movement lock held by file
http is idle in state(s) 0
telnet is idle in state(s) 0
file is doing "M116 P0" in state(s) 0 12
serial is idle in state(s) 0
aux is idle in state(s) 0
daemon is idle in state(s) 0
queue is idle in state(s) 0
autopause is idle in state(s) 0
Code queue is empty.
=== Network ===
Slowest loop: 8.59ms; fastest: 0.04ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0)
HTTP sessions: 1 of 8
Interface state 5, link 100Mbps full duplex

@dc42 Would it make sense to apply the same logic to M221? My flowrate multipliers vary with material, not with which drive it is in. The tension arms on my drives are generally fixed all the same (occasionally, I adjust one if I am using a very soft material). Having the same fixed tension arms in the same type of drives means that the hardness of the filament is the true source of flow rate multiplier variation.

I am trying to set the pressure advance by placing it within the Filament config file. However, it seems that right now M572 requires a drive number to be included in order to assign the pressure advance. Could this be changed so that if there is no drive number, it is assigned to the (all) drive(s) for the active tool?

I am doing this because, in my experience with all mechanical variables held constant (nozzle diameter, extruder type), and varying the material or just the color of a material may be cause for different pressure advance values.

I've been using 2.02 for a few days now and have not noticed any issues myself.

I just installed the new DWC while exploring it, I realized that the new FW also has a way to set material parameters on the machine. I'm really excited to migrate all of my machine/material combo specific firmware parameters out of the slicer and into the machine. This should make it much easier to use various slicers (currently I can only use KISSlicer with my configuration system) while maintaining a well-automated system of parameters for machine/material combos. Thanks for all of your work David!

@dc42 said in Add Drive/Extruder Parameter to M207:

It sounds like per-tool is the way to go, but this feature still needs to be specified. Assuming that I add an additional parameter to specify the tool number:

• Should a M207 command that doesn't specify a tool number affect only the current tool? Or all tools? Or something else?

If no parameter is given it should be the global default but not overwrite any tools that were explicitly configured. This way M207 can be in config.g without a tool parameter to give a good starting point for all tools or just to set them for single extrusion setups or users who do not have independent settings for materials. Then, the beginning of a gcode file would include the more specific configuration depending on what is set in the slicer custom gcode. This would also allow for the current behavior to be mimicked if no tool numbers are ever specified.

If a second print is run without resetting the firmware, then the second file would contain the specific M207 tool configs for that print and update them as needed.

• When a new tool is created, what M207 parameters (if any) should it inherit?

I think it should inherit the global default since this is how the current implementation would behave.

I don't want to break the current behavior as it is working well for me now and I know for other people. I just want to add the possibility of having it be configured per tool to allow me to expand into other slicers while still reducing the amount of manual configuration I have to do for each print/material.

For the filament switches/monitoring maybe only allowing faults/pauses to be flagged when the associated drive is in use would work. That way all monitoring could be turned on/configured at all times but should only ever cause a pause to occur if the firmware tried to use a drive that didn't have filament. This way filament does not have to be present in monitors which are not being used for a print or monitors do not have to be turned on/off for each print.

@dc42 For what I am trying to achieve (having the slicer insert custom parameters for each tool at the beginning of the print and only once), per-tool would be just fine. If it were per-drive, I should be able to make it work too.

If two drives have differing z-hop, I would think using the greater of the two would be safest.

I think for mixing hardware, people are probably using setups in which the drive hardware is all similar enough to do per-tool. I do not know of anyone blending different base materials so I would think that using the same retraction for all drives, in this case, would be okay.

In my experience, retraction settings are much more closely related to the material properties than hardware, assuming all drive hardware is similar. Therefore, I have my toolchain set up to include the custom firmware retraction settings for each material automatically in a section of the slicers custom G-codes. In Kisslicer I put this in the Material tab and then call that material Gcode at each tool change before the Duet runs its tool change scripts. This gets tricky though with anything other than Kisslicer.

Putting M207 in the tool change files would mean I would have to remember to change the retraction for each material manually.

Ultimately, I would like if slicers provided an easy way to tell the firmware what material is being used and where so that the firmware would contain a configuration file for each material and the firmware gets auto-configured for that material, or maybe even replaces certain Gcode parameters with the variables stored in that file. My thoughts are that temperatures, M572, M207, and similar parameters could be stored in this file. Along with this, I would also like if the slicers and firmware could automatically enable and disable the filament monitoring for a drive that is being used or not being used appropriately.

With multiple extruders and materials, it would be nice to be able to associate M207 with a specific extruder/drive since some materials require more or less retraction and differing drive and hot end hardware within a machine may require differing retraction. The parameter could be optional so that if it is included in a command, it is only for a specific drive but if not included it is applied to all drives like it currently is.

In my case, this would allow material specific custom Gcodes (I include M207 and M572 to be inserted only at the beginning of a file. (Currently I have to run the Kisslicer Matl gcodes every tool change in order to have the proper retraction for each material. In turn this would open up more compatibility with other slicers as Kisslicer is the only one that inserts the material specific Gcodes whenever the token is called (in this case I insert it into the custom tool change gcode). I know other slicers have scripting that could post-process the code and add this but this would be a cleaner solution.

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