DNP Driver

I'm currently working on my first DNP project and have also had some trouble getting comms established - though I'm using ethernet rather than serial.   Setting [DNPR] SCADAAddress in citect.ini is important, so that your server has a DNP address.  But the main thing that tripped me up was data in my RTU not being assigned "Good Quality".  On Citect my tags all showed as Bad, which I assumed was the comms link, when in fact the comms link was fine and it was just the Quality flag in my RTU that was not being assigned. 

This is a DNPR User Manual I found in my archives. It's for an older (v3.x) version of the driver, but I think it is more detailed than the help file. Chapter 3 contains details on configuring the driver.

PDF

I believe the device address should be ## NAME where ## is your DNP remote's address and NAME is a name for a section in your INI where you can put device specific DNPR settings. There can also be a DNPR section in the INI for the protocol wide settings. Making the DNPR work is very tricky. The driver help section lists all the possible variables and whether it can be for driver, port or device level. I would leave most at default and maybe update you event polling times, SCADA master address and maybe timeout

I'd suggest trying to determine where and what DNP messages is coming out of Citect. Do you have any type of protocol analyzer or does your field device have any comms logging? How about Tx/RX lights on the remote?

I have done several DNPR projects in the past, so if you still have issues and want to post device settings and INI settings I can take a look and compare with my projects.

Made quite a bit of progress, but not there yet.

I can write commands, but cannot read their status (BoX.Val).

I also can read inputs (BiX.Val), but their status still shows as "#BAD"

Event polls are failing, but integrity polls are doing just fine.

Kernel ireporting error 0x68 ("The IIN_Bits 0x4 generate the error code 104(0x68)").

I was taking this to be an address out of range, but I am just reading the first tag of the Bi and Bo groups.

Any ideas from anybody?

I think the DNPr driver is one of the more difficult drivers in CitectSCADA. I regularly get grumpy with it.

Try the Freyr simulator to see if the data in the RTU/PLC/IED is totally valid. https://www.freyrscada.com/dnp3-ieee-1815-Client-Simulator.php I found this useful to start with. Also as Marco mentioned earlier, check the quality item of the tag you are pointing Citect at, this has caught me a couple of times. 

So, you say write to the BO (Binary Output) fine, which of the five control functions are you using? Pulse, LatchOn/Off, Trip or Close? Citect will operate one of these, and the RTU/PLC should update the status item of the tag so that you can read that .Val.

Have you looked at the timestamps within the tag in the RTU/PLC to see if it has updated? This is where I start looking to see if data is sent, as it can be a pulse which you may miss.

What about AI's and AO's, do you have similar issues?

Yes, I've never had one this bad.

I'll look in to the simulator.  Right now i have some hardware - a Modicon Quantum with the Novatech DNPR loadable.  Patched into two ports from Citect so I can use both Modbus and DNP.  I've created a 2nd DNP port as a memory device so I could focus on hjust a few tags.

Quality in Citect is #BAD, even though it is indicating properly.  With a serial port monitor, I can see failed communications on the event comms, but the integrity polls come through perfectly.  I think I should dig into the .quality a bit more, just to see if the DNP device thinks it is OK.

On the Bo, I am using the Trip/Close, to clarify the single DNP point operating two PLC Addresses.  It updates the PLC immediately, but I have to wait for an integrity poll to update the graphics on the PLC side.  I have switched everything over so I am not displaying any write-only variables.But Bo0.Val responds on the integrity poll, and shows #BAD when you hover the mouse. 

I hadn't thought about the time before - I was wondering why some of the tags were showing December 31, 1969 - I know I had never set the clock in the PLC.  I had put timers on the signals so that they got stretched out long enough to see.

I haven't played with the AI's yet.  There are no AO's in the project.

For the event data comms, can you provide me details on the comm failure? Does the PLC reply to the Citect event polls, but just have DNP errors or are there no responses from the PLC. Are there DNP event/class setting you can adjust in the PLC? Might want to double check it has things in the class 1,2 or 3 classes. I have seen devices that do not provide event or class polls and only reply properly to class 0 integrity polls.  If that is the case you can disable event/class polling in Citect and just do frequent class 0 polls.

With a serial monitor, the result appears to be a timeout for the events polls.  The integrity polls come through just fine.  There is nothing in class 1,2 or 3.  Everything is class 0.  I tried to shut off the hjigher class polls, but haven't found the right combination yet.

Here are some settings that I am using to only do integrity/class o polls.

EventPollRatio = 0

EventPollRatioClass1 = 0

EventPollRatioClass2 = 0

EventPollRatioClass3 = 0

These are in the DNPR.Name section of the citect.ini file . The EventPollRatio = 0 may be enough to disable event polls. I put both in and it worked, so I left it.

Looks like I got things a bit confused - I've set it up like this, but I'm still getting timeout errors.  Still intermittent, and with the poll time set for 1 minute, it does update.  Albeit with a 1 minute delay.  Still trying to figure out waht the error could be.  Reverted all of the other DNPR settings back to default to start over.