CSWorks: web-based industrial automation

Of CSWorks and software development

PostgreSQL support

clock July 29, 2011 16:09 by author Sergey Sorokin
Recently, we have tested CSWorks SQL LiveData provider (version 2.0.4115.0) against PostgreSQL database (connecting using npgsql 2.0.11.91), and it worked fine. Here are the settings we used in the CSWorks.Server.LiveDataService.config.  

Provider reference:

<system.data>
  <DbProviderFactories>
    ...
    <!-- Make sure that npgsql and its dependencies are accessible -->
    <remove invariant="npgsql"/>
    <add invariant="npgsql" name="PostreSQL Provider for .NET"
      description=".NET PostreSQL Provider for .NET"
      type="Npgsql.NpgsqlFactory, npgsql, Version=2.0.11.91, Culture=neutral, PublicKeyToken=5d8b90d52f46fda7" />
  </DbProviderFactories>
</system.data>

Data source description:

<sqlLiveDataSource name="Database01" sampleBufferLength="16" sqlProviderInvariantName="npgsql"
  connectionString="User Id=postgres;Password=pg123!;Server=localhost;Port=5432;Database=postgres;"
  updateRate="1000" maxQueryLength="65535" queryDelimiter=";" useZeroAndOneForBoolean="false">

Yes, you can use boolean data type to store discrete values, see our sample PostgreSQL table definition:

CREATE TABLE measurements(
PointName varchar(64) NULL,
Sensor1 int2 NULL,
Sensor2 smallint NULL,
Sensor4 int NULL,
Sensor8 bigint NULL,
Sensor1u int2 NULL,
Sensor2u smallint NULL,
Sensor4u int NULL,
Sensor8u bigint NULL,
Sensor10 float NULL,
Sensor50 varchar(64) NULL,
Sensor100 boolean NULL)
insert into measurements values('Point101', 1,2,4,8,1,2,4,8,8.0,'TestString',true)

Another SQL database under CSWorks' belt!



BACnet IP performance - Lab 05

clock July 19, 2011 22:31 by author Sergey Sorokin

If you are curious how well our new BACnet IP implementation can perform, you may find this post interesting. I used  CSWorks 2.0.4115.0 LiveData Service installed on a Core2 Quad Q6600 @2.40 GHz machine with 4GB RAM running 64-bit Windows 7. As a testing client, I used four instances of a simple LiveData client application that subscribes to updates from 5000 BACnet analog inputs, requesting for updates every second. Test applications talks to CSWorks LiveData Service directly over WCF (exctly the same way WCF LiveData Agent demo does). All hardware is connected via 100mb Ethernet.

My LiveData Service config file referenced four BACnet IP datasources, from "BacnetIpDemo01" to "BacnetIpDemo04" with ids from 260001 to 260004, you can see correspondent fragment of the config file on the screenshot below.
 
Test application expected every analog input data item to change on every update request. If a data item is not changed, the test application increases item's "skip" count. In the ideal world, skip count for all data items would be zero, since every BACnet device changes every item once a second. But due to the discretization process that occurs twice (once between LiveData Service and the BACnet device, another time between the client application and the server) it is hard to avoid these misses.

Performance monitors shows an average rate of ~18000 updates per second. If there was no device-to-server discretization and UDP packet loss, the rate would be exactly 20000 updates per second. LiveData Service was consuming 5-7% CPU.

Click to enlarge