Libnodave und NetlinkPro

Ralle · 1 März 2007

Ich versuche gerade libnodave mit einem NetlinkPro von Deltalogic zu betreiben. Hat das schon einmal jemand versucht bzw. geschafft? Step7 arbeitet problemlos mit dem NetLinkPro zusammen, ich kann online gehen usw.

Folgende Ausgabe mit Zottels Testprogramm:

Code:

[B]F:\>testnlPro -d 192.168.101.128[/B]
openSocketw.c: enter OpenSocket
openSocketw.c: 1
openSocketw.c: 2 611E
openSocketw.c: peer:192.168.101.128=-2140821312
openSocketw.c: 6
openSocketw.c: 7
openSocketw.c: socket is 1908
openSocketw.c: setsockopt No error 0
openSocketw.c: 8
openSocketw.c: bind Socket error: No error
openSocketw.c: Connected to host: 192.168.101.128
IF1 initAdapter() step 1.
_daveSendWithCRCNLpro:
0:0x00,0x17,0x01,0x03,0x02,0x27,0x00,0x9F,0x01,0x14,0x00,0x90,0x01,0x0C,0x00,0x0
0,
10:0x05,0x02,0x00,0x0F,0x05,0x01,0x01,0x03,0x81,
readMPINLpro: 11 bytes read, 9 needed
readMPIpro: packet:
0:0x00,0x09,0x01,0x03,0x21,0x45,0x3D,0x30,0x33,0x31,0x45,
IF1 initAdapter() success.
ConnectPLC
IF1 connectPLC(1) step 1.
_daveSendWithCRCNLpro:
0:0x00,0x12,0x04,0x82,0x80,0x0D,0x00,0x14,0xE0,0x04,0x00,0x80,0x00,0x02,0x00,0x0
2,
10:0x01,0x00,0x01,0x00,
readMPINLpro: 9 bytes read, 7 needed
readMPIpro: packet:
0:0x00,0x07,0x04,0x82,0x80,0x0D,0x14,0x00,0x80,
IF1 daveConnectPLC(1) step 4.
IF1 daveConnectPLC() step 5.
_daveSendWithCRCNLpro:
0:0x00,0x08,0x04,0x82,0x80,0x0C,0x00,0x14,0x05,0x07,
IF1 daveConnectPLC() step 6.
readMPINLpro: 9 bytes read, 7 needed
readMPIpro: packet:
0:0x00,0x07,0x04,0x82,0x80,0x0D,0x14,0x00,0x80,
IF1 daveConnectPLC() step 7.
PDU header:
0:0x32,0x01,0x00,0x00,0x00,0x00,0x00,0x08,0x00,0x00,
plen: 8 dlen: 0
Parameter:
0:0xF0,0x00,0x00,0x01,0x00,0x01,0x03,0xC0,
_daveExchange PDU number: 65535
IF1 enter _daveSendMessageNLpro
_daveSendWithCRCNLpro:
0:0x00,0x18,0x14,0x82,0x80,0x0C,0x00,0x14,0x32,0x01,0x00,0x00,0xFF,0xFF,0x00,0x0
8,
10:0x00,0x00,0xF0,0x00,0x00,0x01,0x00,0x01,0x03,0xC0,
IF1 _daveSendMessageMPI send done. needAck 0
IF1 _daveGetResponseNLpro receive message.
readMPINLpro: 9 bytes read, 7 needed
readMPIpro: packet:
0:0x00,0x07,0x04,0x82,0x80,0x0D,0x14,0x00,0x80,
result of exchange: 0
PDU header:
0:0x80,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
plen: 0 dlen: 0

[B][COLOR=Red] *** Partner offered PDU length: 0 used limit 0[/COLOR][/B]

