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

www.idxonline.com

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

Scheduling the printing of an Excel file which has an add-in from the command line using visual basic scripting (vbs) via wscript

On a recent project I was required to print out an Excel based report which made extensive use of OSIsoft PI DataLink's Excel Add-in on a sechduled basis (7am daily).

Unfortunately Excel does not easily allow for the printing of an Excel file via the command line via switches or parameters when calling Excel.exe (e.g. C:\Windows\MS Office\Excel.exe -print "C:\Reports\My Report.xls").

I was able to find examples on the Internet which made use of cscript or wscript where one calls VBS code, and where one provides the file name as argument, for example:

wscript "C:\Data\My Scripts\printXLS.vbs" "C:\Data\My Reports\Daily Analyser Excursion Report.xls"

Note the convention of using "" around full path filenames as they contain spaces.

The file printXLS.vbs would contain something akin to the following code:

Dim XLApp
Dim XLWkbk
Dim ObjArgs

set ObjArgs = wscript.arguments
if ObjArgs.count <> 1 then
wscript.echo "Invalid passed arguments"
wscript.quit
end if

Set XLApp = CreateObject("Excel.Application")
XLApp.Visible = False

Set XLWkbk = XLApp.Workbooks.Open(objargs(0))
XLWkbk.PrintOut
XLWkbk.Close False

XLApp.Quit

Set XLWkbk = Nothing
Set XLApp = Nothing
Set ObjArgs = nothing

The problem I experienced was Excel Add-ins are not automatically loaded in Excel applications created via Automation. This resulted in the Excel file printing but with OSIsoft PI DataLink Excel Add-in functions not being recognised and #NAME! appearing in the relevant cells on my printout.

The solution I found was to explicitly load the Excel Add-in via XLApp.RegisterXLL ("fullpath filename")

So my VBS file looked like something this:

Dim XLApp
Dim XLWkbk

Set XLApp= CreateObject("excel.application")

XLApp.Visible = FalseSet XLWkbk = XLApp.Workbooks.Open("C:\OSIsoft\Reports\Scheduled\PI Report - Analyzers - Quality Excursions.xls")
XLApp.RegisterXLL ("C:\Program Files\PIPC\Excel\pipc32.xll")

XLWkbk.Worksheets("Report").Calculate
XLWkbk.PrintOut
XLWkbk.Close False

XLApp.Quit

Set XLWkbk = Nothing
Set XLApp = Nothing

I also wanted to be able to specify the number of copies to print and which printer should be used namely PRC2 in my case. If the printer is not specified then the windows default printer is used.

I also decided to allow one to specify the Excel workbook and which specific worksheet in the Excel workbook to be printed.

So allowing for parameters the VBS look something like this:

'Arguments'1 Excel Name e.g. "C:\OSIsoft\Reports\Scheduled\PI Report - Analyzers - Quality Excursions.xls"'
2 Worksheet Name e.g. "Report"'
3 Printer Name e.g. "PRC2"'
4 No of copies e.g. 1

Dim XLApp
Dim XLWkbk
Dim ObjArgs
Dim strFileName
Dim strWorkSheetName
Dim strPrinter
Dim intCopies

Set ObjArgs = wscript.arguments
If objArgs.count <> 4 Then
wscript.echo "Invalid Passed Arguments"
wscript.quit
End If

strFileName = objargs(0)
strWorkSheetName = objargs(1)
strPrinter = objargs(2)
intCopies = objargs(3)

Set XLApp= CreateObject("Excel.Application")
XLApp.Visible = False
Set XLWkbk = XLApp.Workbooks.Open(strFileName)
XLApp.RegisterXLL ("C:\Program Files\PIPC\Excel\pipc32.xll")
XLWkbk.Worksheets(strWorkSheetName).Calculate
XLWkbk.PrintOut , , intCopies, , strPrinter
XLWkbk.Close False
XLApp.Quit

Set XLWkbk = Nothing
Set XLApp = Nothing
Set ObjArgs = Nothing

I was then able to use Windows Task Scheduler to call the VBS file to print my Excel files on a daily basis.

Handling Late Data

Handling "Late Data" into a historian can be tricky when that data changes over time.

For example, we have a situation where material arrives in a truck on a weighbridge for processing. A sample is taken and sent to a laboratory for composition analysis but in order that the process can continue without waiting for the lab results, estimates are made and stored in the historian for temporary use.

After some time, once analysis has taken place, the actual values then replace the initial values (and the temporary historian entries for that timestamp must be updated) so that more accurate calculations on the given data can be performed.

This back-tracking and synchronisation of historical data and more have been incorporated into our IDX Listener technology to allow for efficient handling of these 'late data' into a historian.

Download PPT Show

Profibus PA for Hazardous Areas

Presentation and Paper by Michael Bean on the use of Profibus PA for Hazardous applications.

Profibus PA was designed as a solution for automation in Process Applications where it is often necessary to guarantee levels of safety with regard to potentially explosive atmospheres. In this paper and presentation given at the Hazardous Areas Conference held at Gallagher Estate in 2008 I discuss Profibus PA's applicability to such applications.

The presentation raised quite a bit of interest as various parties debated their companies' acceptance of the FISCO. Many were surprised at the advantages offered by the "high-powered trunk" concept.

Download Paper
Download Presentation Slides

Profibus Diagnostics

I often have people asking for a copy of my slides from a Profibus Diagnostics Seminar that we gave at the Eskom convention centre last year. I got the last slot of the day so I ended up speaking to only 40 people or so.

If you missed it you can have a look at the slides here.

Download Profibus DP Diagnostics Presentation

ProfiTrace Version 2.4 Released

Download ProfiTrace v2.4*

*If you are registered you can, just fill in your email address and leave the other fields blank.

ProfiTrace Version 2.4 contains 7 languages and includes bug fixes and lots of improvements like the amazing oscilloscope trigger for level and framing errors, reports in different languages, Vista 64 bit support, multiple ProfiCores running on a PC, etc.