# Tuesday, July 27, 2010
What's new:
  • Oracle support tested with Oracle 11g R2, Devart dotConnect for Oracle 5.70.146, Oracle.DataAccess.Client 2.112.1.0 
  • mySQL support, tested with mySQL 5.1.48, Devart dotConnect for mySQL 5.80.146 
  • Improved type control in LiveData stack 
  • Minor fixes in Excel demo

Sergey Sorokin   Tuesday, July 27, 2010 7:26:01 AM (Pacific Daylight Time, UTC-07:00)  #     |  Comments [0]  | 
# Wednesday, July 21, 2010
In some rare cases, after installing CSWorks and running Pipes and Tanks Demo, you can see the following error:



This means one simple thing: ASP.NET cannot run LiveData Web Service code. There can be different reasons for this. The first thing you should do in this case is to get as much additional error information as possible. Check application event log - it may give you some clues. Also, try to get LiveData Web Service definition from your browser at http://localhost/CSWorksDemo/LiveDataWebService/Service.asmx.

The browser will probably give you some more details about the error. Consider the following example.
 


The problem in this particular case is that ASP.NET cannot write temporary binary it compiles for a specific page or web service. There can be several root causes for that, for example: error in the ASP.NET installation, changing ASP.NET  worker process account without modifying temp folder privileges etc. There is a lot of information about this issue in the net, here are some good sources:

http://forums.asp.net/p/1060279/1520411.aspx
http://weblogs.asp.net/rchartier/archive/2006/01/05/434626.aspx

The idea is to give the account ASP.NET runs under, say NETWORK SERVICE, or LocalSystem, or "ASP.NET v4.0 Classic" account (depends on which account you are using, see your IIS Manager settings, Application Pools, "ASP.NET v4.0 Classic" pool properties) full access to all temporary folder it may use while compiling ASP.NET page or service. Those folders include:

c:\WINDOWS\Microsoft.NET\...\Temporary ASP.NET Files
c:\windows\temp

One would assume that ASP.NET setup (or aspnet_regiis command executed manually) should do that, but it looks like there is no 100% guarantee. Fixing folder access manually seems to be the best option. Unfortunately, there is nothing CSWorks installer can do here - it's ASP.NET setup problem.

Sergey Sorokin   Wednesday, July 21, 2010 9:41:09 PM (Pacific Daylight Time, UTC-07:00)  #     |  Comments [0]  | 
# Tuesday, July 13, 2010

Starting from version 1.4.3850.0, CSWorks Trend control is capable of saving trend data to CSV (comma-separated value) files on the client machine. The following video gives the idea how the export process works and how trend data can be used in Excel. It's easy.

Watch the video in high resolution (1280x720) to see the details.

Sergey Sorokin   Tuesday, July 13, 2010 9:14:41 AM (Pacific Daylight Time, UTC-07:00)  #     |  Comments [0]  | 
# Monday, July 12, 2010

Starting from version 1.4.3850, CSWorks Alarm Summary and Trend controls support two more languages: German and Russian:



Those are the screenshots of CSWorks demo applications included in CSWorks install package. Please note that some of CSWorks demo applications now support culture parameter that can be passed in the URL. If you want to run CSWorks demo application using one of the supported cultures just specify "?culture=<culture>" parameter in the address bar.

Sergey Sorokin   Monday, July 12, 2010 1:10:30 PM (Pacific Daylight Time, UTC-07:00)  #     |  Comments [0]  | 
# Tuesday, July 06, 2010
What's new:
  • Client development: integration with Expression Blend 4
  • Improved downsampler engine now used on both client and server
  • Alarm Summary and Trend control in German and Russian
  • Trend Control: data export to comma-separated files
  • Minor OPC emulator fixes

Sergey Sorokin   Tuesday, July 06, 2010 7:38:33 AM (Pacific Daylight Time, UTC-07:00)  #     |  Comments [0]  | 
# Friday, June 25, 2010

Silverlight 4 supports the resolution of relative service addresses. Provided the Silverlight XAP package is hosted at http://somesite.com/application/ClientBin/Application.xap, the following address resolve as indicated:

"../Service1/Service.asmx" resolves to “http://somesite.com/application/Service1/Service.asmx”

For you, CSWorks users out there, it means one good thing: no more ServiceReferences.ClientConfig hassle, see Running CSWorks demo applications from remote clients post for details. Now you can simply specify relative service addres as follows:

<endpoint address="../LiveDataWebService/Service.asmx" ...>

and your CSWorks application will work from any website you deploy it to. Switching to Silverlight 4 pays off!

demo | wcf
Sergey Sorokin   Friday, June 25, 2010 9:59:41 AM (Pacific Daylight Time, UTC-07:00)  #     |  Comments [0]  | 
# Tuesday, June 15, 2010
What's new:
  • LiveData Service: open data sources asynchronously
  • LiveData data source providers: improved logging
  • LiveData Manager: response items 'Updated' event arguments
  • LiveData server stack fixes
  • Trend control: multiple minor additions and fixes
  • LiveDataWebServiceDemo sample: learn to work with LiveData Web Service directly
  • AlarmWebServiceDemo sample: learn to work with Alarm Web Service directly
  • Alarm Summary and Trend: support for multiple configurations

