article

Clair A avatar image
5 Likes"
Clair A posted Clair A commented

Autosave feature

Hi everyone,

I had a discussion with @Jordan Johnson recently and I also wanted to share with the distributors group some thoughts about the autosave feature:


Comment #1: there is no autosave if your model is in a run state every 10 minutes

When a user reads this checkbox, he thinks that FlexSim will "autosave a model backup every 10 minutes" exactly as it is written. But it does not.

As explained in the user manual:

"AutoSave will only save your model if it is reset and not running."

(https://docs.flexsim.com/en/20.1/Reference/GeneralModelSettings/GlobalPreferences/#environment)


Let's take an example: a user saves his model file at 10:00 am.

  • The first autosave is scheduled at 10:10 am. The user starts building his model, then runs his model between 10:09 and 10:11. As at 10:10 am his model was running, there was actually no autosave.
  • So the first autosave is postponed at 10:20 am. The user does some modifications in his model, then resets and runs his model between 10:19 and 10:21. As at 10:20 his model was running, there was actually no autosave.
  • So the first autosave is postponed at 10:30 am. And so on...

So after 1 hour of work, a user could actually have no autosave of his model. And I already have seen this with some users. If FlexSim crashes, then the user looses his work since he forgot to regularly save his model. So he looks for the autosave file, but there is none, even after 1 hour. You might answer me that users are supposed to save their model more regularly, but if they would do so then there would be no need to have an autosave feature.


Idea: if the model is in a run state when the autosave is scheduled, the autosave should not be postponed in 10 minutes, but instead the autosave should be triggered at the next model reset.


Comment #2: there is no autosave if you save your model at intervalls less than 10 minutes

Let's take an example: a user saves his model file at 10:00 am.

  • The first autosave is scheduled at 10:10 am. But the user saves his model at 10:09. So the first autosave is postponed at 10:19 am, there is no autosave at 10:10.
  • Then the user saves his model at 10:18. So the first autosave is postponed at 10:28 am, there is no autosave at 10:19.
  • And so on...

So after 1 hour of work, a user will also have no autosave file if he saves regularly his model. I am not shocked by this behaviour, but again when a user reads that FlexSim will "autosave a model backup every 10 minutes" , he thinks that FlexSim does autosave a model backup every 10 minutes as written on the checkbox. If saving the model postpones the next autosave, then the label of this checkbox should be more precise. And there should also be at least a tooltip on the checkbox and one more sentence in the user manual to explain that the autosave is postponed everytime the user saves his model.


I know that you are all experienced users and you save regularly your models. But I would be interested if you have already seen some of your users loosing their work, and then when looking for an autosave file there was none, or the autosave file was much older than 10 minutes.

Don't hesitate to add comments to this post.

autosave
unnamed.png (1.8 KiB)
· 5
5 |100000
Toggle Comment visibility. Current Visibility: Viewable by all users

Up to 12 attachments (including images) can be used with a maximum of 23.8 MiB each and 47.7 MiB total.

Patrick Cloutier avatar image Patrick Cloutier commented ·

I'm glad to hear this explanation because what you described has happened to me a few times. After a crash, I went looking for a nonexistent autosave file. Thanks.

0 Likes 0 ·
Clair A avatar image Clair A Patrick Cloutier commented ·

Thanks for your feedback @Patrick Cloutier !

0 Likes 0 ·
Clair A avatar image Clair A commented ·

I want to add below a screenshot of a real situation I had in training recently to illustrate this discussion:

We stopped the training for lunch break at noon so the user saved his model at 12:00.

The previous manual save was at 11:46, which became the fsm! file.

The last autosave was at 11:26, which means 34 minutes ago !

That's why I think that the checkbox "Autosave a model backup every 10 minutes" is misleading for our users.

When someone looses his work, and finds an autosave file much older than 10 minutes, I have a hard time to explain him that the parameter "Autosave a model backup every 10 minutes" actually does not perform a model backup every 10 minutes.

0 Likes 0 ·
autosave-time.png (13.9 KiB)
Phil BoBo avatar image Phil BoBo ♦♦ Clair A commented ·

The times don't always update in Windows Explorer if the file is exactly the same. It is also possible that their Windows Explorer is showing the "Date" column, not the "Date modified" column: http://www.rawinfopages.com/tips/2015/05/is-windows-showing-the-wrong-date-for-files-in-explorer/

If the model wasn't running, it is possible that it did autosave, and the time is wrong.

You have a hard time explaining that result because you don't even know what caused the result you are seeing. Neither do we. We don't have all the information. Was the model running? How was Windows Explorer configured? Were they up-to-date on Windows Update? What does it show in the right-click properties window for that file?

If the model was running, then the explanation is really easy. We even wrote it down for you in the user manual: "AutoSave will only save your model if it is reset and not running."

Your complaint is that users are "losing their work," but your explanation of how that happens is that it didn't auto-save because the user saved their model. Your complaint does not make logical sense. It just seems that you are too embarrassed to explain how the feature works when a user asks you a question about it. Just say, "AutoSave will only save your model if it is reset and not running," exactly as the user manual explains it. Problem Solved.™

0 Likes 0 ·
Clair A avatar image Clair A Phil BoBo ♦♦ commented ·

Thanks for your feedback @phil.bobo. I did not take a larger screenshot, so I can't confirm if the "Date" or "Date modified" was shown.

So I have done a new example. It's 9:51.

The "Date modified" for the 3 files are:

  • model: 9:23 (28 minutes ago)
  • .fsm!: 9:14 (37 minutes ago)
  • autosave: 9:06 (45 minutes ago)

Here is what is show in the right-click properties window for these 3 files:

So, imagine the user is working on his model and FlexSim crashes at 9:51. He will then look in his folder for the most recent file. He will be suprised to notice that the last autosave was 45 minutes ago ! And in this case finally the most recent file is the manual save at 9:23. So this user lost 28 minutes of his work and the autosave was not helpful at all.

Here is the sequence of events that can lead to this point:

  • 8:56: I open the model. The next autosave is scheduled at 9:06.
  • 9:06: autosave. The next autosave is scheduled at 9:16.
  • 9:14: I save the model. So the next autosave is actually postponed at 9:24.
  • 9:23: I save the model: So the next autosave is acutally postponed at 9:33.
  • 9:33: the model is running. So the next autosave is acutally postponed at 9:43.
  • 9:43: the model is stopped, but not in a reset state. So the next autosave is acutally postponed at 9:53.

In the end, there are so many situations which postpone the autosave that you can end up with an autosave file much older than 10 minutes.

If the checkbox says "autosave a model backup every 10 minutes", the user would expect it to "autosave a model backup every 10 minutes". If it does not autosave a model backup every 10 minutes, then the name of this parameter should be changed.

Or, as suggested in my 1st post, the autosave feature could also be improved.

For example, if the model is not in a reset state when an autosave is scheduled, instead of postponing the next autosave in 10 minutes, the next autosave could be triggered at the next model reset.

0 Likes 0 ·
folder.png (50.7 KiB)
model.png (19.6 KiB)
fsm.png (18.4 KiB)
autosave.png (19.5 KiB)

Article

Contributors

clair.augsburger contributed to this article

Navigation

Related Articles