frib-high-level-controls / save-set-restore

save set restore
MIT License
2 stars 0 forks source link

Save snapshot #19

Closed shengb closed 8 years ago

shengb commented 8 years ago

It reports """ Error saving snapshot set for 'test'. Snapshot 2016-Feb 17 13:52:19 is not a valid MASAR snapshot. """

no other error message available.

jbobnar commented 8 years ago

When you take a snapshot the client makes a request to the service by calling "saveSnapshot". Masar makes the snapshot and sends it the client. When you press "Save" button, the request "updateSnapshotEvent" is sent to the service for the event ID that was obtained during "saveSnapshot".

When you took the snapshot, masar service failed to take it (as stated in issue #18). If this happens, the application will still take the snapshot by collecting the local values as it knows them directly from the channel access. When you pressed the "Save" button, this locally create snapshot was sent to masar service. However, because this snapshot does not have a masar ID, you cannot save it. It would be nice if Masar was able to save any snapshot, not just the ones that it took by itself.

I already updated the message in the yesterday release.

berryma4 commented 8 years ago

it seems like for masar, a new editor window does not pop up when take a snapshot is clicked. (which usually has the save snapshot button).

jbobnar commented 8 years ago

Seems to be the issue described https://github.com/frib-high-level-controls/save-set-restore/issues/17#issuecomment-188216077.

I cannot reproduce this, so I need some more info. Are you using the latest version, which I pushed yesterday? Are there any messages or any exceptions in the console? Taking a snapshot with masar sometimes takes time (particularly if there are disconnected PVs). Does the progress view claim it has finished all the tasks or is there anything still in progress?

jbobnar commented 8 years ago

I think I finally figured out what happens. There is an error in the interpretation of Masar's response. A RuntimeException is thrown, but because the action is executed by an executor, the executor simply eats the stack trace (which is the default setting!). I'll push an update so that you will at least get the stack trace and I hope we'll see what happens.

jbobnar commented 8 years ago

I pushed an updated to the repository. Please, try what happens and let me know about any exceptions. Thank you!

shengb commented 8 years ago

Here is the test results: after clicking "Take Snapshot", an error popped up: screen shot 2016-02-29 at 4 16 50 pm

After clicked OK, it became: screen shot 2016-02-29 at 4 17 09 pm

After clicking "Save Snapshot": screen shot 2016-02-29 at 4 20 41 pm

jbobnar commented 8 years ago

Great. Thank you! The reason was that you have bi/bo records without the labels. I implemented a check for this, so that they are handled appropriately: 5211a6f and 4c849e0.

shengb commented 8 years ago

the problem is same with the latest one

jbobnar commented 8 years ago

I manage to trigger that error when I used the following PV:

record(mbbi, "TEST")
{
  field(VAL, "16")
  field(ZRVL,"0")
  field(ZRST,"Unknown")
  field(ONVL,"1")
  field(ONST,"Known")
}

It is an enum PV with valid states 0 and 1, but at startup the value of the PV is 16. This doesn't make much sense, but it is possible to put the PV in such a state (not via caget though). Please, confirm if your case is similar to this.

I now pay attention to such cases f8748d1. However, I am not sure if that is enough. The value is invalid and if you make a snapshot with such a value, you will never be able to fully restore that snapshot.