Ormerod stopped working----help!!!! -- resolved

I switched on this morning and could not connect via the web browser but the error page says "This web page is not available,ERR_CONNECTION_REFUSED" , tried Pronterface and the temps are showing correct when cold.
If I switch on the main 12 volt power, I can move all three axis and heat the bed but the hot end is just not heating, occasionally the red light on the duet flashes and the amber light on dc42's board flashes.

I have not made any changes since it was working yesterday, I am using dc42's probe, single hot end board, with the 2 beam sensor and have checked that I do not have 12 volts on the heater connection.
So it appears that the duet is not providing 12 volts to the heaters but I don't know why.
I have also connected a spare duet and the symptoms are the same.

What do I check next?

@dc42 Dave can my dual hot end board be used as a single hot end, without the second hot end being connected?

Edited 2 time(s). Last edit at 10/07/2015 02:30PM by appjaws1.

---

appjaws - Core XYUV Duet Ethernet Duex5
firmware 3.1.1 Web Interface 3.1.1
Ormerod 1-converted to laser engraver, Duet wifi
OpenSCAD version 2020.07
slic3r-1.3.0, Simplify3D 4.1.2, Cura-4.4.1

Quote
appjaws1
I switched on this morning and could not connect via the web browser but the error page says "This web page is not available,ERR_CONNECTION_REFUSED" , tried Pronterface and the temps are showing correct when cold.
If I switch on the main 12 volt power, I can move all three axis and heat the bed but the hot end is just not heating, occasionally the red light on the duet flashes and the amber light on dc42's board flashes.

I have not made any changes since it was working yesterday, I am using dc42's probe, single hot end board, with the 2 beam sensor and have checked that I do not have 12 volts on the heater connection.
So it appears that the duet is not providing 12 volts to the heaters but I don't know why.
I have also connected a spare duet and the symptoms are the same.

What do I check next?

Very strange, if the symptoms are the same when you use your spare Duet. As it is just the hot end heater that is not working, it sounds rather like a temperature error has been detected. I suggest you concentrate on getting the web interface working again, because it provides the real-time status of the hot end heaters.

Quote
appjaws1
@dc42 Dave can my dual hot end board be used as a single hot end, without the second hot end being connected?

Yes. If you still want the fan to turn off when the single hot end is cool, you need to either add the jumper (if your board has jumper pins), or link the unused thermistor connector to the other one. From the fitting instructions:

Quote

If you are using a dual-nozzle board on a single-nozzle machine and your board does not have the jumper pins next to the thermistor 1 connector, when attaching crimp pins to the thermistor wires you must also crimp one end of a short loop of wire into the left hand pin. The other end of this wire goes to the left hand pin in another 2-pin receptacle, which will be plugged in to the Thermistor 2 connector on the board.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Thank you David,

I have checked all the wiring and all seems well. I can ping my ormerod and the response is correct.
Also Pronterface is showing:-

Connecting...
Printer is now online.
Starting network
Network up, IP=192.168.1.84
Setting hotend temperature to 195.000000 degrees Celsius.
Setting bed temperature to 35.000000 degrees Celsius.

The bed heats up but the hotend remains cold.

