Did Repetier-Firmware ever require integer F codes?

[alranel]

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

[repetier]

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?

[VanessaE]

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

[repetier]

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.