Welcome! Log In Create A New Profile

Advanced

New experimental firmware 0.78v-dc42 and web interface 1.03

Posted by dc42 
New experimental firmware 0.78v-dc42 and web interface 1.03
November 01, 2014 11:06AM
I have released this firmware at [github.com] (click on the Raw button to download). This is a minor update. The changes are:

Quote

* The M0 command no longer turns the motors off. The M1 command still does. This brings my fork into line with zpl's.

* The M18 and M84 commands now allow selective disabling of motors (thanks to zpl for this one)

* The code has been updated to permit compilation with newer versions of gcc. However, there is a problem with the free memory calculation when the newer compiler is used, so for now I am still using the original one.

* There are now separate SD-Image/sys folders in my repository for Ormerod 1 and Ormerod 2. Choose the one appropriate to your machine. Alternative, if you don't want to allow negative X coordinates and set X=0 to be at the edge of the bed, use the appropriate files from RepRapPro's 0.78c version.

As usual, see [github.com] for a full list of differences from RepRapPro 0.78c.

Web interface 1.03 is now available at [github.com]. Only reprap.htm and reprap.js have changed since 1.02. The changes are:

Quote

* If the Reset button is pressed after pausing a print, the heater temperatures are not reset, and command M0 is sent instead of M1.

The net result of these changes is that if you Pause a print and then Reset, the drives are not disabled, you do not need to re-home the axes, and although the heaters are turned off the temperatures are not reset. This makes it easier to prepare to start a new print. The same thing happens at the end of a print if you use M0 in your end gcode. If you want to turn the motors off as well at the end of a print, use M1 in your end gcode instead of M0.

I have the following firmware changes planned for the future, although it may be some time before I implement them:

1. Finish support for the UART serial interface, to support the TFT control panel I am making;

2. Change the Move code to pre-compensate for elasticity in the Bowden extruder system. I hope this will improve the print quality, of top surfaces in particular.

EDIT: I've updated the firmware again, to 0.78v-dc42. I hadn't noticed that zpl's code was leaving the heaters on standby and the bed heater on when M0 is executed. It's doubtful whether the bed heater should remain on, and on a multi-head machine the heaters are best not left on standby, especially at the end of a print. So I've changed it to turn all heaters off in 0.78v which is what I originally intended.

Edited 1 time(s). Last edit at 11/01/2014 11:46AM 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].
Re: New experimental firmware 0.78v-dc42 and web interface 1.03
November 01, 2014 02:31PM
Hi dc42, nice to see you're making progress on your firmware fork smiling smiley

Quote
dc42
2. Change the Move code to pre-compensate for elasticity in the Bowden extruder system. I hope this will improve the print quality, of top surfaces in particular.

I'm really looking forward to having a working bowden elasticity compensation and I'd like to support you, but then I need to know some details about how you're planning to implement it. And my main goal would rather be to improve the way sharp edges are printed at higher speeds (>20mm/sec), since they seem to become somewhat blurry at the present time (and unless you're using Simplify3D which can already compensate for this).

Quote
dc42
It's doubtful whether the bed heater should remain on, and on a multi-head machine the heaters are best not left on standby, especially at the end of a print

Yes, basically you're right, but in my opinion it can be quite valuable to leave the heated bed on when a paused print is reset, especially when printing ABS at a first layer temperature of 120°. I've just had an idea though: Why not check if the print is paused at the time M0 is called and only turn off all heaters if it isn't? That would be clean and simple, which is why I'm going to implement it this way in my next firmware release.
Re: New experimental firmware 0.78v-dc42 and web interface 1.03
November 01, 2014 03:04PM
DC42 thanks for your efforts, looking forward to the Bowden improvements.

