My custom Cartesian
-
what do you mean with 2 values?
I have these for my i3 clone:
-
@wilriker said in My custom Cartesian:
@whosrdaddy That's right.
OK, now I found where to set the values for speed, accel, jerk etc. but the default values contain two values and I cannot find which one stands for what. Any input on this, anyone?
What @whosrdaddy said. Also, if you let the mouse hover one of the input boxes, you'll get a little pop-up that explains what it does.
-
@whosrdaddy I mean the
<printer profile name>.ini
file where all the settings are persisted. There will be linesmachine_max_acceleration_e = 10000,5000 machine_max_acceleration_extruding = 1500,1250 machine_max_acceleration_retracting = 1500,1250 machine_max_acceleration_x = 9000,1000 machine_max_acceleration_y = 9000,1000 machine_max_acceleration_z = 500,200 machine_max_feedrate_e = 120,120 machine_max_feedrate_x = 500,200 machine_max_feedrate_y = 500,200 machine_max_feedrate_z = 12,12 machine_max_jerk_e = 2.5,2.5 machine_max_jerk_x = 10,10 machine_max_jerk_y = 10,10 machine_max_jerk_z = 0.2,0.4 machine_min_extruding_rate = 0,0 machine_min_travel_rate = 0,0
where every property has two values. After downloading and searching the source code I found out that the second value is for "silent mode printing".
-
@wilriker Oh I see now
I never bother with the ini files, the gui is easy enough to tweak the settings.
I am not even sure if these ini settings are used when choosing a firmware other than Marlin... -
@whosrdaddy AFAICT from the source code they are used for the print time estimation. Though I have to look deeper into it because changing it to my actual values set in
config.g
did not change the estimated print time at all. I must have missed some setting.Also there is no GUI part where I can set acceleration, max feedrate and jerk settings. At least I have not found it.
EDIT: It did not change the estimates as the settings in the config file will only be applied if Gcode flavor is Marlin. Otherwise they use the hardcoded defaults.
-
@wilriker : hardcoded, so it means you cannot change it at all?
can you point the the correct source file, I can recompile the application so I would love to test this.
I must say that the estimate Slic3r PE gives me is actually quite close to the real world outcome... -
The time estimates may only be valid for actual Prusa printers running Marlin as they use the Marlin motion planner. The two speed values are for the MK2 and MK3 which have high power and silent mode. The silent mode speeds were just added in order to make their speeds more accurate.
The slicer defaults are probably 6 years old now and come from original slic3r. The Prusa profiles are a bit fresher take on it.
-
@whosrdaddy I only looked at the source code part where they would be overwritten if the flavor is Marlin. That you can find at
xs/src/libslic3r/GCode.cpp:489
the defaults seem to be either in
xs/src/libslic3r/PrintConfig.cpp:961
or
xs/src/libslic3r/GCodeTimeEstimator.cpp:19
EDIT: since I have my acceleration very low (not tuned yet, still using the values from Marlin from times before Duet) and Slic3r has much higher defaults it will estimate print times considerably shorter.
-
Just curious, but how long after installing slic3r before you were into the source code? Was that before or after you did a test print?
-
I'm betting it was before.
-
@phaedrux Man, what do you think of me? Of course it was before the first print. But I have to admit it was after slicing and uploading the generated Gcode to my Duet.
But seriously, I would not have done/needed that if there would have been any clue on what these two different values for every speed-related property in the
.ini
file meant. -
What gcode flavour do you have configured in the printer settings? Marlin or reprap?
-
@phaedrux RepRap of course(?).
-
It's starting to seem like the time estimates are only remotely accurate if using Marlin, otherwise it reverts to using the old way of estimating, which doesn't take into account any acceleration values.
-
@phaedrux As I said earlier if it is not Marlin it will consider jerk, acceleration and max feedrate values but they are not configurable but only the hardcoded defaults.
-
I suppose that's one advantage Cura has, since you can specify all speed settings and the path planner takes everything into account for very accurate time estimates.
-
@phaedrux Yeah, in Cura my estimates are usually within single digits of what Duet gives as simulation.
Funnily I found a comment in Slic3r's time estimator that it is partially inspired by Cura's time estimator.
I am not in the mood of doing yet another patch-your-slicer approach (as I currently do with Cura until the next release when the Bugfix I require will finally be included) just to get those estimates right (just wait a few days and see me change my mind about that - or implement a UI part to set these values ).
-
@wilriker Well if print time estimates are your biggest printing issue, you're definitely ahead of the game.
Prusa has been putting a lot of work into Slic3r, and it sounds like the near future will incorporate the modern interface of the Prusa Control basic slicer with the back end slicing engine of Slic3r. So it won't look like it's from the 90's anymore.
It's too bad they are so heavily focusing on Marlin to the exclusion of others. I understand that they are highly integrated with their own version of Marlin firmware, but it would be nice if the gcode flavour switch actually allowed their features to work with other flavours.
At any rate, Slic3r does produce good gcode and the interface is definitely a lot faster than Cura for me at least. It lacks some features and has some others. But generally if I just want to quickly slice something and print it, Slic3r is my go to.
-
If you want an accurate estimate of print time before printing, try right clicking on the file in the DWC GCode Files list and click Simulate.
-
All joking and sarcasm aside:
Me wanting to have accurate print time estimates already in the slicer (no matter which one) is just me being pedantic and not important. It happens quite often that I tune slicer settings to get a print being faster without compromising the requirements for the printed part. But once I get a feeling of how much Slic3r is off it will be just a relative offset I will get used to.
What I meant about the patch-your-slicer approach and not being in the mood for it was maybe poorly worded. It was not supposed to mean that I will not try out Slic3r just because it cannot give me the same level of print time estimation accuracy that I am used to from Cura. It just meant that I could fix this by patching Slic3r but at least for now I won't.
I really do like the speed of Slic3r. It is vastly faster than Cura both in terms of UI and slicing speed. Especially the latter.
Also I don't really care for the look of the UI as long as it gets the job done. I am a minimalist using a tiling window manager on Linux - no fancy animations anywhere, everything full screen all the time.
I can say that I like the look of the UIs of Cura or ideaMaker but it is just not important to me in the first place.There are two things I miss in Slic3r so far (but still no reason to not try it for some time):
- I like to see the coordinates of an object on the build plate. It helps me to arrange for a new print if the previous object is still on the build plate (printing from remote) but I can guess my way around that at least
- I would prefer to see the print time estimates without having to save the Gcode first
EDIT: Probably later today I will print my Slic3r sliced Benchy.