# B&r tcp



## Hannes (17 Juni 2009)

Hallo,

hab mal wieder eine Frage zu einer B&R- Steuerung, Auf meinem PP41 läuft ein TCP- Task, welcher mit einem externen Programm kommuniziert,
wenn ich jetzt über das Automation Studio über Ethernet auf das PP41 will, dann geht das nicht, da mir der TCP- Task die Ethernet- Schnittstelle blokiert,

Meine Frage wäre, wie würdet ihr das machen, wenn ihr so einen Fall hättet, 
immer das externe Programm schließen und dann mit der ProgrammierSW drauf oder gibt es eine Möglichkeit, wie man das anders machen kann?

Vielen Dank,
schönen Tag noch,

lg


----------



## Jens_Ohm (17 Juni 2009)

Ich kann es dir leider nur für AS<3 sagen.


 Klicke im Projekt auf CPU und wähle dann den Reiter „Kommunikation“. Dort trägst Du unter Verbindungen einen Wert > 2 ein.
 Sollte das nicht klappen beschreibe genauer was und wie du kommunizierst.


 Grüße Jens


----------



## Maxl (19 Juni 2009)

Ich denke auch, dass die Erhöhung der maximalen Verbindungsanzahl dasProblem lösen sollte - Ina-Kommunikation und TCP-Kommunikation sollten sich insofern nicht in die Quere kommen können, da INA ja auf UDP basiert.

mfg Maxl


----------



## Jens_Ohm (25 Juni 2009)

..........und?


----------



## Hoffiie (6 November 2009)

Hallo, da es hier schon mal um tcp/INA geht, denke ich mal ich kann auch hier posten.

Frage: Ist es möglich, gibt es Erfahrungen, das INA Protokoll selbst zi implementieren?

Im Zusammenhang einer Projektarbeit möchte ich gern von einem Linux-Rechner auf diverse PLCs von B&R drauf zu greife. Der Datenaustausch über ftp oder http ist nicht geeignet, zu langsam und warum CF-Card belasten. Die Idee steckt dahinter ganz einfach wie im PVI Manager Variablenliste lesen, Variable finden und dann lesen oder Schreiben.

Hat jemand Erfahrungen damit?


----------



## uncle_tom (6 November 2009)

ich glaub ja kaum das B&R so ohne weiteres sein Protokoll offenlegt. Aber du kannst ja mal bei B&R nachfragen.

Andere Alternative währe via Wireshark etc. das Protokoll auszuspionieren - viel Spass.


----------



## Maxl (6 November 2009)

Meines Wissens nach legt B&R sein Protokoll generell nicht offen (nur für Partner wie z.B. Copadata), Du bist eigentlich immer auf PVI oder OPC angewiesen; und hier kannst Du eigentlich nur auf die Plattformen setzen, die auch von B&R unterstützt werden.
Für Linux müsste aber was existieren, da meines Wissens nach ja das B&R Prozessleitsystem Aprol auf Linux basiert - d.H. die greifen da aus Linux auf B&R-Hardware zu.

Eine Alternativlösung wäre noch OPC, welches direkt auf der Steuerung läuft (wurde am letzten B&R Usermeeting vorgestellt), ich weiß nicht ob das schon verfügbar ist; es setzt allerdings eine neue AR voraus (mit allen Nebenwirkungen).

mfg Maxl


----------



## Hoffiie (9 November 2009)

Auf Aprol bin das Wochenende auch gestoßen, mal sehen wie Quelloffen das dort gehalten ist. Mal Runterladen. Den Umweg über OPC wollte ich nicht erste gehen, da dies sehr auf Microsoft zugeschnitten ist und worum nicht Funktionen den OS von der PLC direkt nutzen. Bald ist ja die SPS-Drives, da kann ich mal die guten Freunde von BuR direkt fragen, wie offen sie denn wirklich sind. INA "Communiction Treiber" gibt es gegen Lizenzen für Linux/Aprol.
Werde Posten, was ich in den nächsten Tagen mal so heraus finden konnte.


