I've read a fair bit of a book called "DNP3 and modern scada solutions" that outlines the concepts in the DNP3 protocol. I think my driver might be using incorrect terminology and that might raise my "mental impedance level" up and make it harder for me to understand what I'm doing.
My custom DNP3 master is talking to a DNP3 test-set [TestSet.exe -S, using a default dnp3_slave_default.xml].
I'm hoping that I can use that default slave xml or that I can figure out how to change it so it does what I need. My DNP3 master application expects me to configure it for an IP Address (127.0.0.1), port (20000), and what I've seen labelled in this codebase I inherited as "Channel DNP Master Address", and "Device DNP Address". I have both set to 1 right now in my own app.
That makes a tuple of four items to get right for network communications to
work: IP=localhost, port=20000, masteraddress=1, deviceaddress=1.
Now, did I get that right? Master Address, is the same thing I believe as the Test Set XML's "<Slave><Stack><LinkLayer>" attributes, either "LocalAddress" which is 1, or "RemoteAddress", which is 100.
From the testset xml:
<SlaveTestSet LogFile="slave_testset.log" PhysicalLayer="tcpserver" Remote="false" RemotePort="4999" LinkCommandStatus="false" StartOnline="false">
<Log Filter="LOG_WARNING" />
<Slave>
<Stack>
<LinkLayer IsMaster="false" LocalAddress="1" RemoteAddress="100"
...
But this is where my confusion starts. There's a LocalAddress="1" and RemoteAddress="100" above. Why does a SLAVE have both a local and a remote address? Is this just an artifact of using the same XML schema for both masters and slaves in your test set app? Is one not used in the slave configurations, ie, when IsMaster="false"?
Secondly, when I run, everything works until I get to this trace message:
2013-Mar-02 13:39:58.382 - DEBUG - dnp.tcpserver - MonitorStateOpening(PLS_OPENI
NG) -> MonitorStateOpen(PLS_OPEN) : Open: 1 Opening: 0 Reading: 0 Writing: 0 Clo
sing: 0
2013-Mar-02 13:39:58.382 - DEBUG - dnp.sts.slave.transport - State Change: TLS_C
losed -> TLS_Ready
2013-Mar-02 13:39:58.382 - DEBUG - dnp.sts - State changed from AS_Closed to AS_
Idle
2013-Mar-02 13:39:58.491 - COMM - dnp.tcpserver - <- 05 64 11 C4 01 00 01 00 68
EA C2 C2 01 3C 02 06 3C 03 06 3C 04 06 35 89
2013-Mar-02 13:39:58.491 - INTERPRET - dnp.tcpserver - <~ DL 1 to 1 : FC_PRI_UNC
ONFIRMED_USER_DATA PayloadSize: 12 From Master Pri->Sec FCB=0 FCV=0
2013-Mar-02 13:39:58.491 - WARNING - dnp.tcpserver - Frame w/ unknown route: Lo
cal: 1 Remote: 1
This is telling me, I think, that my transport layer settings are correct but that the second level (device layer? data layer? what's the right term?) of the protocol's settings are not correct.
In the field, As I understand it, we have the following configuration:
[MyDriver] --> [ConcentratorDevice, like SMP 8-40 from CYBECTEC] --> [IEDs]
Is that "Frame w/ unknown route" error really meaning that I'm only simulating a "[MyDriver] --> [IED]" and I need to run both a master and a slave test set, to simulate the above driver->concentrator->IED scenario?
I apologize if this is a beginner thing, but I'm a bit confused.
Warren
Warren
--
You received this message because you are subscribed to the Google Groups "open-dnp3" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-dnp3+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Yes, link layer addressing is a bit confusing. If you're running an opendnp3 outstation, the "local address" is the outstations link layer address. The "remote address" is the address of the master with which it will communicate. These are typically two different numbers, but don't have to be.
Both numbers are required so that the slave knows it's being spoken to, but also so that it can respond to the correct master. Just write back if that isn't clear.
The branch that Alan mentioned is licensed under the AGPL (and sold commercially), and has a separate mailing list so that no one is confused with unrelated posts. The project site for the commercially offering:
The freeware tools you mentioned are not associated with any branch of opendnp3 and were posted here by a 3rd party.
cheers,
Adam
Hi Warren,
Sorry about the confusion on the freeware tools. I have blocked further post regarding regarding the other non associated wares.
Regards/John