New firmware

Quote
dc42
I have just released version 052s-dc42 of my fork of the Duet firmware..

Ok
I will tray... printing now

Thanks dc42
Dario

---

Ormerod 187
Firmware Electronics: Duet 0.6
Firmware Version:1.18.1 (2017-04-07)
Web Interface Version:1.15a
Slic3r 1.2.9a and Simplify3D 4.0.0
[www.dropbox.com]

John, you are quite right, it's 't'!

I'll rename the binary. [Now done, see [github.com]]

Edited 2 time(s). Last edit at 03/05/2014 04:59PM 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].

Nice touches dc42, particular thanks for adding thermistor parameters. Briefly, what is the advantage of storing in flash by the way?

Cheers

Ray

Ray, I for one am finding parameter storage in non-volatile memory a huge help as it saves the faff of writing parameters into files on the SD card while tinkering with the hardware - there may be other advantages. Must remember to comment them out in the files though.

---

RS Components Reprap Ormerod No. 481

Quote
dc42
The hot end fan serves two functions:

1. To cool the heatsink, which in turn cools the nozzle, preventing the filament from melting too far up the nozzle;

2. To cool the work, at least when printing PLA (may not be desirable when printing ABS). For example, I think that fairly rapid cooling (or a lower extrusion temperature) is desirable when bridging.

Requirement (1) means that the hotend fan must be on all the time while the extruder is hot. The hotend/sensor board I have designed (and is currently awaiting completion of PCB fabrication) includes thermostatic hotend fan control, but only to turn the hotend fan off when the extruder is cold.

I was printing for some time with the vents around the HotEnd blanked off. So in my replacement Fan Duct Mk1 (that kills BackWash) the duct doesn't have them.... And no reports that it doesn't work not having them.....

BTW I will be releasing a sexy, LED connection protection shroud addon very soon....Prob... Later today... It will cover up the LED connectors if people do what I have done... Mounted a 3 LED strip under the Ducting... Trust me.... Mounting the LED strip under the Duct IS worth doing...
The LEDs are Magic.....

DC I have a plan for a dual filament head...in my head... fancy doing a co-op on getting it up and running.... It's Simple (well I think at the moment)....
and I really don't think it will involve a BIG expansion card..... (I don't want to say more at this stage.... lets chat in Private)...
Kim..

---

Please send me a PM if you have suggestions, or problems with Big Blue 360.
I won't see comments in threads, as I move around to much.
Working Link to Big Blue 360 Complete

@dc42 - Might be a firmware bug, the Temp reported by the rr_poll and the temp reported by M105 are different

Quote
Serial monitor
JSON response: {"poll":["I","21.3","-1.1","0.00","0.00","0.00","0.0000"],"probe":"12","buff":900,"hx":0,"hy":0,"hz":0,"seq":28,"resp":"T:-1.1 B:21.3"} queued
HTTP request: GET /rr_poll HTTP/1.1
JSON response: {"poll":["I","21.3","-0.3","0.00","0.00","0.00","0.0000"],"probe":"12","buff":900,"hx":0,"hy":0,"hz":0,"seq":28,"resp":"T:-1.1 B:21.3"} queued
HTTP request: GET /rr_poll HTTP/1.1
JSON response: {"poll":["I","21.3","-2.0","0.00","0.00","0.00","0.0000"],"probe":"12","buff":900,"hx":0,"hy":0,"hz":0,"seq":28,"resp":"T:-1.1 B:21.3"} queued
HTTP request: GET /rr_poll HTTP/1.1
JSON response: {"poll":["I","21.3","-1.1","0.00","0.00","0.00","0.0000"],"probe":"12","buff":900,"hx":0,"hy":0,"hz":0,"seq":28,"resp":"T:-1.1 B:21.3"} queued
HTTP request: GET /rr_poll HTTP/1.1
JSON response: {"poll":["I","21.3","-0.3","0.00","0.00","0.00","0.0000"],"probe":"12","buff":900,"hx":0,"hy":0,"hz":0,"seq":28,"resp":"T:-1.1 B:21.3"} queued
HTTP request: GET /rr_poll HTTP/1.1
JSON response: {"poll":["I","21.3","-0.3","0.00","0.00","0.00","0.0000"],"probe":"12","buff":900,"hx":0,"hy":0,"hz":0,"seq":28,"resp":"T:-1.1 B:21.3"} queued

Matt

---

Limited Edition Red RS Ormerod 1 #144 of 200 - RRP 1.09fw
iamburnys Ormerod Upgrades Github
Follow me on ThingiVerse My Designs

Matt, the temps agree in the first of those responses. Subsequent responses just return a copy of the response to the last command, whatever it was. Therefore, the temperatures in the "resp" variable are stale in the later responses. You would have to send M105 commands continuously to keep them in step.

---

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

M304 R100000 B4096 works perfect for my bed
only 10 degree to low

bed and hotend

@dc42 - ah yes of course, apologies I forgot the resp is previous command response not the current value, sorry