SENDING:M122
serial: M122
Platform Diagnostics:
Memory usage:
Program static ram used: 41428
Dynamic ram used: 47020
Recycled dynamic ram: 1664
Current stack ram used: 2880
Maximum stack ram used: 4216
Never used ram: 3976
Last reset 00:09:18 ago, cause: power up
Error status: 0
Bed probe heights: 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000
Free file entries: 10
Longest block write time: 0.0ms
Slowest main loop (seconds): 0.360657; fastest: 0.000031
Move Diagnostics:
MaxReps: 2, StepErrors: 0
Heat Diagnostics:
GCodes Diagnostics:
Move available? no
Network Diagnostics:
Free connections: 16 of 16
Free transactions: 24 of 24
Free send buffers: 20 of 20
LINK
xmit: 1
recv: 140
fw: 0
drop: 0
chkerr: 0
lenerr: 0
memerr: 0
rterr: 0
proterr: 0
opterr: 0
err: 0
cachehit: 0
ETHARP
xmit: 1
recv: 4
fw: 0
drop: 5
chkerr: 0
lenerr: 0
memerr: 0
rterr: 0
proterr: 5
opterr: 0
err: 0
cachehit: 0
IP_FRAG
xmit: 0
recv: 0
fw: 0
drop: 0
chkerr: 0
lenerr: 0
memerr: 0
rterr: 0
proterr: 0
opterr: 0
err: 0
cachehit: 0
IP
xmit: 0
recv: 131
fw: 0
drop: 0
chkerr: 0
lenerr: 0
memerr: 0
rterr: 0
proterr: 0
opterr: 0
err: 0
cachehit: 0
ICMP
xmit: 0
recv: 0
fw: 0
drop: 0
chkerr: 0
lenerr: 0
memerr: 0
rterr: 0
proterr: 0
opterr: 0
err: 0
cachehit: 0
UDP
xmit: 0
recv: 56
fw: 0
drop: 0
chkerr: 0
lenerr: 0
memerr: 0
rterr: 0
proterr: 0
opterr: 0
err: 0
cachehit: 0
TCP
xmit: 0
recv: 0
fw: 0
drop: 0
chkerr: 0
lenerr: 0
memerr: 0
rterr: 0
proterr: 0
opterr: 0
err: 0
cachehit: 0
MEM HEAP
avail: 1024
used: 0
max: 68
err: 0
MEM UDP_PCB
avail: 2
used: 1
max: 1
err: 0
MEM TCP_PCB
avail: 16
used: 0
max: 1
err: 0
MEM TCP_PCB_LISTEN
avail: 4
used: 3
max: 3
err: 0
MEM TCP_SEG
avail: 16
used: 0
max: 0
err: 0
MEM REASSDATA
avail: 5
used: 0
max: 0
err: 0
MEM FRAG_PBUF
avail: 15
used: 0
max: 0
err: 0
MEM PBUF_REF/ROM
avail: 8
used: 0
max: 0
err: 0
MEM PBUF_POOL
avail: 6
used: 0
max: 1
err: 0
SYS
sem.used: 0
sem.max: 0
sem.err: 0
mutex.used: 0
mutex.max: 0
mutex.err: 0
mbox.used: 0
mbox.max: 0
mbox.err: 0
.

---

appjaws - Core XYUV Duet Ethernet Duex5
firmware 3.1.1 Web Interface 3.1.1
Ormerod 1-converted to laser engraver, Duet wifi
OpenSCAD version 2020.07
slic3r-1.3.0, Simplify3D 4.1.2, Cura-4.4.1

The LAN error suggests that you had another device on your network with the same IP address. It is then pot-luck as to whether the browser will connect to the Duet or attempt to connect to the other device (which would usually refuse the connection). Even if it connects to the Duet the IP conflict may cause unpredictable errors. If you get the same error again you can check for an IP conflict by switching off the Duet, re-boot the PC and then ping the IP address - if the ping works it indicates there is another device replying to that IP address.

(Instead of rebooting the PC you can clear its ARP table with an "arp -d" command which requires elevation in Win7/8/10, but re-booting is easier if you are not familiar with command line operations).

Dave

Thank you Dave, I'll try that.

The good news is that the printer is now printing using Pronterface.
Still can't connect with the web interface.
Tried arp -d but it failed as you quite rightly said it requires elevation.----How do I do that?

---

appjaws - Core XYUV Duet Ethernet Duex5
firmware 3.1.1 Web Interface 3.1.1
Ormerod 1-converted to laser engraver, Duet wifi
OpenSCAD version 2020.07
slic3r-1.3.0, Simplify3D 4.1.2, Cura-4.4.1

Quote
appjaws1
Thank you Dave, I'll try that.

The good news is that the printer is now printing using Pronterface.
Still can't connect with the web interface.
Tried arp -d but it failed as you quite rightly said it requires elevation.----How do I do that?