Z Pl, great suggestion. My idea would be to have a setup page on the Web interface so that users could decide which features they want from a series of options.


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
Re: New experimental firmware 0.78v-dc42 and web interface 1.03
November 01, 2014 04:00PM
I don't like the idea of making the behaviour of M1 depend on past history. I think it would be better to add an S parameter to M1 (and perhaps M0 too) to specify what you want to turn off, if it isn't everything.



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].
Re: New experimental firmware 0.78v-dc42 and web interface 1.03
November 13, 2014 07:17AM
Hi Ormerodders, very new to 3d printing and all that goes with it, which is MUCH more than I imagined! I am not sure this is the correct thread , but I did download the version of 'Ianmburnys _extruder_gears_with_adjustable_hole_sizes' which I think DC42 modified and posted. Anyhow after having the problem that was supposed to help, I could not get the change of hole size to work, so thought 'make it huge and see what happens, the problem turned out to be in the mirror of the small gear, the 'bore_diameter' was set to 5.2 NOT the 'spindleDiameter', once I changed that everything was fine and I could adjust the bore to a fittable level.
I purchased my Ormerod 1 from RS here in Australia 2 months ago (2 weeks before they released the Ormerod 2!), and have had a great time learning to use the software around the device, apart from the Ormerod itself. One change I have made, as I use ABS as well as PLA, is to make a removable duct for the heatsink exhaust, so to use ABS I just remove the duct and the airstream just blows away from the unit, and not onto the bed. However having seen the single piece ducts, I am now thinking of two hotends instead, 1 ABS & 1 PLA.
I am using a 600watt power supply set to 12.8v which I now realise is gross overkill, but it does allow ABS printing with ease, the bed will heat at 10c per minute to over 100c, so reaching 110c is no problem, I daresay it could continue until everything caught fire, so I do watch carefully and do not run un-attended! I also have a volt/ammeter in the line and have confirmed that with everything on 20 amps would seem to be absolute maximum draw.
Thanks for the great support in the forums, I currently run ZPL's 0.96b software with 1.06 web interface and find the web interface great to use.
Initially I used the design software from RS 'Design Spark Mechanical' and find that in conjunction with OpenSCAD It provides most of what I need, to feed Slic3R with models.
I anyone is interested in the removeable duct let me know and I will post the STLs.
Re: New experimental firmware 0.78v-dc42 and web interface 1.03
November 13, 2014 07:41AM
Motoray, thanks for pointing out the error in the in OpenScad model for the big gear. I'll upload a corrected 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].
Re: New experimental firmware 0.78v-dc42 and web interface 1.03
November 18, 2014 04:43PM
Hi DC, Ive just flashed my firmware to your 0.78v-dc42, and I can not home X axis. Now when I press +10 the hot end goes toward the motor (prior to the flash it went towards the end - away from the motor), and when I press home X the hot end goes all the way towards the end and jams there, does not go back. What did I miss?

Edited 1 time(s). Last edit at 11/18/2014 04:52PM by Sardi.
Re: New experimental firmware 0.78v-dc42 and web interface 1.03
November 18, 2014 05:11PM
Sounds like you're missing this line in your config.g file:

M569 P0 S1                          ; Reverse the X motor
Re: New experimental firmware 0.78v-dc42 and web interface 1.03
November 18, 2014 05:20PM
You were right zombie, thnx winking smiley
Re: New experimental firmware 0.78v-dc42 and web interface 1.03
November 19, 2014 02:25AM
Alternatively, you can reverse the order of the X motor connector on the Duet, so that it matches the other motor looms (as on the Ormerod 2).



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].
Re: New experimental firmware 0.78v-dc42 and web interface 1.03
November 20, 2014 05:03PM
Hi

I have been doing some test prints with your firmware release. First i am pretty new to 3d printing so my only other experience comes from the newest stock firmware from two weeks ago.
Observations:
  • The hotend takes longer to reach temp, which creates more ozing. I guess the printhead needs to be parked direct above the printbed to avoid this. This is the only thing which was better with stock in my observations.
  • While with stock i had to set the filament multiplier to 0.91 to have some good prints i had to set it back to 1. To get good prints. I guess stock firmware is a little of in this regard as i calibrated the
    firmware in the beginning
  • File upload is much more reliable and faster!. I had repeated lockups with the stock firmware.
  • The progress bar looked promising but wasn't to usefull for my prints even when using slic3r 1.1.7.
  • The regulator sliders for speed and extruders look interesting but i haven't touched them yet.

I had no lockups with this firmware so far. So hopefully my lockups where not hardware but firmware related.

One improvment comes to my mind and that is to heat up the bed when a new print file is uploaded? That would fit at least pretty good to my workflow.

Kudos, all in all a pretty solid improvment to stock firmware.
Re: New experimental firmware 0.78v-dc42 and web interface 1.03
November 20, 2014 05:36PM
Hi, I'm also new(ish) to DC's firmware and your observations match what I have seen.

The hot end temp is PID controlled, and you can alter the parameters. When I first installed the firmware I noticed it was tuned to never overshoot which is, (in my opinion) a good thing. I'm reluctant to advise how to tune the PID loop, but if you posted a screen grab of the temperature graph someone might advise how to speed it up. It does seem to get to T-15 degrees in less than a minute, then take another minute or so to start printing but I'm happy with that. I usually use the time to collect the ooze.

I normally set the bed temp to 65C before I begin to transfer the file, because the bed is really slow to heat. Have you tried setting it to 100 degrees for ABS? I don't think it would ever get there.
Re: New experimental firmware 0.78v-dc42 and web interface 1.03
November 21, 2014 06:24AM
I am having new issues after firware upgrade:

1) everything resets itself after the print is finished - I have to home all 3 axis cause their button turns orange.
2) I can not control my extruder via web interface.
Re: New experimental firmware 0.78v-dc42 and web interface 1.03
November 21, 2014 07:23AM
1) Remove M0, M1, M18 and/or M84 from your end gcode, whichever is present at the end of your gcode file. But be aware your heaters won't turn off unless you specify additional codes.

2) Your tool must be selected to do this. Click on "Head 1" so that it is active or send T1 to your printer.
Re: New experimental firmware 0.78v-dc42 and web interface 1.03
November 21, 2014 07:25AM
Quote
MikeyD
I normally set the bed temp to 65C before I begin to transfer the file, because the bed is really slow to heat. Have you tried setting it to 100 degrees for ABS? I don't think it would ever get there.

The bed is not PWM controlled like the hotend is, it is bang-bang like a thermostat. It does indeed struggle to get to ABS temperatures (I use 110 deg) if you have the original PSU, but after I installed a 30 amp 12V LED PSU, which I adjusted to give 14V output, it gets to temperature within a reasonable time. Like yourself, setting the bed temperature is the first thing I do after switching on the printer. Usually I then have sufficient other tasks to do (slicing the design, uploading the G-code, feeding in the filament, making a cup of coffee or opening a beer) that the bed is up to temperature by the time I am ready to start the print.

Dave
Re: New experimental firmware 0.78v-dc42 and web interface 1.03
November 21, 2014 08:01AM
Quote
Sardi
I am having new issues after firware upgrade:

1) everything resets itself after the print is finished - I have to home all 3 axis cause their button turns orange.

That depends on exactly which firmware you are using and what is in your end gcode. In release 0.78u and later, M0 does not turn the motors off (just as in zpl's fork), so the the axes remain homed. I suspect you are running a slightly older version of my firmware than that, or else you have M1 in your end gcode instead of M0.

Quote
Sardi
2) I can not control my extruder via web interface.

You probably don't have the print head selected. What does the head state underneath "Head 1" say? If it doesn't say "active", click on "Head 1" to make it active (this sends a T1 command).

Edited 3 time(s). Last edit at 11/21/2014 08:03AM 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].
Re: New experimental firmware 0.78v-dc42 and web interface 1.03
November 21, 2014 08:32AM
Thanks for that DC. Also, another question - when I press Motors Off, X-Y-Z buttons turn orange and I have to home the axis again. Is there a way to fix that? I like to turn off the engines while not printing but dont want to home them every time afterwards.
Re: New experimental firmware 0.78v-dc42 and web interface 1.03
November 21, 2014 09:19AM
That behaviour is intentional, because when you turn the motors off, you can move the bed by hand and the axis references become invalid. But I can that see there are times when you don't want that.



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].
Re: New experimental firmware 0.78v-dc42 and web interface 1.03
November 21, 2014 09:31AM
Ok DC, thanks a lot! thumbs up
Re: New experimental firmware 0.78v-dc42 and web interface 1.03
November 21, 2014 09:57AM
Quote
dc42
That behaviour is intentional, because when you turn the motors off, you can move the bed by hand and the axis references become invalid. But I can that see there are times when you don't want that.

Not only that, but when the motors are turned back on it is quite possible that they will flip a step in one direction or the other.

Dave
Re: New experimental firmware 0.78v-dc42 and web interface 1.03
November 23, 2014 03:11PM
Hi all,

I'm trying this new firmware too and faces a hot end warming issue : the hot bed reaches its temperature within approximately 3 to 4 minutes, then the hot end starts warming and suddenly goes inactive. Some tests showed me that this happens always after exactly 2mn of warming.
I found the M570 command to get/set the heater timeout : it is actually set to 120s. Good news, this is exactly the M570 setting.

Did I miss something with the configuration to warm more quickly ? I've seen parameters about the thermistances, but as I'm not sure of the intervals of usable values, I changed nothing to them.
I'm using an Ormerod mk1 (bought last May).

I also faced the reversed X axis coordinates but found quickly zombiepantslol answer above. I think it could be a good idea to add a few comments to the config.g file to help new comers to better understand what's going on and solve such issues. Something like the following :
; If the hot end goes inactive whithout reaching its nominal temperature, try raising the heater timeout (default is 120s)
;M570 S240                ; set heater timeout to 240s

; X axis direction : S0 (default) "0 is far from Duet, +xx move the head closer to the Duet", S1 "0 is close to the Duet, +xx move the head away from the Duet"
;M569 P0 S1

Patrice
Re: New experimental firmware 0.78v-dc42 and web interface 1.03
November 23, 2014 04:03PM
Hi Patrice,

Thanks for trying my firmware fork.