PDU header:
0:0x32,0x01,0x00,0x00,0x00,0x00,0x00,0x0E,0x00,0x00,
plen: 14 dlen: 0
Parameter:
0:0x04,0x01,0x12,0x0A,0x10,0x02,0x00,0x10,0x00,0x00,0x83,0x00,0x00,0x00,
_daveExchange PDU number: 65536
IF1 enter _daveSendMessageNLpro
_daveSendWithCRCNLpro:
0:0x00,0x1E,0x14,0x82,0x80,0x0C,0x00,0x14,0x32,0x01,0x00,0x00,0x00,0x00,0x00,0x0
E,
10:0x00,0x00,0x04,0x01,0x12,0x0A,0x10,0x02,0x00,0x10,0x00,0x00,0x83,0x00,0x00,0x
00,
IF1 _daveSendMessageMPI send done. needAck 1
IF1 _daveGetResponseNLpro receive message.
readMPINLpro: 9 bytes read, 7 needed
readMPIpro: packet:
0:0x00,0x07,0x04,0x82,0x80,0x0D,0x14,0x00,0x80,
result of exchange: 0
PDU header:
0:0x80,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
plen: 0 dlen: 0
_daveSetupReceivedPDU() returned: 0=ok
_daveTestReadResult() returned: -128=Unexpected function code in answer
[COLOR=Red][B] error -128=Unexpected function code in answer[/B][/COLOR]
Now disconnecting
readMPINLpro: 15 bytes read, 13 needed
readMPIpro: packet:
0:0x00,0x0D,0x02,0x00,0x21,0x45,0x72,0x72,0x6F,0x72,0x3A,0x20,0x00,0xFF,0x02,
_daveSendWithCRCNLpro:
0:0x00,0x07,0x04,0x82,0x80,0x0C,0x00,0x14,0x80,
readMPINLpro: 9 bytes read, 7 needed
readMPIpro: packet:
0:0x00,0x07,0x04,0x82,0x80,0x0D,0x14,0x00,0x80,
IF1 enter DisconnectAdapter()
_daveSendWithCRCNLpro:
0:0x00,0x03,0x01,0x04,0x02,
IF1 daveDisconnectAdapter() step 1.
readMPINLpro: 5 bytes read, 3 needed
readMPIpro: packet:
0:0x00,0x03,0x01,0x04,0x20,

[B] F:\>[/B]

*** Partner offered PDU length: 0 used limit 0

Das kann doch eigentlich nicht richtig sein. Auch mit dem Testprogramm von AFK, keine Daten. Fehlemeldung auch hier:

error -128=Unexpected function code in answer

PS: Port 7777 ist offen in der Firewall.

Rainer Hönle · 1 März 2007

Ist kein Problem vom NetLink. Ist ein Problem der CPU. Die antwortet auf Connection Request mit Disconnect Request. Dies kann vorkommen, wenn die CPU nicht da ist (dann generiert der NetLink diese Meldnung) oder die Ressourcen der CPU verbraucht sind. Welche CPU kommt denn zum Einsatz? Greift sonst noch jemand parallel auf die CPU zu? Hast Du schon versucht, über das Web-Interface den Status abzufragen? Hast Du schon mal RFC1006 aktiviert und darüber getestet? Zottel meinte mal, dass die RFC-Kommunikation ausführlicher getestet wurde als die direkte NetLink-Kommunikation. Aber das kannst Du ja jetzt nachholen

.

Rainer Hönle · 1 März 2007

Korrektur meinerseits: Fehler liegt schon vorher. Beim Init des Adapters liefert dieser einen Fehler zurück, und zwar 0x031E. Dies bedeutet, dass kein Busparameter-Telegramm erkannt wurde und der NetLink (der für automatische Busprofilerkennung parametriert ist) somit nicht an den Bus gehen kann. Er weiss nicht wie. Bei der CPU das Senden des Busparametertelegramms aktivieren und es sollte klappen. Oder Adapter als einzigen Master am Bus initialisieren, wenn dies libnodave unterstützt.
@Zottel: Nur wenn sich der Adapter mit V0... meldet ist alles ok. Wenn als Antwort E=0... kommt, trat ein Fehler auf. Betrifft den PC-Adapter genauso.

Ralle · 1 März 2007

@Rainer

Werd mal die Einstellungen ändern, es hängt eine VIPA 214 am MPI. Komischerweise hatte ich es mittendrin beim Testen einmalig geschafft, mit meiner Software im Debugmodus, also mit einem Halt zwischendrin, an dem ich die Variablen kontrolliert habe. Verbindung abgebaut und acuh danach nicht mehtr geschafft. Das ganze war ohne Veränderungen an den Treibereinstellungen so passiert.

PS: Danke übrigens :-D, werden wir schon noch schaukeln!

Ralle · 1 März 2007

Rainer Hönle schrieb:
Ist kein Problem vom NetLink.

Ich mein, ist wohl ein Problem von libnodave, mit Step7 geht es ja völlig problemlos.

Rainer Hönle schrieb:
Hast Du schon mal RFC1006 aktiviert und darüber getestet? Zottel meinte mal, dass die RFC-Kommunikation ausführlicher getestet wurde als die direkte NetLink-Kommunikation. Aber das kannst Du ja jetzt nachholen .

Damit geht es nun tatsächlich. Mußte noch Bus autobaud auf OFF stellen, scheint so, als liefert die VIPA das nicht.

Das ging ja dann schon mal ganz gut, nun kann ich mich dem Testen widmen

!

Ralle · 1 März 2007

Rainer Hönle schrieb:
Beim Init des Adapters liefert dieser einen Fehler zurück, und zwar 0x031E.

Nur mal aus Interesse, wo finde ich das? Ich schein Tomaten auf den Augen zu haben, kann das im Ausdruck nicht entdecken :???:.

afk · 1 März 2007

