Moving forward...
Written by Michael   
Tuesday, 18 November 2008

It seems that we are spending our efforts on investigation of new stuff but don’t make our new features complete. There are a number of nice functionality and possibilities but it doesn’t work right for end-users. They simple don’t know how to use it or it doesn’t work as expected. Therefore I got an idea to summarize of what we have in the code and its status. Then there are few steps of what have to be done to become from Preview version to Beta. Note: product Beta version should have most of declared functionality defined and ready to use, but might have some minor bugs. The bugs which can be workarounded by users without modifying the code (proceed with bit more complicated flow to get something working).

Step 1 (fixing of what we have now):

  • All commands on the toolbar or menu should not be enabled if there is no applicability for this command. For example:
    • Adding new schema when we don’t have any project loaded or created.
    • Zooming function when there is nothing to Zoom (there is no any schema currently active)
  • Schema editing
    • We need to fix multi-selection of graphic elements.
    • Copy to clipboard capabilities. We need to be able to copy&paste our elements.
    • We need to be able to export copied to clipboard content to other application as a raster picture or vector graphic element. Need to decide which format is better.
    • Ability to change Z order of selected element(s) (bring to top, bring to back)
    • Helper grid ruler should work (users can turn it “on” or “off”)
  • Working with “actions”
    • “Move” action. There is no clear understating of how to apply it. What type of helper object, how it should look and etc. Need to make its usage simpler.
    • “Show” action introduces confusing properties. What is “HelperObject” or “Min/Max channel value”?
    • The same is true for “Value” action. We need better way to define it.
    • Improvements of channel selection method. Currently there is simple text string. Therefore users will have no idea how to use it. Having something like a selection from project variables would help to avoid that.
  • Availability of “rich” controls
    • Progress bar has “style” property which brings a question to user for selecting some file. We need to avoid that in general. All available styles should be available via dropdown control. “custom” style is just one item from this list for advanced users.
    • Content control has “content” property. When we show open file dialog, there should be appropriate filters on files. E.g. Graphic files (*.jpg, *.png). But it is not a typical to have reference to some external file. Every content entity should be embedded to the project file unless user says different.
  • Property editor should have only relevant set of properties and each property should have a tooltip which describes it.

Here are the rest of planned activities. However, it hasn't been finalized yet and needs some discussion. Please send your comments on this.

Step 2. Improve communication layer.
  • OPC plug-in need ability not only read data from OPC, but should be able to write data to the server.
  • MODBUS protocol support.
    • It needs channel configuration dialog
    • Ability to read and write values to the device.
    • Connections through TCP and Serial ports.
Step 3. Showing over the time data of specific channel.

This is the simplest task. The only we need is a new graph control which can show trends of specified channels in real time mode. No any saving of this data needed.

Step 4. Event (Alarm) support.
  • Create infrastructure for defining events for one or more channels.
  • Designer needs new “document” window which will be used for event configuration.
  • Schema elements should be able to refer to particular event. E.g. showing some indication of event state and be able to change this state.
Step 5. Historical data collection.
  • Each project variable can be set for archiving.
  • Flexible set of rules to define when and how to save the data. It should be edited by users. Probably we could use some of scripting language to create small snippets of code which will do all of this logic. Users can edit them manually or use some “wizard” to create of what they need.
  • Ability to save changes of event states by following the same rules as project variables.
  • The data is stored in SQL database via standard interfaces so users should be able to choose which database to use (MS SQL, Postgree, MySQL)
  • It makes sense to create separate service application which can do all archiving in background. Does everybody agree with that?
Step 6. Analysis of historical data and reporting.
  • There are three fundamental ways to see historical data.
    • Graphic trends for one or more variables.
    • Table representation of one or more channels.
    • “player” mode. Users can open their schema and use over the time navigation control to locate interesting points. The schema will show state of variables at requested point of time.
  • Any of these views can be sent to the printer.
    • Vector pictures: Graphic trends and current state of a schema in “player” mode.
    • Simple text: Table view.
  • Users can create they own queries for Trends and Table probably using SQL syntax. Those queries are saved in the project file for future usage.
Step 7. Documentation
  • We need as big as we can create help system for our applications.
  • The help should be integrated into applications via help menu and context help.
Step 8. Tag this version as Beta and see users’ reports about our bugs! :)

Step N. Remote access.
  • Ability to see schema in real time mode via browser
  • See predefined reports via browser.
  • We need to choose either to create separate “web application” or to use Real Time application as a server for that.
Last Updated ( Monday, 24 November 2008 )