[ADDED] Speed - mm/minute? Why not mm/sec?

[laird]

The G-code is in mm/minute. Which means all the commands under the scripts tab will be using mm/minute. It would be a much more confusing system if all of the tabs in the FFF window had mm/second and then the scripts tab used mm/minute. The current system is uniform as is and therefore much more user friendly, despite the fact that I've used mm/sec in the past with other programs.

This would make sense if people routinely wrote gcode move commands by hand. But in the real world, everyone uses mm/s for extruder movement speeds, and they use applications (slicers) to generate gcode. So it's not useful to people for the Simplify3D UI to be consistent with the generated gcode. By that argument, people doing page layout should use Postscript code, and of course they don't, because they use software to generate Postscript, and nobody cares whether Poscript uses scaled floating point coordinate systems for rendering.

[KeyboardWarrior]

The G-code is in mm/minute. Which means all the commands under the scripts tab will be using mm/minute. It would be a much more confusing system if all of the tabs in the FFF window had mm/second and then the scripts tab used mm/minute. The current system is uniform as is and therefore much more user friendly, despite the fact that I've used mm/sec in the past with other programs.

This would make sense if people routinely wrote gcode move commands by hand. But in the real world, everyone uses mm/s for extruder movement speeds, and they use applications (slicers) to generate gcode. So it's not useful to people for the Simplify3D UI to be consistent with the generated gcode. By that argument, people doing page layout should use Postscript code, and of course they don't, because they use software to generate Postscript, and nobody cares whether Poscript uses scaled floating point coordinate systems for rendering.

You lost me on that last point.

However, I'm not looking for an argument, I was stating my opinion on the matter. If Simplify3D came in and released a patch tomorrow that changed everything to mm/seconds, it would cause a lot of confusion on my end, since any patch wouldn't affect the scripts tab where your text is directly ported into the end G-code.

This is our fundamental disagreement on the matter, because I'm a user who does write custom G-code commands in the scripts tab, whereas you don't, we're gonna see the matter differently. Which is fine though, because this is a forum that should produce productive conversations on 3D printing. I personally enjoy the fact that if I'm coding in a custom Tool-Change script for retraction that it's going to be using the same system of units as my Retraction Speed under the Extruder tab. It keeps things simple, and the FFF window remains uniform as I stated in my post.

[laird]

What I'd like to see, which I think I posted way back, is that people can select the unit in the GUI, so either mm/s or mm/m, depending on their preference.

[mstahre]

Yes please! Allow us to toggle between the UI showing mm/minute and mm/second.
If I go online and read up on what speeds work well for a specific filament then I'll get it in mm/second. When I talk about it with other people, we always use mm/second.

Even if the gcode for whatever reason contains mm/minute, the inability to change that is the one thing that's really annoying and disappointing about the application so far.

[BaronWilliams]

The G-code is in mm/minute. Which means all the commands under the scripts tab will be using mm/minute. It would be a much more confusing system if all of the tabs in the FFF window had mm/second and then the scripts tab used mm/minute. The current system is uniform as is and therefore much more user friendly, despite the fact that I've used mm/sec in the past with other programs.

I have to agree with that. After playing around with G-code in the scripts quite a lot, I can see how annoying it would be to have to use mm/sec everywhere except for the G-code. That would be too inconsistent. I no longer see the purpose of using mm/sec. Using mm/min is the correct thing to use, since that's what G-code uses. I think the software engineers picked the correct measurement format for filament for their software. If we're never writing G-code, then it wouldn't matter, but at some point if you're making the most out of Simplify3D, you'll start using G-code. At that point you NEED to use mm/min because that's how G-code works. You'd might as well get used to using it. It is the standard for 3D FFF printers. This mm/sec thing is not really meant for 3D FFF printers. I don't know why other people started using it. Let's not repeat that mistake in this software, UNLESS we are going to also make the G-code use mm/sec too, and that's just not going to happen, is it?

[jimc]