----------



## doelckenbeck (16 November 2009)

Hallo, ich habe auch mal eine Frage zur Ethernetkommunikation. Ich verwende ein PP220 von B&R und versuche eine Online- Verbindung über Ethernet mit dem Automation Studio einzurichten, klappt bloß nicht. Die serielle Verbindung über COM1 funktioniert einwandfrei. Hab die IF5(Ethernet)- Eigenschaften eingestellt und Extras -> Optionen -> Online eine neue Online- Kommunikation über TCP/IP eingestellt. Was mach ich falsch?


----------



## uncle_tom (16 November 2009)

Servus,

@doelckenbeck

ich steck jetzt zwar beim PP220 nicht so drin - aber die Kommunikationsdienste sind ja bei allen B&R Steuerungen identisch.

Damit die Onlineverbindung über Ethernet funktioniert, müssen ein paar Sachen eingestellt werden.

1. Bei der verwendeten Schnittstelle muss der Punkt "INA-Kommunikation aktivieren" angehakt werden.

2. Für die INA-Kommunikation muss für die Schnittstelle eine INA-Adresse eingestellt werden. Entweder gibt es hierfür einen hardwareseitigen Knotenschalter oder die Adresse wird softwareseitig eingestellt. Die eingestellte Adresse musst du dann auch bei deinen Verbindungseinstellungen am Programmiergerät einstellen (Stichwort SA und DA).

3. Die geänderten Hardwareeinstellungen (asconfig) müssen in die Steuerung geladen werden - entweder seriell oder CF-Karte am PC beschreiben.

Weiterhin müssen die IP-Adressen von Panel und Programmiergerät natürlich im gleichen Netz liegen. D.h. unabhängig von den Online-Eigenschaften im AS muss sich das Panel vom Programmiergerät schon mal "anpingen" lassen.


----------



## doelckenbeck (16 November 2009)

Vielen Dank, ich werds morgen gleich ausprobieren.


----------



## doelckenbeck (17 November 2009)

So, habs probiert, läuft aber nicht.
Hab folgendes in den Eigenschaften der Ethernet- Schnittstelle eingestellt:
IP: 192.168.10.100
Broadcast: 0.0.0.0
Subnet: 255.255.255.0

außerdem unter dem Reiter INA:
INA Kommunikation aktivieren

Zusätzlich steht da, daß die INA Knotennummer durch die Hardware ausgewählt wird. Hab an den Mode/Node- Schaltern des Gerätes 01 eingestellt und unter Extras -> Optionen -> Verbindungsparameter "/SA=1" angegeben.

Quelladresse ist 1 und Zieladresse wird automatisch bezogen.


----------



## doelckenbeck (17 November 2009)

uncle_tom schrieb:


> Servus,
> 
> @doelckenbeck
> 
> ...


 
So, habs probiert, läuft aber nicht.
Hab folgendes in den Eigenschaften der Ethernet- Schnittstelle eingestellt:
IP: 192.168.10.100
Broadcast: 0.0.0.0
Subnet: 255.255.255.0
Anpingen läßt sich die ip!

außerdem unter dem Reiter INA:
INA Kommunikation aktivieren

Zusätzlich steht da, daß die INA Knotennummer durch die Hardware ausgewählt wird. Hab an den Mode/Node- Schaltern des Gerätes 01 eingestellt und unter Extras -> Optionen -> Verbindungsparameter "/SA=1" angegeben.


----------



## uncle_tom (17 November 2009)

SA = Source-Adresse--> Adresse des Programmiergeräts
DA = Destination Adress --> Adresse der Steuerung

Programmiergerät und Steuerung müssen natürlich unterschiedliche Adressen haben.

Weiterhin muss beachtet werden, dass der Knotenschalter Als Hex-Schalter ausgeführt ist, die Angabe der Adresse im Automation-Studio aber Dezimal erfolgt !

