Posts made by BMMal

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

@t3p3tony

Yes. M119 does not give any information about the filament switches. Only X, Y, Z, Zprobe.

With filament present, the machine properties tab does properly indicate that they have not been triggered with "No" though. I can't really check with filament absent right now since the machine is printing but last time I checked the statuses when figuring out how to configure the switches it did work properly.

Sometimes when an extruder runs out of filament, the trigger does not clear after reloading the filament. The machine runs the pause and resume scripts as it should but immediately after resuming, it pauses again due to filament out. Disabling the sensor, resuming, and then reenabling seems to be ok though.

I have also noticed that if an extruder runs out of filament and DWC disconnects at some point, the Filament out message will reappear every time DWC is reconnected even though I had closed the message window.

I am running:

Firmware Name: RepRapFirmware for Duet 2 WiFi/Ethernet
Firmware Electronics: Duet Ethernet 1.02 or later + DueX5
Firmware Version: 2.01beta1(RTOS) (2018-06-23b1)
Web Interface Version: 1.21.2-b2

To expand further on my issue of not getting responses, it seems that DWC is somehow getting out of sync but not disconnecting ie, a print was started and it did not automatically go to the Print Status screen. DWC still indicated that the machine was connected. I made a change to config.g, the file got updated (confirmed by looking after saving) and DWC asked if I wanted to reboot as if the machine was not printing even though it was. Manually going to the status page, it did not appear that the machine was printing. Refreshing the browser did however update properly.

@dc42 said in It's out! RepRapFirmware 2.0 and 1.21.1 released:

Are you sure? I have just compared the documentation with the code and they agree:

P1 - high when filament present, low when no filament
P2 - low when filament present, high when no filament

I was not getting responses from M122 or even M572. I disconnected DWC and could not reconnect.

After power cycling the machine, these are the diagnostics:
...

Sadly the diagnostics don't indicate anything wrong. If it happens again, if possible please connect via USB and YAT/pronterface etc. and see if you can get a M122 report that way without restarting.

I think someone below figured out my confusion between the m591 response and the wiki info.

I came in this morning and had the same issue where the machine did not give a response to M122 via DWC. I connected with YAT without resetting the machine. Not sure how to get YAT to better format the response but here it is:

=== Diagnostics ===<LF>RepRapFirmware for Duet 2 WiFi/Ethernet version 2.0(RTOS) running on Duet Ethernet 1.02 or later + DueX5<LF>Board ID: 08DDM-9FAM2-LW4SD-6JTDL-3S86R-KJW3X<LF>Used output buffers: 1 of 20 (16 max)<LF>=== RTOS ===<LF>Static ram: 28380<LF>Dynamic ram: 96552 of which 0 recycled<LF>Exception stack ram used: 468<LF>Never used ram: 5672<LF>Task NETWORK ready, free stack 324<LF>Task HEAT blocked, free stack 1200<LF>Task MAIN running, free stack 3568<LF>=== Platform ===<LF>Last reset 14:29:18 ago, cause: power up<LF>Last software reset at 2018-06-05 17:43, reason: User, spinning module GCodes, available RAM 5864 bytes (slot 1)<LF>Software reset code 0x0003 HFSR 0x00000000, CFSR 0x00000000, ICSR 0x0041f000, BFAR 0xe000ed38, SP 0xffffffff<LF>Error status: 24<LF>Free file entries: 9<LF>SD card 0 detected, interface speed: 20.0MBytes/sec<LF>SD card longest block write time: 0.0ms<LF>MCU temperature: min 26.8, current 27.3, max 27.5<LF>Supply voltage: min 24.1, current 24.3, max 24.5, under voltage events: 0, over voltage events: 0<LF>Driver 0: standstill, SG min/max not available<LF>Driver 1: standstill, SG min/max not available<LF>Driver 2: standstill, SG min/max not available<LF>Driver 3: standstill, SG min/max not available<LF>Driver 4: standstill, SG min/max not available<LF>Driver 5: standstill, SG min/max not available<LF>Driver 6: standstill, SG min/max not available<LF>Driver 7: standstill, SG min/max not available<LF>Driver 8: standstill, SG min/max not available<LF>Driver 9: standstill, SG min/max not available<LF>Expansion motor(s) stall indication: yes<LF>Date/time: 2018-06-06 08:14:33<LF>Slowest loop: 4.38ms; fastest: 0.09ms<LF>=== Move ===<LF>Hiccups: 0, StepErrors: 0, LaErrors: 0, FreeDm: 240, MinFreeDm 240, MaxWait: 0ms, Underruns: 0, 0<LF>Scheduled moves: 12, completed moves: 12<LF>Bed compensation in use: none<LF>Bed probe heights: 0.000 0.000 0.000 0.000 0.000<LF>=== Heat ===<LF>Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1<LF>Heater 0 is on, I-accum = 0.0<LF>=== GCodes ===<LF>Segments left: 0<LF>Stack records: 4 allocated, 0 in use<LF>Movement lock held by null<LF>http is idle in state(s) 0<LF>telnet is idle in state(s) 0<LF>file is idle in state(s) 0<LF>serial is ready with "m122" in state(s) 0<LF>aux is idle in state(s) 0<LF>daemon is idle in state(s) 0<LF>queue is idle in state(s) 0<LF>autopause is idle in state(s) 0<LF>Code queue is empty.<LF>=== Network ===<LF>Slowest loop: 1.03ms; fastest: 0.01ms<LF>Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0)<LF>HTTP sessions: 0 of 8<LF>Interface state: 5<LF>=== Filament sensors ===<LF>Extruder 0 sensor: no filament<LF>Extruder 2 sensor: ok<LF>=== Expansion ===<LF>DueX I2C errors 0<LF>ok<LF>

