Hallo, ich bestitze eine Digitale Lötstation von der Firma JBC die ich mir vor kurzem gekauft habe. Jetzt möchte ich sie mit meiner Absaugung verknüpfen bzw soll die Absaugung durch die Lötsation geregelt werden. Ziel soll es sein dass die Absaugung aus geht wenn der Lötkolben in die Halterung gesteckt wurde, was die Lötstation sowiso erkennt. An der Lötsation ist dazu auch ein Ausgang angebracht der für die jbc eigenen Absaugungen vorgesehen ist. Habe allerdings zu diesen Ausgang keinerlei Informationen im Internet gefunden. Weis jemand bescheid über das Pinout dieses Steckers bzw wie man das Problem anderweitig lösen kann?
Meinst du nicht, dass es hilfreich wäre, den genauen Typ deiner JBC Station zu erwähnen?
Stefan schrieb: > Ziel soll es sein dass die Absaugung aus geht wenn der > Lötkolben in die Halterung gesteckt wurde, was die > Lötstation sowiso erkennt. Man kann sich auch einen Knopf an die Backe nähen. Ein halbwegs ruhiger Lüfter stört so wenig, dass man ihn ohne solchen Hokuspokus laufen lassen kann.
Das ist mal wieder ein typischer Facepalm Thread. Hat eine JBC Lötstation aber anscheinend kein DVM um den Port auszumessen. DE geht wirklich den Bach runter...
Ist halt Freitag...da kommen solche Threads häufiger...
W.P. K. schrieb: > Meinst du nicht, dass es hilfreich wäre, den genauen Typ deiner JBC > Station zu erwähnen? Muss er nicht, ist bei allen JBC-Stationen der gleiche RJ-12-Stecker. Dafür existiert genau ein Typ Absaugung. Evtl wäre es interessant zu wissen, ob am Originalverbindungskabel wirklich alle Adern beschaltet sind.
Danke für deine Hilfreichen Beitrag aber auf die Idee bin ich auch schon gekommen. Ergebnis dabei war dass nur an einem Pin Spannung anliegt und dort war eine Art Rechteck Signal (höchstwarscheinlich ein Protokoll). Hab die Lötstation mal aufgeschraubt und an diesen Port war ein Chip verbaut der wohl für eine RS232 Schnittstelle gedach ist. Könnte aber auch sein dass dies eine JBC eigene Schnittstelle ist was ich nicht weis und deswegen auch diesen Post erstellt habe.
Stefan schrieb: > aber auf die Idee bin ich auch schon gekommen. Und warum erzählst du das erst jetzt?
Hallo, welche Station ist es denn jetzt? Es gibt doch auch den Robot Port und einige Dokumentation dazu auf der webpage. Dort wird ein serielles Protokoll beschrieben mit Stx data etx crc. Auf die schnelle habe ich noch 19200 baud gesehen. Vielleicht damit mal anfangen ? Gruß Sven
Kann man da nicht einfach die Abschaltung, wenn der Kolben in den Halter gesteckt wird, dazu missbrauchen? Da liegt wohl irgend ne Kleinspannung an, die wenn der Kolben in der Ablage ist, kurzgeschlossen wird.
Schau mal, Disclaimer, ich habe wenig bis null Ahnung. Ich würde aber auf das Protokoll scheißen und einfach mal die Flanken alle mitschneiden, mehrmals. Irgendein Rohmuster ergibt sich dann. Das einfach dann erkennen. Entgegen der anderen finde ich deine Frage legitim, hätte ja sein können, dass das Protokoll dokumentiert ist, und du es nicht einfach findest. Ein Teilen des Gerätenames, ebenso des ICs, hätte für dich keine Nachteile gehabt. Ulis und Svens Antworten finde ich auch gut.
Um diesen typischen uC.net-Thread mal aufzuwerten: schaue dir mal https://www.jbctools.com/pdf/communication-protocol-stations-0024318_ID-193610.pdf an.
Max G. schrieb: > Um diesen typischen uC.net-Thread mal aufzuwerten: schaue dir mal > https://www.jbctools.com/pdf/communication-protocol-stations-0024318_ID-193610.pdf > an. Der Thread ist zwar schon älter, aber gebau so eine Antwort hatte ich erhofft danke👍
Beitrag #7594091 wurde von einem Moderator gelöscht.
Beitrag #7594126 wurde von einem Moderator gelöscht.
Oder anstatt dem Protokoll eine Master-Slave Schaltung mit der gesamten Lötstation machen https://www.pollin.at/p/kemo-master-slave-schalter-m103n-230-v-ac-400-v-ac-811628
Michael schrieb: > Oder anstatt dem Protokoll eine Master-Slave Schaltung mit der gesamten > Lötstation machen > https://www.pollin.at/p/kemo-master-slave-schalter-m103n-230-v-ac-400-v-ac-811628 Ohne Ausschaltverzögerung bei getakteten Geräten nicht brauchbar.
Die JBC taktet nicht sondern läuft mit PWM. Das Modul hat intern einen kleinen Filter, da es funktionsbedingt mindestens über eine Periode messen muss.
Wie wärs, wenn man da ein kleines z.B. 5V NT parallel zur Kolbenregelung anschliessen würde, oder auch nur ne Batterie, die sobald der Kontakt unterbrochen wird über ein Relais, Fet oder was einem sonst noch einfällt, die Absaugung einschaltet. Es gibt ja Kolben mit Absaugung, da ist dann oberhalb der Spitze ein Rohr ähnlich dem von nem Saugstauber.
Ich habs jetzt mal nachgemessen, am Halter liegen knapp 5V (4,73 gemessen) an. Damit könnte man nen 2803 Schalter, nen Schmittrigger oder ähnliches betätigen, der wiederum den Absauglüfter schaltet.
Angehängte Dateien:
-
SDS00001.png
15 KB -
SDS00002.png
16 KB
Thread ist zwar schon älter, aber wie ist denn die Geschichte ausgegangen? Das mit der RS232-Schnittstelle, die vermutlich mit 19200Baud laufen soll, scheint zumindest bei meiner Station so nicht zu sein. Da sieht es eher nach 230400 (Standard) aus, wobei ich 250000 gemessen habe - was schon irrwitzig flott wäre. Bildchen anbei (TX gelb, RX grün), gemessen an einer CD-2BQF. Der Decoder meines Oszis (Siglent SDS1104X-E) lässt als maximale Baudrate aus den voreingestellten Werten nur die Eingabe von 115200Baud zu - was möglicherweise die angezeigten Fehler erklärt. Theoretisch könnte(!) ich auch die manuell 230400 einstellen, allerdings ist das Oszi da nicht sooooo komfortabel. Es kann nur von in 1er-Schritten von irgendwas 1000 an einem Poti hochgekurbelt werden :-( Soweit ich zudem sehen konnte, verändern sich die Nachrichten (-Muster) nicht, wenn der Lötkolben aus der Halterung genommen wird. Achso, das ganze, weil ich mit dem gleichen Gedanken spiele wie der TO.
Angehängte Dateien:
-
ScreenImg.png
70 KB -
ScreenImg.png
70 KB
Ich teile euch mal mit, was ich schon rausgefunden habe. Die Kommunikationparameter sind 250000baud 8E1 DDE: [DLE] [STX] [NUL] [CAN] [253] [NUL] [SOH] [CAN] [253] [DLE] [ETX] JTSE:[DLE] [STX] [NUL] [DC2] [253] [NUL] [SOH] [DC2] [253] [DLE] [ETX] Man sieht auf jeden Fall, dass die Absender Adresse was mit dem 4. Byte zu tun haben muss. Was ein bisschen komisch ist, das die Adresse zwei mal vorkommt. Wir brauchen Jemaden der eine Lötstion mit Fae hat, um das Protokoll zu entschlüsseln. Ansonsten gibt es noch das Projekt auf Github von Springuin. Er hat einen Arduino Sketch geschrieben für ein USB Host 2.0 Shield in Verbindung mit einem Arduino Uno. Damit soll es möglich sein, den Status der Lötstation über den USB Port an der Rückseite auszulesen.
:
Bearbeitet durch User
Uli S. schrieb: > Damit könnte man nen 2803 Schalter, nen Schmittrigger oder > ähnliches betätigen, der wiederum den Absauglüfter schaltet. Nach dem Ablegen des Lötkolbens wird der Lüfter noch ein bisschen nachlaufen sollen.
Angehängte Dateien:
-
SDS00005.png
14 KB
Tim schrieb: > Was ein bisschen komisch ist, das die Adresse zwei mal vorkommt Ich muss zugeben, dass ich noch nicht einmal die Adresse erkenne - welche soll das sein? Auch "übersetzt" mein Scope auch nur in hex, dezimal, ... aber nicht in sowas wie STX oder DC2. Wie auch immer, inzwischen herausbekommen, wie ich an meinem Scope per Konfig-Datei die Baudrate auf 250KBaud verändern kann, und dann mir die Nachricht angeschaut. Zunächst kann ich die Einstellungen von Tim bestätigen, aber, leider, leider, die JBC-Lötstation sendet immer das gleiche. Also, mit/ohne Tool. Im Ständer oder draußen. Daher nur ein Oszi-Bild Max G. schrieb: > Um diesen typischen uC.net-Thread mal aufzuwerten: schaue dir mal > https://www.jbctools.com/pdf/communication-protocol-stations-0024318_ID-193610.pdf > an. Ich hatte Kontakt zum JBC-Support, weil ich mich über die 250kBaud gewundert hatte (soll das so, oder ist die Station defekt?). Antwort: soll so, und das Protokoll sei nicht das gleiche wie das der Control Units, sondern propritär und vor allem geheim. Es hat hier nicht zufällig jemanden, der einen Fume Extractor von JBC hat und das Protokoll mitschneiden kann?
Sebastian S. schrieb: > Auch "übersetzt" mein Scope auch nur in hex, > dezimal, ... aber nicht in sowas wie STX oder DC2. Das sind ASCII-Steuerzeichen. Hier gibts 'ne Tabelle: https://de.wikipedia.org/wiki/Steuerzeichen#C0-Steuerzeichen
Hey Sebastian, hast du ein Arduino Uno und ein Arduino Host Schield 2.0 zu hand? Bei mir dauert es noch bis es eintrifft. Ich möchte das Projekt von Springuin umsetzen: https://github.com/Springuin/jbc-fume-extraction-arduino . Damit kannst du über USB den jede JBC Station hat, den Status des Lötkolben auslesen und der Arduino steuert dir im Standart schon eine LED auf dem Microcontroller an. Ich denke nicht das JBC ihr Protokoll rausrücken wird, hatte letztes Jahr bei den auch schon angefragt und hab auch diese Antwort bekommen. Man wird sich auch nicht zum Protokoll schnüffeln eine FAE1 im Wert von 1699 Euro anschaffen. :D Wenn du mal in die Anleitung der FAE guckst, wirst du feststellen, dass die CDE Station mit einem USB zu Seriell Wandler an die FAE Angeschlossen wird. Entweder Stellt die CDE Station ihr USB protokoll um auf die FAE Kommunikation oder es ist das gleiche Protokoll was Springuin aus der JBC Connect.ddl extrahiert hat von der JBC Station Updater Windows Anwendung.
Harald K. schrieb: > Das sind ASCII-Steuerzeichen. Danke für die Info! Tim schrieb: > hast du ein Arduino Uno und ein Arduino Host Schield 2.0 > zu hand? Uno schon, einen USB Host Shield leider nicht. Tim schrieb: > Ich möchte das Projekt von Springuin umsetzen Das sieht in der Tat interessant aus. Auch wenn ich - zugegebenermaßen - bei einer (nicht so super intensiven) Durchsicht des Codes so manches nicht verstanden habe. Es sieht irgendwie so aus, als ob über den USB der in der Lötstation verbaute USB-to-Serial Converter direkt angesprochen wird. Hm ... Weiteres zu klärende Detail wäre, wer hier wen mit Strom versorgt. Der Text von Springuin lässt einen glauben, dass der USB-Anschluss der Lötstation eine externe Spannungsversorgung braucht (also dann über den Shield). Ich kenne mich damit nicht aus. Um USB habe ich, was dessen Verwendung in selbst geschriebenen Programmen angeht, bisher einen weiten Bogen gemacht. Andrerseits, ein Versuch ist es Wert. Ich besorge mir mal einen USB - Shield, aber das wird frühestens erst Ende September wieder was. Arbeit, verplante Wochenenden, und: Urlaub :-)
Eigenen Lötrauch absaugen mit dem JBC FAE Emulator Mahlzeit! Nach langem Reverse Engineering habe ich endlich das JBC FAE Protokoll verstanden und in Software umgesetzt. Mit meinem Projekt könnt ihr eure Lötstationen über den FAE-Port (maximal 2 JBC Stationen) mit einem ESP32 oder Arduino Mega verbinden und am Ausgang des Microcontrollers ein Relais ansteuern, das eure Absaugung ein- und ausschaltet. Zusätzlich zeigt der Emulator den Status jeder Station über 2 LEDs an (SK6812 GRBW). Ausschaltverzögerung einstellen Die Ausschaltverzögerung für den Lüfter kann direkt über die CLI konfiguriert werden: set tstop_work <Sekunden> save <Sekunden>: Zeit, wie lange der Lüfter nach dem Abschalten der Station noch läuft save: Speichert die Einstellung im EEPROM, damit sie bei Neustart erhalten bleibt Hinweis: Wenn ihr eine DDE-Station habt, könnt ihr die Nachlaufzeit des Relais auch direkt in der Station einstellen – dann wird der Lüfter automatisch nach der gewünschten Zeit abgeschaltet. Getestet Ich habe das Setup mit der DDE- und JTSE-Stationen getestet – es läuft einwandfrei. GitHub Alle Infos, Code und Anleitungen gibt es hier: https://github.com/IceCube20/JBC-FAE-Emulator Ich freue mich über euer Feedback – schreibt gerne, ob es bei euch reibungslos funktioniert. Viel Spaß mit dem Emulator!
Tim schrieb: > Mahlzeit! Nach langem Reverse Engineering habe ich endlich das JBC FAE > Protokoll verstanden und in Software umgesetzt. Mit meinem Projekt könnt > ihr eure Lötstationen über den FAE-Port (maximal 2 JBC Stationen) mit > einem ESP32 oder Arduino Mega verbinden und am Ausgang des > Microcontrollers ein Relais ansteuern, das eure Absaugung ein- und > ausschaltet. Interessant! Weißt Du zufällig welche Generationen von Basisstationen über dieses Protokoll ein FAE-System (oder eben Deinen Emulator) ansprechen können? Z.B. bei der DDE-Station gibt es verschiedene Generationen. Die haben alle Peripherie-Anschlüsse auf der Rückseite aber ich hab da nicht so den Überblick was es genau für die FAE braucht.
Moin Gerd, so weit ich das verstanden habe, geht das mit allen Stationen die einen FAE/Robot RJ12 Anschluss auf der Rückseite der Geräte haben. Wichtig, Aktuelle Firmware muss installiert sein. Gruß Tim
Tim schrieb: > Ich freue mich über euer Feedback – schreibt gerne, ob es bei euch > reibungslos funktioniert. Hi Tim, ich habe das auf dem ATMega implementiert, und leider funktioniert es wenig bis gar nicht. D.h. manchmal wird das Relais zwar geschaltet, aber meistens nicht. Kannst du hier antworten, mit welchem ESP32 unter den vielen verfügbaren (ich kenne mich da leider gar nicht aus) du es getestet hast? Dann würde ich es einmal damit probieren bzw. mir erst so ein Board mir bestellen. Danke und Gruß Sebastian P.S.: Wenn ich die UART-Signale mit dem Oszi dekodiere werden mir sowohl 12 als auch 13 Byte lange Nachrichten angezeigt. Soll das so sein? PPS: LEDs habe ich deaktiviert, der Relais-Ausgang reicht zum Testen. Aber auch, weil ich die noch nicht auf einer Platine habe.
Hallo Sebastian, Du kannst einen ganz normalen Esp32 benutzen bitte keinen Esp32 c6, s3 usw. Welche Lötstation benutzt du? In einem anderen Forum habe ich von einem gehört, das die JBC CD-2BQF wohl ein anderes Protokoll spricht und mit meinem Projekt nicht richtig funktioniert. Wenn du die gleiche hast, kannst du gerne mal bitte den DBG Mode über die CLI einschalten und mal das log hier postest. Dann können wir mal gucken wo das Problem sein könnte. Der andere berichtete auch, dass das Relais nicht zuverlässig angesteuert wird. Achso und bevor ich das vergesse, was steht bei dir an dem Port dran? Robot/FAE oder steht dort AUX drauf? Liebe Grüße Tim
Tim schrieb: > Hallo Sebastian, > > Du kannst einen ganz normalen Esp32 benutzen bitte keinen Esp32 c6, s3 > usw. > Welche Lötstation benutzt du? In einem anderen Forum habe ich von einem > gehört, das die JBC CD-2BQF wohl ein anderes Protokoll spricht und mit > meinem Projekt nicht richtig funktioniert. Wenn du die gleiche hast, > kannst du gerne mal bitte den DBG Mode über die CLI einschalten und mal > das log hier postest. Dann können wir mal gucken wo das Problem sein > könnte. Der andere berichtete auch, dass das Relais nicht zuverlässig > angesteuert wird. > Achso und bevor ich das vergesse, was steht bei dir an dem Port dran? > Robot/FAE oder steht dort AUX drauf? > Liebe Grüße Tim Um den Debugmode für RX und TX einzuschalten muss man bei DBG_SHOW_RX 0 und DBG_SHOW_TX 0 jeweils eine 1 reinschreiben und das Programm einmal neu flashen. So sieht das bei meiner DDE aus:
1 | [BASE b1] DLE -> P02 |
2 | [RX b1] src=0x00 dst=0x18 fid=253 ctrl=0x00 (M_HS) |
3 | [ADDR b1] adopt 0x18 (locked) |
4 | [TX b1] src=0x18 dst=0x00 fid=253 ctrl=0x00 len=1 (M_HS) |
5 | [RX b1] src=0x00 dst=0x18 fid=254 ctrl=0x21 (M_FIRMWARE) |
6 | [TX b1] src=0x18 dst=0x00 fid=254 ctrl=0x21 len=28 (M_FIRMWARE) |
7 | ↳ fw="02:F2:EMU_02:8881031:0051123" |
8 | [RX b1] src=0x00 dst=0x18 fid=254 ctrl=0x1E (M_R_DEVICEID) |
9 | [TX b1] src=0x18 dst=0x00 fid=254 ctrl=0x1E len=30 (M_R_DEVICEID) |
10 | ↳ deviceId="84495820251031014332F283" |
11 | [RX b1] src=0x00 dst=0x19 fid=254 ctrl=0x21 (M_FIRMWARE) |
12 | [RX b1] src=0x00 dst=0x19 fid=254 ctrl=0x21 (M_FIRMWARE) |
13 | [RX b1] src=0x00 dst=0x19 fid=254 ctrl=0x21 (M_FIRMWARE) |
14 | [RX b1] src=0x00 dst=0x19 fid=254 ctrl=0x21 (M_FIRMWARE) |
15 | [RX b1] src=0x00 dst=0x18 fid=254 ctrl=0x21 (M_FIRMWARE) |
16 | [TX b1] src=0x18 dst=0x00 fid=254 ctrl=0x21 len=28 (M_FIRMWARE) |
17 | ↳ fw="02:F2:EMU_02:8881031:0051123" |
18 | [RX b1] src=0x00 dst=0x18 fid=254 ctrl=0x1E (M_R_DEVICEID) |
19 | [TX b1] src=0x18 dst=0x00 fid=254 ctrl=0x1E len=30 (M_R_DEVICEID) |
20 | ↳ deviceId="84495820251031014332F283" |
21 | [RX b1] src=0x00 dst=0x18 fid=252 ctrl=0x16 (M_SYN) |
22 | [RX b1] src=0x00 dst=0x19 fid=254 ctrl=0x21 (M_FIRMWARE) |
23 | [RX b1] src=0x00 dst=0x19 fid=254 ctrl=0x21 (M_FIRMWARE) |
24 | [RX b1] src=0x00 dst=0x19 fid=254 ctrl=0x21 (M_FIRMWARE) |
25 | [RX b1] src=0x00 dst=0x18 fid=148 ctrl=0x38 (M_R_INTAKEACTIVATION) |
26 | [TX b1] src=0x18 dst=0x00 fid=148 ctrl=0x38 len=3 (M_R_INTAKEACTIVATION) |
27 | ↳ intakeAct=0 port=0 intake=0 |
Angehängte Dateien:
-
IMG_2296.jpg
240 KB -
IMG_2297.jpg
240 KB
Hallo Tim, ich folgendes gemacht: 1) Fotos von meiner JBC-Löstation, es ist eine CD-2BQF, und der serielle Ausgang ist mit AUX beschriftet 2) Foto von dem Aufbau. Als Wandler verwende ich ein Adafruit-Modul 5987 mit dem MAX3232E (https://www.adafruit.com/product/5987) 3) Software frisch von Github heruntergeladen (ich hatte bei meinen Untersuchungen selbst hier und da etwas hinzugefügt, daher "neu" aufgesetzt, um irgendwelche Seiteneffekte ausschliessen zu können) #defines:
1 | #define DBG_SHOW_RX 1
|
2 | #define DBG_SHOW_TX 1
|
3 | #define DBG_SHOW_PROTO 1
|
4 | #define LED_ENABLE 0
|
Note: DBG_SHOW_PROTO ist im Original auf 0 gesetzt, vermute aber dass 1 eher hilft als es schadet. Die Station befindet sich im Sleep-Modus (also reduzierte Temperatur (150°C)), aber noch nicht Hibernation (Heizung komplett aus)) Im Serial Monitor (Arduino IDE, 1.8.19) gibt es dann folgendes:
1 | 19:12:39.414 -> [EEP] |
2 | 19:12:39.414 -> bus0 DeviceID len=32 ascii="................................" | addr=0x11 |
3 | 19:12:39.414 -> bus1 DeviceID len=32 ascii="849158E467A340159646170D6B1596EF" | addr=0x91 |
4 | 19:12:39.414 -> [CLI] type 'help' for commands |
5 | 19:12:39.414 -> [CFG] buses=2 | tstop(w/s)=0/0 | selectflow=100 | suctionlevel=3 | stand_intakes=0 | filter(life/sat)=0/0 | stat_error=0 (0x0) |
6 | 19:12:39.414 -> [FW] 02:F2:EMU_02:8881031:0051123 | by IceCube20 | build Feb 18 2026 19:12:28 |
7 | 19:12:39.414 -> |
8 | 19:12:39.414 -> [JBC FAE Emulator – Base-Link + P02 (SRC,DST), Dual-Bus] |
9 | 19:12:39.414 -> [UART bus0] @ 250000, 8E1 |
10 | 19:12:39.414 -> [UART bus1] @ 250000, 8E1 |
11 | 19:12:41.339 -> [BASE b0] DLE -> P02 |
12 | 19:12:41.339 -> [RX b0] src=0x10 dst=0x11 fid=253 ctrl=0x00 (M_HS) |
13 | 19:12:41.339 -> [ADDR b0] adopt 0x11 (locked) |
14 | 19:12:41.339 -> [TX b0] src=0x11 dst=0x10 fid=253 ctrl=0x00 len=1 (M_HS) |
15 | 19:12:41.435 -> [RX b0] src=0x10 dst=0x11 fid=253 ctrl=0x00 (M_HS) |
16 | 19:12:41.435 -> [TX b0] src=0x11 dst=0x10 fid=253 ctrl=0x00 len=1 (M_HS) |
17 | 19:12:41.532 -> [RX b0] src=0x10 dst=0x11 fid=253 ctrl=0x00 (M_HS) |
18 | 19:12:41.532 -> [TX b0] src=0x11 dst=0x10 fid=253 ctrl=0x00 len=1 (M_HS) |
19 | 19:12:41.629 -> [RX b0] src=0x10 dst=0x11 fid=253 ctrl=0x00 (M_HS) |
.... irgendwann mal das hier (beachte die M_SYN):
1 | 19:12:43.219 -> [TX b0] src=0x11 dst=0x10 fid=253 ctrl=0x00 len=1 (M_HS) |
2 | 19:12:43.317 -> [RX b0] src=0x10 dst=0x11 fid=253 ctrl=0x00 (M_HS) |
3 | 19:12:43.364 -> [TX b0] src=0x11 dst=0x10 fid=253 ctrl=0x00 len=1 (M_HS) |
4 | 19:12:43.843 -> [RX b0] src=0x10 dst=0x11 fid=0 ctrl=0x16 (M_SYN) |
5 | 19:12:44.324 -> [RX b0] src=0x10 dst=0x11 fid=0 ctrl=0x16 (M_SYN) |
6 | 19:12:44.854 -> [RX b0] src=0x10 dst=0x11 fid=0 ctrl=0x16 (M_SYN) |
7 | 19:12:45.335 -> [RX b0] src=0x10 dst=0x11 fid=0 ctrl=0x16 (M_SYN) |
8 | 19:12:45.816 -> [RX b0] src=0x10 dst=0x11 fid=0 ctrl=0x16 (M_SYN) |
9 | 19:12:46.056 -> [RX b0] src=0x10 dst=0x11 fid=253 ctrl=0x00 (M_HS) |
10 | 19:12:46.105 -> [TX b0] src=0x11 dst=0x10 fid=253 ctrl=0x00 len=1 (M_HS) |
11 | 19:12:46.201 -> [RX b0] src=0x10 dst=0x11 fid=253 ctrl=0x00 (M_HS) |
12 | 19:12:46.201 -> [TX b0] src=0x11 dst=0x10 fid=253 ctrl=0x00 len=1 (M_HS) |
13 | 19:12:46.297 -> [RX b0] src=0x10 dst=0x11 fid=253 ctrl=0x00 (M_HS) |
14 | 19:12:46.297 -> [TX b0] src=0x11 dst=0x10 fid=253 ctrl=0x00 len=1 (M_HS) |
15 | 19:12:46.394 -> [RX b0] src=0x10 dst=0x11 fid=253 ctrl=0x00 (M_HS) |
16 | 19:12:46.394 -> [TX b0] src=0x11 dst=0x10 fid=253 ctrl=0x00 len=1 (M_HS) |
17 | 19:12:46.490 -> [RX b0] src=0x10 dst=0x11 fid=253 ctrl=0x00 (M_HS) |
18 | 19:12:46.490 -> [TX b0] src=0x11 dst=0x10 fid=253 ctrl=0x00 len=1 (M_HS) |
19 | 19:12:46.971 -> [RX b0] src=0x10 dst=0x11 fid=0 ctrl=0x16 (M_SYN) |
20 | 19:12:47.502 -> [RX b0] src=0x10 dst=0x11 fid=0 ctrl=0x16 (M_SYN) |
21 | 19:12:47.979 -> [RX b0] src=0x10 dst=0x11 fid=0 ctrl=0x16 (M_SYN) |
22 | 19:12:48.462 -> [RX b0] src=0x10 dst=0x11 fid=0 ctrl=0x16 (M_SYN) |
23 | 19:12:48.991 -> [RX b0] src=0x10 dst=0x11 fid=0 ctrl=0x16 (M_SYN) |
24 | 19:12:49.231 -> [RX b0] src=0x10 dst=0x11 fid=253 ctrl=0x00 (M_HS) |
25 | 19:12:49.231 -> [TX b0] src=0x11 dst=0x10 fid=253 ctrl=0x00 len=1 (M_HS) |
Die M_SYN Blöcke kommen dann regelmäßig immer wieder während der Monitor mit
1 | 19:12:46.056 -> [RX b0] src=0x10 dst=0x11 fid=253 ctrl=0x00 (M_HS) |
2 | 19:12:46.105 -> [TX b0] src=0x11 dst=0x10 fid=253 ctrl=0x00 len=1 (M_HS) |
fröhlich gefüllt wird, wobei der Zeitabstand zwischen den einzelnen M_SYN-Zeilen größer ist (~500ms), als zwischen den M_HS-Zeilen (~100ms). Während der M_SYN-Phasen werden keine Nachrichten an die JBC gesendet. Außerdem, noch mal ganz oben nachschauen
1 | 19:12:39.414 -> bus0 DeviceID len=32 ascii="................................" | addr=0x11 |
Da stand mal was anderes, ist aber nachhaltig verloren gegangen. Zudem gab es mal (am Anfang, nun nicht mehr sichtbar) irgendwas der Art DLE und "unknown command (ID?)" oder dergleichen. Sorry, aber ich hatte es nicht notiert, d.h. ich kann es leider nicht näher/besser beschreiben. Zum Schluss habe ich noch folgendes hinbekommen (beim Rausnehmen des Lötkolbens, also wo dann das Relais anziehen sollte)
1 | 9:23:36.787 -> [RX b0] src=0x10 dst=0x11 fid=0 ctrl=0x16 (M_SYN) |
2 | 19:23:37.076 -> [RX b0] src=0x10 dst=0x11 fid=0 ctrl=0x39 (M_W_INTAKEACTIVATION) |
3 | 19:23:37.076 -> [TX b0] src=0x11 dst=0x10 fid=0 ctrl=0x06 len=1 (M_ACK) |
4 | 19:23:37.076 -> [RELAY] 🟢ON Delay Work 10s |
5 | 19:23:37.269 -> [RX b0] src=0x10 dst=0x11 fid=0 ctrl=0x16 (M_SYN) |
6 | 19:23:37.751 -> [RX b0] src=0x10 dst=0x11 fid=0 ctrl=0x16 (M_SYN) |
7 | 19:23:38.278 -> [RX b0] src=0x10 dst=0x11 fid=0 ctrl=0x16 (M_SYN) |
8 | 19:23:38.761 -> [RX b0] src=0x10 dst=0x11 fid=0 ctrl=0x16 (M_SYN) |
9 | 19:23:39.050 -> [RX b0] src=0x10 dst=0x11 fid=0 ctrl=0x39 (M_W_INTAKEACTIVATION) |
10 | 19:23:39.050 -> [TX b0] src=0x11 dst=0x10 fid=0 ctrl=0x06 len=1 (M_ACK) |
11 | 19:23:39.050 -> [RELAY b0] schedule OFF in 10s |
12 | 19:23:39.291 -> [RX b0] src=0x10 dst=0x11 fid=0 ctrl=0x16 (M_SYN) |
13 | 19:23:39.774 -> [RX b0] src=0x10 dst=0x11 fid=0 ctrl=0x16 (M_SYN) |
Hier habe ich in der Vergangenheit aber auch beobachtet, dass das Relais nicht nach 10s wieder abfällt. Zu guter letzt, was ich auf dem Scope decodieren konnte (Nachrichten, die die JBC sendet, die 255 sind nur zum Auffüllen).
1 | const uint8_t rxCodes [][16] |
2 | {
|
3 | {16, 2, 16, 16, 17, 253, 0, 1, 17, 237, 16, 3, 255, 255, 255, 255}, |
4 | {16, 2, 16, 16, 17, 0, 22, 1, 17, 6, 16, 3, 255, 255, 255, 255}, |
5 | {16, 2, 16, 16, 17, 0, 57, 2, 1, 0, 58, 16, 3, 255, 255, 255} |
6 | };
|
M_HS in der ersten Zeile, M_SYN ist in der zweiten Zeile, dritte Zeile habe ich noch so recht rausbekommen. Vermutlich wenn eine Entnahme des Lötkolbens erkannt wird. Damit sind, hoffe ich jedenfalls, alle Fragen beantwortet (und noch ein paar mehr ;-)), oder? Wenn ich noch was machen soll, so lass es mich wissen. Meine Frage nach dem ESP32 kam übrigens daher, dass im Code steht, dass es beim ATMega zu Schwierigkeiten kommen kann. Auch wenn du es wohl mit der Ansteuerung der LEDs beobachtet hast; daher LEDs via #define aus.
Hey Sebastian, Ich sehe das Problem, du nutzt den Aux Port. Es muss aber explizit ein FAE/Robot Port sein. Wenn du mal hier in die Anleitung von JBC guckst steht dort auch, das du ein Adapterkabel brauchst das von USB auf RJ12: https://www.jbctools.com/pdf/manual-fae1-fume-extractor-0027634_ID-212597.pdf?srsltid=AfmBOookgY9vVBanJUgwPe1-zi5qMFwqUZnZwqQNtK1_H-r7S4aQL-Hz Das mit dem M_HS und M_SYN ist normal, die Station sendet und einen Handshake den wir mit ACK bestätigen (siehst du an TX len 1 und das M_SYN ist ein keepalive) anscheinend akzeptiert die Station unsere Antwort nicht. Ich weiß aber auch ehrlich gesagt nicht was der AUX Port sonst macht, den gibt an meiner DDE nicht. Bei mir steht da FAE/Robot. Das muss ein Grund haben das JBC extra ein USB auf RJ12 Kabel für die CD Stationen hat. Komisch ist aber das die Station schon M_W_INTAKEAKTIVATION sendet ohne den Handshake anzunehmen (das geht bei mir erst wenn der Handshake geklappt hat) dann sendet er alle anderen Befehle die du oben in meinem LOG siehst. Gruß Tim
Tim schrieb: > Hey Sebastian, > > Ich sehe das Problem, du nutzt den Aux Port. Es muss aber explizit ein > FAE/Robot Port sein. Wenn du mal hier in die Anleitung von JBC guckst > steht dort auch, das du ein Adapterkabel brauchst das von USB auf RJ12: > https://www.jbctools.com/pdf/manual-fae1-fume-extractor-0027634_ID-212597.pdf Habe ich mir angeschaut, wobei es hier wohl um einen USB - RS232 converter geht. Da es aber letztendlich mit einem UART verbunden wird, kann man sich doch den Umweg über die RS232 sparen, oder? D.h eigentlich brauche ich einen USB - UART converter, was schwer nach einen Programmier-Adapter klingt. So einen habe ich hier rumliegen, auch wenn ich den erstmal wegen der vielen USB Stecker Varianten nicht an die Lötstation anschließen kann. Und ich noch gucken müsste, wo der Converter seine Spannung herbekommen kann.
:
Bearbeitet durch User
Tim schrieb: > Das muss ein Grund haben > das JBC extra ein USB auf RJ12 Kabel für die CD Stationen hat. Sebastian S. schrieb: > Da es aber letztendlich mit einem UART verbunden wird, > kann man sich doch den Umweg über die RS232 sparen, oder? Ich habe nun den direkten Weg probiert. Also USB - UART converter (den hier: https://www.amazon.de/dp/B0773G2K92?ref_=pe_109184651_1103807401_t_fed_asin_title&th=1), wobei ich noch einen passenden USB-female-female Adapter dazwischen stecken musste (den ich natürlich auch nicht hatte) ... daher hat es ein bisschen mit der Antwort gedauert. Ergebnis ist aber, dass ich das vermutlich alles hätte nicht machen müssen ;-) ... es passiert nämlich gar nichts. Wenn ich deine SW richtig verstanden habe, fängt das ATMega Board erst mit dem Senden an, wenn eine Nachricht empfangen wurde. Gleichzeitig ist die Lötstation auf dem USB-Port stumm ist wie ein Fisch. Und so bleiben RX und TX Leitungen beide bei 3V3 liegen. Entsprechend wenig im seriellen Monitor:
1 | 17:37:45.756 -> [EEP] |
2 | 17:37:45.756 -> bus0 DeviceID len=32 ascii="................................" | addr=0x11 |
3 | 17:37:45.756 -> bus1 DeviceID len=32 ascii="849158E467A340159646170D6B1596EF" | addr=0x91 |
4 | 17:37:45.756 -> [CLI] type 'help' for commands |
5 | 17:37:45.756 -> [CFG] buses=2 | tstop(w/s)=0/0 | selectflow=100 | suctionlevel=3 | stand_intakes=0 | filter(life/sat)=0/0 | stat_error=0 (0x0) |
6 | 17:37:45.756 -> [FW] 02:F2:EMU_02:8881031:0051123 | by IceCube20 | build Feb 27 2026 17:37:34 |
7 | 17:37:45.756 -> |
8 | 17:37:45.756 -> [JBC FAE Emulator – Base-Link + P02 (SRC,DST), Dual-Bus] |
9 | 17:37:45.756 -> [UART bus0] @ 250000, 8E1 |
10 | 17:37:45.756 -> [UART bus1] @ 250000, 8E1 |
Irgendeine Idee?
Hey Sebastian, Ich denke du hast dein USB zu Uart Wandler jetzt zerstört. RS232 arbeitet mit +-12 Volt und der Uart Wandler nur mit maximal 5volt. Du könntest es höchstens noch mit dem esp32 probieren, da dieser Leistungsfähiger ist als ein Mega 2560. Die Station spamt ja die ganze Zeit mit dem Handshake. Gruß Tim
Thread beobachten
Seitenaufteilung abschaltenBitte 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.