this whole thing has been requested ever since i started using s3d 14 mos ago. the first time i dived into my firmware i realized why s3d does this. everything in gcode and firmware is all done in mm/min. since then its always been my opinion that the mm/sec thing is just a bad habit. baron, keyboard and me might be the minority but i vote to keep it all uniform like it is.

[laird]

The G-code is in mm/minute. Which means all the commands under the scripts tab will be using mm/minute. It would be a much more confusing system if all of the tabs in the FFF window had mm/second and then the scripts tab used mm/minute. The current system is uniform as is and therefore much more user friendly, despite the fact that I've used mm/sec in the past with other programs.

I have to agree with that. After playing around with G-code in the scripts quite a lot, I can see how annoying it would be to have to use mm/sec everywhere except for the G-code. That would be too inconsistent. I no longer see the purpose of using mm/sec. Using mm/min is the correct thing to use, since that's what G-code uses. I think the software engineers picked the correct measurement format for filament for their software. If we're never writing G-code, then it wouldn't matter, but at some point if you're making the most out of Simplify3D, you'll start using G-code. At that point you NEED to use mm/min because that's how G-code works. You'd might as well get used to using it. It is the standard for 3D FFF printers. This mm/sec thing is not really meant for 3D FFF printers. I don't know why other people started using it. Let's not repeat that mistake in this software, UNLESS we are going to also make the G-code use mm/sec too, and that's just not going to happen, is it?

First, nobody has proposed that they change from mm/min to mm/sec, they've proposed that users be able to select their preferred units.

Perhaps you don't know the history, but mm/minute has nothing to do with extrusion - it's used for CNC milling, which is where gcode came from. Extrusion speeds are almost always discussed in mm/sec (all printer specs, nearly all slicers and printer control software, etc.), because extrusion is a vastly faster process than CNC milling, and mm/sec yields human-friendly numbers.

So the request is for the software to support either mm/sec or mm/min, depending on whether the user is used to doing extrusion or CNC milling (or writing gcode move commands by hand). And it's the computer's job to conform to the user, not the other way around. Unit conversions are easy for computers to do, and a waste of time for people to do.

Shall we all argue that dates should be all written in seconds since Jan 1, 1970 UTC, just because that's how many computers store dates?

[BaudR8]

/history

Unit conversions are easy for computers to do, and a waste of time for people to do.

/analogy

it's probably not a big deal, but a point of error can come from the math itself.

Say you want to a speed of 2000mm/min, which is in units of (mm/min), native to G-Code.

2000/60 = 33.33333 repeating, so we've already lost a point of precision there. But, we want to "yield human-friendly numbers", so of course we're just going to write that as 33.
so we enter 33 into slic3r, and alas, 33 * 60 = 1980, which =/= 2000.
But, don't we want to print our first layer at half speed?
33/2 (half speed) = 16.5 * 60 (converting back to native g-code understanding) = 990, whereas if we kept 2000/2, it would be 1000.

Anyways I don't see how 2000 is any less human-friendly than 33.

+1 for keeping mm/min!

[laird]

/history

Unit conversions are easy for computers to do, and a waste of time for people to do.

/analogy

it's probably not a big deal, but a point of error can come from the math itself.

Say you want to a speed of 2000mm/min, which is in units of (mm/min), native to G-Code.

2000/60 = 33.33333 repeating, so we've already lost a point of precision there. But, we want to "yield human-friendly numbers", so of course we're just going to write that as 33.
so we enter 33 into slic3r, and alas, 33 * 60 = 1980, which =/= 2000.
But, don't we want to print our first layer at half speed?
33/2 (half speed) = 16.5 * 60 (converting back to native g-code understanding) = 990, whereas if we kept 2000/2, it would be 1000.

Anyways I don't see how 2000 is any less human-friendly than 33.

+1 for keeping mm/min!

It's not a question of "keeping mm/min" - nobody has propose taking mm/min away.

The question is whether there should be an option allowing users to enter mm/sec. And so far I've not seen any reason given not to allow users that want to use mm/sec to do so.

If someone wants to operate in mm/min, they select that as the option, and enter 2000, and there's no conversion, and no conversion error.

