Ormerod 2 RepRap firmware web interface keeps disconnecting

Hi all,

I have an issue with the Ormerod 2 RepRap firmware web interface. We got an Ormerod 2 at work a month or so ago and I updated the firmware to whatever the most recent version was then. It is set up to use DHCP and controlled from Opera on Windows Vista via a network switch. Since the beginning we've had the problem that usually, shortly after starting a print job, the web interface disconnects with the error message "AJAX communication error, session terminated, check printer is on, Syntax error: unexpected token i". It doesn't usually do this when the printer is just sitting idle, only when it's printing. It doesn't stop the print, but reconnecting to the printer is a hit and miss affair. I tried reloading the page, restarting the browser, rebooting the computer, none of these generally works (the web interface front page loads again but then the same error message pops up). It is usually possible to reconnect if you wait for 10 or so minutes. Today I discovered that flushing the DNS ("ipconfig /flushdns") improves the odds of reconnecting after the error.

I also have an Ormerod 2 at home which I bought in April and updated to whatever firmware version was the most current then. It is set up as fixed IP on my home network and I also connect to it from Opera on Windows Vista via a cheap eBay network switch. I think I have seen that error message a few times at the beginning when the printer was still plugged into the router but haven't had any issues for the past several months. Until I came back home today and started a long print: there is that dreaded error message "Syntax error: unexpected token i"! Have I brought the curse home from work?? Flushing the DNS cache didn't help and I couldn't reconnect until I power-cycled the network switch (haven't tried that at work yet). It's connected again, hasn't disconnected yet and is still printing...

Does anyone have any ideas how I might fix this? It doesn't stop me printing (the printer keeps going) but is obviously very annoying, especially when you're trying to change filament colours at a specific point in the print! Should I maybe check that the SD card is not corrupted? (both printers use the card they came with)

Here's a quick comparison of both setups:

Home printer:
Model: Ormerod 2
Firmware: RepRap, whatever version was the most recent in April
Network environment: fixed IP address, connects to network via £10 network switch which itself is connected to the router
PC: Windows Vista, Opera browser, connects to network via WiFi
Problem: not a single disconnection for the past several months, then one not an hour ago! Managed to reconnect by rebooting network switch and it hasn't disconnected since (yet?)

Work printer:
Model: Ormerod 2
Firmware: RepRap, whatever version was the most recent a month ago
Network environment: DHCP, connects to network via slightly more expensive network switch from RS, which itself is connected to the university network
PC: Windows Vista, Opera browser, connects to network via the same network switch as printer
Problem: pretty much regular (much more often than not, although not always) disconnections shortly after starting print. Waiting 10 or so minutes and retrying or flushing DNS cache usually works to reconnect. Haven't tried unplugging the switch yet.

Any help would be greatly appreciated. This is doing my head in!