Minor issue but, I think there is a discrepancy between the description of the M591 P parameter between the wiki and what the description of what the firmware reports is configured (for example when M591 D0 is sent). Ie P1 high/low conditions and P2 high/low condition. It would also be good if the wiki was explicit about which values are acceptable for C, especially that 5-9 on a Duex do not work but 10 and 11 do.

I was not getting responses from M122 or even M572. I disconnected DWC and could not reconnect.

After power cycling the machine, these are the diagnostics:

M122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 2.0(RTOS) running on Duet Ethernet 1.02 or later + DueX5
Board ID: 08DDM-9FAM2-LW4SD-6JTDL-3S86R-KJW3X
Used output buffers: 3 of 20 (15 max)
=== RTOS ===
Static ram: 28380
Dynamic ram: 96480 of which 0 recycled
Exception stack ram used: 348
Never used ram: 5864
Task NETWORK ready, free stack 396
Task HEAT blocked, free stack 1224
Task MAIN running, free stack 3568
=== Platform ===
Last reset 00:00:25 ago, cause: power up
Last software reset at 2018-06-05 17:18, reason: User, spinning module GCodes, available RAM 5864 bytes (slot 0)
Software reset code 0x0003 HFSR 0x00000000, CFSR 0x00000000, ICSR 0x0441f000, BFAR 0xe000ed38, SP 0xffffffff
Error status: 0
Free file entries: 9
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest block write time: 0.6ms
MCU temperature: min 25.6, current 27.9, max 28.1
Supply voltage: min 24.1, current 24.3, max 24.4, under voltage events: 0, over voltage events: 0
Driver 0: standstill, SG min/max 0/668
Driver 1: standstill, SG min/max 0/698
Driver 2: standstill, SG min/max 0/569
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
Expansion motor(s) stall indication: no
Date/time: 2018-06-05 17:41:04
Slowest loop: 7.27ms; fastest: 0.08ms
=== Move ===
Hiccups: 0, StepErrors: 0, LaErrors: 0, FreeDm: 240, MinFreeDm 235, MaxWait: 936212058ms, Underruns: 0, 0
Scheduled moves: 11, completed moves: 11
Bed compensation in use: none
Bed probe heights: 0.000 0.000 0.000 0.000 0.000
=== Heat ===
Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1
Heater 0 is on, I-accum = 0.0
=== GCodes ===
Segments left: 0
Stack records: 4 allocated, 0 in use
Movement lock held by null
http is idle in state(s) 0
telnet is idle in state(s) 0
file is idle in state(s) 0
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.06ms; fastest: 0.01ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0)
HTTP sessions: 1 of 8
Interface state: 5
=== Expansion ===
DueX I2C errors 0