Wenn du also beim x16-Schalter 1 eingestellt hast, dann musst du als DA-Adresse im Automation-Studio 16 eintragen !

Eine Änderung des Knotenschalters wird soviel ich mich erinnern kann nur nach einem Warmstart der Steuerung übernommen !

Bei den Online-Einstellungen im AS kannst du bei Auswahl von TCP/IP unter Eigenschaften die IP-Adresse der Steuerung sowie die INA-Adresse des PG´s (Quelladresse) und die INA-Adresse der Steuerung (Zieladresse) angeben. Die Option automatisches beziehen der Adresse hab ich noch nicht ausprobiert - ich glaub das funktioniert nicht.


----------



## pjtec (12 Januar 2010)

uncle_tom schrieb:


> Eine Änderung des Knotenschalters wird soviel ich mich erinnern kann nur nach einem Warmstart der Steuerung übernommen !
> 
> .... Die Option automatisches beziehen der Adresse hab ich noch nicht ausprobiert - ich glaub das funktioniert nicht.



-> Richtig, Knotennummernschalter werden nur beim Hochlauf ausgelesen.

-> Die Option automatisches Beziehen der Adresse wurde sicher nur so per Spaß eingebaut - sicher funktioniert die auch!

Techn. Hintergrundinfo:
  INA kommuniziert über UDP, standardmäßig Port 11159.

Konzeptmöglichkeiten gibts für Windows Betriebssysteme reichlich:
 - AR OPC Server gibt es seit AR V3.00 bzw. AS 3.0.80
 - Windows OPC Server
 - PVI Services .NET (Programmierung der PC-seitigen Applikation mit Microsoft Visual Studio in C++, C#, VB,...)

Die beiden letzteren bedingen natürlich eine funktionierende Onlinekommunikation ;-) bzw. muss auch beachtet werden, dass der PVI Manager auf nicht-B&R PCs ohne Lizenzdongle maximal 2h läuft.
Da OPC auf DCOM basiert und DCOM ein Protokoll von Microsoft ist, wird das in Linux natürlich schwierig. Die Erfahrung hat gezeigt, dass es aber auch mit Windows nicht ganz einfach ist eine Verbindung aufzubauen ;-)


----------



## mike_nl (20 Januar 2010)

pjtec schrieb:


> ->
> Konzeptmöglichkeiten gibts für Windows Betriebssysteme reichlich:
> - AR OPC Server gibt es seit AR V3.00 bzw. AS 3.0.80
> - Windows OPC Server
> ...


 
Hallo pjtec,

es geht auch anders. Habe selbst mit einem Kollegen zusammen einen ANSL Driver fuer Unix und Linux Entwickelt. Dieser kann auf der Basis von PVI variablen austauschen. Dieser laeuft jetzt seit ca. 10 Monaten bei verschiedenen Kunden ohne Probleme. Das ist aber noch nicht Offiziell, heisst das die TB's davon noch gar nichts wissen. Kommt aber. Bei Fragen Bitte eine PM an mich.