Find "Command processor" in the Start->All Programs menu, right click on it, and select "Run as administrator".

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Thank you David,
I processed that command but it didn't work I still get web page is not available.
I'll try linux as well and see if that works.

---

appjaws - Core XYUV Duet Ethernet Duex5
firmware 3.1.1 Web Interface 3.1.1
Ormerod 1-converted to laser engraver, Duet wifi
OpenSCAD version 2020.07
slic3r-1.3.0, Simplify3D 4.1.2, Cura-4.4.1

I have turned off all other equipment and still I could ping 192.168.1.84. It then dawned on me that that must be the ip address of the main computer.
It didn't used to be 192.168.1.84 so I'm not sure why or how its changed.
I have changed the ormerod to a new address and all is working well.

Sorry for all the noise but I was just frustrated at not being able to solve the problem.

---

appjaws - Core XYUV Duet Ethernet Duex5
firmware 3.1.1 Web Interface 3.1.1
Ormerod 1-converted to laser engraver, Duet wifi
OpenSCAD version 2020.07
slic3r-1.3.0, Simplify3D 4.1.2, Cura-4.4.1

Probably you have DHCP enabled?

---

Slicer: Simplify3D 4.0; sometimes CraftWare 1.14 or Cura 2.7
Delta with Duet-WiFi, FW: 1.20.1RC2; mini-sensor board by dc42 for auto-leveling
Ormerod common modifications: Mini-sensor board by dc42, aluminum X-arm, 0.4 mm nozzle E3D like, 2nd fan, Z stepper nut M5 x 15, Herringbone gears, Z-axis bearing at top, spring loaded extruder with pneumatic fitting, Y belt axis tensioner
Ormerod 2: FW: 1.19-dc42 on Duet-WiFi. own build, modifications: GT2-belts, silicone heat-bed, different motors and so on. Printed parts: bed support, (PSU holder) and Y-feet.
Ormerod 1: FW: 1.15c-dc42 on 1k Duet-Board. Modifications: Aluminium bed-support, (nearly) all parts reprinted in PLA/ ABS, and so on.

Changing Router can couse a change in ip ,changing the PC plug on the router from 1 to 2 ,3,4 can also change IP address

Quote
Darathy
Changing Router can couse a change in ip ,changing the PC plug on the router from 1 to 2 ,3,4 can also change IP address

Or simply power-cycling the router.

Dave

Quote
dmould
Or simply power-cycling the router.

In that case you have a bad router. My router keeps the IP-addresses for several weeks if possible.

---

Slicer: Simplify3D 4.0; sometimes CraftWare 1.14 or Cura 2.7
Delta with Duet-WiFi, FW: 1.20.1RC2; mini-sensor board by dc42 for auto-leveling
Ormerod common modifications: Mini-sensor board by dc42, aluminum X-arm, 0.4 mm nozzle E3D like, 2nd fan, Z stepper nut M5 x 15, Herringbone gears, Z-axis bearing at top, spring loaded extruder with pneumatic fitting, Y belt axis tensioner
Ormerod 2: FW: 1.19-dc42 on Duet-WiFi. own build, modifications: GT2-belts, silicone heat-bed, different motors and so on. Printed parts: bed support, (PSU holder) and Y-feet.
Ormerod 1: FW: 1.15c-dc42 on 1k Duet-Board. Modifications: Aluminium bed-support, (nearly) all parts reprinted in PLA/ ABS, and so on.

Quote
Treito

Quote
dmould
Or simply power-cycling the router.

In that case you have a bad router. My router keeps the IP-addresses for several weeks if possible.

It doesn't make it a bad router. There is not usually a great deal of advantage in putting the leasing table into non-volatile storage, and having too many "sticky" variables can itself cause problems because it means that when something goes wrong due to a misconfiguration, a power cycle does not fix the issue. "Sticky" Arp tables are a nightmare on a system where IP addresses are frequently re-allocated to different devices.

