Firmware 2.03beta2 available

gideon

I get 1 error when I want to print

10-3-2019 15:26:18:: FIRMWARE_NAME: RepRapFirmware for Duet 2 WiFi / Ethernet FIRMWARE_VERSION: 2.03beta2 + 1 ELECTRONICS: Duet WiFi 1.02 or later FIRMWARE_DATE: 2019-02-23b1
Canceled printing file 0: /gcodes/Body1.gcode, print time was 0h 2m
Error: G0 / G1: insufficient axes homed

gavatron3000

Your homeall macro has no endstops defined

gideon

it has always worked on the firmware 2.01,
I also do not use an end stop just Sensorless Homing
or do I have to put a little bit in the firware version in 2.03 "?

gavatron3000

M574 X0 Y0 means no endstops
My sensor less setup is as follows
M574 X1 Y1 S3; X and y min endstops are sensorless

dc42

@gideon said in Firmware 2.03beta2 available:

I get 1 error when I want to print

10-3-2019 15:26:18:: FIRMWARE_NAME: RepRapFirmware for Duet 2 WiFi / Ethernet FIRMWARE_VERSION: 2.03beta2 + 1 ELECTRONICS: Duet WiFi 1.02 or later FIRMWARE_DATE: 2019-02-23b1
Canceled printing file 0: /gcodes/Body1.gcode, print time was 0h 2m
Error: G0 / G1: insufficient axes homed

This one is covered in the troubleshooting FAQ on the wiki.

gideon

@gavatron3000 said in Firmware 2.03beta2 available:

M574 X1 Y1 S3

thanks

rflulling

I know I am late to this party. I have a feeling that familiar issue of the M574 command will bite me when I update too. -"M574 X2 Y1 Z1 S0" currently being the magic configuration for a Wanhao i3 Mini running 2.02(RTOS) (2018-12-24b1). I will also have to test the "M574 X2 Y0 Y0 S0" which has previously produced identical results for this hardware configuration. Perhaps that has changed under 2.03

Will chime in further if there are any issues to provide feed back on. Only doing update to participate in a community action.

dc42

The meaning of existing M574 commands hasn't changed unless you were accidentally using the new C parameter.

kazolar

David, since RC6 I've been having i2c issues. Or more specifically they've gotten worse so that the the firmware is not usable. RC5 shows timeouts when I do M122. (When I get into this condition where the duet is very slow to respond to move commands etc) I checked out forum posts regarding i2c issues and I am not seeing errors, but I am seeing timeouts in RC5, with RC6 the end stops on the Duex5 stop responding after a few hours. I checked my wiring again, and I have short ferule terminated wires between the ground terminals -- basically using the dual wire ferrule which came with duet/duex5. The boards are mounted with the duet at the top of the enclosure and the duex5 under it with 15mm of spacing, and fans blowing across them. When I get into the i2c timeout condition a pure reboot (pressing stop on the screen) doesn't fix it, I have to power down the board, and restart.

Veti

@kazolar said in Firmware 2.03beta2 available:

duex5

https://forum.duet3d.com/topic/7269/duet-sometimes-really-slow-i2c-error-or/2

The most common reason for I2C errors is that you don't have a short thick ground wire between the VIN terminal blocks of the Duet and the DueX.

kazolar

I checked that again. I have a beefy wire there, but I can go up a gauge. I also noticed that the ground wire has things running next to it, so I'm suspecting some interference. So my current plan is to move to a different case with the boards side by side instead one on top of the other and a much beefier ground wire. Since pure reboot doesn't solve it, I'm leaning towards some electrical noise built up which clears up on power down.

dc42

We recently had a report from one of one OEMs that the cables from normally-open endstop switches connected to the endstop inputs on the DueX5 appeared to be picking up interference from extruder cables or elsewhere, and this was triggering I2C errors. So my current advice to users experiencing I2C errors is:

Make sure there is a short thick ground wire between the VIN- terminals of the Duet and the DueX;
Try adding the additional I2C pullup resistors that I already described;
Don't connect normally-open endstop switches to the endstop inputs on the DueX (or if you must, use a 1K pullup resistor to +3.3V and preferably also an RC filter).