And if they want to operate in mm/sec, which is what's used by people in printer specs, online discussions of printing, etc, they should be able to enter those numbers as well, selecting mm/sec as the unit. And when S3D translates to mm/min for gcode generation, there's no reason for rounding - the resulting number isn't shown to anyone, it's just multiplied by 60, which is a pretty well understood mathematical operation. And if someone wants to enter a fractional speed in mm/sec, there's no reason that wouldn't work.

The question isn't whether mm/min or mm/sec are better. The question is whether S3D should force users to convert everything to mm/min just to enter print speed into S3D, when the numbers that they see everywhere (printer specs, discussions of print profiles, people talking about print speeds, most other slicers, etc.) is mm/sec.

Your example of people being forced to use mm/sec when they want to specify mm/min isn't anything anyone's proposed, so your arguments against it don't seem relevant.

So, is there a reason that users shouldn't be allowed to use mm/sec if that's what they intend to do?

[BaronWilliams]

So, is there a reason that users shouldn't be allowed to use mm/sec if that's what they intend to do?

I can see one BIG reason not to add support for mm/sec if Simplify3D also did this for G-code. When copying G-code out of Simplify3D it would need to convert the G-code to mm/min, if in mm/sec mode in the app; and visa-versa, Simplify3D would need to always assume that G-code pasted into Simplify3D was in mm/min and then convert it to mm/sec if in mm/sec mode. That way all outside G-code is always mm/min, whenever you copy G-code from Simplify3D or paste to it. That could cause confusion. If people using mm/sec make a screen shot of their G-code in Simplify3D, and ask for help about the G-code and are clueless that their G-code is altered G-code with mm/min values converted to mm/sec, other people could give them totally wrong advice about values to put into their G-code. I can see this leading a lot of G-code support questions being sent to Simplify3D from people unfamiliar with G-code and it's mm/min requirement. I could see people entering G-code using mm/min values, and expecting it to work even then Simplify3D is in mm/sec mode.

Having mm/sec an option for everything EXCEPT G-code, would be confusing too, but for different reasons.

There's no easy solution that works for all cases if we add support for mm/sec as a switch in Simplify3D. At some level it will cause confusion. This is just not a good idea.


I suggest, in order to avoid confusion, if we want to support mm/sec as an alternate speed format used in Simplify3D then for certain fields that accept mm/min values Simplify3D should have two value entry fields instead of 1. One entry field would be for mm/min, as we already have now, and there would be an alternate field that allows mm/sec values to be entered. If you want to enter values in mm/min, use the mm/min field, then both mm/sec and mm/min values update to match with appropriate conversions. If you want to enter values in mm/sec, use the alternate mm/sec field, and then both mm/sec and mm/min values update to match with appropriate conversions. The dialog with these alternate mm/sec fields should clearly state that mm/min is the actual value used in the G-code and that mm/sec is just an alternate field to enter values in. This way people will know that everything is still in mm/min, and that this mm/sec format is just an alternate field for convenience purposes. If I enter 90 in the alternate mm/sec field for my Default Printing Speed value, I will immediately see 5400 mm/min appear for the actual value. The alternate field could be enclosed in parenthesis such as "(90 mm/sec)", while the real value is not enclosed in parenthesis such as "5400 mm/min". If I hover my mouse over the mm/sec field, then Simplify3D should warn that this is an alternate field for entering values, and that G-code will use the mm/min value only. That way there's no confusion about it. All G-code is still mm/min, and the software makes that very clear even when entering values in mm/sec.

For example, instead of this in the dialog (underline showing the field where we enter the data):

"Default Printing Speed: _5400_ mm/min"

we get this in the dialog:

"Default Printing Speed: _5400_ mm/min (_90_ mm/sec)"

The parenthesis make it clear that mm/sec is an alternate value to enter for the Default Printing Speed.

What do you think? That way we leave everything mm/min as it should be, but still please people wanting to enter some values in mm/sec. G-code remains in mm/min as it should be. Everything is still mm/min. The mm/sec optional entry field is clearly just an option. I think this is less confusing.