DDK

[Anonymous user]

Hi, can I please just confirm that we can use DDK via C# to connect to an internal analogue point and change and read its value?

I have the Simple DDK Guide. Section 2.5 does mention AnaloguePoint in a table.

I have set up a vm with Geo SCADA and VS with the Notify project installed.

My plan is to revisit the DDK Simple driver and try to get it working.
With the Notify I presume this is a good project example to start?

Thanks,

[sbeadle]

Hi. The DDK creates it's own point types inherited from the canonical point types and can manipulate their values. It can not (usually) modify the values of other points, such as a DNP3 or Internal point. Does your application require this?

[Anonymous user]

Hi,

what can you do with canonical point types.

Are you able to display them in a mimic?

Add them into a table?
Can you transfer their values into internal points if needed?

I would wish to use them to transfer values back and forth to a .net application.

Thanks,

[sbeadle]

Your DDK driver will create point types such as Analogue, Digital, String and Time. These have all the same common features as other points, such as alarms, history, access from queries etc. A typical DDK driver will read data from an external source and set values/times/qualities, so it's ideal for your application.

Note - the Notify driver is unusual in that there are no points, so it's not a good example for you. I recommend looking at the other examples in the DDK.

[geoffpatton]

If you are not making a driver, to poll a device, you do not really need to make a DDK driver. You could just have your .Net program read/write to/from internal points. You can also use variables if you are not needing to historize or alarm on a value. Variables do not count against your licensed point count.

[Anonymous user]

Hi,

by the below.

Note - the Notify driver is unusual in that there are no points, so it's not a good example for you. I recommend looking at the other examples in the DDK.

do you refer to examples in the simple driver manual or else where?

Is it correct that the driver will create points with in Geo SCADA?

Thanks,

[BevanWeiss]

@Anonymous user Yeah, I'm confident @sbeadle was referencing the 'walkthrough' of the scanner implementation within the Simple DDK PDF file.

What you need to keep in mind when dealing with the Simple DDK (and the OEM DDK will be similar) is that they (Schneider dev team) very much want drivers to be Silos.  A driver should NOT interact with objects from other drivers.  That would make testing of them incredibly difficult, and would introduce all sorts of different race conditions and undesired inter-dependencies.

Now... in saying that, there are ways.

So in an object within your driver, you can have a Reference Field.  That reference field will be incredibly generic (DBObject).

But, based upon that you should then able to utilise some of the methods against that.

Like:

  ClearSCADA.DBObjFramework.FrameworkBase.Method( string Name, params Object[] Args ) { return Object }

