LabVIEW Developers Feature Brainstorming

cancel
Showing results for 
Search instead for 
Did you mean: 

AutoSave / AutoRecover in LabVIEW

Highlighted

Hello all,

We are currently working on an "AutoSave" feature in LabVIEW, and I thought I might ask for some feedback from you in this new forum.

Now first, please keep in mind that this feature is further along in development than some other feature ideas discussed in this forum, so please don't be too upset if the feedback you provide isn't quite how it ends up working, especially in its first version.  🙂

The basic idea is that we would save modified VIs periodically to a temporary location so as to never save over top of your existing VIs on disk.  Then in the event of a crash or power failure, files would be present to recover on next launch and you would be prompted to recover them.

That said, here are some points of feedback I'd be interested in:

  • Do you think it should be on by default?
  • What do you think the default timeout period should be?
  • Would you consider it useful if it can only handle VIs/CTLs (no LVPROJ, LVLIB, XCTL, etc)?
  • How much importance would you place on it also handling the file types listed above?

Of course, if you have any other questions or comments about how it works or how it should work, I'd like to hear them too!

0 Kudos
Message 1 of 13
(14,172 Views)
Highlighted

Do you think it should be on by default?

Probably. This will definitely help save people who didn't think to turn this on and I doubt the overhead would be so big that it would be a real problem for people who wouldn't know how to turn it off.

What do you think the default timeout period should be?

If by timeout you mean the frequency of autosaving, I would say probably between 20 seconds and 20 minutes, depending on how much resources this takes. Is it possible to autosave only those parts of the hierarchy modified since the last auto-save?

Would you consider it useful if it can only handle VIs/CTLs (no LVPROJ, LVLIB, XCTL, etc)? How much importance would you place on it also handling the file types listed above?

It would probably be useful, but I'm guessing that once it's there people will want it for everything. I didn't get around to 8 yet, so I can't say myself.

