Uncontrolled heating

Hi,
I am having this worrying issue on my Ormerdo: Whenever a file is uploaded by serial connection when it is then printed the machine would stop somewhere during the print and turn off the nozzle heather whilst turning the bed heater to full power.
No big deal, tho it would be a HUGE one if the other way round happens!
Hints?

Which firmware are you running? With some firmwares, that can happen if the PC attached by USB goes into sleep mode, or if you connect other USB devices. And yes, it sometimes happens the other way round.

---

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].

RepRap Firmware 0.78 from 11-06-2014.

Beside uploading files to Sd card via plugging it out and sticking it in the pc (I just read dc42`s explanation about connection brdiging, but havent found out how to upload files via web interface) how can I be sure that this is not going to happen again?
Id be really upset if the hotend gets damaged by such a bug! Isn`t there some watchdog timer in place that prevents the thing from stalling / a rtos with a thread dedidcated to safety?

Anyway ,it happened once with the pc up & running and once halfaway into the print with the cable unplugged (I did unplug it after a few mins of printing), the only common thing was having uploaded the gcode via pronterface.
How should I do to prevent this prom happening again?
thanks!

Quote
Ludo91
How should I do to prevent this prom happening again?
thanks!

How I Learned to Stop Worrying and leave-alone-whilst-printing/love the Ormerod:

dc42's firmware + Hot end board with differential modulated IR Z-sensor

Erik :-)

How these two increase security?

Yes, several months ago I didn't dare to leave my printer alone while using the official RRP firmware. Actually I find it quite horrible to see that RRP still hasn't managed to merge in dc42's watchdog changes and that they don't seem to care at all about potential firmware lock-ups, but that's really only one of the reasons dc42 and I maintain our own firmware forks. So if you're interested in more functionality and more saftey features, you should try out a third-party Duet firmware.

[edit]A watchdog basically checks if the firmware is still running and if it hangs up for some reason, it will reset the firmware and turn off the heaters. A must-have feature for good 3D printer electronics IMHO.[/edit]

Edited 1 time(s). Last edit at 12/21/2014 07:32AM by zombiepantslol.

I know what a WDT is, and I am very glad you implemented it in you firmware. I am trying that out soon, being able to leave it unattended in safety is a musst for me.

You may want to check out Miosix open source RTOS, [miosix.org] , it is being developed by a uberskilled PhD at my university and I think may be a great think on the rrp

In fact there are 2 watchdogs in my fork of the firmware (and zpl's, which started out as a fork of my fork). The software one uses the tick interrupt to check that the main loop doesn't get stuck for too long. The hardware one checks that the tick interrupt is still working. Additional, we do over-temperature checks in the tick interrupt, in addition to the standard ones in the main loop.

However, the problem I think you have hit is that in the RRP firmware, if the USB interface stops accepting data because e.g. the PC goes to sleep or you disconnect the cable, and then the printer tries to send data to USB, it blocks - causing temperature control to be lost. I fixed this in my fork many months ago.

I've considered whether using an RTOS would offer any benefit, but if I do go that route then I would probably look at FreeRtos first, because it is the standard for this sort of project and it is supported by the Lwip subsystem used to provide TCP/IP support in the firmware. Even with an RTOS, the new movement code I am working on would probably still need to generate the step pulses in the tick interrupt, because a full context switch at that point would take too long.

Edited 1 time(s). Last edit at 12/21/2014 09:59AM by dc42.

---

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].

Couldn`t be more clear. Thankyou!

I`ll look forward to use your firmware then / wait for RRP to implement those safety things if thats gonna happen anytime soon.

Only thing that stops me from going from rrp fw to yours is that it is not really clear to me if I`ll have to rewire something/ re-do .g files that I already use with this fw

If you are already using RRP 0.78c firmware, then when switching to my fork you don't need to rewire anything or change your config or homing files. But if you use the web interface, you will need to change the web files on the SD card.

Going from 0.78 to either 0.78c or my fork, you need to either reverse the X motor connector on the Duet so that it is the same way round as the other motor connectors, or add M569 P0 S1 to your config.g file, otherwise the X axis will move the wrong way.

Edited 1 time(s). Last edit at 12/21/2014 10:42AM by dc42.

---

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].

Quote
dc42
Going from 0.78 to either 0.78c or my fork, you need to either reverse the X motor connector on the Duet so that it is the same way round as the other motor connectors, or add M569 P0 S1 to your config.g file, otherwise the X axis will move the wrong way.

... but only in case you have an Ormerod 1. Both dc42's and my firmware fork assume your wiring matches the official Ormerod 2 wiring as seen here. If you decide to try out my fork, make sure you also copy my three new macro files (pause.g, resume.g and reset.g) into your /sys directory. You may use FTP to do this as well.

Quote
Ludo91
... / wait for RRP to implement those safety things if thats gonna happen anytime soon...

Don't count on it!



Erik

Nice one Erik, I've been waiting to get an "official" review from Adrian about my firmware fork since the beginning of November :-) Somehow I doubt this is ever going to happen. Apparently RRP's number one priority right now is abusing the cooling fan RPM pin to implement M571 (do something on extrude on/off).

Quote
zombiepantslol
Nice one Erik, I've been waiting to get an "official" review from Adrian about my firmware fork since the beginning of November :-) Somehow I doubt this is ever going to happen...

Well at least they finally changed the material for the bed, that fluffy thing was da pain...



Erik