Thema Verbindungen:
Alles ist moeglich. Das habe ich schon so oft bei kunden umgesetzt. Externe TCP und Online Kommunikation ist gar kein Problem. In Highspeed und in Restzeit (TK#8 ). RAW TCP Kommunikation von der PLC zu Linux, UNIX und Windoof und zurueck bei gleichzeitiger AS Online Verbindung.


----------



## doelckenbeck (20 Januar 2010)

Hallo,
ich verwende AS 2.5.2.7 und möchte damit eine Modbus TCP Kommunikation zu einer Steuerung aufbauen. Ab AS 3 gibts Bibliotheken dafür. Hat zufällig jemand eine Bibliothek für 2.5, die es mir ermöglich eine solche Kommunikation aufzubauen?


----------



## mike_nl (21 Januar 2010)

doelckenbeck schrieb:


> Hallo,
> ich verwende AS 2.5.2.7 und möchte damit eine Modbus TCP Kommunikation zu einer Steuerung aufbauen. Ab AS 3 gibts Bibliotheken dafür. Hat zufällig jemand eine Bibliothek für 2.5, die es mir ermöglich eine solche Kommunikation aufzubauen?


 
An Deiner Stelle doelckenbeck wuerde ich updaten. Du hast eh keinen Support mehr auf die alten Softwareschinken. AS 3.x.x ist die Zukunft. Wer nicht umsteigt verschenkt Geld in Punkto Software schreiben und Projekthandling. Leider kann ich nicht mehr sagen, ausser das Du mit der alten Version und ModBus TCP deine Probleme kriegen wirst.


----------



## doelckenbeck (22 Januar 2010)

Hab da schon was vorbereitet. Die Bibliothek libmodbus 2.0.3 hab ich im Automation Studio fehlerfrei kompiliert, allerdings musste ich ein paar Befehle auskommentieren, damit das läuft. Mit folgenden Befehlen bzw. Funktionen hab ich noch Probleme:
htons(...)
printf
TCP_NODELAY
error
perror
IP_TOS
sprintf
Die printf- Befehle sind nicht so wichtig, bei error und perror bin ich mir nicht sicher, aber die anderen sind für die Funktion maßgeblich. Andere Funktionen konnte ich durch die selben aus den B&R- Bibliotheken ersetzen, nur halt diese nicht.
Fällt jemandem dazu was ein?


----------



## eder2f (25 Januar 2010)

Jens_Ohm schrieb:


> Ich kann es dir leider nur für AS<3 sagen.
> 
> 
> Klicke im Projekt auf CPU und wähle dann den Reiter „Kommunikation“. Dort trägst Du unter Verbindungen einen Wert > 2 ein.
> ...


 
Das ist eine Falsch-Info!!
Die Anzahl der Verbindungen bezieht sich nur auf Ina-Verbindungen - sprich via PVI, PVIControl, PVIServices, PVI Comdll, ASIMA,..
Eine TCP Kommunikation via beliebigem Port fällt nicht unter Verbindungen!!


----------



## eder2f (25 Januar 2010)

doelckenbeck schrieb:


> Hallo,
> ich verwende AS 2.5.2.7 und möchte damit eine Modbus TCP Kommunikation zu einer Steuerung aufbauen. Ab AS 3 gibts Bibliotheken dafür. Hat zufällig jemand eine Bibliothek für 2.5, die es mir ermöglich eine solche Kommunikation aufzubauen?


 
In AS 3.x gibts nicht Fubs sondern einen integrierten Master, welcher im HW-Baum konfiguriert werden kann.
Ab 3.0.80 gibts wieder Fubs wie für ModbusRTU nur für TCP!


----------



## doelckenbeck (27 Januar 2010)

Hallo, da ich leider nur Automation Studio 2.5.2.7 verwenden kann bringt mich das nicht wirklich weiter. 
Ich hab da was von B&R bekommen: ein mbtcp- Konfigurationsdatenobjekt und ein modtcp- Systemobjekt. In dem Datenobjekt steht nun folgendes (als Beispiel):

"#MBFUNCTION=READ_DISCRETE_INPUTS" 
"#MBTELEGRAMSTARTADDRESS=0"
"#MBNUMBEROFITEMS=4"
"#MBPOLLINTERVALL=3000"
"#MBSTATUS=uiTel2Status"
"bTestDi1, DI, 0"
"bTestDi2, DI, 1"
"bTestDi3, DI, 2"
"bTestDi4, DI, 3"

Ich frag mich nun folgendes:

Wenn ich Werte von Variablen mit meinem Client austauschen will, weise ich den Variablen bTestDi1, usw. diese Werte zu, solange die vom Typ BOOL, USINT oder UINT sind? Oder hab ich das falsch verstanden?


----------



## knuppel (14 November 2014)

@doelckenbeck wie hast du die libmodbus auf der Steuerung kompiliert?


----------



## nl_tmp (14 November 2014)

Beitrag gelöscht


----------

