Moving forward... PDF Print E-mail
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 )
 

Comments  

  1. #10 Adam
    2008-12-2214:57:19 Pavel,
    If the library does only single-threading, then it should work with all Modbus/TCP servers.
    However, if you can provide the *capability* of multithreading, then you can greatly improve your throughput, since many servers will be embedded and have a limited number of sockets available.
    We find that most customers expect rapid updates of their network I/O (on their SCADA screen) even when it is not necessary or practical.
  2. #9 Pavel.Ch
    2008-12-2021:13:03 Adam,
    in fact, according to my investigation of the nModbus library, it works according to the 1.0 spec with only 1 transaction active in a given time on a Modbus/TCP socket. I will ask by the author how to deal with this, perhaps I do not fully understand his code.
  3. #8 Adam
    2008-12-1822:49:08 Hi Pavel,
    Another thing you may consider is that there are still devices in the world that only support the original (1.0) specification for Modbus/TCP.
    In that original spec, only a single query could be outstanding on a socket at any given time. (This is "single-threaded" Modbus/TCP) Most later implementations support multithreaded Modbus/TCP but it could be helpful to allow the user to define the maximum number of outstanding queries on any single socket, to allow for the older hardware that you may encounter.
  4. #7 Pavel.Ch
    2008-12-1822:22:34 Adam,
    thank you for your comment. Now, there is default "0" for Destination Index in nModbus library, which I internally use. I intend to use a separate field for this index in a variable setup dialog - that means the user will be able to configure more variables with different indexes (end devices addresses) through one Modbus/TCP link bound to one socket (IP address/TCP port pair). The same mechanism will then be used for serial MODBUS RTU connection end device addressing.
  5. #6 Adam
    2008-12-1715:03:05 Pavel,
    Many implementations use 0 or 1 as the Destination Index; this is fine for a default. The Schneider Electric Unity software uses the syntax 192.160.0.100;13 to indicate index 13 on that IP—seems like a reasonable syntax, but most others just present it in a separate field, which is easier to understand unless you don't know or care what the index is (as in the case of talking directly to a PLC).
  6. #5 Pavel.Ch
    2008-12-1620:21:02 Adam and Alexey,
    Modbus/TCP "plugin" is in a very early stage of its implementation. I will surely take your comment into account. I studied the implementation of this "Destionation Index" field in the nModbus library and it is supported on TCP. So there is no inconvenience for me for an implementation of this feature.
  7. #4 Alexey Dovgan
    2008-12-1219:32:52 Adam. Thank you very much for your remarks, I think Pavel(our collage who work with modbus plugin) will take to account your remark.
    And thank you for attention to our project, we a try to do all that we can for it's further implementation .
  8. #3 Adam
    2008-12-1215:48:51 I'd like to comment that in your Modbus/TCP implementation you should not neglect to allow the user to select the target device's "Destination Index" in addition to IP address. This is a common failure of HMI that we interface to. Our products will often act as a bridge from Modbus/TCP to many serial or other devices, and the Destination Index field ends up being a selector for which target device you wish to address.
    Very interesting project, I hope you're able to get it finished!
  9. #2 Michael
    2008-11-2912:10:28 I'm not talking about technology of how Archiving can be implemented. I'm very flexible here. I just think that having some simple and extendable tool for saving and viwing historical data is what users want. Are there any free tools which could be used for that functionality?
  10. #1 Alexey Dovgan
    2008-11-2422:20:34 Michael, I already agree with you, only one point… Separate application for archiving - I think this is unnecessary, this complicates the architecture, and does not give us any advantages. We must implement in our runtime OPC XML DA service at first, and OPC UA service at future, and anybody who will need collect data from our scada to his DB will can do this through this services.

Add comment

:D:lol::-);-)8):-|:-*:oops::sad::cry::o:-?:-x:eek::zzz:P:roll::sigh:


< Prev   Next >