Ralle schrieb:
Nur mal aus Interesse, wo finde ich das? Ich schein Tomaten auf den Augen zu haben, kann das im Ausdruck nicht entdecken :???:.

Ich vermute mal, hier:

Code:

F:\>testnlPro -d 192.168.101.128
openSocketw.c: enter OpenSocket
openSocketw.c: 1
openSocketw.c: 2 611E
openSocketw.c: peer:192.168.101.128=-2140821312
openSocketw.c: 6
openSocketw.c: 7
openSocketw.c: socket is 1908
openSocketw.c: setsockopt No error 0
openSocketw.c: 8
openSocketw.c: bind Socket error: No error
openSocketw.c: Connected to host: 192.168.101.128
IF1 initAdapter() step 1.
_daveSendWithCRCNLpro:
0:0x00,0x17,0x01,0x03,0x02,0x27,0x00,0x9F,0x01,0x14,0x00,0x90,0x01,0x0C,0x00,0x0
0,
10:0x05,0x02,0x00,0x0F,0x05,0x01,0x01,0x03,0x81,
readMPINLpro: 11 bytes read, 9 needed
readMPIpro: packet:
0:0x00,0x09,0x01,0x03,0x21,0x45,0x3D,[COLOR="Red"]0x30,0x33,0x31,0x45[/COLOR],
IF1 initAdapter() success.
ConnectPLC
IF1 connectPLC(1) step 1.

0x30,0x33,0x31,0x45 sind die ASCII-Codes für 031E ...

Gruß Axel

Ralle · 1 März 2007

@afk

dann frag ich mich doch aber, wieso kommt initAdapter mit Success zurück, oder?

He der NetlinkPro ist schnell und funtionierte sofort (mit step7), wenn man weiß auf was man achten muß geht es dann auch mit libnodave.

Rainer Hönle · 2 März 2007

Meines Wissens nach schickt die Vipa kein Busparametertelegramm. Bei Step7 muss dann in der NetLink Pro-Einstellung bei Buseinstellungen "Keine automatische Erkennung der netzbezogenen Parameter" angeklickt sein. Dann wartet der NetLink Pro nicht auf das Busparemetertelegramm und geht mit den gewünschten Einstellungen an den Bus.

dann frag ich mich doch aber, wieso kommt initAdapter mit Success zurück, oder?

Der Meinung bin ich auch. Der der Adapter ist nach dem fehlgeschlagenen Init nicht am Bus und es kann keine Kommunikation zu irgendwem aufgebaut werden.

@Ralle:
Installier mal die Demoversion von AGLink. Davon brauchst Du nur das Konfigurationsprogramm. In diesem gibt es den Tab "Gerätetest". Dort wird versucht, von allen erkannten SPSen die MLFBNummer zu lesen. Und dort sollte dann eine Fehlermeldung im Klartext ausgegeben werden. In diesem Fall bei der Funktion AGL_InitAdapter.

afk · 2 März 2007

Ralle schrieb:
dann frag ich mich doch aber, wieso kommt initAdapter mit Success zurück, oder?

Mußt Du nur mal in die Sourcen von libnodave schauen, dann siehst Du's gleich: Weil die Rückgabewerte von NLpro gar nicht überprüft werden, was dann in den nächsten Schritten zu dem beschriebenen Verhalten führt.

Darum gilt:

Ralle schrieb:
wenn man weiß auf was man achten muß geht es dann auch mit libnodave.

Allerdings finde ich eines schon recht seltsam:

Ralle schrieb:
Step7 arbeitet problemlos mit dem NetLinkPro zusammen, ich kann online gehen usw.

und

Rainer Hönle schrieb:
Der der Adapter ist nach dem fehlgeschlagenen Init nicht am Bus und es kann keine Kommunikation zu irgendwem aufgebaut werden.

Das passt IMHO nicht zusammen, entweder der NLpro kann die Bus-Schnittstelle nicht initialisieren, dann dürfte Step7 auch nicht kommunizieren können, oder der Init vom Bus funktioniert, dann sollte das auch mit libnodave problemlos funktionieren ... :sb10:

Gruß Axel

Rainer Hönle · 2 März 2007

afk schrieb:
Das passt IMHO nicht zusammen, entweder der NLpro kann die Bus-Schnittstelle nicht initialisieren, dann dürfte Step7 auch nicht kommunizieren können, oder der Init vom Bus funktioniert, dann sollte das auch mit libnodave problemlos funktionieren ... :sb10:

Gruß Axel

Hallo Axel,
wie geschrieben ist bei Siemens das Kreuzchen "Keine automatische Erkennung der netzbezogenen Parameter" bei den Buseinstellungen gesetzt. Dann kommt der Adapter problemlos an den Bus, da er nicht auf das Busparametertelegramm wartet. Und alles ist in Butter

