Wenn dein Problem oder deine Frage geklärt worden ist, markiere den Beitrag als "Lösung",
indem du auf den "Lösung" Button rechts unter dem entsprechenden Beitrag klickst. Vielen Dank!
Hallo,
ich muss im Rahmen einer Projektarbeit ein "Beckhoff Busklemmensystem" mit dem Buskoppler BK9000 über LabVIEW ansteuern. Hat bereits jemand Erfahrung mit Beckhoffklemmen gemacht und evtl. schon ein paar Treiber geschrieben?
Würde mich über Hilfe sehr freuen.
MfG Chaos
Ich arbeite auch mit Beckhoff SPSn, du kannst TwinCAT ADS oder Modbus TCP verwenden um mit deiner SPS zu kommunizieren.
ADS gibs als API für Activex, als Dll, als .net lib, oder du verwendest den OPC Server von Beckhoff, der auch ADS verwendet. such mal in den Hilfefiles (.chm) nach "TcAdsOcx.chm" ,"TcAdsNet.chm"
Am einfachsten ist natürlich ein OPC Server, falls du diesen nicht hast schlage ich dir .net. oder activex vor.
Bei Modbus wirds ein bisschen schwieriger, da must du das Modbus TCP Protokoll selbst mit LabVIEW Nachbilden, oder du kaufst dir eine MosbusTCP API. hier gibs die Protokoll beschreibung "www.modbus.org"
mfg Mario
26.09.2007, 08:01 (Dieser Beitrag wurde zuletzt bearbeitet: 09.01.2008 12:21 von rolfk.)
' schrieb:Hallo
Ich arbeite auch mit Beckhoff SPSn, du kannst TwinCAT ADS oder Modbus TCP verwenden um mit deiner SPS zu kommunizieren.
ADS gibs als API für Activex, als Dll, als .net lib, oder du verwendest den OPC Server von Beckhoff, der auch ADS verwendet. such mal in den Hilfefiles (.chm) nach "TcAdsOcx.chm" ,"TcAdsNet.chm"
Am einfachsten ist natürlich ein OPC Server, falls du diesen nicht hast schlage ich dir .net. oder activex vor.
Bei Modbus wirds ein bisschen schwieriger, da must du das Modbus TCP Protokoll selbst mit LabVIEW Nachbilden, oder du kaufst dir eine MosbusTCP API. hier gibs die Protokoll beschreibung "www.modbus.org"
mfg Mario
Hier ist noch eine erste Version um Beckhoff Ethernet Klemmen direkt über ADS anzusprechen ohne die Verwendung von TwinCAT, also direkt mit TCP/IP Nodes in LabVIEW. Das Ganze funktioniert bei mir erfolgreich um digitale Eingänge zu lesen. Die Basisinfrastruktur ist im Prinzip anwesend um alle möglichen Module anzusprechen. Das einzige Problem dabei ist die interne Struktur der ADS Register ausfindig zu machen. Es ist selbst möglich um andere ADS Ports dann 300 direkt anzusprechen, etwa Port 100 um die Konfigurationsregister zu lesen und zu veränderen. Aber das habe ich bis jetzt nicht getestet. Mit dieser Library ist das einzige Problem bei ADS wohl vor allem die Registermap herauszusuchen. Die Dokumentation lässt da wirklich einiges etwas im unklaren.
Die UDP Implementierung ist noch nicht gemacht. Im TCP Directory ist ein ADS TCP Test Example.vi das eine einfache Idee gibt wie die VIs verwendet werden können. ADS TCP Tree.vi gibt eine Übersicht über alle VIs die man benützen kann. Andere VIs innerhalb der Library sind HilfsVIs und sollten bei Gebrauch in einer Applikation nicht verwendet werden, da ihr Interface in zukünftigen Versionen jederzeit ändern kann oder sie ganz verschwinden können.
Hallo rolfk,
der Thread ist zwar schon fast 1 Jahr alt aber vielleicht wird er ja wieder gelesen.
Ich versuche auch gerade eine BK9000 mit LabVIEW in Betrieb zu nehmen. Anpingen kann ich das Teil bereits.
Angeschlossen ist bei mir:
KL2134 (4 outputs)
KL2134 (4 outputs)
KL1418 (8 inputs)
Jetzt hab ich mir mal deine VIs runtergeladen und laufen lassen.
Geöffnet hab ich gerade das file "ADS TCP Test Example.vi" in das ich die IP von meinem BK9000 eingetragen habe.
Wenn ich es ausführe bekomme ich als Rückgabe:
major: 1800
minor: 0
build: 0
Name: BK9000
bei "data" bekomm ich dann den Status des KL1418 zurück. Dh wenn ich manuell per Kabel den:
Eingang 1 auf 24V setze bekomme ich eine b1
Eingang 2 auf 24V setze bekomme ich eine b10
Eingang 3 auf 24V setze bekomme ich eine b100
Eingang 4 auf 24V setze bekomme ich eine b1000
Eingang 5 auf 24V setze bekomme ich eine b10000
Eingang 6 auf 24V setze bekomme ich eine b100000
Eingang 7 auf 24V setze bekomme ich eine b1000000
Eingang 8 auf 24V setze bekomme ich eine b10000000
Jetzt ist nur noch die Frage wie kann ich die beiden KL2134-Module ansteuern?
Das sind jeweils 4 Ausgänge pro Modul.
In deinem VI-Tree gibt es auch ein Write-Bytes-vi. Aber wie kann man dieses verwenden?
' schrieb:Hallo rolfk,
der Thread ist zwar schon fast 1 Jahr alt aber vielleicht wird er ja wieder gelesen.
Ich versuche auch gerade eine BK9000 mit LabVIEW in Betrieb zu nehmen. Anpingen kann ich das Teil bereits.
Angeschlossen ist bei mir:
KL2134 (4 outputs)
KL2134 (4 outputs)
KL1418 (8 inputs)
Jetzt hab ich mir mal deine VIs runtergeladen und laufen lassen.
Geöffnet hab ich gerade das file "ADS TCP Test Example.vi" in das ich die IP von meinem BK9000 eingetragen habe.
Wenn ich es ausführe bekomme ich als Rückgabe:
major: 1800
minor: 0
build: 0
Name: BK9000
bei "data" bekomm ich dann den Status des KL1418 zurück. Dh wenn ich manuell per Kabel den:
Eingang 1 auf 24V setze bekomme ich eine b1
Eingang 2 auf 24V setze bekomme ich eine b10
Eingang 3 auf 24V setze bekomme ich eine b100
Eingang 4 auf 24V setze bekomme ich eine b1000
Eingang 5 auf 24V setze bekomme ich eine b10000
Eingang 6 auf 24V setze bekomme ich eine b100000
Eingang 7 auf 24V setze bekomme ich eine b1000000
Eingang 8 auf 24V setze bekomme ich eine b10000000
Jetzt ist nur noch die Frage wie kann ich die beiden KL2134-Module ansteuern?
Das sind jeweils 4 Ausgänge pro Modul.
In deinem VI-Tree gibt es auch ein Write-Bytes-vi. Aber wie kann man dieses verwenden?
Hast du mir hier noch einen Tipp?
Danke und Gruß
O.
Also, die Busklemmen Module werden alle in der Reihenfolge wie sie angeschlossen sind in die Registermap des Controllers gemappt. D.h. Wenn Du das KL1418 an erster Stelle hast sollte das 8 Bits auf Adresse (index offset) 0 belegen. Die zwei anderen Module kämen dann wahrscheinlich ab Adresse 1 (oder haben die Module jetzt 16 Bit Adressierung, das weiss ich jetzt nicht mehr so ganz).
Das Problem ist hier folgendes: Ich habe die Library zwar allgemein implementiert aus Informationen die ich vom Internet gefunden habe, (beispielswiese source code im Projekt zu http://visual.sourceforge.net/new/index.php) aber beim Kunden war nur gefragt um ein einziges digitales Eingangsmodul pro Controller lesen zu können. Ich hatte dann auch nur das zum Testen, also keine zwei Module, um etwas besser das Mapping in die Registermap untersuchen zu können und auch keine Ausgangsmodule um das Schreiben nach dem Beckhoff Controller testen zu können. Als solche ist die Library zwar grundsätzlich vorhanden und funktioniert auch zum Lesen von Modulen (die Frage ob es jetzt 8 oder 16 Bit sind und ob die Module packed also ohne Lücke oder aber immer gerundet auf eine bestimmte Addresse in der Registermap liegen lässt sich im Bedarfsfall sehr schnell mit ein paar Tests herausfinden). Ob das Schreiben funktioniert kann ich leider nicht garantieren da ich das nie testen konnte. Und im Moment habe ich auch gar keine Beckhoff Module zur Verfügung um weitere Tests durchführen zu können.
Natürlich wäre es grossartig wenn Du eventuelle Resultate Deiner eigenen Untersuchungen hier gegebenfalls zum Vorteil aller anhängen könntest.
Also ich habe an
Position 1: KL2134
Position 2: KL2134
Position 3: KL1418
Das Example von dir hat bereits unmodifiziert funkioniert für die Digital-Inputs.
Dh beim Vi "TCP read bytes" hab ich als Parameter
Index group: xF020
index offset: 0
length: 0
Dh obwohl das 1418 an Position 3 ist hat es indexoffset = 0. Wenn ich indexoffset verändere (1 oder 2), dann funktioniert das Einlesen nicht mehr.
Oder beginnt die Nummerierung von hinten aus, also von rechts? Dann würde es ja wieder passen.
Ich habe jetzt mal versucht einfach in das Example das "TCP Write bytes" mit reinzuhängen, aber jetzt frage ich mich wie du auf den Wert von indexgroup gekommen bist? Der ist F020 beim readbytes.vi.
Ich hab bisher nur gefunden, dass in der Twincat-Demoversion auch eine ADS-Info ist für die einzelnen Module.
Dort steht zb für Kanal 1: Port: 300, IGrp: 0x13001, IOffs: 0x0, Len: 1
Dort steht zb für Kanal 2: Port: 300, IGrp: 0x13001, IOffs: 0x1, Len: 1
Dort steht zb für Kanal 3: Port: 300, IGrp: 0x13001, IOffs: 0x2, Len: 1
Dort steht zb für Kanal 4: Port: 300, IGrp: 0x13001, IOffs: 0x3, Len: 1
Aber wie kann ich jetzt diese Info weiterverwenden?
Anzeige
01.08.2008, 11:36 (Dieser Beitrag wurde zuletzt bearbeitet: 01.08.2008 11:42 von rolfk.)
' schrieb:Also ich habe an
Position 1: KL2134
Position 2: KL2134
Position 3: KL1418
Das Example von dir hat bereits unmodifiziert funkioniert für die Digital-Inputs.
Dh beim Vi "TCP read bytes" hab ich als Parameter
Index group: xF020
index offset: 0
length: 0
Dh obwohl das 1418 an Position 3 ist hat es indexoffset = 0. Wenn ich indexoffset verändere (1 oder 2), dann funktioniert das Einlesen nicht mehr.
Oder beginnt die Nummerierung von hinten aus, also von rechts? Dann würde es ja wieder passen.
Ich habe jetzt mal versucht einfach in das Example das "TCP Write bytes" mit reinzuhängen, aber jetzt frage ich mich wie du auf den Wert von indexgroup gekommen bist? Der ist F020 beim readbytes.vi.
Ich hab bisher nur gefunden, dass in der Twincat-Demoversion auch eine ADS-Info ist für die einzelnen Module.
Dort steht zb für Kanal 1: Port: 300, IGrp: 0x13001, IOffs: 0x0, Len: 1
Dort steht zb für Kanal 2: Port: 300, IGrp: 0x13001, IOffs: 0x1, Len: 1
Dort steht zb für Kanal 3: Port: 300, IGrp: 0x13001, IOffs: 0x2, Len: 1
Dort steht zb für Kanal 4: Port: 300, IGrp: 0x13001, IOffs: 0x3, Len: 1
Aber wie kann ich jetzt diese Info weiterverwenden?
Also den F020 habe ich irgendwo tief in der Beckhoff Dokumentation zum ADS Protokol gefunden. Ist zwar nicht wirklich eine Protokoldokumentation aber gewisse Informationen darin sind durchaus hilfreich.
Scheint ja dass Input und Output in zwei unterschiedliche Indexgruppen gemappt werden. Deshalb wohl auch der Offset von 0 da alle Inputmodule hintereinancer gemappt werden und alle Outputmodule ebenfalls aber in eine andere Indexgruppe.
In Deinem Fall denke ich mal dass die Twincat Info schon mal sehr hilfreich sein könnte. Der Port ist deutlich da; 300 ist hier für alle IOs und auch die meisten anderen Informationen. Der wird ja intern in den VIs default gebraucht. Gewisse Konfigurationsparameter sind dagegen soviel ich mich erinnern kann unter Port 100 erreichbar. Aber auf automatische Konfiguration und dergleichen habe ich bewusst verzichtet da das ohne ausführliche Dokumentation des Protokolls praktisch nicht zu tun ist und es ist ja nicht die Idee um ein komplettes Twincat in LabVIEW bauen zu können sondern eben nur die IO Daten lesen und schrieben zu können.
IGrp klingt verdammt verdächtig nach einer Abkürzung für Index Group
Also würde ich das mal versuchen. Kannst ja zur Verifikation mal schauen was IGrp für das KL1418 in Twincat ist. So irgendwas wie 0xF020 schiene mir hier logisch. ^_^ IOffset ist deutlich der index offset. Wie sich das jetzt verhält respektive zu Bits/Bytes oder gar Words kann ich hier mal schwierig sagen.
Meine ADS VIs funktionieren grundsätzlich im Byte Modus. Darum herum müsste man gegebenenfalls noch VIs schreiben um spezifische logische Bits oder eventuel 16 Bit analoge Werte anzusprechen.
Hallo Ralf,
Ich habe inzwischen auf der Beckhof-Homepage die Doku gefunden zum ADS (siehe zip-file).
Darin finde ich auch die F020 (SPS-Prozessabbild der physikalischen Eingänge) die du verwendet hast.
Ebenso gibt es den Wert F030 (SPS-Prozessabbild der physikalischen Ausgänge).
Wenn ich den aber im Vi benutze dann kommt ne Fehlermeldung (siehe Screenshot).
Für den funktionierenden DigInput KL1418 steht im Twincat:
Kanal1: Port: 300, IGrp: 0x14001, IOffs: 0x0, Len: 1
..
Kanal8: Port: 300, IGrp: 0x14001, IOffs: 0x7, Len: 1
Der Wert x14001 entspricht also wohl irgendwie dem xF020
Wenn es klappen würde Bytes zu schreiben wär das Top. Das ganze in Bit umzubauen ist dann nicht mehr das Problem.
Aber derzeit bekomme ich leider noch den Fehler :-(
Eigentlich sollte es funktionieren oder?
Gruß
O.
01.08.2008, 21:02 (Dieser Beitrag wurde zuletzt bearbeitet: 01.08.2008 21:27 von rolfk.)
' schrieb:Hallo Ralf,
Ich habe inzwischen auf der Beckhof-Homepage die Doku gefunden zum ADS (siehe zip-file).
Darin finde ich auch die F020 (SPS-Prozessabbild der physikalischen Eingänge) die du verwendet hast.
Ebenso gibt es den Wert F030 (SPS-Prozessabbild der physikalischen Ausgänge).
Wenn ich den aber im Vi benutze dann kommt ne Fehlermeldung (siehe Screenshot).
Für den funktionierenden DigInput KL1418 steht im Twincat:
Kanal1: Port: 300, IGrp: 0x14001, IOffs: 0x0, Len: 1
..
Kanal8: Port: 300, IGrp: 0x14001, IOffs: 0x7, Len: 1
Der Wert x14001 entspricht also wohl irgendwie dem xF020
Wenn es klappen würde Bytes zu schreiben wär das Top. Das ganze in Bit umzubauen ist dann nicht mehr das Problem.
Aber derzeit bekomme ich leider noch den Fehler :-(
Eigentlich sollte es funktionieren oder?
Gruß
O.
Hmm, also ich denke mal dass 0x14001 eigentlich 0xF021 entspricht. Das ist der physikalische Eingangsbereich dann aber in Bitnotation, anders als 0xF020 das derselbe Bereich in Byteoperation ist. Der Unterschied scheint dann vor allem in der Offsetberechnung zu sein die dann nicht mehr in Bytes funktioniert sondern in Bits als im Prinzip 8 mal grösser wird.
Könnte es sein dass dann 13001 eigentlich 0xF031 entspricht und ebenfalls in Bitnotation? Auch zu Berücksichtigen ist dass das von Dir gefundenen Dokument die ADS Schnittstelle von TwinCat selber als virtuelle SPS dokumentiert. Die Busklemmen brauchen da natürlich nicht zwangsmässig die selben indexgruppen zu verwenden auch wenn die Übereinstimmung zumindest für die Eingänge natürlich doch als ein Indiz gesehen werden kann dass dem im Grossen und Ganzen eben schon so ist.
Edit: ADS Error 1799 bedeutet ungefähr "device is not in a ready state", was immer das hier bedeuten könnte.
Was ich beim Debuggen des ADS Read getan habe war mittels Wireshark schauen was durch Twincat über den Bus geschickt wird und dann analysieren und dasselbe in LabVIEW tun. Da das Grundgerüst von ADS ja schon fertig vorhanden ist sollten die nötigen Anpassungen die auf diese Weise eventuel noch zutage treten absolut minimal sein.
' schrieb:Was ich beim Debuggen des ADS Read getan habe war mittels Wireshark schauen was durch Twincat über den Bus geschickt wird und dann analysieren und dasselbe in LabVIEW tun. Da das Grundgerüst von ADS ja schon fertig vorhanden ist sollten die nötigen Anpassungen die auf diese Weise eventuel noch zutage treten absolut minimal sein.
Rolf Kalbermatter
Hallo Ralf
Ich habe mal mit Wireshark den Datenverkehr von Twincat mit geschnitten. Aber leider benutzt Twincat ein RawIO Format, das mit dem ADS von Beckhoff nichts gemeinsam hat. Wie hast du damals den Datenverkehr von Twincat mitgeschitten?
Mittlerweile kommt kein Fehler mehr beim Schreiben von Daten. Nur schreibt er leider nicht ins Register mit dem Index 0. Aber genau dort liegen die zwei Output Module. Wie du siehst ist Index auf 0. Er schreibt auch alles richtig in die Register. Nur leider nicht in Index 0.
