This blog entry describes what I intend to do in the near future. It does not collide with our roadmap, there will be only one new item inside (scripting), and the implementation will be planned carefully in order to exclude any interference with other functionality.

 O.K., so what's inside:

- improvement of Timers plugin:
    - relative timer already implemented (ticking in a regular interval, but unsynchronized to real time)
    - absolute timer (ticking at a given time in a given interval - for example every second sync to 0:00, or every hour sync to 00:04:30, or every Monday at 8:00, or every last day of a month at 23:59:59, etc....).

- improvement of MODBUS plugin:
    - exception handling
    - device failure information in a dedicated channel
    - channel conversion when reading from MODBUS registers for various device stored types (uint16, int16, uint32, int32, float, string)
    - serial interface Master
    - implement TCP and Serial Slave, but this not in a near future

- adding of Scripting infrastructure. I think it will radically improve flexibility and usability of FS2.
    - scripting using IronPython (now matured technology in version 2.0)
    - script editing (in future also debugging) using Scintilla (Scintilla.NET wrapper)
    - script storing in Project file
    - various types of scripts, at the time I think about three types:
        1) "Channel" scripts - can read any channel value, make computation and write to any channel value (preferably simulation generic channels as internal variables). Activation of these scripts via configured channels' "value changed" event (that means also possible "cyclic" behavior using timer channels, or "spontaneous" (computation when input value changes) using value source channels).
        2) "Action" scripts for schemas: A new "Script" Action object will be defined, which will call the script according to defined channel change event. Script also becomes the source FrameworkElement object reference as a parameter, so it can freely manipulate with grahical representation of the actioned object.
        3) "Designer" scripts - user scripts for design time extensions for Designer, in some form of a "plugin" infrastructure, usable for writing of import or export filters for database or schemas etc. This type must be still thought over, at the time I have no closer idea how to do it.

Some next ideas for development
- New communication plug for SNMP device monitoring
- New communication plug for system resource monitoring will be I hope covered by Lada.

That's all folks.

 Pavel

We have posted Roadmap for our project to Wiki page. Your comments are welcome.

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).

• 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.

• 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.

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.

• 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.

• 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?

• 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.

• 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.

• 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.