mesh grid compensation crashing dwc

dc42

@monster-delta, I just wanted to let you know that I haven't forgotten about this issue, but I find it puzzling and right now I am out of ideas

Monster Delta

@dc42 no worries there's no real rush the printer is working fine appart from this issue.

dc42

@monster-delta said in mesh grid compensation crashing dwc:

once i start mgc i cant get m122 to work

Do you mean that M122 doesn't even work if you send it from USB?
Please can you temporarily double the mesh spacing to 54.0 and try again. I am wondering whether the fact that you are using the maximum number of points is related to the problem.

Monster Delta

yes thats correct m122 doesnt even work through usb. i have tried double triple ad quad roupling the mesh spacing its exactly the same

dc42

Can you confirm that the only command you send to do mesh probing is G29?
Does the G29 command write a new heightmap.csv file to the SD card? If so, after restarting the Duet, are you able to load that height map using G29 S1 without provoking this problem? And are you able to use the "View height map" function of DWC without any problems?
If loading an existing height map using G29 S1 works, are you able to save it again using M374 https://duet3d.dozuki.com/Wiki/Gcode?revisionid=HEAD#Section_M374_Save_height_map without getting a disconnection?

I'd like to get to the bottom of this problem before I do the 2.02 release. The above tests should help determine whether it is probing, saving the height map to file, or activating it that is causing the problem.

PS - also, please check in the DWC Settings General page that you really are running RRF 2.02RC4, DWS 1.21 and DWC 1.22.5.

Monster Delta

once the connection crashes the probing continues to the end and it saves the height map to the sd card and i am able to load it and use it. the crash occurs not as soon as i start probing but after a few probe points. i can confirm that i am using the latest firmwares and dwc releases

dc42

Ah OK, I see now that in your first post you said the disconnect occurs half way through probing.

What type of Z probe is it? Do you have any deployprobe.g or retractprobe.g files in /sys on the SD card?

dc42

PS - also, are you initiating probing from DWC? if so, do you still get a disconnect if you initiate it from USB or PanelDue instead?

Monster Delta

the z probe is the smart effector and i don't have any deployprobe.g or retractprobe.g. if i deploy using usb i get the same problem but if i have the paneldue connected everything woks as it should no matter how i start the g29 command

dc42

When you run it with the PanelDue disconnected, is the PanelDue cable still plugged into the Duet? I'm wondering whether it could be picking up noise.

I've just disconnected the PanelDue on my delta, powered up, homed the printer and run mesh bed probing from DWC. No problems. Then I increased the number of points to 11x11, probed again, and still no problems.

Monster Delta

Yes the cable is still pluged in. I'll unplug it and try again

Monster Delta

i unplugged the cable and the problem went away i plugged the cable back in as before and the issue did not return. thankyou for your help

dc42

@monster-delta, I am surprised that leaving the cable connected caused a problem. Please can you tell me what type it is (the ribbon cable or the 4-way cable), and how long it is?

Monster Delta

Its the ribbon cable that was supplied with the paneldue. I was suprised aswell and would of never thought to remove it but it worked and i don't seem to be able to recreate the issue but might be worth putting a note in the wiki to be on the safe side

dc42

In that case it was probably caused by the high capacitance of the ribbon cable. Something probably caused data to be written to PanelDue, and that was likely being coupled back into the receive wire through the cable capacitance. The received data probably caused an error message, and the cycle repeated. I have seen this happen on computers. But I am surprised it caused network disconnections.