Posts: 9
Joined: Thu Jun 13, 2013 10:48 pm

Possible bug - 2.1.0 - Issue with saving .FFF profiles

Fri Apr 18, 2014 9:16 pm

Broken off from

In the course of investigating the cause of minSpeedLayerTime being set to zero upon loading the .FFF profile, it's become apparent there is some very odd behavior regarding how S3D reads, exports, and modifies .FFF files. Here is a summary of what I've found so far...

There are 2 formats S3D appears to save config files in. One appears to be formatted as a .xml file and begins with the line

Code: Select all

<?xml version="1.0" encoding="UTF-8"?>
The other format looks like a standard text file and starts with

Code: Select all

The problem I've encountered is that .FFF files saved in the XML format will set minSpeedLayerTime to 0 when loaded in S3D. Files saved in the other format do not have this problem. This is very consistent across multiple config files. I have not noticed any other problems when loading config files saved in the XML format.

Another interesting wrinkle:
1. If I manually create a .FFF file for, say, PLA in the non-XML format
2. Import it into S3D in the process settings dialog
3. Verify that minSpeedLayerTime is non-zero (it always is)
4. Export the same config from the process settings dialog without making any changes.
5. Open the resulting file in a text editor - it will be formatted in XML.
6. Load the file from step 4 back into S3D, and the minSpeedLayerTime will be set to 0.
(The same happens when I do this to my ABS profile)

This is problematic because any time a user makes a change to the config file and exports it, it effectively breaks it. You have to manually make any changes in a text editor in order to not rewrite (and therefore break) the file format.

However, if I do the above process to my Bridge config, it is saved as the XML format but the minSpeedLayerTime is still read correctly!

I have also noticed that some settings are not written into the non-XML .FFF file, yet have some persistence. For instance, a line for inflating support was not in the file. I manually added it to the .FFF file like so:

Code: Select all

This doesn't throw any errors when S3D loads the .FFF file, but I suspect it would fail silently?
I attempted to test that this is read correctly by making a second config with the same value set to 0, and swapping between them.
I did the same thing for settings for the start points for each layer - pulled the variable names out of the XML-formatted config and copied the syntax for the other. As far as I can tell this is working as intended.

So, I have a couple requests from S3D staff:
1. Please help me understand what is going on here. Is this a bug, or intended behavior that I do not fully understand?
2. Please provide a complete list of configuration variables so that we can manually edit .FFF files when needed.

I have attached my PLA, ABS, and Bridge .FFF files in both formats. Remember the PLA and ABS files do not read minSpeedLayerTime correctly in the XML format while Bridge is unaffected.
(4.09 KiB) Downloaded 137 times
(7.17 KiB) Downloaded 168 times
(4.09 KiB) Downloaded 128 times

Posts: 9
Joined: Thu Jun 13, 2013 10:48 pm

Re: Possible bug - 2.1.0 - Issue with saving .FFF profiles

Fri Apr 18, 2014 9:17 pm

Second post to attach rest of .FFF files...
(7.24 KiB) Downloaded 161 times
(4.09 KiB) Downloaded 127 times
(7.17 KiB) Downloaded 166 times

Posts: 9
Joined: Thu Jun 13, 2013 10:48 pm

Re: Possible bug - 2.1.0 - Issue with saving .FFF profiles

Tue Apr 29, 2014 9:05 pm

Tentatively resolved.

It was recommended to me to migrate to the XML-style profiles, since this is the new format. Therefore it become necessary to find a working solution that used the XML profiles yet did not set minSpeedLayerTime to 0.

In the end the fix was rather simple, if non-obvious. For my ABS and PLA profiles, this variable was saved as a 2-digit decimal number, for instance 2.7. Replacing this with an integer, such as 3, resulted in the profile being loaded correctly. This is non-obvious because S3D displays the number as a decimal number. In my Bridge profile this was an integer, which explains why this profile loaded correctly.

Return to “Troubleshooting and Bug Reports”