@dc42
I think it would be good to cancel the print if G29 or G32 fails, since they're important for some setups. Maybe any code that involves homing shouldn't be allowed to continue printing if it fails, but I'm not sure if that would be good for everyone. If G29 and G32 cancelled an SD print upon failure, i think it would be a good stopgap before conditional gcode comes.

I like the idea of a parameter to change the behavior too, but conditional gcode is probably a better solution anyway and if it's a lot of work it probably won't be worth it.

It could be that something could also be done to retry G32 in a different way after a failure of a certain type. For instance if the probe was already triggered on one corner, then move that side up by a couple mm and retry, but that could be done with conditional gcode probably. Also it might be a bit dangerous to do that since the machine could possibly rip itself apart, but w/e.

@phaedrux I'm already at 50% overlap and it still hasn't been fixed, so I'll be looking at my hardware I think.

@mrehorstdmd Nope, all lines except for where it starts and stops extrusion are equally spaced, at least by my eye.

The start and ends are misaligned though, but instead of with the long direction of each line, they're misaligned width wise. so like this ////// / instead of |||||l

All my belts and pulleys are tight so I'm gonna have a tough time finding any backlash.

Do you think a busted bearing could cause this behavior?

Been using my duetwifi based corexy for quite some time now, and I've just noticed that in some instances, the infill does not like to connect to walls. This seems like a motion planning thing to me, since I can't feel any backlash in the belts. The problem also only propagates in the same directions every time, it does not change like it should if there were backlash.

I've uploaded an image that shows the issue.

In the image, the long arms are along X and Y axes, and the short flats are on 45 degrees. The short sides that are on the top and the right side are the ones that have no connection between infill and perimeter, while the other sides seem properly connected.

any ideas?

@dc42
I think it would be good to cancel the print if G29 or G32 fails, since they're important for some setups. Maybe any code that involves homing shouldn't be allowed to continue printing if it fails, but I'm not sure if that would be good for everyone. If G29 and G32 cancelled an SD print upon failure, i think it would be a good stopgap before conditional gcode comes.

I like the idea of a parameter to change the behavior too, but conditional gcode is probably a better solution anyway and if it's a lot of work it probably won't be worth it.

It could be that something could also be done to retry G32 in a different way after a failure of a certain type. For instance if the probe was already triggered on one corner, then move that side up by a couple mm and retry, but that could be done with conditional gcode probably. Also it might be a bit dangerous to do that since the machine could possibly rip itself apart, but w/e.

My machine has 4 independent Z axis motors, so I use G32 to level the gantry before it starts printing. However, if G32 fails (due to too much gantry misalignment), the duet gives a message that it failed, but print continues without attempting to level the gantry.

Is there a way to cancel printing after a G32 failure so it doesn't ruin my bed surface again?

@phaedrux Right, but even with the SD card formatted properly, using one network vs the other still reduces the speed to sub 50KiB/s so I think that's the primary cause.

using the SD formatter on its own didn't work for me. I think my issue is a network issue because of my comcast router. My network tests were done with 64k block size so that could be helping, but I'm certain it's not the only thing at play here.

OK So I've just done some testing with using another router and different configurations.

I can't get rid of the original router, but I can connect up the second router as a repeater. I can connect the Duetwifi to the repeater network, and connect my laptop to the repeater network, and uploads work FAST (up to 600 KiB/s!!)(but something about comcast business class blocks DNS queries from repeaters so I don't get internet).

I can connect my laptop up to the comcast router, and keep the duetwifion the repeater network, but it seems that doing that brings the upload speed back down. There is some interaction from uploading through the comcast router.

I just tested a microSD card from microcenter, still very slow. I'm not sure what's going on here, but it's weird. Different router is my next step.

@phaedrux
I've got an extra router at home that I can bring in. I'll try that.

Thanks.