New firmware

Re: New firmware

dc42 — Sun, 30 Mar 2014 03:33:49 -0400

For prints which have difficulty sticking, I recommend printing on glass painted with solvent pipe cement. Good bridging depends on good cooling from the fan duct outlets, and using just the right extrusion temperature.

Re: New firmware

Gyro — Sat, 29 Mar 2014 23:05:27 -0400

Hi Dave and DC42,
I've tried a lot of parmeters (in slic3r) on a print that thr Ormerod finds hard to do, its a sheep and the 4 legs don't stick to the bed too well, so I tried just the glass and it had less stick, so I found by increasing the first layer height to 150% ( of 0.24mm) and also put a brim around the legs of 2mm with the tape on the glass, seemed to work OK (bed start temp 65 hotend at 200 then the bed to 60 and hotend to 195) , but then it came to the sheeps belly, and the printer tries to print its belly in mid air, and consequently left a quite a few "worms" of PLA before it joined it all together, I tried parameters of "support" etc but I didn't know how to make it print that bit right, got 4mm of retraction and that seems OK no stringy bits, I couldn't attached the sheep stl file as it was too large,
cheers
Gary

Re: New firmware

Davek0974 — Sat, 29 Mar 2014 04:53:48 -0400

Is this PLA, if so try 65 for the bed first layer then 60, 195 for hot end first layer then 190.

The 4mm retract really helps too.

Re: New firmware

dc42 — Sat, 29 Mar 2014 04:01:22 -0400

205C is a little too hot. RRP recommended that when they had the wrong thermistor parameters in the firmware. You will get less stringing at lower temperatures. I use 195C first layer and 190C other layers. Some users use lower. The bed temperature is less critical, it just needs to be hot enough for the print to stick.

Re: New firmware

Gyro — Fri, 28 Mar 2014 20:55:24 -0400

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

Re: New firmware

dc42 — Fri, 28 Mar 2014 19:42:56 -0400

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

Re: New firmware

Gyro — Fri, 28 Mar 2014 19:20:18 -0400

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

Re: New firmware

dmould — Fri, 28 Mar 2014 11:13:10 -0400

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)

Re: New firmware

Ormerod187 — Fri, 28 Mar 2014 09:59:31 -0400

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

Re: New firmware

dc42 — Fri, 28 Mar 2014 09:44:52 -0400

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?

Re: New firmware

Ormerod187 — Fri, 28 Mar 2014 08:29:54 -0400

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

Re: New firmware

dmould — Fri, 21 Mar 2014 13:34:23 -0400

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)

Re: New firmware

dc42 — Thu, 20 Mar 2014 18:16:08 -0400

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.

Re: New firmware

Ormerod1234 — Wed, 19 Mar 2014 14:34:15 -0400

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?

Re: New firmware

chrishamm — Tue, 18 Mar 2014 18:18:37 -0400

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.

Re: New firmware

rayhicks — Tue, 18 Mar 2014 17:37:13 -0400

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

Re: New firmware

chrishamm — Tue, 18 Mar 2014 17:01:07 -0400

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

Re: New firmware

Davek0974 — Tue, 18 Mar 2014 15:34:18 -0400

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.

Re: New firmware

dc42 — Tue, 18 Mar 2014 15:27:04 -0400

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

Re: New firmware

chrishamm — Tue, 18 Mar 2014 13:46:58 -0400

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 :)

Re: New firmware

KimBrown — Tue, 18 Mar 2014 06:06:47 -0400

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

Re: New firmware

Davek0974 — Tue, 18 Mar 2014 05:10:26 -0400

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.

Re: New firmware

kwikius — Sat, 15 Mar 2014 04:53:29 -0400

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

Re: New firmware

Gyro — Sat, 08 Mar 2014 06:03:42 -0500

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

Re: New firmware

88Zombies — Fri, 07 Mar 2014 16:41:13 -0500

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

Re: New firmware

iamburny — Fri, 07 Mar 2014 15:17:01 -0500

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

Matt

Re: New firmware

Le-Seaw — Fri, 07 Mar 2014 14:56:27 -0500

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

bed and hotend

Re: New firmware

dc42 — Fri, 07 Mar 2014 14:39:27 -0500

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.

Re: New firmware

iamburny — Fri, 07 Mar 2014 13:33:25 -0500

@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

Re: New firmware

KimBrown — Fri, 07 Mar 2014 00:48:39 -0500

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