|
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
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.
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.
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.
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.
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 IPseems 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).
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.
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 .
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!
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?
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.