Guten Tag zusammen Hat von euch schon jemand mal versucht, mit einem Mikrocontroller, Busklemmen z.B. eine Beckhoff KL1002, anzusteuern? Oder hat jemand dazu Infos über das HW Interface und Protokolle ? Danke und Grüsse Josch
>Oder hat jemand dazu Infos über das HW Interface und Protokolle ?
Ja. Hans Beckhoff hat die.
Und die Spezifikation de K-Bus werden die sicher nicht herausrücken.
Dann könnte ja jeder seine eigenen Klemmen bauen...
Mit dem K-Bus habe ich beruflich zu tun. Alles unter NDA...
>Mit dem K-Bus habe ich beruflich zu tun. Alles unter NDA...
Ich eher nicht. Wir nehmen E-Bus.
Was ist NDA ?
@Haha Was heisst beruflich? Setzt du Steuerungen von Beckhoff mit dem K-Bus ein oder weisst du genauer wie er funktoniert ? Bez. NDA : funktionieren nicht auch die WAGO Klemmen mit diesem Bus ?
>Was heisst beruflich? Setzt du Steuerungen von Beckhoff mit dem >K-Bus ein Ja. K-Bus nicht mehr. WIr nehmen E-Bus. >oder weisst du genauer wie er funktoniert ? Nein. >funktionieren nicht auch die WAGO Klemmen mit diesem Bus ? Das Design ist dasselbe. Es gibt wohl Wago-Klemmen mit EtherCat. Aber die kenne ich nicht.
Würde mich auch interessieren... Man müsste halt mal so ein Modul haben und reinschauen. Müsste ja bestimmt irgendein Bussystem drin sein (485, SPI, I2C,..). Kann man sagen wieviele Pins da so zur verbindung genutzt werden?
Die "einfachen" Klemmen funktionieren im jeweils anderen System, was wohl daher rührt, dass eine gemeinsame Entwicklung/Kooperation vorlag ;-) Im Verhältnis der Preise Busklemme <-> Koppler rentiert sich die Entwicklung einer eigenen Schnittstelle für µC nicht wirklich, wenn man zusätzlich in Betracht zieht, dass zu den Systemen ganze Lösungsbibliotheken mitgeliefert werden. Wer übrigens berufliche Aspekte verfolgt sollte sich ohnehin mit Codesys beschäftigen.
@Jörg Ich schaue mal nach.... @L.G. Ja, für den professionellen Bereich ist eine solche Konstellation fraglich. Interessant finde ich einfach die Bauform und die Erweiterbarkeit. Ich habe bei meinen µC Projekt immer das selbe Problem.... die I/O's. Wenn man solche Produkte verwenden könnte, wären für mich als SW'ler viele HW-Probleme gelöst.
Das Protokoll der Kommunikation der EtherCat Klemmen ist ein öffentliches Protokoll. Gem. der verlinkten Beschreibung ist der Master eine reine Softwarelösung welche "nur" eine Ethernet Schnittstelle braucht. http://www.ethercat.org/pdf/german/EtherCAT_Implementierung.pdf http://www.ethercat.org/en/technology.html#3.1
Hallo zusammen! Wenn ich das hier so lese stellt sich mir die Fragen warum eigentlich direkt auf den K- bzw. E-Bus gehen. Warum nicht einfach einen Buskoppler für den K-Bus mit RS232/485 oder CanOpen Schnittstelle zwischen schalten? Wenn ich richtig gesehen hab ist der Koppler für RS485/232 nur von Beckhoff erhältlich. Den Koppler für CanOpen bieten beide Firmen an. Grüße Marco
Die günstigste Variante eines solchen Kopplers kostet ca 100€. Bei der EtherCat Variante kostet ein Koppler, der eingentlich "nur" das Ethernet mit den Klemmen verbindet, ebenfalls ca 100€. Der µC kann aber so noch immer nicht mit den Klemmen kommunizieren.Was fehlt, ist eine schlanke Implementiereung es EtherCat Protokolls für einen µC, am liebsten für einen AVR ;-) Bei SourceForge gibts eine EtherCat Master implementierung, aber für Windows. Und ob die tut, muss man testen. http://egato.sourceforge.net/
EtherCat ist aber nicht so gängig, oder? Mir geht es da hauptsächlich um Gebrauchtware bei ebay. Wobei da in den letzten Tage schon 2 Profibus Koppler für ~35€ versteigert worden sind. Da wird's mit der Eigenentwicklung preislich schon etwas uninteressant...
EtherCat und Profibus sind nicht vergleichbar.. Beitrag "Grundlagenfrage: I/O's im Ethernet verfügbar machen"
>EtherCat und Profibus sind nicht vergleichbar..
Na ja, was heisst vergleichbar... sind halt beides Feldbusse :)
Für mich würde als Hauptverbindung eh nur Profibus in Frage kommen da
selbst- entwickelte Profibus Geräte schon existieren.
Die Frage wäre nur ob es sich lohnt den K-Bus zu untersuchen. Wenn die
E-Bus Klemmen vom Preis, Verfügbarkeit und Interface komplexität gleich
wären (was ich eher bezweifle?) würde sich der Aufwand für den K-Bus
wohl nicht lohnen. Ich vermute aber mal das der K-Bus gängiger und das
Interface wohl auch einfacher ist.
E-Bus ist EtherCat. Das Telegramm geht durch jede Klemme durch. Ohne den ASIC dazu von Beckhoff wirst du dort keine Chance haben. K-Bus weiß ich nicht wie das geht.
@Jörg S. Ich nehme an du meinst mit E-Bus den EtherCat und nicht diesen hier : http://www2.ebus.de/ ja, die Komponenten sind halt bei ebay usw. nicht so sehr verbreitet, aber die Kosten bei den Herstellern auch nicht alle Welt und es sind einzelne ASIC für eigene Slaves erhältlich. Wie der von Matthias Lipinsky verlinkte Beitrag es zeigt. Unter http://www.etherlab.de/ gibts eine EtherCat OpenSource Masterimplementation für den Linux Kernel 2.6 zum downloaden.
>Ohne den ASIC dazu von Beckhoff wirst du dort keine Chance haben.
Hab ich beim Thema Profibus auch schon mal gehört :)
Das Grundlegende Protokoll von EtherCat scheint ja offen zu sein (Siehe
Links von Joschua). Physical Layer wäre noch eine Frage...
Es gibt doch ein paar Open Source Implementierungen von EtherCat. Als Betriebssystem ist meisst die Rede von Linux. Hier noch eine weitere Implementierung: https://developer.berlios.de/projects/soem/ das letzte Release ist vom 18.1.09. Da ist wohl eine einfache Portierung auf einen AVR nicht gerade so simple.....
Eine weitere Option wäre der Einsatz von FreeRTOS. Hiermit wäre eine Portierung von z.B. SOEM ev. einfacher zu gestalten. Da aber ein AVR zu wenig Resourcen bietet, wäre wohl der Einsatz eines AVR32 oder Cortex-M3 angebrachter. Lieder kenne ich mich damit nicht so gut aus und habe auch keine einfachen Boards gefunden, welche mit einer Ethernet Schnittstelle, USB, und ein paar I/O's für Tasten oder Display ausgerüstet ist. Die Boards die ich gefunde habe, haben sind sehr gut ausgerüstet, haben aber so ihren Preis > 100€. Wenn jemand mit solchen Boards Erfahrung hat, wäre ich um jeden "Input" froh.
Hallo, von Wago gibt es auf jeden Fall Buskoppler mit RS232, die dann Modbus machen. Z.B. der 750-316/314. Einfacher geht es wohl kaum. Sicherlich von der Geschwindigkeit her nicht mit direkten GPIOs am Prozessor zu vergleichen, aber eben robuster Industriestandard. Das Protokoll von Modbus ist in den Anleitungen der Buskoppler von Wago ganz klar und einfach beschrieben. Das sollte keine Hürde darstellen. Alternativ gibts natürlich auch noch die Canbus-Koppler. Viele Grüße Benny
Kurze Frage: Es soll eine Busklemme über ein selbstentwickeltes Protokoll mittels Mikrokontroller angesteuert werden. Wozu? Das geht doch, berücksichtigt man den Soft- und Hardwareaufwand - von den Responsezeiten ganz zu schweigen - ohne Klemme min. doppelt so gut und halb so teuer.
@Bogumil: ...und nicht einmal annährend halb so flexibel! Bei Wago bspw. können bis zu 64 Klemmen angeschlossen werden, nimm bloss mal allein eine Klemme mit 8 digitalen Eingängen. Macht bei 64 Stück also 512 digitale I/Os. Und allein die Vielfalt der Klemmen http://www.wago.com/cps/rde/xchg/wago/style.xsl/deu-12537.htm ist verführerisch ;-)
@Benny: mit Ethernet wäre aber eine sternförmige Verkabelung möglich. Wie das bei CAN aussieht, weiss ich nicht. @Bogumil : Wie bereits gesagt, es gibt Klemmen, z.B. für 230V. Die sind geprüft und zugelassen. Bei selbergebaute Ansteuerungen an 230V ist eine Prüfung wohl eher mit einem grossen Aufwand zu machen.
Ich stehe gerade vor der selben Thematik (753 430, 753 530 Module). Bist du in deinem Projekt diesbezüglich weitergekommen?
Theroretisch kann man bei Beckhoff kostenlos Mitglied im Ethercat Club werden und hat dann Support - habe ich auch mal gedacht. Man kriegt aber schneller eine Absage als man gucken kann. Alles geklüngel. An deiner Stelle würde ich CanOpen nehmen. Hat den Vorteil dass es im Gegensatz zu Ethercat und Profibus (oder Profinet) schon jede Menge uC mit CAN gibt. Den Stack dazu kann man selbst schreiben. Die Doku dazu wird zwar von Open auch verkauft aber vielleicht verraten auch die Hersteller wie das Modul angesteuert wird. Man muss einfach mal PDO und SDO verstehen und man kann auf CAN gut mithören und gucken was andere so machen. Wenn nix gekauft oder kompatibel sein muss, geht CAN auch ohne Open mit irgendwelchen PDOs. Die haben die Sicherungsschicht schon per HW drin so daß die SW auf dem uC fast so einfach wie seriell ist.
:
Bearbeitet durch User
So richtig kompliziert scheint der Bus nicht zu sein. Die Pins, bei Draufsicht auf die Front des Moduls, von oben nach unten: 1 +5V 2 GND 3 MOSI 4 MISO 5 COMMAND/DATA H = CMD, L = DATA 6 CLK (1.778Mhz mit einem 750-652) Pin 1-3,5,6 sind in jedem Modul durchverbunden, Pin 4 ist unterbrochen (da ist vermutlich die Logic im Modul dazwischen, als Schieberegister. Ich habe jetzt mal SPI Signalbezeichnungen genommen, ob das richtig ist, keine Ahnung) Die Commandbytes scheinen in den meisten Faellen 4 Bit zu sein, + 4 bit invertiert. Also zum Beispiel erstes Byte F0, zweites Byte 5A. Die Ausgaenge scheinen mit einem Datenzyklus geschrieben zu werden, wobei es da 7B und B5 gibt, sowie 84 und noch einen anderes Wert (habe ich mir nicht notiert) als erste zwei Bytes. Die Bytes danach scheinen die Ausgangsdaten zu sein, die 0x55 auf dem Screenshot habe ich per Modbus geschrieben.
In einem 750-653 RS485 ist als einziges aktives Bauteil ein PIC16F73-I + 93C46 drin. Spezialhardware braucht man also nicht.
Stimmt nicht, man sollte auch auf die Rueckseite der Platine schauen... ;-)
Hier ein Bild der Beschaltung einer 753-430 (8x24V input). Ich hatte diese Klemme vor zwei Monaten geöffnet um die Schutzbeschaltung vor den Optokopplern zu sehen.
Hallo, vielen Dank fuer das Foto! Ist also ein ASIC drin - ich hatte mal noch eine Beckhoff KL2408 aufgemacht, dort war ein 'Beckhoff BK100' drin wenn ich mich recht entsinne, ich habe dort aber nicht auf die Rueckseite der Platine geschaut. Ich habe mir mit einen CPLD mal einen Serial->Parallel Konverter gebaut, um die Daten parallel aufzuzeichnen, da ich da deutlich laenger mitschneiden kann. Als Befehle vermute Ich: F1: Reset? Wird ohne Klemme immer wiederholt F0 E1: Gibt eine Ladung Byte zurueck, fuer jede Klemme eins. Klemmentyp? Netzeinspeisung = 5?, I/O = 4? D2: Gibt eine Ladung Byte zurueck, fuer jede Klemme eins. Klemmentyp2?: 5 = Netzklemme, 4 = Input, 8 = Output, 1c = analog i/o - Koennte auch Bitmap der moeglichen Funktionen sein. Es gibt noch einen Typ '2', bei dem bin ich mir noch nicht sicher was das ist. C3: Unbekannt, scheint nach fast jeden Befehl zu kommen Ausgangsdaten schreiben: Siehe Screenshot oben Eingangsdaten lesen funktioniert vermutlich aehnlich. Reverse Engineering macht Spass, ansonsten macht das vermutlich wenig sinn, so billig wie man Modbus Koppler bekommt... Ich habe mir jetzt mal ein paar Einspeiseklemmen bestellt, an die ich ein paar Draehte loeten kann. Damit werde ich mal ein paar Sequenzen schicken und schauen was passiert. Interessant waere noch, was die einzelnen CLK Impulse die in dem Screenshot sichtbar sind bedeuten.
Ich habe die Wago Klemmen an einen Arduino Mega2560 angeschlossen. Die Datenleitungen haengen an SPI, Pin 53 ist das CMD Pin. Als Klemmen habe ich von links nach rechts: 2xKL2408, 1xKL1408, 1x750-653. Das gibt auf dem Arduino den folgenden Output: 11:14:57.700 -> Klemme 0: vorhanden 11:14:58.628 -> Klemme 1: vorhanden 11:14:58.628 -> Klemme 2: vorhanden 11:14:58.628 -> Klemme 3: vorhanden 11:14:58.628 -> Klemme 0: Typ 2 11:14:58.628 -> Klemme 1: Typ 2 11:14:58.628 -> Klemme 2: Typ 1 11:14:58.628 -> Klemme 3: Typ 87 Der C Code zaehlt auf der zweiten KL2408 hoch:
1 | #include<SPI.h> |
2 | |
3 | #define CMD 53
|
4 | |
5 | static void single_clock_pulse() |
6 | {
|
7 | // WAGO seems to use a single clock pulse
|
8 | // after the CMD bytes as either an acknowledge or delay
|
9 | // As a quick hack, disable SPI and generate a single clock.
|
10 | // Note that the modules seem to drive the MOSI line after
|
11 | // the rising edge until the next clock transition.
|
12 | |
13 | SPI.end(); |
14 | digitalWrite(SCK, 0); |
15 | digitalWrite(MOSI, 1); |
16 | pinMode(MOSI, INPUT); |
17 | digitalWrite(SCK, 1); |
18 | pinMode(MOSI, OUTPUT); |
19 | SPI.beginTransaction (SPISettings (1778000, LSBFIRST, SPI_MODE3)); |
20 | }
|
21 | |
22 | static void cmd1(uint8_t cmd) |
23 | {
|
24 | digitalWrite(CMD, 1); |
25 | SPI.transfer(cmd); |
26 | digitalWrite(CMD, 0); |
27 | }
|
28 | |
29 | static void cmd1_with_pulse(uint8_t cmd) |
30 | {
|
31 | digitalWrite(CMD, 1); |
32 | SPI.transfer(cmd); |
33 | digitalWrite(CMD, 0); |
34 | single_clock_pulse(); |
35 | }
|
36 | |
37 | static void cmd2_with_pulse(uint16_t cmd) |
38 | {
|
39 | digitalWrite(CMD, 1); |
40 | SPI.transfer(cmd >> 8); |
41 | SPI.transfer(cmd & 0xff); |
42 | digitalWrite(CMD, 0); |
43 | single_clock_pulse(); |
44 | }
|
45 | |
46 | static void identify() |
47 | {
|
48 | cmd1_with_pulse(0xe1); |
49 | cmd1(0xc3); |
50 | for(int i = 0; i < 64; i++) { |
51 | uint8_t c = SPI.transfer(0x00); |
52 | if (c) |
53 | printf("Klemme %d: vorhanden\n", i, c); |
54 | }
|
55 | |
56 | cmd1_with_pulse(0xd2); |
57 | cmd1(0xc3); |
58 | for(int i = 0; i < 64; i++) { |
59 | uint8_t c = SPI.transfer(0x00); |
60 | if (c) |
61 | printf("Klemme %d: Typ %x\n", i, c); |
62 | }
|
63 | }
|
64 | |
65 | static void write_process(void) |
66 | {
|
67 | static uint8_t data; |
68 | cmd2_with_pulse(0x0fa5); |
69 | cmd1_with_pulse(0x87); |
70 | cmd1(0xc3); |
71 | SPI.transfer(0x7b); |
72 | SPI.transfer(0xb5); |
73 | SPI.transfer(0x00); |
74 | SPI.transfer(0x00); |
75 | SPI.transfer(data ^ 0xff); |
76 | SPI.transfer(0x00); |
77 | SPI.transfer(0x00); |
78 | SPI.transfer(0x00); |
79 | SPI.transfer(0x00); |
80 | SPI.transfer(0x00); |
81 | SPI.transfer(0x00); |
82 | SPI.transfer(0x00); |
83 | cmd1_with_pulse(0x96); |
84 | cmd1(0xc3); |
85 | SPI.transfer(0x84); |
86 | SPI.transfer(0x4a); |
87 | SPI.transfer(0xff); |
88 | SPI.transfer(0xff); |
89 | SPI.transfer(data); |
90 | SPI.transfer(0xff); |
91 | SPI.transfer(0xff); |
92 | SPI.transfer(0xff); |
93 | SPI.transfer(0xff); |
94 | SPI.transfer(0xff); |
95 | SPI.transfer(0xff); |
96 | SPI.transfer(0xff); |
97 | |
98 | cmd1_with_pulse(0x87); |
99 | cmd2_with_pulse(0x0fb4); |
100 | delay(100); |
101 | data++; |
102 | }
|
103 | |
104 | void loop() |
105 | {
|
106 | write_process(); |
107 | }
|
108 | |
109 | int serial_putchar(char c, FILE* f) |
110 | {
|
111 | if (c == '\n') |
112 | serial_putchar('\r', f); |
113 | return Serial.write(c) == 1? 0 : 1; |
114 | }
|
115 | |
116 | void setup() { |
117 | static FILE serial_stdout; |
118 | Serial.begin(57600); |
119 | fdev_setup_stream(&serial_stdout, serial_putchar, NULL, FDEV_SETUP_WRITE); |
120 | stdout = &serial_stdout; |
121 | |
122 | SPI.begin(); |
123 | SPI.beginTransaction (SPISettings (1778000, LSBFIRST, SPI_MODE3)); |
124 | pinMode(CMD, OUTPUT); |
125 | pinMode(MISO, OUTPUT); |
126 | digitalWrite(CMD, 0); |
127 | identify(); |
128 | }
|
Nachdem I/O jetzt funktioniert, interessiert mich noch, wie Wago eigentlich rausbekommt, welche Klemme wieviel I/Os hat. Das scheint ueber die e1 und d2 Kommandos kodiert zu sein. Mit dem folgendem Klemmensetup von links nach rechts: KL2408, 750-610, 750-653,KL2408,KL2408 bekomme ich folgende Datenhaufen auf die e1/d2 Kommandos zurueck: e1: 01 05 00 00 04 04 d2: 02 9d 02 00 08 08 Wenn man das binaer anzeigt und die Bitreihenfolge umdreht, sieht man: Antwort auf e1: 10000000 10100000 00000000 00000000 00100000 00100000 Antwort auf d2: 01000000 10111001 01000000 00000000 00010000 00010000 e1 scheint die Laenge des Prozessabbildes per Klemme festzulegen, jede 1 ist eine neue Klemme. d2 scheint den Typ festzulegen. e1: 10000000 10 100000 00000000 00000000 00 100000 00100000 (8 bit) (2 bit) (24 bit) (8 bit) (8 bit) KL2408 750-610 750-653 KL2408 KL2408 d2: 01000000 10 111001 01000000 00000000 00 01000000 01000000 (Output) (Input) (Unbekannt) (Output) (Output) Fuer die Multibyte Klemmen wie die 653 (RS485) habe ich noch keine Idee wie die Identifizierung funktioniert, aber fue normale I/O Klemmen scheint das recht einfach kodiert zu sein.
Hallo, vielen Dank für die Infos und die Arbeit. Ich denke dass die 2bit bei der Interpretation nicht richtig sind. Die Potentialeinspeiseklemme belegt doch gar keine Bits im Prozessabbild. Die ist doch dumm? VG
Entschuldigung - wer lesen kann - es sind tatsächlich 2bit reserviert für Spannung und Sicherung. VG
Wow Ich bin begeistert. Wenn du jetzt noch die Busverlängerung. 750-628 als Interface benutzen kannst, ist das ne saubere Sache.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.