Open alranel opened 7 years ago
Can't say what the problem is here. F has always been a float. There are only a few parameter that were always and will always be integers: G, M, T, N, S and P. All others are float since they are supported.
Wanaho was using X3G I think and some users found out how to configure repetier for it. So I guess it is a converted printer then. Anyhow we never had integer F values.
Any information why he thinks that is required?
The user (who is/was indeed using Repetier 0.91) originally reported:
[05-08 09:08] <XXXXXX> The printer is a rebranded Wanhoa Duplicator I3 V2.1
[05-08 09:12] <VanessaE> try asking in #reprap
[05-08 09:12] <VanessaE> I'm kinda surprised any firmware demands integer speeds though
[05-08 09:13] <XXXXXX> I used Cura 14.02, Cura 2.5 and Craftware - they all Slice with integers.
[05-08 09:14] <XXXXXX> I am trying Slic3r now and was surprised to see it tries to print at full speed, which is disastrous!
[05-08 09:15] <XXXXXX> Then I compared the output from Slic3r and tested - it's definetaly the integer that cause my problem.
[05-08 09:17] <VanessaE> you sure it isn't a firmware bug?
[05-08 09:20] <XXXXXX> Its the opposite. It seems to ignore the floats and use some strange speed - I can't figure out what.
[05-08 09:21] <XXXXXX> This send it shooting fast over the bed: G1 X88.349 Y87.940 F4800.000
I have used Slic3r a lot and never had a problem with F values (ok I always enter full numbers). But of course I use repetier host and server for sending data. But I can not believe it is the problem. I would have heard in the time we had 0.91 or is it something new that slic3r is non integer.
Regardless from working or not I would remove the .000 if possible and only use fractions for non integer values. These are 4 bytes more to send and store that are useless and slow down communication if not using the repetier binary protocol.
Hello! Slic3r dev here.
We got a very incomplete report from a user about his printer using an old Repetier-Firmware (0.91?) not being able to parse F codes with decimals. It might be a clone of a Wanhao printer or something, but we have very incomplete information. A commercial printer anyway, so instructing user to upgrade his firmware is not easy.
Was this behavior ever changed/fixed? What version did introduce support for decimal F codes? I'm considering adding an option for supporting such older Repetier machines, but I didn't find this in the changelog or commit history.
cc @curieos @VanessaE