@primal dove DWC disconnected from network access, i tried to ping it from my PC, no connection, i could ping other devices on my network ok
#DWC disconnect
primal dove
With problems like this we really need a simple reproducible case and we need to be able to see the M111 debug output. At the moment with all that you have going on in that log file that is pretty much impossible. In a previous post you mentioned that you made changes to your router and lost an ethernet connection, but this does not seem to be that problem, is this something new/different?
I'd suggest that you clean up whatever is spamming your USB output with all of this stuff about Daemon.g. You also seem to be spamming the USB output with M122 output, why is that? It really is pretty much impossible to understand what is going on here.
lament thicket
it looks like the disconnect before was a coincidence , this time the disconnect happened in the middle of a print . so i connected the usb lead to get the info above. the M122 i manually requested as per your request to do after the
m552 s-1
m111 P14 S1
m552 s1 p"ethernet"
i might have the log file on my sd card as its been running for a while i have a look
lament thicket
just this
and this in the log when i rebooted the control board
2025-03-01 12:16:55 [debug] Debugging On
power up + 00:00:00 [info] Event logging started at level debug
power up + 00:00:00 [info] Running: STM32F4: 3.6.0-beta.4 (2025-02-11 17:31:34)
power up + 00:00:01 [debug] HTTP is enabled on port 80
power up + 00:00:01 [debug] FTP is disabled
power up + 00:00:01 [info] G10 P0 X0 Y0 Z0
power up + 00:00:01 [info] G10 P0 R0 S0
power up + 00:00:01 [debug] home_maz_Z.g
power up + 00:00:01 [debug] Bed has landed
power up + 00:00:01 [info] G10 P0 X0 Y0 Z0
power up + 00:00:01 [debug] tool
power up + 00:00:01 [debug] Done!
power up + 00:00:01 [debug] RepRapFirmware for STM32F4 based Boards is up and running.
power up + 00:00:02 [debug] Damon running
power up + 00:00:02 [debug] BiQu + flintZone sensor + NF Crazy 0.6mm
power up + 00:00:02 [debug] Debugging On
power up + 00:00:02 [debug] Dry box Fan & Heater Off
power up + 00:00:02 [debug] 2
power up + 00:00:02 [debug] 5
power up + 00:00:02 [debug] null
power up + 00:00:04 [warn] WiFi module started
power up + 00:00:07 [warn] WiFi module is connected to access point ethernet, IP address 192.168.0.102
power up + 00:00:08 [warn] HTTP client 192.168.0.197 login succeeded (session key 283094272)
2025-03-01 12:17:14 [warn] Date and time set at power up + 00:00:08
2025-03-01 12:17:15 [warn] HTTP client 192.168.0.172 login succeeded (session key 1289151399)
2025-03-01 12:17:16 [warn] HTTP client 192.168.0.197 login succeeded (session key 805048410)
2025-03-01 12:17:18 [debug] Damon running
2025-03-01 12:17:18 [debug] BiQu + flintZone sensor + NF Crazy 0.6mm
2025-03-01 12:17:18 [debug] Debugging On
2025-03-01 12:17:18 [debug] Dry box Fan & Heater Off
primal dove
That just looks like it is all working fine.
As above to have any chance of working out what is going on I really need to be able to see (and read!), the output from running M552 s1 p"ethernet" with debug enabled.
lament thicket
reset logging so module 14 is always logged , got rid of most of the other crap being logged , im printing in the next 2 days
primal dove
You will need to have a USB terminal connected (and if you are using putty I would recommend turning on the option to write all of the output to a file), the debug from M111 does not get logged in any other way.
lament thicket
havnt been printing today but have been checking that the putty.log file was working ok are these normal
lament thicket
ive noticed that the sientific notataion hasnt gone away yet, who do i need to send that too
started a print in the console, it looks like all this may have been triggered by a stop event and not an ethernet disconnect .
primal dove
I'm not sure what you mean by "a stop event"?
I don't see any sign of a problem in the putty output (other than the system being very busy).
You seem to have a lot going on here. How many DWC instances are you running? The "pend" message basically means that the network code found itself with more than 4 connections to the same listening socket, RRF typically only allows 4 connections to a service, like http.
As to the scientific notation I think the output you are seeing it being used in is different this time. Before it was in the output generated by RRF as a result of running G30, that seems to have been fixed. The output you are now seeing is I think coming from your bed.g script. At the moment the echo meta command (which I think is what you are using) does not provide any way to control how numeric values are formatted, so you get what you get. I'm not really sure what the problem is though it is displaying what the actual value is. If you want more control over formatting then put in a feature request. If it really bothers you you can probaly fix it your self by multiplying the result by say 1000 (if you want 3 decimal places), then use floor or ceil to convert it to an int followed by dividing the result of that by 1000.0 (to go back to a float) then print out that value.
I think overall your problem may be that RRF is just too busy. I'd suggest doing the following...
- Get rid of as much logging as you can, only report errors or odd things. So lose all of the stuff coming from daemon.g
- Avoid running multiple http clients
- Consider reducing the update rate of any http clients you do run
- Try and reduce the system load as much as you can, if you have things running in daemon.g try and have them do things less frequently.
What I really need to see is the M111 P14 S1 output when you are not able to connect to the board from DWC. ideally after running M552 s-1 M552 s1 p"ethernet"
lament thicket
ok, ill get on to all this tomorrow ,
the G32 is a strange one it does 2 round to get the bed trammed , the first round it does in mm the second time round it does in scientific notation
he is my bed.g code, worked fine in non beta version
; bed.g G32
echo "bed.g G32"
M118 P3 S"M118 bed.g" L1
M561 ; clear any bed transform
G31
echo "bed g31 start"
G90
; If the printer hasn't been homed, home it
if !move.axes[0].homed || !move.axes[1].homed
G28
if global.debugging = true
echo "line 10"
if sensors.probes[0].value[0] == 1000 ; if sensor is value other than 1000 do this, 0=probe attached
echo "already homed, going to pick up probe"
M98 P"/macros/ProbePickUp" ; probe pick up
if sensors.probes[0].value[0] == 0 ; Probe the bed and do auto calibration
G90
G1 X44 Y44 F6000 ; go to just above the first probe point
while true
if iterations = 5
M98 P"/macros/ProbeDropOff" ; probe drop off; end loop
abort "Too many auto calibration attempts"
G30 P0 X30 Y30 Z-99999 ; probe starboard bow
if result != 0
continue
G30 P1 X290 Y30 Z-99999 ; probe port bow
if result != 0
continue
G30 P2 X160 Y280 Z-99999 S3 ; probe port stern
if result != 0
continue
if move.calibration.initial.deviation <= 0.085 ;maximum deveation required
break
echo "Repeating calibration because deviation is too high (" ^ move.calibration.initial.deviation ^ "mm)"
echo "Auto calibration successful, deviation", move.calibration.final.deviation ^ "mm"
G1 F12000 X160 Y177.5 ; probe to center bed
G30 F600 ;Single Z-Probe set height
M98 P"/macros/ProbeDropOff" ; probe drop off
G1 Z20 F1000 ; get the head out of the way
primal dove
What is strange about it? As I said the output is coming from "your" code not RRF:
echo "Auto calibration successful, deviation", move.calibration.final.deviation ^ "mm"
and
echo "Repeating calibration because deviation is too high (" ^ move.calibration.initial.deviation ^ "mm)"
But in one case the number to be displayed is relatively "normal" 1.126 and in the other case it is very small 0.000000004311 or whatever. It is normal in the case of a small number like that to switch to scientific notation (unless told otherwise and there is no way to do that with the current echo). The gory details of how/when RRF makes that switch are all here:
https://github.com/Duet3D/RepRapFirmware/blob/3.6-dev/src/RepRapFirmware.cpp#L168
lament thicket
I suppose what I'm trying to say it's only in the beta versions that it's doing the scientific notations didn't do it in previous released versions, maybe they had a bug .
primal dove
What are you expecting the output to look like? Do you really want the number displayed as 0.000000004311?
Are you sure you were printing the same values (they almost certainly change every time you run the macro)? If you are then go back to the previous version and try just printing a very small value like the one above, then try the same code on the latest beta version. If you think the older one is "correct" then post on the Duet forum and provide the details. Personally I'd say the current version is correct.
lament thicket
So in previous versions it would show it as 0.000mm
It just rounded it out to 3 decimal places
primal dove
Are you sure that was the number being displayed by your script using echo rather than the numbers being displayed by RRF as part of the G30 commands? Because I don't think it is correct for the echo command to perform rounding on numbers it is asked to display, it has no way of knowing what sort of usage that number is for (unlike G30 where it knows the context of the number).
lament thicket
If I roll back to the release version , I'll document it all and post to the duet forum .
primal dove
If it was displaying 0.000 from an echo command on a value that was not zero I'd say that was a bug.
fp numbers can be much smaller than 0.000000004311 how would you display them if it always rounded them to zero?
lament thicket
This is why I mentioned it as it wasn't the same as I had been seeing previously . I need to capture this dwc disconnect first then I'll look into it more.
@primal dove is there away to query how many connections there are tp dwc
in putty
primal dove
M122 reports the number of http sessions:
HTTP sessions: 3 of 8
don't you know how many copies of DWC you have running?
lament thicket
M122 reports the number of http sessions:
```
HTTP sessions: 3 of 8
```
don't yo...
it says 4 but can only find 2, 1 on a pc. 1 on a laptop
primal dove
No idea I only have a single DWC session running and M122 reports:
HTTP sessions: 1 of 8
So if yours is reporting 4 then it looks like you have something else connected? Are you using anything else (like a slicer, or maybe a plugin), that may open extra connections? Can't really help, you need to shut everything down and work out where the connections are coming from.
lament thicket
No idea I only have a single DWC session running and M122 reports:
```
HTTP sess...
ill need to find them , i do have an esp sendeing data back to the OM
lament thicket
ive checked all the connection , i have just the PC connected via orca slicer in "Device" i have DWC
but still seeing
WiFi: ./src/Listener.cpp(252): pend connection on port 80 already 4 conns
in M122
HTTP sessions: 1 of 8
WiFi: Conns: 0:closePending 80, 60338, 192.168.0.172, 1:free, 2:free, 3:free, 4: free, 5:free, 6:free, 7:free
is it possible its not letting go of connections?
lament thicket
any idea what this is? this was in the putty log
SDIO Read 2086200 len 2 error 1 code 1
Error reading sector 2086200 length 2
primal dove
You can clearly see that it is "letting go of connections" because the per socket status is reporting all but one socket as free and one in the process of closing, if was not releasing them you would see more open sockets there.
As to the SDIO report it is reporting a problem with accessing the SDIO card. If you have not done anything odd (like removing the card while the board is active), then I would consider replacing the card with a new one.
If you have logging enabled (with M929) I would suggest you turn it off. Your system is already very busy and having something constantly writing to the SD card is not going to help with that.
I'd recommend these SD cards, though there are so many counterfeit cards around buying anything can be tricky. https://www.amazon.co.uk/dp/B073K14CVB
lament thicket
i never buy counterfeit cards i always buy samsung or kingston
i dont use M929 but i do run this macro at the end of a printed part
echo "history logged to sd card"
echo >>"history_job.g" state.time^ ",file," ^ job.file.fileName ^ ",elapsed time," ^ job.duration/60
echo "print time logged"
M98 P"/macros/printTime.g"
echo "stop.g file has run"
echo "printTime"
;if exists(job.lastDuration)
;if job.duration != null
set global.printTime = job.duration
set global.totalTime = global.totalTime + global.printTime
;echo >"totalValue.g" "global.totalTime = global.totalTime
echo >"totalValue.g" "set global.totalTime = " ^ global.totalTime
primal dove
If it's only running at the end of a print, that's unlikely to be an issue. What you want to avoid is something that is constantly writing to the SD card.
The problem with counterfeit cards is that it is very hard to identify them, buying a name brand is unfortunately no guarantee.
lament thicket
so this doesnt mean there a 4 connections
WiFi: ./src/Listener.cpp(252): pend connection on port 80 already 4 conns
lament thicket
The problem with counterfeit cards is that it is very hard to identify them, buy...
i buy from a camera shop 99% trust them 🙂
primal dove
Just remember that what may be good for a camera, may not be very good at all for a printer. We do very few writes to a disk and all of the I/O operations are relatively small compared to say streaming video to the card.
lament thicket
Just remember that what may be good for a camera, may not be very good at all fo...
this card is quite old , and it has been in a camera before when i upgrade my camera cards they go to the printer
primal dove
Keep an eye on these numbers over time:
SD card longest read time 14.6ms, write time 5.4ms, max retries 0
they may help spot if anything is going bad. But don't worry about it too much.
lament thicket
current status
SD card 0 detected
SD card longest read time 90.2ms, write time 85.9ms, max retries 1
lament thicket
today
SD card 0 detected
SD card longest read time 33.6ms, write time 30.0ms, max retries 0
lament thicket
todays putty
Dry box Fan & Heater Off
Dry box Fan & Heater Off
Resume state saved
Dry box Fan & Heater Off
Dry box Fan & Heater Off
Dry box Fan & Heater Off
WiFi: [0;31mE (18670330) esp.emac: emac_esp32_transmit(229): insufficient TX buf fer size[0m
WiFi: [0;31mE (18670330) esp.emac: emac_esp32_29): insufficient TX buffer size[0 m
WiFi: [0;31mE (18670361) esp.emac: emac_esp32_transmisufficient TX buffer size[0 m
WiFi: [0;31mE (18670420) esp.emac: emac_esp32_transmit(229): insufficient TX buf fer size[0m
Dry box Fan & Heater Off
Dry box Fan & Heater Off
Dry box Fan & Heater Off
Dry box Fan & Heater Off
Dry box Fan & Heater Off
Dry box Fan & Heater Off
Dry box Fan & Heater Off
Dry box Fan & Heater Off
Done printing file
Cancelled printing file 0:/gcodes/duct_PA-CF_47m35s.gcode, print time was 0h 30m
Dry box Fan & Heater Off
WiFi: Conns: 0:closePending 80, 62472, 192.168.0.172, 1:free, 2:free, 3:free, 4: free, 5:free, 6:free, 7:free
Dry box Fan & Heater Off
lament thicket
i also swapped out the sd card today just incase
SD card longest read time 5.5ms, write time 1.3ms, max retries 0
primal dove
What exactly is this showing? Did your print complete? Did you get any actual errors (from RRF rather than debug messages from the WiFi)? Have you done anything to reduce the load on the main mcu?
lament thicket
What exactly is this showing? Did your print complete? Did you get any actual er...
this happened during a print , this is from the Putty serial stream
WiFi: [0;31mE (18670330) esp.emac: emac_esp32_transmit(229): insufficient TX buf fer size[0m
WiFi: [0;31mE (18670330) esp.emac: emac_esp32_29): insufficient TX buffer size[0 m
WiFi: [0;31mE (18670361) esp.emac: emac_esp32_transmisufficient TX buffer size[0 m
WiFi: [0;31mE (18670420) esp.emac: emac_esp32_transmit(229): insufficient TX buf fer size[0m
the print finished ok
primal dove
My understanding is that that is just informational messages from the esp32 sdk, it does not indicate an error. It just means the transmission of the data will be delayed. How many devices/session do you have connected to the printer via the network? Where you doing anything unusual when that happened?
lament thicket
ive limited the connections to one for this testing, i didn't notice anything unusual happen while this was printing,
primal dove
No because the number you are displaying in the echo statement in the first case is the value after running the levelling operation (move.calibration.final.deviation), not the deviation before (move.calibration.initial.deviation), which is the number you have ringed. move.calibration.final.deviation is the second set of zeros in this output "after (0.000, 0.000)".
primal dove
As I've said before, if you think this is incorrect, please raise it on the Duet forum. I don't see any problem in displaying small values for things like a mean and deviation in engineering format. I'd rather see the actual value than have it rounded.
lament thicket
ok back to the disconnect