Web Based Configuration Tool

W3DRK · 9 Sept 2016, 19:06

I noticed this configuration tool mentions the ability to define a Steinhart-Hart coefficient as term C of the M306 gcode in Firmware 1.16.

Is this supported in the current version 1.15c or do we need to wait for 1.16?

Also, upon entering the appropriate values from the Semitec 104-2GT datasheet I get:
M305 P1 T100000 B4338 C7.034421808033219e-8 R4700 L0 H0

Is scientific notation OK or should that be 0.0000000703442181?

PRZ · 9 Sept 2016, 17:00

AussiePhil, that is a bit off-topic, but could you explain a bit (preferably in another thread) how you did cool your board, as the value of 1600 is indeed quite high for the Duet 0.8.5. Your machine is quite on the edge, it might be interesting to create a page with some specifications on the RepRap Wiki.

As for the value exceeding limits in the configuration tool, instead of enforcing values, may be a warning might be better or the possibility to overpass the told limit.

deckingman · 9 Sept 2016, 17:46

@chrishamm:

Ian, is there any chance you didn't activate the H0 heater for all tools on the config tool? You could check that again by loading "config.json" after clicking on "Use existing template" on the welcome page.

At the moment the config tool tries to map only one heater+extruder per added tool, so assuming you have four heaters+extruders and create three new tools, the default tool mapping would look like this:

T0: H0, E0
T1: H1, E1
T2: H2, E2
T3: H3, E3

Maybe it would make more sense to pre-select all the heaters and extruders if a tool is added and the number of extruders and heaters differs? I guess that would make things a bit simpler when mixing nozzles are configured.

In addition it could show a warning if a tool is supposed to be generated without assigned extruders or heaters.

Hi Chris,

You are absolutely right - I didn't activate the heater (E0 in this case) for all the tools - my bad. In my defence the configurator did show the heater as being E0 and I assumed that it was selected, but on closer examination I can see that it was in a lighter shade of grey than when it is selected. Maybe a larger contrast between selected and not selected might help in these situation? (esspecially for old guys like me who's eyesite isn't what it was).

So I can confirm that it does work as it should. Your other suggestions sound good.

Ian

Dougal1957 · 9 Sept 2016, 17:50

I Would also suggest altering the Bed.G generator to fit in with the latest FW that will allow for upto 64 probe point's and also to allow for a Probe offset in there that does not impact the Config.G file.

I ran it thru a short while ago and it didn't actually complete Ie it didn't download anything?

Maybe change the selected colour to Green that would show a little better?

Doug

deckingman · 9 Sept 2016, 18:00

@chrishamm:

Well, it depends on what you prefer - I like to leave the nozzle at the trigger height when the bed is probed.

As a consequence all my G-code files have a custom starting G-code which instructs the printer to go just beyond the bed and then to go down to Z=0.3, which allows me the do a trivial "snort-cutter" move that removes left-over plastic from the nozzle just before anything is printed. Also if you have a sensitive build surface like BuildTak and leave the nozzle at Z=0, there is a risk of damaging it when the nozzle is heated up.

If you find this behaviour disturbing, I may add an extra option to the config tool to move the nozzle back to XYZ=0 once Z has been homed/probed, but I guess that's really optional.

Hi again Chris,

I have no personal preference as to how it should be and it's certainly not disturbing behaviour. My own way of doing it is to pe-heat the nozzle to around 120deg C before homing Z as the Diamond hot end has a tendency to ooze after a print has finished. On homing prior to the next print, the resulting lump of cold plastic used to flex the bed on my somewhat flimsy Mendel, and really screw things up. I guess everyone has their own way of doing it. I'm just thinking of new users who maybe haven't got around to doing any sort of start gcode on their slicers. They will (should) at least home all before starting their first print, so having it go to XYZ =0 might be a better default than leaving it somewhere else?

Ian

Dougal1957 · 9 Sept 2016, 18:07

Ian Bare in mind that on a delta you home to Max Z tho I would think that it takes this into account (At least I hope so)

Doug

deckingman · 9 Sept 2016, 18:17

@Dougal1957:

Ian Bare in mind that on a delta you home to Max Z tho I would think that it takes this into account (At least I hope so)

Doug

Hi Doug,

Yes the configurator does that. You can tell it whether home is max or min for any of the axes.

Ian

deckingman · 11 Sept 2016, 15:31