1. The default X motor direction in my firmware is set to be correct when you have the X motor loom plugged into the Duet the same way round as the other motor looms (as on the Ormerod 2). So for the Ormerod 1, you either need to reverse the X motor loom to be like that, or add the M569 command to config.g.

2. Check that if you have any M301 commands in config.g, the S parameter in those commands is set to 1. In some earlier versions of the firmware, I set the default to 0.9. This reduces the heater power, which is a good thing for some recent cartridge heaters I have received from RepRapPro, but not for some of the original heaters, especially if you are using the ATX power supply supplied with Ormerod 1. If there are no M305 commands or the S parameters are already set to 1, then use the M570 command to increase the heater timeout.



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].
Re: New experimental firmware 0.78v-dc42 and web interface 1.03
November 24, 2014 11:52AM
Quote
dc42
Thanks for trying my firmware fork.
You're welcome ;-)

Quote
dc42
1. The default X motor direction in my firmware is set to be correct when you have the X motor loom plugged into the Duet the same way round as the other motor looms (as on the Ormerod 2). So for the Ormerod 1, you either need to reverse the X motor loom to be like that, or add the M569 command to config.g.
Understood. I don't know what I'll do, I'm rather reluctant to change things that do operate well (some sort of profesionnal obsession !). For the moment it's easier to add a M569 command as I did, maybe I'll change the wiring later.

Quote
dc42
2. Check that if you have any M301 commands in config.g, the S parameter in those commands is set to 1. In some earlier versions of the firmware, I set the default to 0.9. This reduces the heater power, which is a good thing for some recent cartridge heaters I have received from RepRapPro, but not for some of the original heaters, especially if you are using the ATX power supply supplied with Ormerod 1. If there are no M305 commands or the S parameters are already set to 1, then use the M570 command to increase the heater timeout.
I've no M301 command in my config.g file, and a query returned the following :
Heater 1 P:10.00 I:0.100 D:100.00 T:0.40 S:1.00 W:180.0 B:30.0

The S parameter is already set to 1, so nothing to change here. I'm using the original ATX power supply provided with my Ormerod 1 : either I change the power unit, but as it does work there's no really need to do so, or I use the M570 command as I did and as you suggest to me. I'll keep the second option, it did the job.

Thanks for your quick answer
Patrice
Re: New experimental firmware 0.78v-dc42 and web interface 1.03
November 30, 2014 06:58AM
Hi DC,
Would it be possible to make and offset parameter in the config file that influences at what height the nozzle is set when automated bed levelling is used - G32?
Re: New experimental firmware 0.78v-dc42 and web interface 1.03
December 05, 2014 06:57AM
Strange issue...
Yesterday I update my firmware from 0.78q, Seems all go fine, but during the printing (same gcode already printed) the heated bed gone off O_O, and there was no way to restart it.
I execute the print via web interface (1.3), from sd card, and it reported the correct temperature, but the bed was off while the set temperature was 100C°.
I try to pause and change the bed temperature but nothing to do....
Very strange...
This evening I'll retry.
Re: New experimental firmware 0.78v-dc42 and web interface 1.03
December 05, 2014 07:11AM
have a look at thermistor. maybe the connection got loose and you encountered a safety shutdown of the heated bed. you can look at the messages of the web interface
Re: New experimental firmware 0.78v-dc42 and web interface 1.03
December 05, 2014 08:54AM
I have checked the messages, there was no one error.
Also I tried command as M140 S100 and it get "ok", but still remain off, or M144 and M140 without argument, always "ok" but nothing changed.
The connections to the bed heater are very reliable (I use cable tie to lock the ribbon cable), I'll check again this evening, may be the thermistor connection? but I never loose the temperature reading....
confused smiley
Re: New experimental firmware 0.78v-dc42 and web interface 1.03
December 05, 2014 01:09PM
Is this an Ormerod 1 or Ormerod 2? There have been a couple of reports of failed heated bed connections on Ormerod 2.



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].
Re: New experimental firmware 0.78v-dc42 and web interface 1.03
December 12, 2014 11:09AM
Hi Guys,

It's been a long time since I fired up my Ormerod or visited these forums (in fact didn't even know there was an Ormerod 2 until today). Anyway I am currently on 0.65e-dc42 and web 0.90. If I upgrade to the latest are there changes to config files that I need to make to get things to work?

Regards,

Les


Pointy's Things
Pointy's Blog
Re: New experimental firmware 0.78v-dc42 and web interface 1.03
December 12, 2014 11:31AM
Hi Dave, a quick question.

Please would it be possible to place commented example of the config.g file along with the bin file.

I'd like to upgrade to the latest firmware, but where I'm using an old version (65k), I know that the config file I am using at the moment might not
work with the latest update.

Thanks,
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
Sorry, only registered users may post in this forum.

Click here to login