GeoSCADA DNP3 File transfer

[DavidSkilbeck]

Hi, I see the YouTube videos below.

Do these cover GeoSCADA DNP3 file transfer?

If not can anyone point me in the direction of videos training material that does please?

Thanks,

[DavidSkilbeck]

Hi, I have found this below
http://gtg.ddns.net:8080/file/help_en-US/Content/DNP3DriverGuide/DefinetheDNP3MasterFileTransferPara...

though I have not been able to find this section

and also

https://www.youtube.com/watch?v=9Q93N8H40uc

Running through the tutorial / guide I found a section below related to file transfer

I am not sure if this is going to work. As I need to use DNP3 file transfer between a number of Hunter water tech and legacy SCADAPack RTU's.
Does any body know if I will I have to write code outside of GeoSCADA or if it is possible to accomplish this?
Thanks,

[JChamberlain]

That section is in the server config tool under global parameters > DNP3 Master.

For RTU -> CS with stuff that old it's hard to say but I wouldn't have thought you would need any external code, just run the UploadFile method on the outstation object.

If you actually want to transfer files directly between the RTUs then yeah I imagine that would need some code on the RTU.

[DavidSkilbeck]

Hi Jesse,

I may have failed to say there are approx 50 of these RTU's to grab a file from. So can it be set up as some sort of queuing system. Where it grabs a file from each RTU in turn?

[BevanWeiss]

The GeoSCADA (nee ClearSCADA) DNP3 driver doesn't support queuing for devices that are actively connected.

Queuing is only when devices are not 'available'.

However... if the RTU supports the DNP3 File Transfer mechanisms, and most SCADAPacks do (certainly the E-series versions, I'm less certain on the non-E series.. and I haven't yet tried the x70 range.. but I really hope so), then you can call the GeoSCADA DNP3OS method to perform the file transfer.

From memory the filenaming was ok, I think you got to pick both the filename that would be uploaded from the RTU, and what it would be written to 'locally' (i.e. on the server).

[BevanWeiss]

There goes the method, against the DNP3OS class.

So you could have logic that goes through and does this to stagger it out, perhaps create a DataTable, and then take the TOP(1) record each 10 minutes, and perform the UploadFile action, I suspect you're possibly looking to retrieve the config.rtu file from a SCADAPack E-series RTU.  Or some .dat files from a Hunter WaterTech RTU.

I've found doing DNP3 uploads on congested radio networks to be a little hit or miss.  And depending on what version of GeoSCADA you're using it may handle issues better or worse than others.

I would advise to perform some kind of verification on the files after you've received them.  Which can actually be harder than it sounds.  config.rtu files for instance don't have any checksum inside them to tell you it's still good.  So if the transfer terminates early, and you're left with 3/4 of a file, you may not immediately be able to identify that.

[AndrewScott]

If the file transfer fails the partial file is often deleted, however not if there is a communication error. This has been changed in the upcoming Geo SCADA 2020 (V83) release to always delete the partial file.

[BevanWeiss]

Thanks @AndrewScott ,

Is there an ETA on GeoSCADA 20202 Release?

From memory we had some issues where the file transfer was flagged as having succeeded, but where the config.rtu was clearly incomplete.  As I was only supervising the person with the actual task of retrieving the files, and didn't have much time, I didn't perform much more investigation.  But retrying the file transfers a few more times did ultimately result in a complete file received.

Without proper IO logs, I couldn't say whether it was ClearSCADA or the RTU that was in the wrong on the connections.

Possibly there was a combination, I'd need to look into the DNP3 spec again.  Perhaps there were too many retries from the RTU end, and hence it terminated the transfer, but since ClearSCADA had already received some valid data it mistakenly called the transfer a success... that's a pure hypothetical spitball idea.  Without logs I don't have evidence for this any which way...