Thanks for confirming that. The problem is fixed in the 1.18 release.

That did it - brilliant, all up and running again. Thanks everyone for your patience. Things mechanical, not a problem but the intricacies of programming syntax is best left to those who understand these things.

I will make a note for future reference.

Thanks again,

Mike

that seams to have fixed it , not sure what exactly happened but reinstalling the fw seams to have resolved my issues.
thanks

I preformed a clean install of windows 10 and loaded 18(beta). It worked. I think I had a conflict or corruption that needed to be removed. Now on to the z probe . . .

You should configure just fan 1 to be the thermostatic one (which it is by default anyway) and leave fan 0 as the print cooling fan. If you have 2 hot ends each with a hot end fan, either use fan 1 and 2 outputs to control them, or connect them both in parallel to fan 1 output.

I suggest you download firmware version 1.18beta3. Follow this link https://github.com/dc42/RepRapFirmware/blob/dev/Release/Duet-WiFi/Edge/DuetWiFiFirmware-1.18beta3.bin then click on the Download button.

These wiki articles should contain all needed info:
https://duet3d.com/wiki/Checking_the_firmware_versions_and_updating_the_firmware
https://duet3d.com/wiki/Duet_Wiki#Updating_Duet_WiFi_firmware

@Cata:

I have that problem, finally it return to the seller. Not funny, 70 USD fees when arrive to my country and 30 USD shipping cost to send back.

I'm sorry to hear that. If you ever have to ask for a replacement for goods you have imported, ask the seller to make it clear in the customs declaration that what they are sending is a replacement for faulty goods that you have previously purchased, with zero customs value, That way you should not have to pay any import fees.

Ah OK maybe i just hadn't noticed it before.

Cheers
Charlie

Yeah, I have a similar problem. If I already had the page loaded from a previous connect and I'm not on the Machine Control tab, none of the macros show up. I haven't tried running one to get them to show up, normally I just dc and reconnect on the machine control page.

The M574 command overrides M558 now. So use Z0 in M574 to use a Z probe for Z homing.

Assuming your want to do bed probing with the nozzle and bed at printing temperatures, then it's best to calibrate the Z probe trigger height at operating temperature too.

Awesome David! Will give the newer FW a go now and let you know if all is good after I've tested a bunch of CW/CCW variations.

….

After some testing it looks like we are on a winner. I may have mentioned that you probably need tests to make sure an arc does not drive the head out of the bed limits however in reality the part won't be outside of the bed limits in the first place. It's only when a rubbish arc call in the gcode can cause this. Up to you if you want to include that safeguard in the code?

Thanks again for making this work. My code to take visibly faceted curves on an object and smooth them out by replacing all the short lines with one arc call is coming along nicely. Here is a good example of a before and after using the code -

Still more work to do with complex objects before it is ready.

So new issue has arised after I had let my panel sit on my desk (I get distracted easily) and upon trying to connect my panel due to my pc, it will now not have the standard white background and backlight but just the backlight (Only if I flipped the jumper to 5v). Additionally while connected to my pc, it does not come up in the device manager (or hardware connected chime). So my pc does not register the due at all. I think I may have messed up something here ha.

I will try restarting my pc after this post and see if it is an issue.

Thanks. My z jerk was a way to low and increasing it cleared up the jerking perfect. Thanks!

Hi DC42
I took a look add the code and i think it should be something like this:

From this function:
bool GCodes::DoSingleZProbe(GCodeBuffer& gb, StringRef& reply, bool reportOnly, float heightAdjust)

Call :
float m[DRIVES];
float offs[DRIVES];
reprap.GetMove()->GetCurrentMachinePosition(m, false);
offs[Z_AXIS] = m[Z_AXIS]
Tool::SetOffset(const float offs[MAX_AXES])

Why is this happening?

I've previously updated firmware just fine.. or rather, I got some error messages, but it worked.

When updating from 1.17c to 1.17e I suddenly get the "missing iap4e.bin" error.

All sorted now, got the touchscreen working correctly.
All I did is swapped order witch X and Y coordinates from touchscreen is read in UTouch.cpp

[[language]] // If the panel is touched, return the coordinates in x and y and return true; else return false bool UTouch::read(uint16_t &px, uint16_t &py, uint16_t * null rawX, uint16_t * null rawY) { bool ret = false; if (!portIRQ.read()) // if screen is touched { portCS.setLow(); delay_us(100); // allow the screen to settle uint16_t ty; // <- was tx if (getTouchData(false, ty)) // <- was tx { uint16_t tx; // <- was ty if (getTouchData(true, tx)) // <- was ty

Thank you David for nice add on to DuetWifi

Mark

Those of you having issues with 1.18beta 2, please try 1.18beta3 and continue the discussion in the thread about that release.

https://www.duet3d.com/forum/thread.php?id=1115

I'll add them to my repo when I publish firmware 1.18beta3 later today.