Found the problem, was playing around with 1.19xx before and not everything revert back to 1.18.1.

Now everything compiles again.

hi Chris ,
just curious whether the upgrade instructions are similar to those provided by dc42 one we get higher up then v1.18? the reason i ask is that upon my knee jerk upgrade motions that i follow , i ran into an error while attempting to update to the duetwebcontrol 1.16 package via the web update firmware button: when attempting to last three 1.16 version , i am denied with an error message that tells me i cannot upload zip packages through this system . how then , to update properly? i also ask because i read dc42's branch that includes this update instructions and warnings ,which indicates that going forward apparently , the wifi server software I think it was still no longer reside on the wifi module , but rather be offloaded to the cpu or mcu…wondering if the same precautions apply to your 1.19b6?

thanks , in advance .

Jonathan

Oops, I posted in the wrong place. Can someone fix that?

I'm seeing this same problem using firmware 1.18.1 (2017-04-09) using absolute using cura 2.5 on cartesian

edit: NM, needed M82 in start code

I have just released version 1.19beta1 for the Duet WiFi. See the new thread on that version for details. Please can those of you who have been trying 1.19alpha upgrade to that version. You need to do a simultaneous upgrade of DuetWiFiFirmware and DuetWiFiServer again, but you should not need to re-enter your access point data because it will not be erased by the firmware upgrade.

And a big thank you to Doug who took the time to make a file up for me that did it all automatically.

Cheers Doug!

So. Today it is working.

P3 is the only one that doesnt give me an invalid servo index for M280 and that doesnt work. The issue is radds actually uses heater 3. H3's pin is 21. I think to fix my issue I need to direct M558 to pin 39 instead of heater 3 in order for it to work.

Please request this in the Duet Web Control Wish List section of the forum

Okay so I fixed the endstop logic but am still having troubles with the bltouch. I can get it to home the x and y but when it goes to home the z it says the z probe is already triggered. Here are the lines from my config.g for the bltouch. I've tried setting p as both 5 and 4 just but neither work.

[[language]] M307 H3 A-1 C-1 D-1 M558 P5 X0 Y0 Z1 H3 F200 T5000 G31 X-20.0 Y20.0 Z0 P25

I am also having an issue with thermal runaways. When heating my hotend, I configured it so it heats slowly but even when it hits its target temperature it continues to heat. The entire time it is heating up, it does so in bursts. I dont know how to configure the pid properly please help.

[[language]] M305 P0 T100000 B3950 R4700 H0 L0 M305 P1 T100000 B3950 R4700 H0 L0 M305 P2 T100000 B3950 R4700 H0 L0 M301 H1 P0.1 I0.10 D100 T0.10 S1 M301 H2 P0.1 I0.10 D100 T0.10 S1

I did revert both. I got sick of trying so I just reverted back to day 1 and started over. Back in business now.

Thanks for reporting the bug. I will ask Christian to look at this.

@digiex_chris:

Is it sane to use G29 S1 in config.g? I'd like it to load the heightmap when the machine is turned on, rather than in my start gcode, since I like to run the same print file on multiple machines.

Yes that should be ok. Or you could put it at the end of homeall.g.

ypu ID10T error, 5th try was the charm. thanks much suspect usb cable was just too short…

Thanks dc42 but the problem has been solved. T3P3Tony put me right as I was using G32 instead of G29. All good now.

Bossac doesn't he support the SAM4E chip on the Duet WiFi/Ethernet, which is why we tell you to use SAM-BA. We've sent a Duet WiFi to the creator of bossac so that he can add and test support for the SAM4E in it. This should make things easier for Mac users. The newer Duets also have the Erase button set back so that it is harder to press it by mistake.

I suggest you test X, Y and Z homing individually until they are all working. Make sure that your M574 command in config.g is correct, and make sure that your homez.g file is correct according to whether you are using a microswitch or a Z probe to home Z. See https://duet3d.com/wiki/Configuring_RepRapFirmware_for_a_Cartesian_printer#Homing_files.

Hi Claustro, It is not normal to do that, although i don't see why it would be a problem. Slicers normally add the feed rate in at the right point so there is no need to define it.

@Qdeathstar:

I believe i had to run it as administrator and in compatibility mode with windows 7 to get it to work on my machine.

Thanks for that tip. This should really be in the docs. I'm not a regular Windows user so I had forgotten about compatibility mode.