State Monitor versions
References:
Program ideas, missing implementation:
- W2: Possibility for some kind of a filter or some averaging, so that one spike does not issue an error log. (in TopoScan there is a rutine which can delete outliers. The best would be that a running average was made, say with 5 datapoints. This shold be default on read parameters (which change often). (JSN 030814)
- W1: Would be nice if one could set (or clear) one or more option of all selected trees (with an option of traversing all sub trees also). (JSN 020529)´
- W1: Would be nice if the "StateWindow" (the upper right window) could write the present (last) value of the parameter. (JSN 020801)
- ** Comments on activation window - possibility to describe why a state is disabled. (TW000516)
- Independent ConSys client for some leaves (compare, get adc and dac values for stateViewWindow). (TW000511)
- ** Sorting of controllers in the list view. (TW000511)
- Highlight method: Highlight states with given specs (ex. Activation status, current State etc.) (TW99)
- More information in the state view window. (TW99)
- Toolbar should include most used methods. (TW99)
- *** Compare change from abs/rel to (offset error +
relative error) (ie. two control values)
abs should be given as a percentage of MaxVal
rel should be given as a percentage of the current value.
Formula (one test): abs(adc-dac) < (offsetError/100 * MaxVal + relError/100 * dac). (JSN/TW000719) - Would also be nice if there was a state type, which could subtract two parameters and acting on the difference (like a float state), i.e. a difference state. (JSN 050704)
- Persistent store of logs. (TW001214)
- M1: Notifications back from state server not implemented yet. When implemented, a notification should be send when a controller could not be created because of another controller with the same name. (TW021028)
- W1: Check parameter names in database when finished editing a parameter. Perhaps also after import - or a general method to find all illegal/wrong parameters. Could also be called when exiting edit mode. (TW021028).
Bug list:
I am afraid this is an old/wrong version. I thing some the bugs have been fixed! (JSN 030814)
- E2: When the kernel is started it faulty creates an errorlogning (including an email) (Must be initialization which is not done correctly) JSN 021210.
- E2: When an email notification is issued it includes
(in the body) the last (about) 25 logs. However it does not include the last
log (which is the one giving rise to the notification), which was the whole
point of the message. JSN 021210.
It is somewhat confusing getting a long list of irrelevant/old errors in the email body (I know it is not straightforward) - the Float Compare setup dialog has a caption with G64 compare, likewise there is a tab saying G64 compare. JSN 011210
- E2: The state of parent states is not updated when a state is activated/deactivated in an active controller. (TW021031)
- E2: State window is not updated when the state is activated/deactivated. (TW021031)
Version information:
Version 1.26.122.176 (TW 061205):
New features:
Use New CStateCompareState: Use new Kernel dataserver, CCompareFloatDataserver, if possible (parameters on same front-end and front-end code new enough to support CCompareFloatDataserver. Otherwise use floating point dataservers and compare locally. Combine absolute and relative compare.
Old Compare types can be converted to new by compiling ConSysState wit CONVERT_TO_CSTATECOMPAREFLOAT_EXPORTFORMAT and exporting to text. If CONVERT_TO_CSTATECOMPAREFLOAT_EXPORTFORMAT, CStateG64Compare and CStateFloatCompare exports as CStateCompareFloat. Used for one time conversion of state tree.
Corrected errors:
Corrected minor bugs.
Version 1.17.72.91 (TW 1/11-2002):
NEW FEATURES:- Auto-expand errors (right mouse key function).
- Collapse tree (right mouse key function).
- Import, delete all existing first
- Delete all function
- Inactive states, state lamp in tree view substituted with over crossed state lamp (common for all state types)
- Visible response when client connection lost implemented: State tree and state item view cleared.
- The body of an error (log) mail could contains a list of the last 25 errors in the concerned tree.
CORRECTED ERRORS:
- State view window for floating point range unable to show small values (1E-9), missing exp. Notation.
- E3: Starts playing sound (bicycle clock) when client reconnected after a lost connection.
Version 1.17.72.91 (TW 9/10-2002):
NEW FEATURES:Hysteresis on floating point states.
CHANGES:
All addressing is changed from computerNo,DeviceNo to unique device id. Changes in the use of the StateServer database table: The device number must now be the unique device id and ServerNumber -1.
CORRECTED ERRORS:
E2: There is some serious problems (crashes) having two StateMonitors in edit mode for the same Controller. (JSN 020726)
E2: Kernel crashed, when device id was wrong.
Version 1.11.40.59 (TW 14/12-2000):
Implemented sound on logs.
Log data format prepared for e-mail notifications.
Version 1.11.40.58 (TW 7/12-2000):
Implemented Logging!
Version 1.11.40.54 (TW 24/11-2000):
Improved state display update: Now only updates, if anything changed in content for the state. (Implemented in CState classes).
Bug corrected:AND operator and other three operators (and possible other tree ops.) did not show state changes when an substate is set inactive and ok. (TW000524)
Bug corrected: Edit - closing window while editing => File save dialog - should be removed (TW/JSN000719)
Check for changes if window in edit mode implemented.
Version 1.11.40.53 (TW 22/11-2000):
Find method: Updated - now works in multiple windows + more information.
Monitors: Implemented monitors to avoid access errors.
Improved tree display update:Before, the full tree was redrawn when new content arrived. Now the data structure is checked for changes since last content and only the changed and visible states are updated.
Version 1.11.40.51 (TW ?/11-2000):
Find method: Revised, new structure that is more flexible.
New method: Open all sub controller windows.
Version 1.10.33.41 (TW ?/05-00):
Version 1.10.32.40 (TW 24/05-00):
Find method: Find states with given specifications - for the moment only activation. The structure is ready for future search criteria. This version only search in the active window.
Version 1.10.32.39 (TW 22/05-00):
First real usage - setting up and finding errors.
IMPROVEMENTS:
Icons redefined:in controller list for operational state (is now filled circles - change to 'play/stop'). Use the same icons in the StateView header.
Importing into sub tree:Before, the tree collapsed and no state was selected because the tree has to be rebuild. Now remember the selected state that we are importing into - after import the state is reselected and the expanded.
State view now includes activation status when deactivated - in highlighted colour.
Edit state from StateView:Now possible by double click or by context menu.
Edit controller settings.
Test update: Controllers can now be updated while they are running, i.e.. no need for stop/restart any longer.
CORRECTED ERRORS:
Wrong bitmap in state tree for controller.
Set Inactive - cleared immediately if auto activate not set, Set permanent deactivation from in active mode does not work if no activation time is set.
Sometimes crash, when changing state tree: Was due to display call back routine. Directly refers to CState classes in the document. These where deleted during update. For speed reasons we don’t want a monitor to ensure that no display call backs are called during CStDocument update. Instead, a delayed delete of the old CStDocument has been implemented - with the deletion time controlled from the view. This solution is not very nice - but chosen for speed reasons instead of a monitor solution.
Version 1.8.24.32 (TW 24/01-00):
BUG corrected: State tree window does not become active after editing/start, if the tree has changed.
Version 1.8.24.31 (TW 20/01-00):
Double clicking on a controller state finds and bring the corresponding state view window in front. If the a state window for the controller is not all ready present or if it is in edit mode, a window is created.
Auto storage of the configuration changes on the server - instead of only saving when the ConSysKernel closes, as it was before.
Corrected error: In edit mode, selection changed after editing a state.
Remove unused commands from menues.
Version 1.8.24.30 (TW):
Use of optimised data servers - new floating point dataserver option used.
Compare two values on G64 (adc/dac)
Version 1.7.22.29 (TW 23/12-99):
Moved auto activation back to CState class
Implemented auto activated update when states are edited on the fly.
Version 1.7.22.28 (TW 22/12-99):
Added on the fly editing: implement a way to change settings that are allowed to change while activated (like the activation status.
Changed update notifications/handling on: In cases where the state structure has not changed, the state tree is now updated instead of destroyed and recreated.
Version 1.7.22.26 (TW 17/12-99):
Delete state/Delete state tree implemented.
Delete controller implemented
Added common property pages to all state types.
Position of state items changed after editing - corrected.
Activation management implemented: States can now be deactivated and set to a given result code.
BUG corrected: Start edit when running - state lamps does not go to grey
Auto activate implemented - and working in a temp version. The activation status is now in the content - it should be moved (back) to the State class itself where it belongs - and instead a state update message should be implemented as described in the idea section, 'On the fly editing'.
Version 1.7.22.25 (TW 13/12-99):
State view part of the display implemented.
Import/Export implemented
Bugs corrected
Version 1.7.20.17 (TW 17/11-99):
Tree view bitmap state display changed to callback.
Version 1.7.20.16 (TW 17/11-99):
First version with the structure working - first bit displayed !!!
Version 1.7.20.13 (TW 8/11-99):
Version 1.7.20.11 (TW 5/11-99):
Basic program layout setled.
Version 1.6.17.1 (TW 16/9-99):
The initial version including the basic class structures.
Initial program ideas (jsn 990817):
Introduction (user viewpoint):
The AlarmMonitor should be a program for viewing and optional logging (to a database) of machine status. Viewing of alarm logs should be done in a separate program (AlarmView) or perhaps in a separate view in the AlarmMonitor. The statusView should be hierarchic, so in the top there is one button indicating the overall status. The view should be expandable (like a tree view), so one get the composition of the status. There should be a number of basic parameter status (a bit equal true etc) and a possibility of making expressions (and, or, xor). A basic status should have the possibility of being negated. Each level should have a text, either auto generated (for the basic status) like "BMH11IBM.on Equal True" or manual (for the expressions).
Each status should have a possibility of being disabled, either permanent (until manual enabled) or until a specific time (date). It would also be nice to some way to indicate that a fault has been recognized and action has been taken, but we would like to remember the fault (could be a yellow lamp). Each status should have the possibility to autoReset, i.e. a bit determining whether or not a fault should reset by itself or an operator should reset the fault (a fault which has gone away and which does not autoReset should go lightRed). There should be a severity code, and a error type attached to each status (maybe most for logging purpose).
It should be possible to store all or parts of a status setup, which one then later can retrieve into somewhere in the hierarchic.
It should be possible to enable and disable logging to the database in some clever way, so part of the structure logs and other parts does not log.
StatusColors:
Red: Fault .
Light Red: A condition which has been in Fault but has become OK again. (occurs only for conditions which does not autoreset)
Yellow ??: Could indicate a fault which is not sever, i.e. we can run but want to remember the fault.
Green: OK
Severity codes:
An integer number between 0 and 10. Zero being everything OK, and ten being catastrophic fault
Error types:
An integer number between 0 and something. We have to define which error types we want to assign. Its something like "power supply error", "vacuum interlock error", etc.
Status types:
BASIC status (all have the option of being negated):
* Static Color status. Always returns the selected color.
* Bit equal True
* Word equal given value.
* Word in given range.
* Float in given range.
Expression status (all have the option of being negated):
* AND: Makes a logical (color) AND between any number of inputs
* OR: Makes a logical (color) OR between any number of inputs
* XOR: Makes a logical (color) XOR between two inputs.
Connection to RampControl:
One could imagine that the same status structure could be reused in RampControl. In that way the possibilities in events would be boosted.
Last Modified 06 May 2020