mm/M

How do I set the speed units in the configuration editor to mm/minute rather than mm/s?

The printer we are sending the file to is calibrated in mm/M and the units look about right so we would prefer to change the units in Slic3r as the numbers will be more manageable.

Thanks,

Jim

I doubt very much that you'd be able to get slic3r to take mm/m. Just take your mm/m value and divide by 60 to get mm/s

Hmmm.... well thanks for responding but I can't say I find that answer very satisfactory. Does Alessandro visit this forum often?

Jim

Slic3r does output its speeds in mm/minute. So why do you have a problem?

Edited 2 time(s). Last edit at 03/01/2015 03:09PM 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].

Quote
Jim Blackwood
Hmmm.... well thanks for responding but I can't say I find that answer very satisfactory. Does Alessandro visit this forum often?

Jim

Why not? There are only a few places to set speeds, and you can have different profiles so you only have to do the arithmetic once. I don't know why you say mm/m is more manageable than mm/s - the latter are smaller numbers and you are unlikely to need any more than unit precision so IMO mm/s is more manageable as well as being easier to visualise. (I can easily visualise the speed of something moving 100mm in 1 second - if necessary I can move my finger along that distance on a ruler over a counted second, but visualising how fast it will look if covering 6 meters over a period of a minute is more difficult). The G-code output is in mm/m so the print speeds will be correct for you - i.e. set 50mm/s and the G-code will output a speed of 3000.

Dave

Thank you everyone for trying to help.
Yes, I know I could just put in the numbers in mm/s but we are not even close to being able to set and forget here. It's a new process and we'll have to play with the numbers for awhile yet.
I also know the G-code is in mm/m, and that is more readable. Although our rapid is up around 1000 mm/m our travel while depositing is more on the order of 2-20 mm/m. Much easier to use those numbers than .0333-.3333 mm/s wouldn't you say? And I would suggest that 1000 mm/m is easier than16.66 mm/s as well.
The biggest thing though is that we would like to standardize at mm/m across the entire platform rather than having one standard here, another standard there. Why confuse the user when we could resolve this at an early stage? It seems quite evident that the units could be converted in the code if not more easily elsewhere, after all, it's already being converted somewhere or the G-code would not be in mm/m.

I would guess the G-code standard is the ruling one here, as it has to be generated on one side and accepted on the other.

Jim

Quote
Jim Blackwood
Thank you everyone for trying to help.
Yes, I know I could just put in the numbers in mm/s but we are not even close to being able to set and forget here. It's a new process and we'll have to play with the numbers for awhile yet.
I also know the G-code is in mm/m, and that is more readable. Although our rapid is up around 1000 mm/m our travel while depositing is more on the order of 2-20 mm/m. Much easier to use those numbers than .0333-.3333 mm/s wouldn't you say?

Slic3r was designed to work with most ordinary FFF printers, but you are complaining that the units it works in are a bit less convenient (but still completely usable) for a machine that is most certainly not a typical FFF printer. A bit like complaining that your car's speedometer is unsuitable because you are using it on a skateboard. However in this case there are several solutions. One is to write a simple program into which you can enter figures in whatever units you like, which are then converted and written to a file that has the same format as Slic3r's ini file. Another is to enter all the variables in Slic3r in mm/m and then post-process the ini file to adjust those fields to mm/s. Another is to do all your speed trials by post-processing the g-code to change speeds rather than re-slicing every time.

Or just get used to thinking in either unit - I have to work in metric units for some projects and imperial units for other projects, and with a bit of practice it is not difficult to switch from one to the other.#

The source code for Slic3r is also available.

Dave

Thanks guys, I'm sure we'll figure it out eventually. There's still some confusion about what exactly is going on here and I may not be the mosty qualified to sort it out but it looks like I've got the job anyway. So... what I do know is that the actual movement of the machine is in mm/s (about 10mm/s for building walls) and the G-code to run it is in mm/s. The G-code that comes out of Slic3r matches that, so what I really don't understand is why the speed for print moves is 1/60th of that and is also labeled mm/s? We have to input numbers like .0833 to get 5mm/s at the machine.

It obviusly can't all be mm/s when there's a x60 multiplier in Slic3r somewhere between the speed settings and the g-code output. I'd just like to turn off the multiplier that's all.

Jim

No, the G-code that comes out of Slic3r (F parameter) is in mm/m not mm/s. The inputs to Slic3r are in mm/s. That's probably where you are going wrong.

Dave

So why would the speed settings for Slic3r be in mm/s when the G-code outputted is mm/m? I realize there must be some way that this makes sense but I'm not following it.

Obviously our printer is scaled for GIGO so that we get out what we read in, but in in mm/s so what you are telling me is that we should create a scaling factor on our machine so that it divides the input by 60 and then the speed numbers in the Slic3r configurator will match machine speed, right? But to make any sense of the G-code we'll have to multiply everything by 60. Can't do that in your head. Doesn't that seem just a little messed up to you? I dunno, maybe it's just me but why would you want to multiply everything by an obscure factor just to turn around and divide it again? Is the convention that well established that it can't be changed on a new system?

Not trying to be arguesome here, I just want the most usable configuration we can get. I'm not a programmer. More of an operator. To me simpler is almost always better. I'd like to see this system evolve to a simple, hit the button operation, and since I own 45% of the company my opinion does count for something.

Jim

Most of us don't care what the output units are because we will never be looking at them, we are only interested in having the input units in the most convenient form. As I said before, at the speeds that most FFF printers operate it is far easier to visualise speeds in mm/s than mm/m so I prefer the input units to be mm/s - and the output could be in cubits per month expressed in octal notation for all I care because the machine will usually be reading those, not I. Slic3r outputs in mm/m simply because that's the standard G-code units that the firmware for most FFF printers use.

Yes, I saw that in your description the 60 factor (mm/s to mm/m) was in the wrong direction. I can only assume that you are mistaken or your machine's firmware is incorrect, because I assure you that the input speed units for Slic3r is in mm/s, and the G-code output ("F" parameter) is in mm/m. You can test that easily by setting all speeds to (say) 100mm/s and noting that the "F" parameters in the resulting move codes are all 6000. The exception is in the start and end scripts where you are inputting raw G-codes that will be sent to the printer without translation.

Dave