. Fehlt das Häkchen, kommt auch Step7 nicht an den Bus.
Zur Info: Die eingestellte Baudrate erkennt der NetLink Pro automatisch. Um aber zu wissen, mit welchen Parametern (MPI/PB/DP/Std.....) er am Bus mitspielen darf, wartet er normalerweise auf das Busparametertelegramm. Die Jungs (m/w) die bereits spielen, sollten ja wissen, nach welchen Regeln gespielt wird. Dann geht er sich mit genau diesen Parameter an den Bus. Dadurch wird ein "Zerstören" des Busses durch falsche Baudrate oder sporadische Fehler durch falsche Parameter verhindert. Wird dieses Telegrammnicht gesendet, kann man dem NetLink Pro mitteilen, dass man weiß was man will und er mit den gewünschten Parametern ohne Busprofilerkennung mitspielen soll.

afk · 2 März 2007

Rainer Hönle schrieb:
Hallo Axel,
wie geschrieben ist bei Siemens das Kreuzchen "Keine automatische Erkennung der netzbezogenen Parameter" bei den Buseinstellungen gesetzt. Dann kommt der Adapter problemlos an den Bus, da er nicht auf das Busparametertelegramm wartet. Und alles ist in Butter . Fehlt das Häkchen, kommt auch Step7 nicht an den Bus.

Hallo Rainer,
hab's mir gerade mal angeschaut, Du hast natürlich recht, da das Häkchen in den Parametern der PG/PC-Schnittstelle untergebracht ist.

Ich hätte diese Option allerdings eher in der Hardware-Konfiguration des NLpro erwartet, da das meines Erachtens ja nichts damit zu tun hat, mit welchem Programm bzw. mit welchem PC (unterschiedliche Konfiguration der PG/PC-Schnittstelle) ich auf den NLpro zugreife, sondern von dem Bus abhängt, an dem dieser NLpro hängt. Und wenn es in der Hardware-Konfiguration des NLpro stecken würde, dann wäre es wieder für alle gleich ...

Gruß Axel

Rainer Hönle · 2 März 2007

afk schrieb:
Hallo Rainer,
hab's mir gerade mal angeschaut, Du hast natürlich recht, da das Häkchen in den Parametern der PG/PC-Schnittstelle untergebracht ist.

Ich hätte diese Option allerdings eher in der Hardware-Konfiguration des NLpro erwartet, da das meines Erachtens ja nichts damit zu tun hat, mit welchem Programm bzw. mit welchem PC (unterschiedliche Konfiguration der PG/PC-Schnittstelle) ich auf den NLpro zugreife, sondern von dem Bus abhängt, an dem dieser NLpro hängt. Und wenn es in der Hardware-Konfiguration des NLpro stecken würde, dann wäre es wieder für alle gleich ...

Gruß Axel

Wir haben uns da an Siemens gehalten. Dort heißt die Einstellung "Einziger Master am Bus" und bewirkt genau das Gleiche. Diese Daten im NetLink Pro zu speichern wäre für einen stationären Einsatz sicher ok. Aber oft wird er NetLink Pro an wechselnden SPSen betrieben. Bei Siemens z.B. einmal über STep7 und dann über MicroWin. Und dann legt die Applikation fest, wie der NetLink sich verhalten soll.

afk · 2 März 2007

Rainer Hönle schrieb:
Wir haben uns da an Siemens gehalten. Dort heißt die Einstellung "Einziger Master am Bus" und bewirkt genau das Gleiche.

Wieder was gelernt, danke ... eure Bezeichnung für die Option finde ich übrigens deutlich besser.

Gruß Axel

Ralle · 2 März 2007

@afk

Code:

Mußt Du nur mal in die Sourcen von libnodave schauen, dann siehst Du's gleich: 
Weil die Rückgabewerte von NLpro gar nicht überprüft werden, was dann in den 
nächsten Schritten zu dem beschriebenen Verhalten führt.

Klar, ich tu mich mit C-Code und vor allem dem von libnodave noch etwas schwer, da finde ich genau diese Sachen eher nicht :???:.

@Rainer

Danke für den Tip, ich werde das mit AGLink mal machen.

Libnodave und NetlinkPro

Ralle

Super-Moderator , User des Jahres 2006-2007

Rainer Hönle

Level-3

Rainer Hönle

Level-3

Ralle

Super-Moderator , User des Jahres 2006-2007

Ralle

Super-Moderator , User des Jahres 2006-2007

Ralle

Super-Moderator , User des Jahres 2006-2007

afk

Level-1

Ralle

Super-Moderator , User des Jahres 2006-2007

Rainer Hönle

Level-3

afk

Level-1

Rainer Hönle

Level-3

afk

Level-1

Rainer Hönle

Level-3

afk

Level-1

Ralle

Super-Moderator , User des Jahres 2006-2007

Similar threads

Wir schützen deine Privatsphäre