I was several hours into a long print when the machine appears to have missed a portion of a travel move mid-layer. The move was mostly in Y but also had an X component. It does not appear that any steps were missed in the X direction but about 18.5-19mm worth of steps were missed in Y. It might be coincidental but my Y offset for the tool active when this happened is -18.5.

It's likely some mechanical problem but at this point but I'm not sure if there is anything meaningful in the diagnostics below.

M122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 2.0(RTOS)RC6 running on Duet Ethernet 1.02 or later + DueX5
Board ID: 08DDM-9FAM2-LW4SD-6JTDL-3S86R-KJW3X
Used output buffers: 3 of 20 (12 max)
=== RTOS ===
Static ram: 28380
Dynamic ram: 96516 of which 0 recycled
Exception stack ram used: 420
Never used ram: 5756
Task NETWORK ready, free stack 324
Task HEAT blocked, free stack 1200
Task MAIN running, free stack 3560
=== Platform ===
Last reset 05:57:03 ago, cause: software
Last software reset at 2018-06-04 10:05, reason: User, spinning module GCodes, available RAM 5672 bytes (slot 0)
Software reset code 0x0003 HFSR 0x00000000, CFSR 0x00000000, ICSR 0x0441f000, BFAR 0xe000ed38, SP 0xffffffff
Error status: 24
Free file entries: 9
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest block write time: 762.6ms
MCU temperature: min 24.6, current 26.9, max 27.9
Supply voltage: min 24.0, current 24.4, max 24.6, under voltage events: 0, over voltage events: 0
Driver 0: standstill, SG min/max 0/1023
Driver 1: standstill, SG min/max 0/1023
Driver 2: standstill, SG min/max 0/1023
Driver 3: standstill, SG min/max 0/1023
Driver 4: standstill, SG min/max not available
Driver 5: standstill, SG min/max 0/1023
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
Expansion motor(s) stall indication: yes
Date/time: 2018-06-04 16:02:25
Slowest loop: 821.33ms; fastest: 0.08ms
=== Move ===
Hiccups: 0, StepErrors: 0, LaErrors: 0, FreeDm: 240, MinFreeDm 150, MaxWait: 4058580675ms, Underruns: 0, 0
Scheduled moves: 12, completed moves: 12
Bed compensation in use: none
Bed probe heights: 0.000 0.000 0.000 0.000 0.000
=== Heat ===
Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1
Heater 0 is on, I-accum = 0.0
=== GCodes ===
Segments left: 0
Stack records: 4 allocated, 0 in use
Movement lock held by null
http is idle in state(s) 0
telnet is idle in state(s) 0
file is idle in state(s) 0
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: 821.33ms; fastest: 0.01ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0)
HTTP sessions: 1 of 8
Interface state: 5
=== Filament sensors ===
Extruder 0 sensor: ok
=== Expansion ===
DueX I2C errors 0

Are you using firmware retraction in the slicer? If so, please run M207 without parameters and confirm that it says there is zero Z hop configured. Also please provide a sample of the GCode that demonstrates this.

Do you have mesh bed compensation enabled, and if so, could the "Z hop" be the normal action of bed compensation?

Looks like the slicer was adding an extra z move due to the z shrink compensation feature in it and it happened to line up with the retraction timing. This isn't a firmware issue. Sorry for the confusion.

Are you using firmware retraction in the slicer? If so, please run M207 without parameters and confirm that it says there is zero Z hop configured. Also please provide a sample of the GCode that demonstrates this.

Do you have mesh bed compensation enabled, and if so, could the "Z hop" be the normal action of bed compensation?

Yes I am using FW retract. I did confirm that it reported the Z parameter set to 0. I do not use bed compensation.

I am going to do some more investigation. It looks like some of what I was seeing may have been some how related to the Z shrink compensation in KISSlicer. I need to run with that turned off. I'll report shortly.

I just noticed that my machine is adding Z-hop even though I have set M207 Z0. There is no Z-hop turned on in the slicer nor in the G-code being printed.

I tried increasing to M207 Z1 and the machine did increase the amount of movement. I then resent M207 Z0 and it went back to some small fraction of a mm but can't tell how much it is.