ok, thx.

Exactly the same issue here, what was the solution
?

Doesn't seem to be working with SAM-BA CDC 2.1.6 utility either. This utility connects but then seems to lock up during the write phase.

This board updated the normal way and was running the web server just fine but then just stopped working after thr last power up.

My bad, it does say which board..

Fallback 3

https://duet3d.com/wiki/Updating_main_firmware

I suggest you copy the correct DuetWiFiserver-xxx.bin file to the SD card on a PC, then put the SD card back in the Duet, start the Duet, and send M997 S1 to re-flash the wifi module.

If you have flashed version 1.18.2 or earlier firmware, you need DuetWiFiServer-1.03ch.bin. if you have flashed version 1.19beta6 then you need DuetWiFiServer-1.19beta1.bin.

Thank you again.

I tried another print at 190C for the nozzle and 55 for the bed as opposed 195 and 57 previously.

The result was better but still failed after about 52mm on the Z axis. At that point, I slowed the print speed to 80 then 60% but that did not change anything.

It's true that ambient temps is around 24C as opposed to 19C normally when I print.

Also, I am at the end of the filament roll, so that could be a factor.

There is no change in the noise generated by the fan, but I guess it could be slowing…

Last week, with the old firmware, I did a lot of printing and had absolutely no problems, except for the head crashing into the plate during Z probing. I printed 55m heigh objects, but larger than 10x10mm, 25x35mm in fact.

Here's a photo of today's test: https://goo.gl/photos/ZF9Ms48RkZx2ZLD66

Thanks,
Bob

Reproducible disconnections when you do a certain thing usually indicate an incompatibility between RRF and DWC. I suggest you upgrade your beta5 to beta 6 (just upload the beta6 binary through DWC, the wifi code hasn't changed), then upload the DWC zip file in the same way.

M588 was working last time I tested it, but I'll test it again before I release beta7.

@brian:

I'm in western Canada, not much help in these parts. My z probe arrived so maybe i'll have more success. Now if i can find that link to v 1.19 beta.

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

Well, It worked for one day. It will still print when I hook up via usb, but the wifi module will not work today. It just reports that the wifi module is idle. I am just going to replace the duet wifi with something else until you make the ethernet module available.

Thanks!

I'll give it a try!

BTW, I managed to upgrade the firmware to 1.18 and it seems to work so far!

Cheers,
Bob

@Kulitorum:

Rmpfh….

Still does not compile, and I have no idea what _sbrk is:

22:45:17 **** Incremental Build of configuration DuetWiFi for project RepRapFirmware ****
make all
'Building target: DuetWiFiFirmware.elf'
'Invoking: Cross G++ Linker'
arm-none-eabi-gcc -L"C:\Eclipse\ReprapFirmware\CoreNG\SAM3X8E" -Os -Wl,--gc-sections -Wl,--fatal-warnings -mcpu=cortex-m4 ...

Your library path is wrong. For the Duet WiFi build of RRF, you should be using the SAM4E build of CoreNG, not the SAM3X8E one.

Another user who was unable to flash new firmware on his Duet WiFi and reported a similar problem running Bossa 1.8 managed to flash the firmware using the command line version of Bossa 1.8. I had suggested the following command line to him:

bossac.exe –port=COM_nn_ -U true -e -w -v -b C:\path\FirmwareFile.bin -R

If necessary, put in the full path at the beginning to the version of bossac.exe installed with Bossa 1.8. Substitute your own COM port number and firmware path and file name in this command.

No biggie, I'm just glad it wasn't something fundamental - no apologies necessary.

That's because it has been released since I posted that link, so it's now in Stable instead of Edge.

I don't like the look of this:

< 9:23:14 AM: Push(): stack overflow!
< 9:23:14 AM: serial: N6 M105 *1
< 9:23:14 AM: ok T:B:2000.0
< 9:23:14 AM: daemon: T0
< 9:23:14 AM: daemon: T0
< 9:23:14 AM: daemon: T0
< 9:23:14 AM: daemon: T0
< 9:23:14 AM: daemon: T0
<<

Unless you have 5 T0 commands near the end of your config.g file, it looks like you have an infinite recursion in a gcode file. I suggest you delete config-override.g, comment out the M501 command in config.g, and try again.

I am using the ELP IP1881 camera, which as far as I know is identical to the TOP 201. I can't get a stream to the DWC. Last night I did find that I could get the still to update with the http qualifier turned off, but it is super poor quality and choppy as it will not let me update faster than 1 time per second. Do you have any ideas? Also, I would love it if you could point me in a direction to learn how to compile the files to make a new bin. I know cpp basics but not to the extent of paths and compiling multiple files to make a .bin. I guess it doesn't really apply to this camera issue anymore though.

In short, I would like to see if we can make this little IP camera work as well as my old tablet does with DWC. It updated very fast and seemed more like a stream.

Please can you clarify in what way(s) the heaters and temperature probes are not working. Are you selecting a tool before trying to heat up the extruder(s)?

@3ddevil:

Great answer! Thanks. We found the same thing at M3D with DRV8834 and use it in mixed decay mode also. It helps having gearing motors too. The Duet3D is going to make the best printer we've ever worked on : )

can you comment on this issue?
G91
G0 Y0.02> Moves
G0 Y0.01> Won't move.

Is the firmware throwing away the error (instead of accumulating it)?

What type of printer is it, and what is your steps/mm? If it's around 80 then 0.01mm is less than 1 microstep. What happens if you send G0 Y0.01 several times?

Firmware 1.19beta1 is now superseded by 1.19beta2. Those of you who were having problems with beta1 please try beta2.