I have found a wee bug, genuine this time and not just me. When configuring tools sharing the same heater (mixing hot end), the code for setting the mixing ratios should be M567 and for turning on mixing is M568. The configuration tool generates a config.g which has M569 (instead of M567) for setting the mixing ratios (but the M568 is correct). I just tried the tool again, being extra careful that I asked for all the right things and got the same result.

Hope you don't mind me pointing that out.

chrishamm · 11 Sept 2016, 17:10

Thanks Ian, I've just fixed the config.g template. Now it should generate the right M567 code when a mixing tool is defined.

W3DRK · 11 Sept 2016, 18:47

Bump in case my question above got overlooked…

DebugBear · 11 Sept 2016, 20:19

Just had a quick go with this, one thin I noticed was in the homeall.g file the z homing appears to be done at the corner (first point) rather than the middle.

deckingman · 11 Sept 2016, 21:21

@DebugBear:

Just had a quick go with this, one thin I noticed was in the homeall.g file the z homing appears to be done at the corner (first point) rather than the middle.

Under "Endstops", then "Z Probe", there are settings for Probe X offset and Probe Y offset. Put the values you want in here and it'll generate the x and y moves in the homeall.g and home Z files (at least I think it does).

StephenRC · 9 Nov 2016, 21:38

The probe offsets are for letting the firmware know the probe and nozzle are not in the same location.

chrishamm · 12 Sept 2016, 11:33

@W3DRK:

I noticed this configuration tool mentions the ability to define a Steinhart-Hart coefficient as term C of the M306 gcode in Firmware 1.16.

Is this supported in the current version 1.15c or do we need to wait for 1.16?

Also, upon entering the appropriate values from the Semitec 104-2GT datasheet I get:
M305 P1 T100000 B4338 C7.034421808033219e-8 R4700 L0 H0

Is scientific notation OK or should that be 0.0000000703442181?

As the note says, you'll have to wait for RRF 1.16 because 1.15 doesn't support it yet. You can add already add the optional 'C' parameter though, it just isn't used at the moment. I don't think scientific notation will work, so I suggest you specify the whole number. That's what the config tool does, too.

W3DRK · 9 Dec 2016, 12:44

Thanks for the clarification. Unless something's been fixed since Friday, although it displays in decimal form on the website, it does indeed write it out to the config file in scientific notation.

@chrishamm:

As the note says, you'll have to wait for RRF 1.16 because 1.15 doesn't support it yet. You can add already add the optional 'C' parameter though, it just isn't used at the moment. I don't think scientific notation will work, so I suggest you specify the whole number. That's what the config tool does, too.

sga · 12 Sept 2016, 12:46

Very nice!!! I was thinking would it be possible to actually have all these pages embedded in the duet webserver? Is this planned already?

chrishamm · 12 Sept 2016, 13:05

W3DRK, thanks for the note. I was expecting JavaScript would display floats without exponent by default, but this doesn't seem to be the case. As a work-around the config tool will now convert the C value to fixed precision with 16 decimal places - I guess that should suffice.

sga, I was thinking about integrating the config tool in DWC so that the template (i.e. config.json) can be loaded and edited using the online configurator at any time. But there are still many more items on my TODO list, so I think this will have to wait a bit longer. If more people are interested in this, I will try to include this feature in my next DWC release.

deckingman · 12 Sept 2016, 13:23

@chrishamm:

sga, I was thinking about integrating the config tool in DWC so that the template (i.e. config.json) can be loaded and edited using the online configurator at any time. But there are still many more items on my TODO list, so I think this will have to wait a bit longer. If more people are interested in this, I will try to include this feature in my next DWC release.

That would be soooooo cool. Admittedly changing configuration settings is rarely done but when it is necessary, it would be so much easier to use the configurator than try to remember, or have to look up, the requisite M or G code along with all the associated parameters.

dc42 · 12 Sept 2016, 13:56

I beleve RRF does recognize scientific notation. It uses the C library function strtod to parse floats. I've noticed that although you can usually leave out the spaces in gcode commands, you can't leave out the space before E in a command such as M906X800Y800Z800 E800.

chrishamm · 12 Sept 2016, 14:35

I've just tested this and I must revise my previous statement: strtod can indeed parse numbers in scientific notation, so it should not matter which format the M305 C-parameter represents. I've just changed the config template to use the native JS float-to-string conversion again.