Matt

---

Limited Edition Red RS Ormerod 1 #144 of 200 - RRP 1.09fw
iamburnys Ormerod Upgrades Github
Follow me on ThingiVerse My Designs

Just installed the new firmware, a big thank you dc42 for your time and effort creating this, i've read good things.

One issue I've found (it might not be related) when i go to home my Zaxis to start the Z probe. it wont go to the set position of X60 Y-1..................... Sorry just read page 2 of the thread, all explained...

Edited 1 time(s). Last edit at 03/07/2014 04:49PM by 88Zombies.

Hi Cameron,
I loaded the version 057q and its cheese and chalk between the 057 version I loaded, really good and thanks, I will read up on your later version and see if its good to load,
cheers
Gary

Genius!

I'm pleased to report that DC42 't' firmware has enabled me to print a part ( well OK its still printing but has printed perfectly so far way past a part of the print that failed 2x previously using the latest official fiirmware. Using the official firmware on tight undercut caused it to barf and slip in y.

During printing using the original firmware at various points prior to the big failure, you could hear a clunk which must have meant something wasnt right. When the y steps were missed, the clunk was consuistent and louder.

With DC42's firmware there is overal a much more satisfying "whooze". sound. I'm guessing this is due to improved control of the acceleration!

Thanks DC42. Great stuff

regards
Andy

---

Ormerod #318
www.zoomworks.org - Free and Open Source Stuff

Just a quick thanks to DC42 for the new firmware (t), I finally took the plunge and dropped the plain vanilla RRP firmware and it was well worth it.

I managed to print a very nice job direct from pronterface last night, a vast improvement over uploading and you get the nice indicator of progress made on-screen too.

---

Another RS Ormerod Mk1 meets the world

Retired now but I used to make....
CNC Machined Mk1 aluminium bed support plates for the Ormerod
CNC machined X-plates and ribs for Mk1 & Mk2 Ormerods
CNC machined bed support arms for the Mk2 Ormerod.
Dual Hot-End heatsink blocks.

Hi Dave, that's an interesting Plumber Block, what are the plans for it?

---

Please send me a PM if you have suggestions, or problems with Big Blue 360.
I won't see comments in threads, as I move around to much.
Working Link to Big Blue 360 Complete

Hello again,
I think I found another (minor) bug: After a print finishes, the maximum Z acceleration and/or feedrate is messed up. That means the Z axis moves too fast and I get skipped steps. I use custom accelerations/feedrates - except for the Z axis - and this combination works fine until I try to lower the nozzle using G1 after a print has finished.

At the moment I'm using version 0.57t, but I'll update to 0.57u as soon as my print finishes.

Thanks again for your hard work, I couldn't imagine my Ormerod running without your firmware any more

Hi zombiepl, can you post the gcode file you were printing when this happened, or at least the last 200 or so lines?

---

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
KimBrown
Hi Dave, that's an interesting Plumber Block, what are the plans for it?

It's going on a CNC plasma table I'm building, needs to be split as the shaft is already fitted. I would have spent a day making it in the shop without knowing it would work or not, with the ormerod it was a two hour print and job done at least for now. It's a low stressed part so should be ideal.

---

Another RS Ormerod Mk1 meets the world

Retired now but I used to make....
CNC Machined Mk1 aluminium bed support plates for the Ormerod
CNC machined X-plates and ribs for Mk1 & Mk2 Ormerods
CNC machined bed support arms for the Mk2 Ormerod.
Dual Hot-End heatsink blocks.

Quote
dc42
Hi zombiepl, can you post the gcode file you were printing when this happened, or at least the last 200 or so lines?

Sure, there you go:
First 200 lines: [pastebin.com]
Last 200 lines: [pastebin.com]

My current feedrates and accelerations look like this:

M203 X15000 Y15000 Z300 E6000
M201 X1000 Y1000 Z10 E1000

Quote
dc42
Hi zombiepl, can you post the gcode file you were printing when this happened, or at least the last 200 or so lines?

