same with Fritzbox 7490 (last beta - only 20mhz, no pmf)
after wlan off ... 30sek wlan on
no reconnect of wifiServer 1.21
with 1.19.2 ok

@denke said in Pausing print for the night:

BTW the gcode database seems to be incorrect when stating: "A G92 without coordinates will reset all axes to zero." At least for a delta with fw 2.0 "stable" it seems to do nothing, while G92 X0 Y0 Z0 works as expected.

I think that behaviour applies to some other firmwares, but not to RRF. See https://duet3d.dozuki.com/Wiki/Gcode?revisionid=HEAD#Section_G92_Set_Position.

I downgraded to 1.20, i probably confused the error, will retest 1.21 later after my printing is done.

@danal

I actually think I found the issue. The name was recently changed from #define BEZIER_CURVE_SUPPORT to #define S_CURVE_ACCELERATION

& whoever did that missed 1 part of the code that still used #define BEZIER_CURVE_SUPPORT

That's what you get for beta testing. I'm trying the firmware with both defined and should actually be using the s-curve feature.

I think SeeMeCNC use their own version of RepRapFirmware and perhaps their own version of Duet Web Control too, so you will need to wait for them to respond. However, if you have updated Duet Web Control recently, try clearing your browser cache.

I did try all three channels and did not see any change in behavior.
I have accessed it via duettest.local and it's ip address without seeing any difference. I have not done a wireshark trace.
After I posted yesterday, I was finally able to get a "stable" connection for a couple of hours - though I really have no idea why as I did not change anything. Turned it off for the night and came back this morning and I have the same issue. I bought the board from Filastruder so will contact them about the warranty and will reference this thread as you recommended. I was suspicious of the WiFi module but wanted to be certain I had not missed something.

Thanks for you input.

@dc42 Yep, I'm good now on the filament load.

Thanks

@jddt

I use belts to lift the Z axis in my printer. I solved the bed-drop-on-power-off problem by installing a worm gear drive. If the gear ratio is sufficient (and/or the pitch of the teeth is right), the mechanism is irreversible and no brakes are needed to hold the bed.

My printer's bed assembly weighs about 3.5 kg and does not move unless the motor tells it to move.

Great. Thx much.

@mlaustin6 : that means that your axis minima are X:-16 and Y-30, update your M208 command in config.g to get the correct 0,0 position

@t3p3tony

I agree that a lot more investigation is required. I have gotten some spurious errors and other unexplained wonkiness. I should receive a new Duet WiFi and Duex5 today so I'll first try to isolate which board it causing the problems and then try to narrow it down from there.

Unfortunately, this thread seems to have been hijacked so I'll start a new one if/when I figure anything out.

Looking at the map, my first reaction was "inconsistent probe hardware". But... if you are seeing this in prints...

So, let's figure out if this is the bed, or the carriages, or something entirely different.

What is the bed? Glass? Aluminum? Is there a plastic coating, PEI or similar? And the real question: Put a really good steel straightedge across the bed and see if you see the dips and peaks.

@danal, @Juice

Thanks! : ))

3mm

The Z probe X and Y offsets are measured from the head reference point (which in a single-nozzle printer is always the nozzle) to the probe. So if +X movement moves the nozzle to the right and the probe is to the left of the nozzle, then the X offset will be negative.

If you want mesh compensation to correct for the bed not being flat and level, then it's important that the measured height error is at the specified bed coordinates. So the firmware puts the probe at those coordinates to measure the height error, not the nozzle.

If on the other hand the bed is flat and level but the gantry that carries the print head isn't (for example, in the middle of the X travel the gantry sags a little under the weight of the print head), then you are better off setting the probe X and Y offsets to zero so that the firmware puts the nozzle at the specified XY coordinates.

HTH David

Some really interesting techy stuff there! I was thinking about a PhD project one of my peers was working on way back while doing research. His project had a large optical component but one of the ideas worked on was to allow the use of more flexible (i.e. lighter) robots and through the fast optical sensor detect oscilations and commanding an inverse oscillation to the position control to damp out the oscillation. Realistically for our machines I think we'd be talking about requiring FPGA sort of speeds along with the ultra fast accelerometers which probably would need most of us to up our game in terms of electrical noise control. The FPGA programming is a whole different mindset to micro controllers. Having said that with the parallel processing being demonstrated with the 2.0 release of firmware the micro controllers are proving themselves ever-increasingly more powerful.

Edit: Arduino have or are about to release an FPGA development kit. I may have a play to see if that is quick enough to get a good signal from an accelerometer strapped to the head or if noise is too bad!

Edit 2: My competence is more along the lines of a hobbyist hacker/tinkerer now rather than professional so don't be expecting my results too quick!

I Have tried both, for testing something else with my extruder. The filament always shows 100% so if thats something to go by for now thats fine. Do you recommend another version of cura or another slicer then.

@paboman said in Firmware Retraction:

@dc42
Do I need to have the Retraction check box (Ooze control in S3D) activated in order to have M102 etc commands in the Gcode?
In other post I read that Retraction need to be ON but all values need to be set to ZERO

No, but you need to have the box labelled "Generate M101/M102" instructions (sorry, I can't remember the exact term) checked.

However, it has turned out that using this option doesn't work quite right. So the best answer is don't use S3D until they have added proper support for firmware refraction. It's the only major slicer that doesn't have this support.