I wonder if this button disappearing issue is related to something in the FFF file or FRM file? When I use Windows XP, which I don't see this problem on, I'm using a different printer with a completely different FFF process profile file and a completely different FRM firmware profile file than what I use on my Mac.
On my Windows XP machine, the profile I use was almost completely made from scratch because I'm using a FlashForge Dreamer, which Simplify3D didn't support out of the box, so I had to make my own process and firmware profiles.
On my Mac machine, the profile I use is a modified existing MakerBot Replicator 2 profile. I always see the problem on this machine, but I'm always using this profile and modifying it. Maybe this is a fault of the profile and has nothing to do with the Mac?
-
BaronWilliams
- Posts: 184
- Joined: Tue Jul 15, 2014 8:30 pm
-
BaronWilliams
- Posts: 184
- Joined: Tue Jul 15, 2014 8:30 pm
Re: Really annoyed now of "autoconfigure for material"
I have been testing this out today on my Mac. I noticed something very odd. If I export without making any modifications or making modifications, but I export using a new file name, then it works, all the buttons are still there in the new file. If I load the new exported profile and then export it again using a new file name, then all the buttons are still there. But if I then export to the same file name then that's when all the buttons disappear.
It's definitely a bug that's triggered by certain sequences.
To avoid this bug I now export in the Mac using a new file name. That is working for me. If I export using the same file name, then all the buttons are lost. It doesn't matter if I change any settings or not. Simply exporting to the same file name to update your profile causes the buttons to be lost. So from now on I will export using a new version number after my file name so that I don't run into this problem again. That is working 100% of the time
EDIT: when I say new file name, I mean a file name that's not the same as the current loaded profile. If the exported file name matches the file name of the current loaded profile, that's what causes this bug to happen. If you always export to a file name that doesn't match the current loaded file name, then the bug never happens. So it's not exactly saving to a new file name that gets around the bug, its saving using a file name that doesn't match the current loaded profile file name.
For example, if my current loaded profile is CUSTOM.FFF, and I modify it and export it to CUSTOM.FFF to save my modifications, because the export file name matches the current loaded profile then the bug will be triggered and I will lose all my material and quality settings along with their buttons if I reload my CUSTOM.FFF profile. But if I save my modifications to a file name that doesn't match such as CUSTOM2.FFF, then that doesn't trigger the bug and all my material and quality settings along with their buttons will remain intact if I load CUSTOM2.FFF.
On Windows XP, I am using a different profile, and I've been saving my changes to a new file name each time. I wonder if that's why I never saw this bug on Windows XP? I will test this out later on Windows XP to see if the bug is also there and I was simply avoiding the bug by saving to a new file name each time.
It's definitely a bug that's triggered by certain sequences.
To avoid this bug I now export in the Mac using a new file name. That is working for me. If I export using the same file name, then all the buttons are lost. It doesn't matter if I change any settings or not. Simply exporting to the same file name to update your profile causes the buttons to be lost. So from now on I will export using a new version number after my file name so that I don't run into this problem again. That is working 100% of the time
EDIT: when I say new file name, I mean a file name that's not the same as the current loaded profile. If the exported file name matches the file name of the current loaded profile, that's what causes this bug to happen. If you always export to a file name that doesn't match the current loaded file name, then the bug never happens. So it's not exactly saving to a new file name that gets around the bug, its saving using a file name that doesn't match the current loaded profile file name.
For example, if my current loaded profile is CUSTOM.FFF, and I modify it and export it to CUSTOM.FFF to save my modifications, because the export file name matches the current loaded profile then the bug will be triggered and I will lose all my material and quality settings along with their buttons if I reload my CUSTOM.FFF profile. But if I save my modifications to a file name that doesn't match such as CUSTOM2.FFF, then that doesn't trigger the bug and all my material and quality settings along with their buttons will remain intact if I load CUSTOM2.FFF.
On Windows XP, I am using a different profile, and I've been saving my changes to a new file name each time. I wonder if that's why I never saw this bug on Windows XP? I will test this out later on Windows XP to see if the bug is also there and I was simply avoiding the bug by saving to a new file name each time.
-
rustutzman
- Posts: 2
- Joined: Sun Aug 03, 2014 11:51 am
Re: Really annoyed now of "autoconfigure for material"
I just noticed this behavior in Linux so I'm glad you posted this info. It was driving me crazy! Thanks!
Russ
Russ