As a side note, there is already an auto backup tool floating around the web (OpenG? LAVA? can't remember) which might be a good temporary solution.


___________________
Try to take over the world!
Message 2 of 13
(14,149 Views)
Highlighted
  • Do you think it should be on by default?  Yes, but it should be easy to turn off (you know, like auto-tool)
  • What do you think the default timeout period should be? I have a couple ideas:
    1. Don't use a time period. Do it like Quicken and save every change as it is made. Save the VI and then log every "transaction" as the user makes it. You are already sort of doing this in reverse with the Undo function. If you have the initial VI and all the Undo transactions saved to a file, you could recover all the way up to a crash. (Your undo logs may not be optimized for forward motion, but you could change that)
    2. If you need to use a time period, let the user set the default. Then, let every VI have a small countdown in the toolbar. If a backup save it too slow for a large VI, then it can be changed for that VI by selecting a new time from the toolbar. (See file)
    3. You don't need to waste time compiling for these backup saves, so only compile code during a real save.
    0 Kudos
    Message 3 of 13
    (14,136 Views)
    Highlighted
    • Do you think it should be on by default?
              No. Strictly a personal preference.
    • What do you think the default timeout period should be?
              5 minutes.
    • Would you consider it useful if it can only handle VIs/CTLs (no LVPROJ, LVLIB, XCTL, etc)?
             Yes.
    • How much importance would you place on it also handling the file types listed above?
             Could always be added later if their was demand for it.

    What would be REALLY slick is to store the last N (already configurable) undo steps with the temporary file, and give the temp file configuration a "save temp file on run" option. I've often changed what seemed like one little thing, clicked the run button and locked/crashed my vi because of a race condition, a reference problem, or a user event error; then had to CTL-ALT-DEL because the FP or the controls were not responding. If I could load the temp VI that was automatically saved and then UNDO the steps that got me there, that would be great!

    Now is the right time to use %^<%Y-%m-%dT%H:%M:%S%3uZ>T
    If you don't hate time zones, you're not a real programmer.

    "You are what you don't automate"
    Inplaceness is synonymous with insidiousness

    Message 4 of 13
    (14,121 Views)
    Highlighted
    Do you think it should be on by default?

    My personal preference would be for it to be turned off, however I believe the general user population would probably like it on by default.

    What do you think the default timeout period should be?

    I don't think the system should save on a fixed time schedule. It is possible to make some pretty significant changes to code in a very short period of time. It would be nice if the autosave feature was triggered when a VI lost focus (I'm on to modifying other code....) or when a particular number of program actions or # of nodes changes significantly.

    Would you consider it useful if it can only handle VIs/CTLs (no LVPROJ, LVLIB, XCTL, etc)? How much importance would you place on it also handling the file types listed above?

    I think that the autosave should handle all of the LabVIEW types. While I have not used X controls to any significant degree...yet, Murphy's law, being what it is, guarantees that I will be working on an X control when I experience my crash.

    One thing the auto save tool must be is fast. I would be fine if after a crash I had to run an autorecover tool that would convert some super efficent binary file into the actual vi, ctrl, lvproj, etc....
    If the tool is slow enough that the users can tell it is running (i.e. development system latency). Then they will more than likely take one of two approaches.
    1) Turn it off completely
    2) Set the timeout to a threshold that does not adequately protect them in the event of a crash.
    0 Kudos
    Message 5 of 13
    (14,096 Views)
    Highlighted

    Thanks for your feedback so far, keep it coming!  Smiley Happy

    I just wanted to quickly address some questions / comments that have come up so far:

    • Yes, we are only autosaving VIs with new changes since the last time they were saved - automatically or explicitly.
    • Pure G-based approaches to AutoSave can be pretty good, but will suffer from the following issues:
      • Undo history for a VI is cleared when it is saved
      • If an object has text focus, it won't after the save
      • If an object is selected, it won't be after the save
    • Keep in mind at least that even though LVLIB, XCTL and other newer types might not be supported in the first version, most of these are containers for VIs, which is where most of your work typically is.  These VIs would still get saved.  I can certainly envision someone setting up a big complicated build spec in their project and being pretty upset if that got lost before they saved it, so it's definitely on my radar.
    • Performance of the saving has been a big concern.  While some of the ideas presented (saving at every change) are interesting and do have advantages, I think things could start feeling pretty sluggish.  As it is though in my testing, the saving is pretty unobtrusive.  It definitely gets noticeable though if you're editing a VI that's a few MB in size.

    There have been some very interesting suggestions regarding when to trigger the AutoSave, which is also a point of concern and up for discussion as well.

    Message 6 of 13
    (14,072 Views)
    Highlighted
    One thing that would also be a useful feature would be to allow the user to manually trigger the "Recover" feature in case you need to go back to an earlier save, or just want to compare what you currently have with an earlier version. Maybe the Compare VIs tool could integrate the auto saved versions for comparison.

    Another thing to consider would be to allow more than one save per VI. In other words, as it saves, append a time marker or just a number to the name so you have a time history of what you've done. If you had the saves setup to run every 5 minutes and were allowing 5 backups per VI, you'd be able to compare VIs back to 25 minutes from your current point.

    You also need a way to manage when the backups get deleted.
    • Delete everything when LabVIEW exits
    • Delete backups older than X hours/days/weeks
    • Only allow a certain amount of disk space
    Ed


    Ed Dickens - Certified LabVIEW Architect - DISTek Integration, Inc. - NI Certified Alliance Partner
    Using the Abort button to stop your VI is like using a tree to stop your car. It works, but there may be consequences.
    Message 7 of 13
    (14,029 Views)
    Highlighted
    • Do you think it should be on by default?

    Yes, you never know when you are going to need, you never plan for your application to crash (talking hypothetically ofcourse Smiley Wink but especially true when interfacing DLLs)

    • What do you think the default timeout period should be?

    600 seconds but this should be adjustable in the preferences screen by the user.
    This is the default value I use for the LabVIEW monitor tool which is always present in the lower left corner of my workspace. I can see a count-down untill the saving time which I can disable/reset very easily by clicking on the countdown.

    It is true that saving the VIs takes some time. Depending on the number of VIs that need to be saved ofcourse. If you work like I do, with your pink stuck on control and your middle finger on 's' and you instinctively press these buttons once in a while the number is limited. But if you upgrade to 8.0.1 for instance and you open an older project you can get quite a lot of changed VI's. In these cases it is usefull to be able to switch it off. Also the front panel of the monitor tools turns red so you know what is going on when your selected control looses focus all of a sudden.

    Besides auto saving every 600 seconds into the default temporary directory it also shows me which version of LabVIEW I am working in at the moment, how many VI's are in memory, how many of them are running and how many are changed. The autosave function only saves the changed VIs and as copy without updating the callers so the 'changed' flag is not updated for the VI. The files are removed when the tool is exited by pressing the Quit button (which quits LabVIEW aswell). It is not a replacement for a version control package so changed files are removed when LabVIEW quits.

    I attached the LV7.1.1 version of the toolbar for inspiration. Some additional info: clicking the VI's in mem counter pops-up the VI's in memory tool, pressing the running vi's counter pops up the LabVIEW task manager, clicking the changed VI's counter pops-up a dialog showing you which VI's changed and why (in a very crude manor). The tool starts automatically with LabVIEW when you put it into the vi.lib directory. Put the other tools (from the zip file) into your LabVIEW\project directory.

    • Would you consider it useful if it can only handle VIs/CTLs (no LVPROJ, LVLIB, XCTL, etc)?

    Yes, I would, although it would ofcourse be nicer if these files are saved as well.

     

    Hope this helps
    Remco

    Download All
    Message 8 of 13
    (13,952 Views)
    Highlighted

    "It is true that saving the VIs takes some time. Depending on the number of VIs that need to be saved ofcourse. If you work like I do, with your pink stuck on control and your middle finger on 's' and you instinctively press these buttons once in a while the number is limited. But if you upgrade to 8.0.1 for instance and you open an older project you can get quite a lot of changed VI's. In these cases it is usefull to be able to switch it off. Also the front panel of the monitor tools turns red so you know what is going on when your selected control looses focus all of a sudden."

    Thank you for your feedback!

    I also wanted to mention that the goal is that only user-initiated changes would get autosaved.  Automatic things that cause a dirty dot such as compiling when loading a previous version, subVI loaded from a different location, etc, would not cause the VI to get autosaved.  So hopefully if you upgradeed to 8.0.1 and chose not to mass compile, this would not be a reason for you to disable autosave.  🙂

    0 Kudos
    Message 9 of 13
    (13,919 Views)
    Highlighted
    I like how the autosave feature is coming along. I suggest having it turned on by default. An interval of 15mins. sounds good. I would also prefer to be able to customize the location of the autosave files.

    Another comment somehow related is this: I would like to have the undo feature always work. This should not only be limited to the sutosave feature. For example, I would LOVE to be able to hit ctrl+s and do a save and also be able to undo. The save should NOT clear my undo capabilities.


    Michael Aivaliotis
    VI Shots LLC
    0 Kudos
    Message 10 of 13
    (13,892 Views)