zombiepantslol's observation is consistent with one I hinted at but didn't go into in the (I think) Cura thread when I mentioned that there were other issues as well as combined x/y/z moves I mentioned a potential issue with next/previous - what I've observed is that manual movement speeds are affected by the previous manual move - [edit - I type too slow!if zombiepanstlol doesn't come up with some gcodes,/edit] I'll see if I can come up with a reproducible test.
Briefly though, I have manual movement set to 1200mm/min on X and Y in repetier, and Z moves at 150mm/min (so if I hit the move Y -100mm button, it sends " G1 Y-100.00 F1200.00 " etc) - my caps for x,y and z speed are set as follows : M203 X5000 Y5000 Z200 E6000 . If I move X by 100, then y by 100, I get slow controlled movement, if I then move Z it's also seems to be at the expected speed - if I then move X or Y by 100mm after a Z, the first move is at a much higher rate (probably the 5000 cap), then all subsequent moves seem normal until I move Z again then the next x/y move is faster- it could be that Z following X or Y is also faster, but I'm not sure (the difference between 150 and 200 isn't that great).

I'm not sure that any of your changes are causing this, but now that we can use higher speeds, the effect is noticeable.

Ray

Edited 1 time(s). Last edit at 03/18/2014 05:39PM by rayhicks.

Okay, forget about the issue I reported. Seems like the feedrate specified in a simple X/Y G1 movement also affects the following Z moves and my maximum Z feedrate was simply too high. Now I'm back at 200mm/min and I don't get missed steps any more. Sorry about that.

Nonetheless, I can confirm rayhicks' observation. While printing, I've noticed the first XY movement after each layer change happens much quicker than specified in Slic3r or Cura and seems to be only limited by the firmware maximums. To reproduce this issue, limit all speeds to, say, 20mm/s in Slic3r, slice some STL file and print it.

Hello Everybody,
I have noticed that the printer is not doing any acxis-compensation while printing after the firmware update.
Is it my fault, or has anyone else noticed it?

Quote
zombiepantslol
Nonetheless, I can confirm rayhicks' observation. While printing, I've noticed the first XY movement after each layer change happens much quicker than specified in Slic3r or Cura and seems to be only limited by the firmware maximums. To reproduce this issue, limit all speeds to, say, 20mm/s in Slic3r, slice some STL file and print it.

I've tracked this problem down. There is a minimum XY feed rate of 15mm/sec, but what actually happens is that if an XY move with a low feed rate occurs after a Z move, the feed rate ends up as about 48. The velocity calculation in the ISR is going wrong because the preceding Z move caused the start velocity to be set very low. I'm now trying to work out the safest way to fix this without breaking anything else.

---

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

Aha! that probably explains the clunk I often hear at a layer change. I have been looking for problems in my Z axis - and couldn't understand why Z moves made for bed compensation and when moving manually did not make the sound.

I'm also looking at what I think is an acceleration artefact on my prints - I'll do some test prints and post the results to a separate thread after the weekend.

Dave
(#106)

Hi dc42,
This morning I tried the "r" firmware version .... I had connection problems..
Pronterface waiting for connection.... forever... after restart all I got the same experience.
I tried to reinstall the "r" firmware but I had the same problem.
I've only tried with windows 7.
Back to the "t" version everything works fine. (I printed a lot with the "t" version)

Many thanks for your work.... I'm really happy with your firmware!

Dario

---

Ormerod 187
Firmware Electronics: Duet 0.6
Firmware Version:1.18.1 (2017-04-07)
Web Interface Version:1.15a
Slic3r 1.2.9a and Simplify3D 4.0.0
[www.dropbox.com]

Hi Dario,

Did you download the firmware by clicking on the link and pressing the Raw button? If not, you probably got the HTML file. When flashing the firmware, bossac should report about 174K bytes and about 680 pages.

I presume you meant the x version, not the r version?

---

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

Hi David,
yes... the X version.... sorry....

Tonight I'll try again ... if I am the only one having this problem is probably my only problem

Dario

Edited 1 time(s). Last edit at 03/28/2014 10:30AM by Ormerod187.

---

Ormerod 187
Firmware Electronics: Duet 0.6
Firmware Version:1.18.1 (2017-04-07)
Web Interface Version:1.15a
Slic3r 1.2.9a and Simplify3D 4.0.0
[www.dropbox.com]

Well, the "w" firmware certainly seems to have fixed a bug. I had overlooked the fact that I had downgraded to "t" when I printed a part with "wipe on retract" set in Slic3r. The base of the part had no retracts and printed fine. When it got to the layers with more detail, each retract (without layer change) caused a big clunking sound, and it soon became obvious that the Y motor was being driven too fast and stalling on every "wipe" operation. The first photo shows the result.

Updating the firmware with "w" and printing the same G file resulted in the print of the second photo - which is printed correctly. I was already printing when I saw that "x" is now released, so I'll load that now.

Thanks for the fix, DC42.

Dave
(#106)

Hi,
I am a relative newcomer to the Ormerod printer, but getting things most going OK, one problem I have is little "spider webs" when the head moves and is not suppose to print as shown in the phot of the sheep, I downloaded the STL file then converted it to a GCODE file using slic3r, I am using vertion 057t-dc42.bin, is this problem a software or setup problem,
Cheers
Gary

Do you have retraction set to 4mm (or greater) in slic3r? What extrusion temperature are you using?

---

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

Hi DC-42,
I just found that parameter in slic3r, it was set to 1 so I set it to 2 and it was a lot better, I will try 4mm, I have the extruder temp set to 205 and had the bed at 65, but just reset it to 57, as when it was printing the belly of the sheep, it knocked one of the legs over, also I think that there is not enough air cooling getting to the extruder hotend and the plastic stays soft for too long,, I have attached the ini file I use with the slic3r, I', running the 057y-dc42.bin now,
cheers
Gary

Edited 1 time(s). Last edit at 03/28/2014 08:56PM by Gyro.