Or you could probably cast it down to an ISCXReference interface, which likely has an Item[] accessor to retrieve properties (I honestly haven't tried).

I think on the whole, if you're just trying to get some values from some existing (other driver) points, then the .NET API is the right way forward.  You're much much much less likely to completely corrupt a database into a non-retrievable pile of arbitrary bits...

[BevanWeiss]

@Anonymous user ohh, and in answer to your question about:

Is it correct that the driver will create points with in Geo SCADA?

---

The answer to that is an absolute 'NO'.

A driver is not responsible for creating points (or in general objects) in GeoSCADA.

A driver merely defines what an objects function (behaviour) and form (properties/methods) will be... and gives a unique name to that object so that it can be created within the database using a different interface, like ViewX, or the Query Processor, or the .NET API, or the Automation Interface.

As an example.  The Simple OPC Driver.  It is a Simple DDK style driver.  But the Simple OPC Driver itself doesn't create any points.  You have to go into ViewX, find a group, right click, select New > Simple OPC > Analog Point, and then something goes away and calls a whole bunch of other things, one of which is a method in the OPC Driver which initialises some data related to the OPC point (but is not creating the OPC point itself), and validates a few settings (again, related to the OPC point).

Then it (the OPC driver method) returns, and the other thing reports that it has successfully created the point.

If the OPC driver method doesn't work right (i.e. crashes)... then it probably takes down all of ClearSCADA/GeoSCADA, and it's entirely possible at that point that the database is irretrievable (depending on what the OPC driver was trying to do).

If you only colour within the lines of the drawing provided (i.e. you don't try to do things you shouldn't... which is essentially what you're asking for guidance on here), then the crash will just take down your driver, the create object will fail, your driver may try to restart, and the user can try the same thing again (to likely the same consequence).

[sbeadle]

I was referring to also to the other example projects in the DDK download too, at:

https://community.se.com/t5/Geo-SCADA-Knowledge-Base/Driver-Development-Kit-DDK/ba-p/279081

[Anonymous user]

Hi,

which .NET Framework version should be used?

Thanks,

[BevanWeiss]

@sbeadle Hey Steve,

My understanding was that the three 'Samples' in the DDK were all roughly 'similar'.

There is a C# for defining just objects / aggregates, a C# for objects / aggregates using the Serial aggregate, and then a VB which matches the first C#..

Inside the PDF is pretty much a walk through of the object / aggregate versions, with reference to C++ also.

I think overall the DDK is the wrong tool for what @Anonymous user is likely trying to do.

[BevanWeiss]

@Anonymous user That one is in the PDF document (vaguely)

In order to build or use drivers developed with the Simple Driver Development Kit, you must have the correct version of the .NET Framework installed for this version of GeoSCADA Expert.

I'd go with:

1. What .NET does the included example project use?
2. If you look inside the Geo SCADA Expert Redistributables, what version of the .NET Framework does it ship with?

In a perfect world these should really be the same.  But I wouldn't be surprised if the example projects sometimes forget to be updated when the Geo SCADA Expert release moves .NET Framework targets.

You SHOULD be able to use an older (compatible) .NET framework than what Geo SCADA Expert ships with, and things should still work.  But there are gotcha's on this, like going to  .NET 1.1 isn't advised, since it's not compatible with the .NET v4 that Geo SCADA Expert uses... likewise .NET 2, of even .NET 3.5... but I think all of the .NET v4's are backwards compatible, and GeoSCADA 2019 currently ships with .NET 4.7.1... so you should be able to target .NET 4.7.1 without any problem for v81 Geo SCADA... likewise your driver should be able to happily rely upon functionality in:

• VC Runtime 2005 SP1
• VC Runtime 2008
• VC Runtime 2010
• VC Runtime 2012
• VC Runtime 2013
• VC Runtime 2017

Since these also appear to be bundled with Geo SCADA, which is a little surprising that they go back quite so far... I would have thought moving some of the old dependencies (like the 2005->2013 VC Runtimes) up to VC Runtime 2017... or even VC Runtime 2019 would have been 'better'

@sbeadle I assume there's just no appreciable return on investment for consolidating VC Runtime dependencies?

[Anonymous user]

Hi, I am trying to follow the pdf.
Which does say VS2015.

I have VS2019 on a vm and using .NET Frame work 4.7.2.

I have got up to just before 2.3 Add the category.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using ClearSCADA.DBObjFramework;

[assembly: Description("CS Sample Driver")]
[assembly: DriverTask("DriverCSSample.exe")]
[System.ComponentModel.RunInstaller(true)]

public class CSInstaller : DriverInstaller
{
}

It has a warning below

Severity Code Description Project File Line Suppression State
Warning There was a mismatch between the processor architecture of the project being built "MSIL" and the processor architecture of the reference "ControlMicrosystems.ClearSCADA.DDK, Version=6.81.7268.1, Culture=neutral, PublicKeyToken=9e16b9dd55e2cd53, processorArchitecture=AMD64", "AMD64". This mismatch may cause runtime failures. Please consider changing the targeted processor architecture of your project through the Configuration Manager so as to align the processor architectures between your project and references, or take a dependency on references with a processor architecture that matches the targeted processor architecture of your project. ClassLibrary

Thanks,

[sbeadle]

In project properties, set platform target to x64.

[BevanWeiss]

@Anonymous user I'm getting deja-vu...

I'd really recommend to just copy-pasta the C# demo project that ships with the DDK... and then compile it, install it, confirm it works.. then modify it a little to get it closer to what you need... compile it, install it, confirm it STILL works.. then modify it a little more to get it still closer to what you need.. compile it, install it, confirm it STILL works...

Then discover that the DDK process is really quite painful, side-track by about a week to put together an MSI that will install and register the driver for you, so that you don't have to jump through hoops all the time...

Then modify the driver code a little to get it closer to what you need.. compile it, fail to install it because a new Geo SCADA Expert version was released, and you installed that..

Side-track by 2 to 3 weeks re-working your entire build process so that you can now build and bundle yoru driver for each released version of ClearSCADA / Geo SCADA Expert..

Then modify the driver code a little to get it closer to what you need... build.. deploy... find you need something that the DDK doesn't provide for (like easy interaction with objects outside of your own driver silo)... and then have to shoe-horn the .NET API into your driver in some way to get easy access to the things you actually need...

Unless you KNOW you need to use the DDK, really try NOT to use the DDK.

It's really good that Schneider have it, and there are good uses for it.  But it is really NOT suitable for many many things.

The .NET API is the general purpose Geo SCADA API Interface (interface.. interface.. interface...).

If there is something that you need to do with Geo SCADA that you feel the .NET API just really isn't providing you.  Go to Stack Overflow.... look at how questions are asked on there, and how poor questions are absolutely ripped to shreds.  And then come here and write the question as though it is the best Stack Overflow question you have seen.

Tell us what version of Geo SCADA you are using, what code you are doing, what your final goal is, what your current small goal is, why you think your small goal will help you achieve your final goal, what you expect the .NET API to do, what the .NET API is actually doing... and then I'm confident that you will get a response that will help you achieve the best solution to get you to your final goal.

[Anonymous user]

In project properties, set platform target to x64.
Seems to have cured it. I am now further than I got last time.

Thanks Stephen.

[Anonymous user]

As regards to the Geo SCADA side is this what is required? Thanks,

[BevanWeiss]

@DS Nope... that looks like lots of things missing...

The point type that you appear to have created is an OPC point, so not a point derived from your DDK driver.

Once you have created your DDK you will have at least a .DLL file in the bin\x64\Release\ folder  (or maybe it's bin\Release\x64\ I don't have it in front of me).

You will also likely have a .EXE in that same folder (this is technically the 'Driver', the other .DLL is the DatabaseModule).. but we still call the whole assembly a 'driver' also.

Once you have these files, then you need to move them into your correctly versioned Geo SCADA Expert folder (i.e. C:\Program File\Schneider Electric\ClearSCADA), and then register them using the commands provided in the PDF file that you diligently read.

When you register them, it's better if you don't have Geo SCADA running.

Then... when you start Geo SCADA up again, if everything was successful, you will have a new 'folder' under the Create New > context menu which will allow you to create some new objects that you defined within your driver.

[Anonymous user]

Hi, I found the example projects I think you guys were talking about?

I ran the projects and grabbed the files as below

and pasted them here

That's as far as I have got. Does section "2.15 Install the Database Module" of the pdf cover the complete registration?

Thanks,

[BevanWeiss]

That looks like the wrong directory.

If you have a 'Program Files (x86)', then you are on an x64 Windows computer (I hope).

If you're on an x64 Windows computer, then you will be running an x64 install of ClearSCADA / GeoSCADA.

If you're running an x64 install of ClearSCADA / GeoSCADA then the installation path for the ClearSCADA / GeoSCADA Server is:

  "%ProgramFiles%\Schneider Electric\ClearSCADA"

The rest of 2.15 seems 'mostly correct.  NOTE: There shouldn't be a '.' at the end of the .NET paths.

You would just type:

START KEY -> 'cmd' then when it comes up with the Command option, right click 'Run as Administrator'

You MUST have an administrative elevated console.

Then..

cd %ProgramFiles%\Schneider Electric\ClearSCADA

%WindDir%\Microsoft.NET\Framework64\v4.0.30319\InstallUtil.exe CSharpSample.dll

It should just reply back something really boring, like 'Registration successful'

Then start up the ClearSCADA server again.  Go into the Server Status tool -> Modules, and you should see the CSharpSample there (which is likely Stopped, No Config).

If you go into ViewX and create an object.. then go back to the Server Status tool the driver should now be running.

Of course.... things are generally never this easy.  So I expect you'd get one of the following:

• Driver Version Mismatch
• Unknown Error

In which case you need to start diving into the ClearSCADA startup log file to see what happened to the driver at startup.

If it all worked, congratulations.  Unfortunately having the first installation of it working isn't the end of the game.

There's some dark magic around when Windows wants to let go of files.. so trying to recompile a new version of the DLL and replace the existing one can be a struggle.  Sometimes you need to re-run the InstallUtil with a -u parameter I think, to uninstall the DLL from the registry.  And then restart, and then you can delete/overwrite the file...  Sometimes you're sure you've done that, but Windows still says no...  Sometimes you just get so crazy trying to do that you just throw away that VM and start again..

NOTE: I'd recommend taking a VM backup of your GeoSCADA install before you start registering your new driver.

[BevanWeiss]

Also... Whilst the breakpoint debugging works, I'd try to avoid it on a real system.

It can cause some slightly strange behaviour.

If you're stopping your driver mid-process, then sometimes GeoSCADA will get bored of waiting and force terminate the process and start another one, breaking your debugging.

And if you have deadlock detection enabled, that can cause problems when you hit a breakpoint in your DBmodule.

It tends to be better to just do a bunch of logging... lot a big bunch...

So every function you write, have a log message telling you that you've entered it.  And another one tell you that you've exited it (you probably want to start using some of the compiler capabilities here so that code files, functions and lines are automatically added into your log messages) it'll make things easier as you progress.

I still don't feel that you've listened to me about my advise that I'm sure the DDK is not what you're looking for.

But hey... at least at this stage you've kind of almost learnt how to write a 'Simple ClearSCADA Driver'.

Even if you do just throw it out and never look at it again...

[Anonymous user]

Hi, using the files created by the example projects give the error below. Dependencies / incorrect format.

(If and when it works, I imagine I will see something added into the project tree?).

[BevanWeiss]

Details are mucho mucho importanto...

So you've just tried to run the x86 InstallUtils on an x64 DLL.  They are different languages.

You should have just copy-pasta'd what I'd written precisely.

I wrote:

%WindDir%\Microsoft.NET\Framework64\v4.0.30319\InstallUtil.exe CSharpSample.dll

You wrote:

C:\Windows\Microsoft.NET\Framework\v4.0.30319\InstalUtil.exe CSharpSample.dll

They look quite different to me... so try again.

As to your question on seeing something in the Project Tree.  Nope, you will not.

As I explained.  THE DDK DOES NOT CREATE OBJECTS.  It defines Objects (for something else to instantiate/create).

You would need to create those newly defined objects through a different manner, like the method I mentioned in a previous message... the right click Create New > ... context option

[Anonymous user]

Hi, it gives the following error.

[BevanWeiss]

Ok... that's my bad.  I've got too many 'd's

%WinDir% instead of %WindDir%

If you just typed 'cd %WinDir%' it should have taken you to C:\Windows (on a default installation)...

[Anonymous user]

Hi,

[Anonymous user]

Hi,

[BevanWeiss]

Yep, that's what it should look like.

I'd forgotten about the 'CSharp Object' object.

So you can see that it's created definitions for these things, but it hasn't created any of them.

You would have to come in and Create New > .. or use the .NET API / Automation Interface to actually create these objects.

If you want your driver to create objects (which as mentioned previously, is frowned upon) then you'd most likely need to use the .NET API in your driver.  Which would have all those annoyances of the .NET API (like creating system definitions, and tracking connections, and server states, and authentication etc etc).

@sbeadle It would be great if I was wrong on this, and there was a way to just instantiate something 'like' the .NET API Advanced Connection from within the Simple DDK without having to jump through all the hoops of the .NET API stuff.  The reasons that I'd like this are to more easily subscribe to change events so that a driver can respond more dynamically to events on other objects (that belong to other drivers).

[Anonymous user]

Hi,

Can I now refer to the objects (once they are created in Geo SCADA) with in a C# project?

(If so, how)

Or is this not possible. (There was a mention of only being of use to a device connection, or something along the lines of).

Thanks,

[BevanWeiss]

Yes,

Once the objects have been instantiated within Geo SCADA, they are normal objects, they exist in CDBObject, you can reference them using the .NET API, or the Automation Interface, or the Query Parser (or the Logic Engine / Expression Engine).

For interactions between objects within your own driver, then there are mechanisms for that which are quite well documented within the Simple DDK PDF (e.g. passing commands from DBModule->Driver exe, or passing data from Driver.exe->DBModule, and to each of the points associated with the scanner, associated with the channel).

If you need to do something which isn't detailed in the Simple DDK PDF, then you can look at the Simple DDK Help File which provides more of a class/object definition basis, and shows you the inheritance, methods and fields against each Simple DDK class.

[Anonymous user]

Hi,

Can I create a new C# project and reference it the to the driver or do I have change the code that was used to create the driver?

I only want to change the value of the analogue in C# and see if it change in Geo SCADA via the driver (if possible).

Thanks,

[BevanWeiss · Accepted solution]

You can create a C# Project that references the .NET API (or the Automation Interface, or that uses ODBC to access the Query Processor.. or that uses AutoIt like libraries to click buttons within ViewX).

The 'reference it to the driver' part doesn't make much sense.

Now that you have your driver, it is part of Geo SCADA.  So you use all the standard Geo SCADA interfaces to deal with objects created from your driver.

You essentially forget that you ever created the driver... you reference the schema if you want to get information on what methods your driver objects expose, what properties they have, what aggregates are available etc etc.

If you only wanted a CDBPoint in GeoSCADA Expert that you could change the value of programmatically, then you should have just created an Internal Analog / Digital point, and used the .NET API to interface to GeoSCADA.  If you wanted to do this on a schedule, then you could have used other Windows standard systems to assist your .NET API application (i.e. the Task Scheduler, or Windows Service Subsystem).

[Anonymous user]

Hi,

I wanted to see if I could communicate between a .net application and Geo SCADA using the driver.

(which was recommended in  a previous post some time back).

I have already been using other methods mentioned to communicate.

It sounds like it is not possible?

It hasn't been a waste of time, I like to check everything out.

I wonder if it would be possible to use the DDK to develop a driver for DNP3 file transfer and to read files.
This is something that may be coming up.

As Geoff said above.

If you are not making a driver, to poll a device, you do not really need to make a DDK driver. You could just have your .Net program read/write to/from internal points. You can also use variables if you are not needing to historize or alarm on a value. Variables do not count against your licensed point count.

Thanks Bevan.

Thanks,

[AndrewScott]

---

@Anonymous user wrote:

I wonder if it would be possible to use the DDK to develop a driver for DNP3 file transfer and to read files.
This is something that may be coming up.

The standard DNP3 driver already supports reading, writing and deleting files using DNP3 file transfer. See the UploadFile, DownloadFile and DeleteOSFile methods in the DNP3 outstation object (CDNP3OS table in database schema).

[Anonymous user]

Thanks Andrew.

The standard DNP3 driver already supports reading, writing and deleting files using DNP3 file transfer. See the UploadFile, DownloadFile and DeleteOSFile methods in the DNP3 outstation object (CDNP3OS table in database schema).

Do the files have to be of a Geo SCADA trend file format for them to be read?

Thanks,

[AndrewScott]

These three methods are generic, they can be used with any file.

When you read (upload) a file its just stored on disk (on the Geo SCADA main server) ready for you to use however you like.

[Anonymous user]

Hi,

I am going to mark Bevan's last post as the answer to this post.

Thanks again for shining a light in the dark.

Andrew, I was told that only trend files with a certain format could be read into Geo SCADA.

What you have wrote sounds good.

An added issue is that I am told that the current files have a unique encryption.
Set up by Hunter Water Tech. I can't confirm this is true at the moment.
I have an example file.
I was hoping to get a copy of the current code from the current SCADA, which is not Schneider.

Thanks,

[BevanWeiss]

@DS20 There is an absolutely atrocious search feature on this forum that is (almost) worth a try sometimes

I thought we'd discussed the DNP3OS upload stuff previously.. so I searched, of course the sort order is broken, so I couldn't find the message I was thinking of, but with searching on upload, I did get this...

https://community.se.com/t5/SCADA-Telemetry-Devices-Forum/Imported-Reading-RTU-configurations-clearS...

(which also doesn't feel like the full discussion thread, that seems like far too short of a message from me).

You can upload ANY file accessible from the SCADAPack filesystem (bold claim... haven't really tested this to the 'ANY' level, but certainly logs, .RTZ configs, .RTU configs, memory crash dumps...).

I do not believe that the HWT files were encrypted, but it's been a very long time.  It should be easy to test if you know the name of the file... the worst it will likely do is just complain and not return the file 🙂 (or core dump the RTU and never work again.. but that likelihood is lowish)