Web Based Configuration Tool
-
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
-
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
-
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
-
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.
-
Thanks Ian, I've just fixed the config.g template. Now it should generate the right M567 code when a mixing tool is defined.
-
Bump in case my question above got overlooked…
-
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.
-
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).
-
The probe offsets are for letting the firmware know the probe and nozzle are not in the same location.
-
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 H0Is 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.
-
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.
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.
-
Very nice!!! I was thinking would it be possible to actually have all these pages embedded in the duet webserver? Is this planned already?
-
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.
-
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.
-
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.
-
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.
-
Works for me! Thanks!
-
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.
Actually the fact that configuration settings are rarely done depends on your usage I guess, I have exchangeable print heads with dual and single heads and and the Vulcan requires a different Z heights as well… Having a laser head is also part of my plans for the next 3-4 month.
So not only having the web based configuration tool embedded would be a dream but also being able to store, recall and edit multiple config files without uploading would be nice. -
Just noticed something else. In the generated config.g there is this line
M350 X16 X16 X16 X16 X16 X16 I0 ; Configure microstepping without interpolation
Should it not be M350 X16 Y16 Z16 Enn16 etc? At least that is how the wiki seems to read.
-
Yes, also the default should be I1 unless you turned interpolation off in the configurator.
