Unity Pro - DNP3 and NOR Module

Modicon M340, NOR module configured for DNP3 and Trihedral VTScada.
Below is a question I posed to a Schneider Electric automation start up engineer. This is my first DNP3 project and it's kickin' my butt. Have any of you Modicon guys seen something like this? I cannot find anywhere that value is being written over.

EDIT: Unity Pro 8

=============
VTS writes a setpoint to M340 via AO tag in the NOR module. The M340 receives the setpoint command successfully and moves that setpoint to an AI tag which is the readback tag in VTS. All tags are configured as REAL/FLOATING POINT. When the readback is displayed in VTS, it is flip flopping between the actual REAL number and the decimal point being truncated. It’s like the readback is being told to display REAL and then it’s told to display INTEGER. We have verified with Trihedral support the both AO and AI tags are configured correctly in VTS. Also, I have verified that I am not using data type INTEGER anywhere in the M340 with this setpoint tag.
=============


Thanks,
Ben

is the value transmitted over the wire on DNP3 only when it changes by a certain amount, eg with a deadband? Some DNP3 devices have settings for deadbands which have tripped me up before.

is there a deadband around zero so that 0 is sent instead of very small insignificant measurement errors?

If it is over ethernet I would capture the traffic with wireshark and see what is actually being sent over the wire.

Yes, there is a deadband setting in the data mapping setup. It doesn't seem to have an effect as I've tried DB from 0.0, 0.001, 0.1 and 1.0 up to 5.
Wireshark, thanks for the tip. Though I've seen it mentioned here plenty of times, I've never used it. Sounds like it can tell me where the problem is originating.

DNP is an complex protocol. I'm just starting to wrap my head around it.

I assume the Scada is the Master? I lookeed up VTS and it seems to use proprietary driver which concerns me. With OPC driver you can see the value before it hit the client application. Master determine the variation (integer vs float, etc) and sometime the variable is implicit. To me, the problem points to the VTS more then PLC communication module.

Here's a suggestion. Download one of the DNP OPC driver from one of the many vendors (Kepware, Metrikon, etcc). They all have demo modes. Run them and look at the same data with a OPC test client (also free from Kepware or Metrikon) and see if you still see the same issue.

Hi,

>Master determine the variation...

The master can request a specific variation but, the master must be prepared for the outstation to send some other variation than requested.

PeakHMI supports DNP3 (as a master and as an outstation) and you can use the demo to test for the correct response.

Mark,

I see Logix and Modbus driver on your website but no DNP3?

Hi,

>I see Logix and Modbus driver on your website but no DNP3?

Near the top of the drivers list:

•DNP3 Master ◦RS-232, RS-485 and TCP/IP
•DNP3 Outstation emulation ◦TCP/IP

Select the menu "Products/PeakHMI/drivers".

Logix and MODBUS on the home page are standalone OPC servers we offer.

harryting said:

DNP is an complex protocol. I'm just starting to wrap my head around it.

I assume the Scada is the Master? I lookeed up VTS and it seems to use proprietary driver which concerns me. With OPC driver you can see the value before it hit the client application. Master determine the variation (integer vs float, etc) and sometime the variable is implicit. To me, the problem points to the VTS more then PLC communication module.

Here's a suggestion. Download one of the DNP OPC driver from one of the many vendors (Kepware, Metrikon, etcc). They all have demo modes. Run them and look at the same data with a OPC test client (also free from Kepware or Metrikon) and see if you still see the same issue.

Click to expand...

Thanks Harry and all of you that have replied. Our company uses Kepware so that's a great idea though I am forced to use it as a last resort.

I've come to find out that my problem is not unknown and has happened to others. What's really freaky is that my AI's that I monitor, e.g., Flow, Pump Speed, Level et.al, are working flawlessly. It's only happening with the AI's that are a readback for the AO setpoints that VTS is asking for. Yes, VTS is the master and NOR module is slave. Moving a %MW to another %MW, data type DINT or REAL. And yes, I'm starting on even addresses.

I have to say that Schneider Electric responds. I have a Start Up App Engineer coming to our panel shop on Monday to sit down with me and nail this problem on a live M340. That is some pretty good service I'd say. I have worked with this guy before and he's sharp, very sharp.

Oh how I wish it will be something stupid like a check box or something.

Problem solved.
I have learned that DNP3 is very finicky about address locations and data types.

For 2 days, I had a Schneider App Engineer sit with me and try to work out this problem. Everything kept pointing to the client, VTScada. Trihedral, VTScada, WebEx'd in to our VTScada machine, ran WireShark and inside of 15 minutes found the problem.

Block size. I had DINT's mixed in with REAL's and apparently VTScada doesn't like that transfer within the same block transfer. I spent about 6 hours converting all my DINT, INT to REAL within the program and NOR module and all was well.

While that worked fine, I still don't like it. My take on this is to use REAL numbers over DINT number, to hell with INTs, make them all REAL. It takes no extra memory so why would it bother me? I reckon because I'm old school and try to conserve memory. Live and learn, die and forget it all.

Ben

Thanks for the update.