(and before anyone suggests ditching Vista: no, those are the computers I'm stuck with and besides Vista has worked fine for me for years and with my home printer for several months without any issues)

Cheers,
Bart

Hi Bart,

I suggest you upgrade to either dc42's firmware or to my latest one. Don't forget to add the M574 code as seen here to your config.g file.

The reason you're experiencing this problem is an invalid JSON response sent from the firmware and I remember having fixed a related bug a while ago. If an upgrade doesn't fix your symptoms, this would mean you're having a really unreliable network connection and I'd advise you to try a reset of your TCP/IP stack first. See [support.microsoft.com]

It could be this (http://forums.reprap.org/read.php?340,522632,522632#msg-522632) problem which Dave corrected a while ago.

One thing I have noticed with the Duet is it can be sensitive to other network traffic, I found that when I turned my TV on then my Printer would start shuddering and the connection would become unreliable, the eventual cause, was identified as my HDMI-LAN converters that allowed me to distribute SAT TV to other rooms in my house.

This problem was fixed in one of the newer firmware updates by changing the priority of the web server (or something like that), but I still notice disconnects when I put my printer on the domestic network, but when I put it on a Printer only network or direct connect to my laptop which doesn't have any other traffic then it works very reliably.

The thing to remember about the duet is it only has the one processor, and when you consider that its doing G-code interpretation, Driver management, running a web server and FTP server.... its getting pretty busy, and sometimes it drops the occasional ball, as long as the ball its dropping is only the web server then that's not too bad, its when your printing quality suffers you will have problems.

---

RepRapPro Mendel 3 Tricolour
RepRapPro Fisher
-Carbon Arms
-Easy adjust Carriage+effector
-axis stiffness mods
HE3D -600 delta
-Duet 0.8.5
-PanelDue
-DC42 Height probe
-RobotDigg metal components
Simplyfy3D
RS Design Spark CAD

You have to understand that a network cable can only transfer one network package at the same time. If you have high traffic on that line something will fail. We already suggested you to seperate these networks. Just to remember.

---

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.

Yes something will fail in terms of communication latency, I build network based SCADA systems on a daily basis and very familiar with the issues of high data traffic on a network......the thing is, its very unusual for something on a network to suffer from network traffic when its not actively using the network and not dependant on network data, Ive tried to explain this detail before but you failed to listen or understand.

---

RepRapPro Mendel 3 Tricolour
RepRapPro Fisher
-Carbon Arms
-Easy adjust Carriage+effector
-axis stiffness mods
HE3D -600 delta
-Duet 0.8.5
-PanelDue
-DC42 Height probe
-RobotDigg metal components
Simplyfy3D
RS Design Spark CAD

As we also use a SCADA system at work. May I ask you what system do you use?

---

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.

All of them

---

RepRapPro Mendel 3 Tricolour
RepRapPro Fisher
-Carbon Arms
-Easy adjust Carriage+effector
-axis stiffness mods
HE3D -600 delta
-Duet 0.8.5
-PanelDue
-DC42 Height probe
-RobotDigg metal components
Simplyfy3D
RS Design Spark CAD

I meant the manufacturer of the SCADA software.

---

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.

All manufacturer's, All SCADA systems, All PLC, All DCS, All of them, control system integration is about integrating all control systems.

---

RepRapPro Mendel 3 Tricolour
RepRapPro Fisher
-Carbon Arms
-Easy adjust Carriage+effector
-axis stiffness mods
HE3D -600 delta
-Duet 0.8.5
-PanelDue
-DC42 Height probe
-RobotDigg metal components
Simplyfy3D
RS Design Spark CAD

Okay that means you also know Bachmann and atvise?

---

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.

You catch on quick!

---

RepRapPro Mendel 3 Tricolour
RepRapPro Fisher
-Carbon Arms
-Easy adjust Carriage+effector
-axis stiffness mods
HE3D -600 delta
-Duet 0.8.5
-PanelDue
-DC42 Height probe
-RobotDigg metal components
Simplyfy3D
RS Design Spark CAD

A wired Ethernet LAN should not suffer too much from high network traffic between nodes that do not include the printer and web client. Congestion occurs when the traffic is passing through a common node - e.g. the Internet gateway, the "backbone" connection between two different hubs (switches) or WiFi connections via the same hotspot.

Regardless, a bad Ethernet connection should not cause any juddering or printing issues as it is used only for control during printing, not print data transfer.

Dave

Quote
dmould

Regardless, a bad Ethernet connection should not cause any juddering or printing issues as it is used only for control during printing, not print data transfer.

Dave

EXACTLY....but I proved that it did and zpl and dc fixed it

---

RepRapPro Mendel 3 Tricolour
RepRapPro Fisher
-Carbon Arms
-Easy adjust Carriage+effector
-axis stiffness mods
HE3D -600 delta
-Duet 0.8.5
-PanelDue
-DC42 Height probe
-RobotDigg metal components
Simplyfy3D
RS Design Spark CAD

Quote
bgkdavis
You catch on quick!

I was asking because this software especially atvise is not very common and I am wondering if there is maybe a better software that is easier to handle and we are looking also for a better licensing model but we could not find anything suitable yet.

---

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.

Nope its not common, try indusoft, its not too common either, but is very good value for money and has great opc and system specific drivers, most of the more common systems are expensive.

---

RepRapPro Mendel 3 Tricolour
RepRapPro Fisher
-Carbon Arms
-Easy adjust Carriage+effector
-axis stiffness mods
HE3D -600 delta
-Duet 0.8.5
-PanelDue
-DC42 Height probe
-RobotDigg metal components
Simplyfy3D
RS Design Spark CAD

Quote
zombiepantslol
Hi Bart,

I suggest you upgrade to either dc42's firmware or to my latest one. Don't forget to add the M574 code as seen here to your config.g file.

The reason you're experiencing this problem is an invalid JSON response sent from the firmware and I remember having fixed a related bug a while ago. If an upgrade doesn't fix your symptoms, this would mean you're having a really unreliable network connection and I'd advise you to try a reset of your TCP/IP stack first. See [support.microsoft.com]

Hi Zombie,

I reset the TCP/IP stack as per instructions and it didn't help (on the work printer).

Unreliable network connection? I don't know about work. Internet connectivity and download speed (e.g. for firmware packages) are good, but I have no control over it anyway. But my home printer has now also started disconnecting from the PC and that's on my home network with very little traffic! So it seems I have brought the curse home from work! Because both control computers (home and work) are Vista, I'm now starting to think maybe it was some recent Windows update that messed things up...

As for upgrading to zpl or dc42: how much of a difference would I see in terms of operating the printer day-to-day? Any at all or would it be completely transparent (apart from the M574 bit)? I'm getting on a bit you see, and therefore don't like change... :-)

Cheers,
Bart

Quote
FatFreddie
It could be this (http://forums.reprap.org/read.php?340,522632,522632#msg-522632) problem which Dave corrected a while ago.

Hi FatFreddie,

Ok, so I would need to change the firmware to dc42. I may do that, but that still doesn't explain why my home printer/computer were fine for several months and have now suddenly started having issues with disconnections. The work printer is also controlled from a Vista computer so maybe some Windows update messed things up.

Cheers,
Bart

Quote
bgkdavis
One thing I have noticed with the Duet is it can be sensitive to other network traffic, I found that when I turned my TV on then my Printer would start shuddering and the connection would become unreliable, the eventual cause, was identified as my HDMI-LAN converters that allowed me to distribute SAT TV to other rooms in my house.

This problem was fixed in one of the newer firmware updates by changing the priority of the web server (or something like that), but I still notice disconnects when I put my printer on the domestic network, but when I put it on a Printer only network or direct connect to my laptop which doesn't have any other traffic then it works very reliably.

The thing to remember about the duet is it only has the one processor, and when you consider that its doing G-code interpretation, Driver management, running a web server and FTP server.... its getting pretty busy, and sometimes it drops the occasional ball, as long as the ball its dropping is only the web server then that's not too bad, its when your printing quality suffers you will have problems.

Hi bgdavis,

I'm ok with the Duet dropping the occasional ball, but when it starts dropping anything and everything that's not cuboid, it gets annoying!

I don't have much traffic on my home network (none that should be there or that I know of anyway) and I haven't had a disconnect in months. Until now.

What do you mean by saying that you direct connect to your laptop? Is there a way to plug a network cable straight into printer and PC with no switch inbetween?

Cheers,
Bart

Quote
dmould
A wired Ethernet LAN should not suffer too much from high network traffic between nodes that do not include the printer and web client. Congestion occurs when the traffic is passing through a common node - e.g. the Internet gateway, the "backbone" connection between two different hubs (switches) or WiFi connections via the same hotspot.

Regardless, a bad Ethernet connection should not cause any juddering or printing issues as it is used only for control during printing, not print data transfer.

Dave

Hi Dave,

As I said in my original post, the work printer and control PC are connected, both by cable, to a network switch, which itself is connected to a wall network socket. I have no control over what happens past the switch. In my limited knowledge of networking, I thought of replacing the switch with a router with DHCP/local IP adress allocation capabilities but I don't think work take kindly to us plugging our own routers into their network. I suppose I could always leave that router unplugged from the network (and use it as a printer and control PC-only local network) and plonk another network card into the PC and use that to connect to the university network. Would this idea work in terms of having a guaranteed congestion-free path from PC to printer?

As concerns my home printer (which, after many months of not a single disconnection, has now suddenly developed the same connection issues as the work one: both control PCs are Vista so I'm thinking maybe a recent Windows update messed things up?), it connects (by cable) to a network switch which itself is connected to my DSL router (the network switch is there because another computer is connected to it as well, but that computer is very rarely on and hasn't been on since the disconnection problems developed). The printer control PC connects to the DSL router via WiFi. The question remains: why has the setup worked flawlessly for several months and has only now started failing?

The problem is not causing any printing issues (once the print gets going) but not being able to monitor print progress or pause it (when planning a filament change at a specific point in the print) is starting to become a major issue.

Also (and this may be related to the problem at hand, or be a completely different subject), when the connection is not dropping and the web interface is working, some of the reported stats are wrong. For example, the print apparently starts at layer 2 (layer counter just below progress bar), first layer height is either "0.1" or "n/a" (it's not 0.1), and first layer time is either "n/a" or the counter never stops and increases synchronously with the total print time counter. This did not use to be the case...

Cheers,
Bart

Quote
bartdietrich

Quote
bgkdavis
One thing I have noticed with the Duet is it can be sensitive to other network traffic, I found that when I turned my TV on then my Printer would start shuddering and the connection would become unreliable, the eventual cause, was identified as my HDMI-LAN converters that allowed me to distribute SAT TV to other rooms in my house.

This problem was fixed in one of the newer firmware updates by changing the priority of the web server (or something like that), but I still notice disconnects when I put my printer on the domestic network, but when I put it on a Printer only network or direct connect to my laptop which doesn't have any other traffic then it works very reliably.

The thing to remember about the duet is it only has the one processor, and when you consider that its doing G-code interpretation, Driver management, running a web server and FTP server.... its getting pretty busy, and sometimes it drops the occasional ball, as long as the ball its dropping is only the web server then that's not too bad, its when your printing quality suffers you will have problems.

Hi bgdavis,

I'm ok with the Duet dropping the occasional ball, but when it starts dropping anything and everything that's not cuboid, it gets annoying!

I don't have much traffic on my home network (none that should be there or that I know of anyway) and I haven't had a disconnect in months. Until now.

What do you mean by saying that you direct connect to your laptop? Is there a way to plug a network cable straight into printer and PC with no switch inbetween?

Cheers,
Bart

Yes, I only suggest it as a diagnostic check, sometimes isolating everything helps.

First you need to reconfigure your config.g to fixed ip and give it an address like 192.168.1.14, then you need to do the same for they pcs network port just use a differnet ip address isq192.168.1.100, then you just run a regular network cable between the printer and your computers com port. And try and access the printer using the 192.168.1.14 address

---

RepRapPro Mendel 3 Tricolour
RepRapPro Fisher
-Carbon Arms
-Easy adjust Carriage+effector
-axis stiffness mods
HE3D -600 delta
-Duet 0.8.5
-PanelDue
-DC42 Height probe
-RobotDigg metal components
Simplyfy3D
RS Design Spark CAD

Quote
bgkdavis

Quote
bartdietrich

Quote
bgkdavis
One thing I have noticed with the Duet is it can be sensitive to other network traffic, I found that when I turned my TV on then my Printer would start shuddering and the connection would become unreliable, the eventual cause, was identified as my HDMI-LAN converters that allowed me to distribute SAT TV to other rooms in my house.

This problem was fixed in one of the newer firmware updates by changing the priority of the web server (or something like that), but I still notice disconnects when I put my printer on the domestic network, but when I put it on a Printer only network or direct connect to my laptop which doesn't have any other traffic then it works very reliably.

The thing to remember about the duet is it only has the one processor, and when you consider that its doing G-code interpretation, Driver management, running a web server and FTP server.... its getting pretty busy, and sometimes it drops the occasional ball, as long as the ball its dropping is only the web server then that's not too bad, its when your printing quality suffers you will have problems.

Hi bgdavis,

I'm ok with the Duet dropping the occasional ball, but when it starts dropping anything and everything that's not cuboid, it gets annoying!

I don't have much traffic on my home network (none that should be there or that I know of anyway) and I haven't had a disconnect in months. Until now.

What do you mean by saying that you direct connect to your laptop? Is there a way to plug a network cable straight into printer and PC with no switch inbetween?

Cheers,
Bart

Yes, I only suggest it as a diagnostic check, sometimes isolating everything helps.

First you need to reconfigure your config.g to fixed ip and give it an address like 192.168.1.14, then you need to do the same for they pcs network port just use a differnet ip address isq192.168.1.100, then you just run a regular network cable between the printer and your computers com port. And try and access the printer using the 192.168.1.14 address

Hi bg,

Ok thanks, I didn't know you could just put a network cable between computer and printer with no switch or router inbetween and have them still talk to each other. If that works, then that's the way I'm going to leave it. On the home setup, internet connectivity to the PC is via WiFi anyway so there's an unused network socket on it. As for the work setup, I'll just put another network card into the PC and use that to connect to the internet.

Cheers,
Bart

Quote
bartdietrich

Quote
FatFreddie
It could be this (http://forums.reprap.org/read.php?340,522632,522632#msg-522632) problem which Dave corrected a while ago.

Hi FatFreddie,

Ok, so I would need to change the firmware to dc42. I may do that, but that still doesn't explain why my home printer/computer were fine for several months and have now suddenly started having issues with disconnections. The work printer is also controlled from a Vista computer so maybe some Windows update messed things up.

Cheers,
Bart

Did you change from relative to absolute extruder movement?

Your problem seems to be the same as the one I had a few months ago.
It was solved for me by upgrading the firmware to dc42 or zpl's latest.
Just make sure you read the information about motor cable connections and sys changes on the sd card.

---

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
bartdietrich

Quote
dmould
A wired Ethernet LAN should not suffer too much from high network traffic between nodes that do not include the printer and web client. Congestion occurs when the traffic is passing through a common node - e.g. the Internet gateway, the "backbone" connection between two different hubs (switches) or WiFi connections via the same hotspot.

Regardless, a bad Ethernet connection should not cause any juddering or printing issues as it is used only for control during printing, not print data transfer.

Dave

Hi Dave,

As I said in my original post, the work printer and control PC are connected, both by cable, to a network switch, which itself is connected to a wall network socket. I have no control over what happens past the switch. In my limited knowledge of networking, I thought of replacing the switch with a router with DHCP/local IP adress allocation capabilities but I don't think work take kindly to us plugging our own routers into their network. I suppose I could always leave that router unplugged from the network (and use it as a printer and control PC-only local network) and plonk another network card into the PC and use that to connect to the university network. Would this idea work in terms of having a guaranteed congestion-free path from PC to printer?

For diagnoses, just unplug the wall connection just after you have connected to the printer and see whether the issue goes away. Also make very certain that you do not have an IP address conflict (the Duet using the same IP address as something else on your network). Maybe change the Duet IP address and see if it makes a difference.

Quote
bartdietrich
As concerns my home printer (which, after many months of not a single disconnection, has now suddenly developed the same connection issues as the work one: both control PCs are Vista so I'm thinking maybe a recent Windows update messed things up?), it connects (by cable) to a network switch which itself is connected to my DSL router (the network switch is there because another computer is connected to it as well, but that computer is very rarely on and hasn't been on since the disconnection problems developed). The printer control PC connects to the DSL router via WiFi. The question remains: why has the setup worked flawlessly for several months and has only now started failing?
Bart

Normal traffic on the wall or WiFi side of the switch will not affect the printer because the packets will not be passed through the switch to the printer. The exception are broadcast and multicast packets. There is a possibility that something on the network (possibly the PC itself or a router) has recently started creating a "broadcast storm" (lots of small broadcast packets in a very short period of time). On a relatively slow CPU this will often use up all the available LAN packet buffers faster than they can be processed. The firmware should be able to handle a LAN buffer overflow with little or no symptoms, but I've found many implementations of Ethernet driver code that doesn't handle overflows too well and can end up disabling the Ethernet functionality. A Wireshark trace (no need to have the printer connected) will detect whether there are periodic "broadcast storms" on your network. Handling a LAN buffer overflow is not that straightforward in firmware, and it is something that tends not to be extensively tested during development. If that is where the issue lay, it will be in the supplied libraries rather than the code developed for the Duet. Crude workarounds are (1) allocate more LAN buffers and/or (2) reset (re-initialise) the Ethernet driver whenever there has been no expected reply to a packet for X milliseconds or (3) use a "brute force" method of hooking the LAN buffer overflow interrupt and causing it to immediately completely re-initialise the Ethernet driver instead of using the library-supplied interrupt routine (all buffered packets will be lost, but the higher protocol should handle that OK).

In detail - a LAN buffer overflow is first detected by the Ethernet hardware. This results in the hardware receive section being immediately disabled, and a buffer overflow interrupt (or flag) generated. The interrupt/flag should result in the firmware initiating a process that first waits a reasonable time for the full buffers to be processed (emptied), then re-initialising the LAN buffer chain, clearing the overflow fault and re-starting the receive engine (which may require other operations such as re-initialising the LAN DMA engine and resetting various pointers etc. depending on specific hardware requirements). Getting it to recover reliably in all cases (especially a sustained broadcast storm where a second overflow can occur during the recovery process) is not as simple as it may first appear. Things are complicated in some cases by "clever" operating systems that monitor the Ethernet hardware and switch off the Ethernet clock when the Ethernet function is disabled (to save power). In that case the clock could be disabled by the OS supervisory function when the hardware auto-disables the Ethernet following a buffer overflow, but the recovery routine may fail to re-start the clock.

Dave

Edited 1 time(s). Last edit at 09/21/2015 08:23AM by dmould.

Hi all,

So following all the advice here, here's what I did:

I connected the home printer to the control PC directly via a network cable and turned the WiFi on the PC off: no chance of any other network traffic interfering with communications between PC and printer. This did not solve the problem as I got disconnections pretty much straight away again after starting a print.

Installing dc42's firmware (1.09k) on the other hand seems to have done the trick: not a single disconnection during a 5 hour print. I'll restore the setup to what it was before (with network switch etc) and hopefully it will still work, but so far it's looking good. This still does not answer the question why I had not a single problem for nearly 5 months and then the disconnections suddenly started, but don't look a gift horse in the mouth I guess eh.

On the work printer I installed zpl's firmware (1.09g): this did not seem to solve the problem, started getting disconnections straight away after starting a print. Installing dc42's firmware on the other hand seems to have got rid of the disconnections. Touch wood this will remain the case.

So thanks to everyone for their suggestions and time. Still have the problem that the web interface stats are wrong (prints start on layer 2, first layer time counter doesn't stop etc) but this will be the subject of another post.

Cheers,
Bart

Quote
bartdietrich
Installing dc42's firmware (1.09k) on the other hand seems to have done the trick: not a single disconnection during a 5 hour print. I'll restore the setup to what it was before (with network switch etc) and hopefully it will still work, but so far it's looking good. This still does not answer the question why I had not a single problem for nearly 5 months and then the disconnections suddenly started, but don't look a gift horse in the mouth I guess eh.Bart

It could be that a recent Windows update resulted in your PC's protocol stack changing in some way that triggered the symptom. There are many variables in the TCP/IP stack - window size, MCU size, timings and timeouts etc. Also PCs can sometimes generate the broadcast storms I have mentioned.

Dave

Hi Dave,

Thanks for your reply, I was typing my last message while you posted yours so didn't see yours straight away. I did mention a recent Windows update as a possible cause of the problem in my original post (especially considering that both printers are controlled from Vista machines) but no one took me up on it!

The problem seems to be solved now that I've installed dc42's firmware on both machines (we'll see if it lasts). Still having issues with the wrong stats being reported by the web interface, but I should probably start a new thread for that.

Cheers,
Bart

Can you check whether your slicer is using relative or absolute extrusion mode - the symptoms you describe mirror exactly my experience with absolute extrusion mode as mentioned in an earlier posting. Initially disconnects with the same message as you were getting and then when dc42 fixed the problem, incorrect stats.

Original thread

Hi FatFreddie,

I checked: the "use relative E distances" box in Slic3r is ticked, and there's also an M83 command in the start code, just in case I guess.

Bart