The PC itself usually retains its last DHCP address, and will request the same address in its following network boot or lease renewal, which will be granted if the subnet address is correct and that address has not been leased to another device, so even if the router does not retain its lease table many devices will nevertheless keep the same IP address. Port-forwarding is these days associated with MAC addresses rather than IP addresses, so ports will be forwarded to the same PC even if its local IP address has changed.

Dave

Thank you for all the advice and knowledge.
I now know what to look for if it happens again.

---

appjaws - Core XYUV Duet Ethernet Duex5
firmware 3.1.1 Web Interface 3.1.1
Ormerod 1-converted to laser engraver, Duet wifi
OpenSCAD version 2020.07
slic3r-1.3.0, Simplify3D 4.1.2, Cura-4.4.1

Quote
dmould

Quote
Treito

Quote
dmould
Or simply power-cycling the router.

In that case you have a bad router. My router keeps the IP-addresses for several weeks if possible.

It doesn't make it a bad router. There is not usually a great deal of advantage in putting the leasing table into non-volatile storage, and having too many "sticky" variables can itself cause problems because it means that when something goes wrong due to a misconfiguration, a power cycle does not fix the issue. "Sticky" Arp tables are a nightmare on a system where IP addresses are frequently re-allocated to different devices.

The PC itself usually retains its last DHCP address, and will request the same address in its following network boot or lease renewal, which will be granted if the subnet address is correct and that address has not been leased to another device, so even if the router does not retain its lease table many devices will nevertheless keep the same IP address. Port-forwarding is these days associated with MAC addresses rather than IP addresses, so ports will be forwarded to the same PC even if its local IP address has changed.

Dave

You cannot ensure that if the power returns all consumables are ready such as PCs or printers. To ensure all get the right IP back the router should store these IPs for at least one or two weeks before any other consumer can take the IP-address. That is my opinion.

---

Slicer: Simplify3D 4.0; sometimes CraftWare 1.14 or Cura 2.7
Delta with Duet-WiFi, FW: 1.20.1RC2; mini-sensor board by dc42 for auto-leveling
Ormerod common modifications: Mini-sensor board by dc42, aluminum X-arm, 0.4 mm nozzle E3D like, 2nd fan, Z stepper nut M5 x 15, Herringbone gears, Z-axis bearing at top, spring loaded extruder with pneumatic fitting, Y belt axis tensioner
Ormerod 2: FW: 1.19-dc42 on Duet-WiFi. own build, modifications: GT2-belts, silicone heat-bed, different motors and so on. Printed parts: bed support, (PSU holder) and Y-feet.
Ormerod 1: FW: 1.15c-dc42 on 1k Duet-Board. Modifications: Aluminium bed-support, (nearly) all parts reprinted in PLA/ ABS, and so on.

Quote
Treito
You cannot ensure that if the power returns all consumables are ready such as PCs or printers. To ensure all get the right IP back the router should store these IPs for at least one or two weeks before any other consumer can take the IP-address. That is my opinion.

OTOH the clients may have been allocated different IP addresses during the outage, and the assumption by the router that everything is the same as it was before the outage could cause issues.

In practice in a home system it is unlikely to cause any problems. The router (DHCP server) should check whether there is an ARP reply before allocating an IP address, and should also monitor the IP source addresses and mark as "in use" all that it finds in local packet traffic (and route them OK), so client operation is unlikely to be affected. That's why giving the Duet an ad-hoc IP address that is within your local DHCP range seldom causes problems unless the IP address was already allocated at the time the Duet came online. The router should recognise that a device is using an IP address that it did not allocate, and mark it as unavailable to the DHCP pool. Not all routers behave the same in that respect however.

When the Duet has been allocated a fixed IP address in its config file, it should also ideally attempt to ARP that address a few times before using it to ensure there is no conflict, and remain offline (bringing up an error message) if there was a reply to the ARP. The same process should occur following an Ethernet disconnect/reconnect event. It's not mandatory to do so, just "polite".

Dave