dc42

@kazolar said in Firmware 2.03beta2 available:

I checked that again. I have a beefy wire there, but I can go up a gauge. I also noticed that the ground wire has things running next to it, so I'm suspecting some interference. So my current plan is to move to a different case with the boards side by side instead one on top of the other and a much beefier ground wire. Since pure reboot doesn't solve it, I'm leaning towards some electrical noise built up which clears up on power down.

The beefy ground wire needs to be short as well.

Mounting the boards back-to-back is a good option, because it makes for easy fan cooling and it allows you to use a short thick ground wire between the two VIN terminal blocks.

kazolar

@dc42 so I'll leave the case be. That's easier obviously. I have very good cooling, CPU reported temperature doesn't go above 27c. I'll replace the ground wire, though it's at least an 18 gauge silicone insulated wire, but I can go to 16? Or 14. Wire is short, basically just long enough to jump between the boards. And will add the resistors as you suggested in the other post. It's rather curious that i2c timeouts (not errors although not sure if it's a difference) don't start until several hours of operation. I was calibrating my extruder offsets and checking my z probe etc so I was running homing routine multiple times and lead screw compensation routine,I am using normally closed end stops, I've had issues with normally open in the past. Hopefully I can resolve this and move to the latest firmware since I am presently stuck on rc5 since i2c is a bit more resilient there.

gavatron3000

18 gauge is only around 0.8mm² the wiki says around 2.5mm² is recommended which is around 13-14 gauge

Dont know if it's a pattern yet but I've read about a few issues with the duex and all those people seem to be running solid core cable.

kazolar

Thanks, will bump up to 14 gauge. I'm using stranded wires crimped in ferrules. I'm guessing, the insufficiently thick ground would the source of my issues. I'm not sure solid core can be crimped, or tightened adequately.

gavatron3000

Yes completely agree

kazolar

@dc42 I installed a 14 gauge ground wire -- while at it also did the VIN wire. Both are 1/2 the length they were before, couldn't get shorter than this now. I left the 16 gauge(it was 16 not 18 before) going to the PSU, it's coupled in a ferrule together with a very short 14 gauge jumper to duex5. The printer itself with everything on never pulls more than 200w, since my I'm using an AC bed, 16 gauge wire has not been an issue for 24v DC power.

Now the main question is, how do I test the i2c bus for reliability. Under normal conditions it takes a long time for me to start seeing timeouts, is there a test routine, something that would send a bunch of data on i2c which you would expect to produce some errors if the wiring was at issue (I don't mind running some custom firmware to bang on the i2c bus).

Thanks again.

SMK2019

Will do later today.

dc42

@kazolar said in Firmware 2.03beta2 available:

@dc42 I installed a 14 gauge ground wire -- while at it also did the VIN wire. Both are 1/2 the length they were before, couldn't get shorter than this now. I left the 16 gauge(it was 16 not 18 before) going to the PSU, it's coupled in a ferrule together with a very short 14 gauge jumper to duex5. The printer itself with everything on never pulls more than 200w, since my I'm using an AC bed, 16 gauge wire has not been an issue for 24v DC power.

Now the main question is, how do I test the i2c bus for reliability. Under normal conditions it takes a long time for me to start seeing timeouts, is there a test routine, something that would send a bunch of data on i2c which you would expect to produce some errors if the wiring was at issue (I don't mind running some custom firmware to bang on the i2c bus).

Thanks again.

You could try sending repeated commands to change the speed of the DueX fans. Each one will require an I2C transaction.

Here's another possibility: pick one of the DueX servo outputs that corresponds to an unused heater channel, connect the servo control pin of that output to the cathode of a small signal diode, and connect the anode of that diode to one of the DueX endstop inputs. Then use M307 to disable that heater, and M42 to set up 50% PWM on that servo output at a low frequency. Every time the endstop input toggles, the DueX will signal a change to the Duet, and the Duet will do an I2C transaction to find out what changed.