Sergey Sorokin   Tuesday, June 15, 2010 2:29:23 PM (Pacific Daylight Time, UTC-07:00)  #     |  Comments [0]  | 
# Wednesday, May 26, 2010

A few CSWorks educational videos are available on YouTube. Watch them in high-definition mode (1280x720):

CSWorks - creating your first application

CSWorks - using third-party OPC servers

Sergey Sorokin   Wednesday, May 26, 2010 4:07:28 PM (Pacific Daylight Time, UTC-07:00)  #     |  Comments [0]  | 
# Tuesday, May 25, 2010
What's new:
  • Server requires .NET 4.0
  • Client requires Silverlight 4
  • Client development: integration with Visual Studio 2010
  • Trend Control: specify date range explicitly
  • Delayed alarms to avoid noise

Sergey Sorokin   Tuesday, May 25, 2010 2:11:01 PM (Pacific Daylight Time, UTC-07:00)  #     |  Comments [0]  | 
# Wednesday, May 19, 2010

If you are curious about the number of Trend controls you can run against your CSWorks server infrastructure, you may find this post interesting. We will make minor changes to historical data server configuration, run a few Trend control clients against it and analyze what we see.

Environment

CSWorks 1.2.3800.0
Server: Intel Core 2 Duo @ 2.40GHz, 2 GB RAM, Windows Server 2008
Client: Intel Core 2 Duo T5300 @ 1.73GHz (notebook), 2 GB RAM, Windows XP SP3
Network: Wireless 54 Mbps

Server Configuration

1. As usual, we have to configure History Recorder so it uses some scalable database. Install SQL Server 2008 Express on your server machine.

2. Create database "CSWorks"

3. Create HistoricalData table - see "createCommand" parameter of <dbtarget ...="" name="Standard SQLServer DbTarget"> in CSWorks.Server.HistoryRecorderService.exe.config.

4. Configure SQL Server data source and make it active in CSWorks.Server.HistoryRecorderService.exe.config:

<dbTargetConfig>
  <dbTargets activeDbTarget="Standard SQLServer DbTarget">
    <dbTarget name="Standard SQLite DbTarget" ...
      ...
    />
    <dbTarget name="Standard SQLServer DbTarget"
      providerInvariantName="System.Data.SqlClient"
      connectionString="Data Source=localhost\sqlexpress; Initial Catalog=CSWorks;user id=sa;password=...;"
      ...
    />
  </dbTargets>
</dbTargetConfig>


5. Configure HistoryReaderWebService to read historical data from this database. In the web.config, assign SQLServer target to the primary partition and specify correct connection string:

  <historyTopology>
    <historyPartitions>
      <historyPartition name="partition1" primaryDbTarget="partition1 Primary DbTarget (SQLServer)" secondaryDbTarget="">
        ..
      </historyPartition>
    </historyPartitions>
  </historyTopology>

  <dbTargetConfig>
    <dbTargets>
      ...
      <dbTarget name="partition1 Primary DbTarget (SQLServer)"
                providerInvariantName="System.Data.SqlClient"
                connectionString="Data Source=localhost\sqlexpress; Initial Catalog=CSWorks;user id=sa;password=...;"
                ...
                />
    </dbTargets>
  </dbTargetConfig>

6. Restart HistoryRecorder service and verify that it writes observation to the newly configured database.

Running clients

Before running the clients, make sure you have prepared *.clientConfig in CSWorks.Client.TrendDemo.xap to run from a remote machine. Please see this post for details.

Now run a few Trend clients on your client machine using this command:

start iexplore "http://myserver/CSWorksDemo/TrendDemo.html"

I ran 25 instances, increasing the load by 5-instance chunks.

Results

All 25 clients run without problems, trending data (both live and historical) arrives without delays, server seems to be perfoming fine. Here is a screenshot made on the server machine. Clients consume about 200K of live and historical data every second, server machine uses about 35% of its CPU capacity. SQL Server and ASP.NET worker process are working hard (14% and 18%, respectively) to deliver historical data to the clients.

The spikes in data transfer rates mark moments when Trend control were re-querying bigger amounts of historical data - View->Tracking setting were set to On for all Trend control instances, and all instances were refreshing the whole picture synchronously (well, in chunks of 5 instances, of course).

The spikes in CPU consumption mark moments when I ran chunks of 5 IE instances.

Summary

Not bad for a commodity server box that runs every piece of the deployment: all CSWorks services (LiveData, Alarm, HistoryRecorder), web services and database engine. Potential bottlenecks are:
- the database - not surprising;
- web service layer - but we can scale it out using web farm.

Sergey Sorokin   Wednesday, May 19, 2010 2:18:06 PM (Pacific Daylight Time, UTC-07:00)  #     |  Comments [0]  |