Wednesday, September 23, 2009

Siemens PCS7 Direct PLC Tag Data Retreival

Exciting Work in Development at IDX
TOPIC: PCS7 Direct PLC Communication via IDX Runtime

Background:
IDXOnline has an exciting solution in development to solve a long–standing challenge which involves collecting plant data directly from the Siemens PLC as opposed to from the WinCC OPC Server.

Out with the old:













In With the New:














How will we achieve this?
IDX has obtained a dll package from one of our partners that are able to communicate with a Siemens PLC via TCP/IP. The package is suitable to be incorporated into the IDX runtime as a driver module, and thus will work like any other IDX driver module will enable communication with any other software that IDX currently supports.

Is there already software available that can do this?
Yes. IDX has tested the Softing S5/S7 OPC Server as well as the Wonderware DasSIDirect Server, and the results that this test yielded were impressive when compared to the standard WinCC OPC server. A report of the findings is available and can be provided on request.

The shortfall with all existing products of its kind is the fact that when a full download is done from the PCS7 Engineering Station to the PLC, the DB Addresses change. The result of this is that tags now no longer point to the same piece of information in the PLC.

So, for example, before a download, the tag 440LIC104 at address (DB44,DW3) would point to a level indicator and after the download, if the address mappings are not updated, DB44,DW3 might now be the address of a furnace temperature, etc.

The new IDX Driver will detect this download and set the quality of the tags to BAD until the new addresses have been updated using IDX Unifig, after which the driver will continue transmitting the tag data.

For more information contact

Ryan Coetzee - IDX
ryanc@idxonline.com

Monday, September 7, 2009

C# COM issue : "the application has called an interface that was marshalled for a different thread”

Hello people. I bled a little on something, so I thought I might share and save you some pain:

When calling code in a com class (for example, when using an external dll written in some other language (vb, for example), the implicit threading can be an issue)

VB by default uses STA threading (Single thread apartment), which loosely means that the application runs in one thread.
If you use the above class in C#, which by default uses MTA (Multi thread Apartment), You get an error : “the application has called an interface that was marshalled for a different thread” .

SO:

When you use such a dll in c#, you need to add the [STAThread] directive above your main program.cs file as follows:

namespace MYIDXApp
{
  class TimeServer
  {
    [STAThread]
    static void Main(string[] args)
    {
    }
  }
}


Furthermore:
There is a “feature” in c# that even though you specify that the main thread runs under STAThread, any timer events happen as MTAThread.

Thus, for a timer event, you must launch a new thread under STAThread as follows:

void timer_Elapsed(object sender, System.Timers.ElapsedEventArgs e)
{
  timer.Stop();

  //Classes.IDX_PI_Processing oProcessing = new Classes.IDX_PI_Processing(config);   // these have now been moved to a new thread due to the issue
  //oProcessing.ProcessPIQueue();
  Thread t = new Thread(new ThreadStart(StartNewStaThread));
  t.SetApartmentState(ApartmentState.STA); // this has to be done BEFORE the thread   //starts, else it is too late
  t.Start();
  t.Join();

  timer.Start();
}

private void RunProcessingClass()
{
  Classes.IDX_PI_Processing oProcessing = new Classes.IDX_PI_Processing(config);
  oProcessing.ProcessPIQueue();
}


for further reading:
http://www.developer.com/net/cplus/print.php/2202491