Ich habe ein MeanWell BIC-2200 Netzteil das ich gerne per CANBus steuern möchte. Die Spezifikation findet man hier: https://www.meanwell.com/Upload/PDF/BIC-2200-E.pdf Ich nutze einen RasPi mit Can/RS485 HAT von Waveshare und habe alles soweit konfiguriert, dass ich mit cansend senden und per candump diese Nachricht auch empfangen kann. Dieser Part scheint also zu funktionieren. Das CanHat ist mit 250000kbits konfiguriert und per Can_High und Can_low sowei Ground_Aux mit den Netzteil verbunden. Ich versuche nun seit längerem das Netzteil zu einer Antwort zu bewegen aber nicht funktioniert. Ich sende z.b. "cansend 000C0300#0000", um den Status abzufragen und sollte eine Antwort mit vom Netzteil mit dem byte "01" erhalten, aber nichts wird empfangen. Nur wiederrum die gesendete Nachricht. Der Canbus ist beim Raspi mit 120ohm terminiert. Hat einer von euch netten Menschen noch eine Idee? Vielen Dank schonmal :)
Felix K. schrieb: > Das CanHat ist mit 250000kbits konfiguriert Sicher nicht, denn das wären 250 Mbit ;-) > und per Can_High und Can_low > sowei Ground_Aux mit den Netzteil verbunden. OK > Der Canbus ist beim Raspi mit 120ohm terminiert. > Hat einer von euch netten Menschen noch eine Idee? Wie sieht das Signal auf dem Bus aus? Richtige Adresse beim Ansprechen verwendet?
Felix K. schrieb: > Der Canbus ist beim Raspi mit 120ohm terminiert. Der Widerstand zwischen CANH und CANL sollte 60 Ohm betragen. Fehlen die 120 Ohm am Netzteilende des Busses? LG, Sebastian
Felix K. schrieb: > Nur wiederrum die gesendete Nachricht. Hängt beim Empfang ein ACK vom Netzteil hinter der gesendeten Nachricht? LG, Sebastian
Sebastian schrieb: > Der Widerstand zwischen CANH und CANL sollte 60 Ohm betragen. Das stimmt, zum Test mit kurzem Kabel geht es aber auch mit 120 Ohm. Nur ganz ohne Terminierung geht es nicht, denn der rezessive Pegel wird nur dadurch hergestellt.
Felix K. schrieb: > Nur wiederrum die gesendete Nachricht. > Du empfängst die gesendete Botschaft? Dann stimmt schon mal grundsätzlich etwas nicht. Aus Versehen so eine Art loopback aktiviert?
Bei ausgeschaltetem Netzteil bekomme ich im Candump das gesendete nicht zurück. Mittlerweile hab ich das Netzteil acuh zum Antworten bewegt. Allerdings reagiert es komsicherweise nur auf ein Kommando: und zwar auf 000C0300#0000 darauf bekomme ich zuerst zweimal meine anfrage zurück. und dann bei jedem weiteren mal einmal die anfrage und die korrekt Antwort mit 00 00 01 (Netzeil aktiv). Hier der candump log:
1 | can0 000C0300 [2] 00 00 |
2 | can0 000C0300 [2] 00 00 |
3 | |
4 | can0 000C0300 [2] 00 00 |
5 | can0 000C0200 [3] 00 00 01 |
6 | |
7 | can0 000C0300 [2] 00 00 |
8 | can0 000C0200 [3] 00 00 01 |
9 | |
10 | can0 000C0300 [2] 00 00 |
11 | can0 000C0200 [3] 00 00 01 |
Die Kommunikation funktioniert also grundsätzlichs, nur finde ich es auch komisch dass ich immer die Anfrage zurück bekomme, vieleicht ein Art Signalverstärker für nachfolgende Netzteile, weil man ja viele Netzteile parallel und per Can dann in Reihe schalten kann... hmm Loopback ist aus. Wenn das Netzteil aus ist, bekomme ich auch keinerlei Reaktion in candump wenn ich etwas sende. Jetzt nur das Problem: Kein anderes Kommando funktioniert. cansend 000C0300#0062 sollte z.b. die Temperatur als Antwort zurückbringen, es passiert aber nicht. Sondern etwas sehr komisches: candump zeigt wie aus einer Art Zwischenspeicher folgendes:
1 | can0 000C0300 [2] 00 62 |
2 | can0 000C0200 [3] 00 00 01 |
3 | |
4 | can0 000C0300 [2] 00 62 |
5 | can0 000C0200 [3] 00 00 01 |
6 | |
7 | can0 000C0300 [2] 00 62 |
8 | can0 000C0300 [2] 00 62 |
zweimal die ANtwort auf eine vorhereige Anfrage und dann weider das verhalten dass einfach wie beim Repeater das Originalkommando wiederholt wird. Ich versteh das nicht :/ Ich rufe das can Interface mit
1 | sudo ip link set can0 type can bitrate 250000 |
2 | sudo ifconfig can0 up |
auf, also kein loopback.
„Signalverstärker“ kann nicht sein, es dürfte kein zweiter Teilnehmer einfach die Botschaft unter der gleichen ID noch einmal spiegeln. Das müsste irgendwie aus dem lokalen System kommen. Ansonsten hast Du bei dem 0x62 vermutlich Low- und High-Byte vertauscht, kann das sein? Kommando 0x0062 ist auf dem CAN Bus 62 00
Harald A. schrieb: > Felix K. schrieb: >> Nur wiederrum die gesendete Nachricht. >> > Du empfängst die gesendete Botschaft? Dann stimmt schon mal > grundsätzlich etwas nicht. Das kommt auf die Einstellung des CAN-Controllers an. Jeder CAN-Controller liest beim Senden die gesendete Botschaft auch wieder zurück. Das muss er schon alleine wegen der Arbitrierung tun. Je nach Einstellung kommt die dann auch wieder als Empfangene Botschaft an oder wird unterdrückt. Felix K. schrieb: > Loopback ist aus. Wenn das Netzteil aus ist, bekomme ich auch keinerlei > Reaktion in candump wenn ich etwas sende. Das sollte auch nicht funktionieren, weil dann keiner das Ack setzt. Dann gilt die Botschaft als nicht erfolgreich gesendet. > Ich rufe das can Interface mit > sudo ip link set can0 type can bitrate 250000 > sudo ifconfig can0 up > > auf, also kein loopback. Wo hast du es denn ausgeschaltet? Unter https://docs.kernel.org/networking/can.html heißt es: "The loopback functionality is enabled by default to reflect standard networking behaviour for CAN applications. Due to some requests from the RT-SocketCAN group the loopback optionally may be disabled for each separate socket. See sockopts from the CAN RAW sockets in RAW Protocol Sockets with can_filters (SOCK_RAW)."
Ich muss mich korrigieren, wenn ich mich richtig erinnere zeigt candump auch die eigenen gesendeten Nachrichten. EDIT: Zeitgleich mit der Antwort von Rolf EDIT2: Der CAN Controller INTERN liest natürlich mit, CANSEND und CANDUMP sind als Systemfunktionem aber nach meinem Verständnis nicht auf der Ebene sondern bedienen den CAN Controller ja nur. Ich kann mich aber erinnern, dass ich dieses Verhalten von candump schon einmal etwas schräg fand.
Dann ist das ja schonmal normal, dass man die Nachrichten im Candump sieht. wenn man loopback noch zusätzlich aktiviert, dass sehe ich die Nachrichten auch wenn das Netzteil aus ist. Komischweise funktioniert die Kommunikation, also die Antowrt auf diese eine Nachricht, die funktioniert (000c0300#0000-->000c0200#000001), nur ohne Terminale Wiederstände, was für mich keinen Sinn macht, da das Raspi Bord angeblich keinen an Bord hat und in der SPezifiaktion vom Netzteil dazu auch gar nichts gesagt wird. :/ Andererseits frage ich mich, wieso wenn eine Nachricht ein Ergbnis bringt, alle anderen ins leere laufen und doppelt im Candump erscheinen. Einmal wohl das selbst gesendete und das andere veilleucht die Reflektion beim Netzteil, weil ohne Wiederstand :( . Ich probiere mal paar andere wiederstände, irgendwas ist faul. EDIT: Danke auf jeden fall schonmal für die Ideen. EDIT2: Aha, ich messe im Pi-HAT einen wiedestand von 120 ohm, ist dort also wohl schon auf der platine
Felix K. schrieb: > ohne Terminale Wiederstände, was für mich keinen Sinn macht, da das > Raspi Bord angeblich keinen an Bord hat und in der SPezifiaktion vom > Netzteil dazu auch gar nichts gesagt wird. :/ Standard ist bei CAN Teilnehmer kein integrierter Widerstand, man kann als Hersteller ja nicht wissen, ob es das physikalische Ende des Busses ist. > > Andererseits frage ich mich, wieso wenn eine Nachricht ein Ergbnis > bringt, alle anderen ins leere laufen und doppelt im Candump erscheinen. > Einmal wohl das selbst gesendete und das andere veilleucht die > Reflektion beim Netzteil, weil ohne Wiederstand :( . > Ich probiere mal paar andere wiederstände, irgendwas ist faul. Es gibt keine Reflektion von Nachrichten aufgrund eines falschen Widerstandes. Das physikalisch offene Ende (die „Reflexion“) kann keine Nachrichten speichern. Andere Widerstände sind Blödsinn, bei ganz kurzen Kabeln kann es auch mal ohne Widerstand funktionieren, ist aber eher ein Zufallsprodukt. 120Ohm an beiden Enden oder auch nur an einem Ende bei kurzen Verbindungen sind absolut in Ordnung.
Drehe doch erstmal Low- und Highbyte, mein obiger Beitrag ist offensichtlich (bei dir) verschütt gegangen.
Harald A. schrieb: > Felix K. schrieb: >> ohne Terminale Wiederstände, was für mich keinen Sinn macht, da das >> Raspi Bord angeblich keinen an Bord hat und in der SPezifiaktion vom >> Netzteil dazu auch gar nichts gesagt wird. :/ > > Standard ist bei CAN Teilnehmer kein integrierter Widerstand, man kann > als Hersteller ja nicht wissen, ob es das physikalische Ende des Busses > ist. Es gibt auch welche mit schaltbaren Widerständen, entweder per Jumper oder sogar per Software. Aber wenn im Handbuch nix dazu steht, würde ich auch davon ausgehen, dass keiner da ist. Kann man aber einfach mit einem Multimeter nachmessen. > 120Ohm an beiden Enden oder auch nur an einem Ende bei kurzen > Verbindungen sind absolut in Ordnung. Ja. Ganz ohne funktioniert es fast nie, bei zu vielen Widerstanden gibt's irgendwann auch Probleme, weil die Last zu groß wird, aber ansonsten ist CAN da sehr robust.
Oh mein gott, vielen Dank. Das macht natürlich Sinn. Ich habe keine Ahnung von CAN und scheitere an solchen Basics. Das hat geklappt und erklärt auch warum 00 00 als kommando funktioniert. Dass kann man ja drehen und wenden, wie man will und es bleibt das selbe :) Ich habe also Low und High Byte nicht richitg angeordnet ;) Danke euch udn besonders dir, Harald!
Genau, das Netzteil hat keinen schaltbaren oder festen Wirderstand aber beim Board habe ich mit Multimeter 120 gemessen, auch wenn ich auf der Website von Waveshare zu diesem modell nix zu einem Widerstand finde.
Felix K. schrieb: > Genau, das Netzteil hat keinen schaltbaren oder festen Wirderstand aber > beim Board habe ich mit Multimeter 120 gemessen, auch wenn ich auf der > Website von Waveshare zu diesem modell nix zu einem Widerstand finde. Bereits fest eingebauter Widerstand ist häufig bei RS485 oder CAN Shields, die für „allgemeinen Experimentierbedarf“ entworfen wurden, der Fall. Vermutlich wollen die Entwickler damit das Erfolgserlebnis für Gelegenheitsuser erhöhen, die dem Widerstand nicht so viel Bedeutung zumessen. Der Widerstand ist ja eben nicht nur ein reiner Terminierungswiderstand sondern auch ein Arbeitswiderstand, damit sich die Pegel am Bus überhaupt ausbilden können (wie Falk schon schrieb). Jaja, ganz ohne Widerstand kann es auch funktionieren, aber nur in sehr engen Grenzen. Ein erfahrener Anwender erarbeitet sich die beste Lage der Widerstände sowieso noch einmal genauer.
Felix K. schrieb: > aber > beim Board habe ich mit Multimeter 120 gemessen, auch wenn ich auf der > Website von Waveshare zu diesem modell nix zu einem Widerstand finde. Die haben den Schaltplan im Wiki: https://www.waveshare.com/w/upload/1/1d/RS485_CAN_HAT_Schematic.pdf -> R12.
Felix K. schrieb: > Andererseits frage ich mich, wieso wenn eine Nachricht ein Ergbnis > bringt, alle anderen ins leere laufen und doppelt im Candump erscheinen. Du könntest auch einen Logik-Analysator an RXD des SN65HVD230 bzw. an RXCAN des MCP2515 klemmen und dir dort die Vorgänge auf dem CAN-Bus im Detail ansehen. Da wird vieles dann doch noch klarer. LG, Sebastian
Hallo, ich benutze einen esp32 mit mcp2515. Leider bekomme ich keine Antwort von Lader. Meanwell npb 1700. Bekomme ich hier noch Hilfe? Gruß Udo
Hallo, ich mache das ganze über esphome. Im mcp2515 ist ein TJA1050 verbaut soweit ich das verstehe. Ich habe 2 Gegenstellen zum Test aufgebaut und die Kommunikation funktioniert hier. Der BUS funktioniert also. Hi und Low-bit kann ich nicht drehen, da ich einen Fehler bei 0x8000 bekomme. Da der Wert über 255 ist. Aber 8ch bekomme auf die 0x0000 auch keine Antwort. Deswegen Versuche ich hier mein Glück. Die Verkabelung zum Lader checke ich heute nochmal. Angeschlossen sind CanH CanL und GND. Gruß Udo
auf den Modulen sind Jumper drauf für die Terminierung, damit mal rumspielen
Wer mit CAN Bus experimentiert, dem empfehle ich einen zusätzlichen CAN Adapter zu kaufen, damit hat man eine unabhängige Kontrolle was tatsächlich auf dem Bus übertragen wird. Der von der Firma PEAK-System ist relativ günstig, die Software sehr gut und die bieten sogar eine API mit dem man eigene Programme schreiben kann. https://www.peak-system.com/PCAN-USB-FD.365.0.html Ich habe von denen mehrere, weil die mir so gut gefallen und ich habe auch schon ein paar Programme dafür selbst für den PC geschrieben. Der Link zeigt auf einen USB Adapter der FD-CAN fähig ist und kompatibel zu CAN. Es gibt einen "nur CAN" Adapter, den empfehle ich jedoch nicht zu kaufen, da FD-CAN die Zukunft ist und man nur einmalig Geld dafür ausgeben möchte.
Machst Du hier Schleichwerbung für PEAK-PCAN? Da ist auch nix anderes drin wie auf dem Arduino Modul, nur Faktor 10 teurer.
Das Modul ist mir zu teuer. :-) Also der Jumper ist aktiviert. Sprich terminiert. Das Kabel zum Lader ist ca 5cm lang. Sollte also nichts stören. Meanwell habe ich schon angeschrieben. Leider keine Antwort. An dem Lader hängt kein Akku. Das sollte aber nicht das Problem sein oder? DIP Schalter sind auf programmieren gestellt. Was ich nicht genau kapiere sind die Adressen oder IDs Charger to controller message ID Controller to charger message ID Controller broadcasts to charger message ID Message ID 0x000C00XX 0x000C01XX 0x000C01FF Welche Adresse hat der Lader
Angehängte Dateien:
-
BIC-2200-E_CanID.PNG
45 KB -
BIC-2200-E_DIP.PNG
66 KB
Udo E. schrieb: > Welche Adresse hat der Lader Laut deinem Manual im Kapitel 5.10.2 ist da nichts mit 000c00xx und 000co1xx dabei...
Angehängte Dateien:
Sorry, ich hatte vergessen zuschreiben das es sich um ein NPB 1700 handelt.
Felix K. schrieb: > Allerdings reagiert es komsicherweise nur auf ein Kommando: > und zwar auf > 000C0300#0000 > darauf bekomme ich zuerst zweimal meine anfrage zurück. Eigentlich kannst du deine Anfrage nicht "zurückbekommen", denn CAN funktioniert nicht wie eine übliche serielle Schnitte mit 2 Teilnehmern. CAN funktioniert so, dass irgendwer auf dem Bus irgendeine Message mit einer bestimmten ID auf dem Bus sendet. Und wenn es mindestens 1 Teilnehmer auf dem Bus gibt, der diese ID kennt und die Message brauchen kann, dann legt der das ACK auf den Bus. Felix K. schrieb: > Ich nutze einen RasPi mit Can/RS485 HAT von Waveshare und habe alles > soweit konfiguriert, dass ich mit cansend senden und per candump diese > Nachricht auch empfangen kann. Geschickt ist es immer, wenn man 2 solcher Geräte miteinander verbinden und untereinander kommunizieren kann. Dann weiß man schon mal, dass die eigene Hardware tut. > noch eine Idee? Ich würde erst mal sicherstellen, dass der CAN-Bus hardwaremäßig gut funktioniert. Also mit dem Oszi die Pegel und Flanken sowie das Timing auf beiden Busleitungen kontrollieren. Und dann noch schauen, was sich überhaupt auf dem Bus tut und ob da irgendwas ausser deiner eigenen Message auf dem Bus unterwegs ist. EDIT zum Thema Oszi: wenn du den Bus beidseitig mit 120R terminierst und einen 4R7 Widerstand in die beiden Busleitungen schleifst, dann kannst du mit dem Oszi leicht erkennen, welcher der beiden Teilnehmer grade das dominante Bit auf den Bus legt.
1 | Oszi |
2 | Kanal A Kanal B |
3 | | | |
4 | v v |
5 | CanHi ----o-------------------4R7---------------o---- CanHi |
6 | | | |
7 | A 120R 120R B |
8 | | | |
9 | CanLo ----o-------------------4R7---------------o---- CanLo |
Alexander schrieb: > Udo E. schrieb: >> Also der Jumper ist aktiviert. Sprich terminiert. > > Und warum? Ich habe den Jumper auch schon deaktiviert. Gleiches Ergebniss. Das System Can Bus habe ich verstanden. Ich habe eine ID und sende einen Command. Die Gegenstelle oder der Teilnehmer antwortet nur wenn er das in seinem Code hinterlegt hat. Ich habe 2 ESP32 die miteinander kommunizieren können. Nur die Kommunikation mit dem Lader funktioniert leider nicht.
Lothar M. schrieb: > Und wenn es mindestens 1 > Teilnehmer auf dem Bus gibt, der diese ID kennt und die Message brauchen > kann, dann legt der das ACK auf den Bus. Nein, das ACK wird immer dann gesendet, wenn mindestens ein Empfänger die Richtigkeit der Message auf dem Bus incl. CRC bestätigen kann, egal, ob der Identifier bzw. die Message für ihn gedacht ist oder nicht.
Angehängte Dateien:
Helmut -. schrieb: > Lothar M. schrieb: >> Und wenn es mindestens 1 >> Teilnehmer auf dem Bus gibt, der diese ID kennt und die Message brauchen >> kann, dann legt der das ACK auf den Bus. > > Nein, das ACK wird immer dann gesendet, wenn mindestens ein Empfänger > die Richtigkeit der Message auf dem Bus incl. CRC bestätigen kann, egal, > ob der Identifier bzw. die Message für ihn gedacht ist oder nicht. Dann ist meine Message nicht richtig?? Ich sende 0x0080 das ist laut Anleitung der Herstellername zum lesen.
was bedeutet R und R/W? klingt für mich nach read/write. was du machst ist W schreiben oder? Terminierung mal gemessen? Wieviel Ohm? Soweit ich mich erinnere ist da ein 500 Ohm Widerstand auf dem Modul verbaut.
Alexander schrieb: > was bedeutet R und R/W? klingt für mich nach read/write. was du machst > ist W schreiben oder? > > Terminierung mal gemessen? Wieviel Ohm? Soweit ich mich erinnere ist da > ein 500 Ohm Widerstand auf dem Modul verbaut. R und W ist Lesen und Schreiben. Manche Werte können nur gelesen werden. Aber so weit bin ich noch lange nicht.
Erstmal würde ich die Rate checken und dann bruteforcen. Kann ja am Code liegen, dass zwei ESP32 miteinander reden heißt ja nichts.
Alexander schrieb: > was bedeutet R und R/W? klingt für mich nach read/write. was du machst > ist W schreiben oder? > > Terminierung mal gemessen? Wieviel Ohm? Soweit ich mich erinnere ist da > ein 500 Ohm Widerstand auf dem Modul verbaut. Also Wiederstand ist 120 Ohm zwischen CanH und CanL
also wenn Du sicher bist Du sendest mit 250 kbps und 29-bit und Du hast die Kabel nicht vertauscht, dann bleibt nur der Griff zum Oszilloskop.
Angehängte Dateien:
-
20230817_152911.jpg
190 KB
Alexander schrieb: > also wenn Du sicher bist Du sendest mit 250 kbps und 29-bit und Du hast > die Kabel nicht vertauscht, dann bleibt nur der Griff zum Oszilloskop. Alternativ, wie gesagt, ein Logikanalysator am RX-Pin des Transceivers, in diesem Fall am TJA1050. LG, Sebastian
oder gleich direkt an den ESP32 anschließen ohne SPI
Ich schreibe jetzt direkt ein Programm über Arduino. Danach berichte ich nochmals. Ich hoffe das klappt besser.
Nimm doch erstmal die fertige SPI Bibliothek <mcp2515.h> direkt alles selbst schreiben kannst du ja immer noch.
Hallo, ich probiere jetzt erst Mal MCP-CAN https://github.com/coryjfowler/MCP_CAN_lib Nur mit der Pinbelegung muss ich noch rumspielen, da ich einen NodeMCU ESP32 verwende.
Hi there,
I've struggled for the past few days with similar issue. I was using
mcp_can library and after checking that all the registries were setup
correctly and all my hardware was fine and and and....checking
everything!
I then realised with the help of meanwell support that in CANbus you
have to swtich the LSB with MSB!
When you send the command, let's say for IOUT_SET (0x0030), you have to
send it with the two bytes in the opposite order, like so:
byte data[] = {0x30, 0x00};
Hope this helps someone as I was banging my head for a long time!
Hallo, mittlerweile habe ich das Problem gelöst. Es war ein Wahnsinns weg um am Schluss doch festzustellen, das am Anfang alles richtig war!!! Hier die Lösung. Der ESP32 funktioniert super mit dem MCP2515. Hierzu nutze ich ESPHome in meinem Homeassistant. Wie in dem letzten Post schon steht, muss das LowBIT als 1. abgefragt werden. Das habe ich aber schon in einem Post von einer anderen Seite gelesen. Ich habe mir mit einem Arduino UNO ein CanHack Board gebastelt. Darüber konnte ich mittels der Software CanHacker Befehle zum Ladegerät senden und auch visualisieren. Komischerweise funktionierte das. Nur über ESP32 eben nicht. Dann hatte ich die Idee mal statt extendet-ID eine normale ID zu senden. Und siehe da. es funktionierte. Um das ganze kurz zu machen, habe ich zum Schluss dem MCP2515 getauscht und musste feststellen, das er das Problem war. Mit einem anderen funktioniert alles perfekt. Falls jemand Interesse hat, helfe ich gerne, da ich hier echt am verzweifeln war. Gruß Udo
Hallo Udo, ich habe mir ebenfalls ein Meanwell NPB-1700-24 bestellt. Ich würde dieses ebenfalls gerne mit Home Assistent oder IP-Symcon nutzen bzw. regeln. Da Canbus für mich komplett neu ist, wollte ich mich schon mal etwas einarbeiten. Gibt es irgendwo eine Anleitung von Dir wie Du das mit ESP Home gemacht hast? Gruß Giuseppe
Hallo Giuseppe, ich kann dir da gerne helfen. Anleitung ist in meinem Kopf. Allerdings nur mit homeassistant. Es gibt auch noch einiges das du über die CAN Steuerung wissen musst. Das Ladegerät muss eingestellt werden. Wie weit bist du. Gruß Udo
Hallo Udo, Danke für die schnelle Antwort. Aktueller Stand ist Ladegerät bestellt, Lieferung wird aber leider noch dauern. Wie geschrieben wollte ich aber schon mal alles vorbereiten und mich in Canbus etwas einarbeiten. Ich habe mehrere ESP32 und Arduinos da und habe auch schon das ein oder andere mit ESP Home gemacht. Von den MCP2515 habe ich einen 3-Pack hier und einen Waveshare USB to Can habe ich ebenfalls bestellt, dürfte Morgen eintreffen. Homeassistant ist vollkommen ok für mich, wichtig ist, dass ich mal einen Startpunkt habe. Eine Beispiel ESP Home Yaml wäre z.B. ganz cool dann könnte ich mir die genauer ansehen und versuchen zu verstehen. Gruß Giuseppe
Hallo, du benötigst auf jeden Fall die CAN Anleitung vom Ladegerät. Ich habe einen ESP32 mit MCP2515. Und das funktioniert. Hier mal ein kleiner Teil meiner Config.
1 | spi:
|
2 | id: McpSpi |
3 | clk_pin: GPIO18 |
4 | mosi_pin: GPIO23 |
5 | miso_pin: GPIO19 |
6 | |
7 | time: |
8 | - platform: homeassistant |
9 | on_time: |
10 | seconds: /5 |
11 | then: |
12 | - canbus.send: |
13 | canbus_id: my_mcp2515 |
14 | use_extended_id: True |
15 | data: [0x30, 0x00] |
16 | can_id: 0x000C0103 |
17 | - lambda: |- |
18 | ESP_LOGD("CAN Strom abfragen","",""); |
19 | - delay: |
20 | milliseconds: 100 |
21 | |
22 | canbus: |
23 | - platform: mcp2515 |
24 | id: my_mcp2515 |
25 | spi_id: McpSpi |
26 | cs_pin: GPIO5 |
27 | clock: 8MHZ |
28 | bit_rate: 250KBPS |
29 | |
30 | on_frame: |
31 | - can_id: 0x000C0003 |
32 | #can_id_mask: 0x1fffffff
|
33 | use_extended_id: true |
34 | then: |
35 | - lambda: |- |
36 | if(x[0]==0x88 and x[1]==0x00) { |
37 | int seriennummer =int((x[2]) & (x[3])); |
38 | int wert2 =int(x[2]); |
39 | int wert3 =int(x[3]); |
40 | ESP_LOGD("main", "Antwort von 00 Hex: %x %x ", wert2, wert3); |
41 | }
|
42 | - lambda: |- |
43 | if(x[0]==0xC1 and x[1]==0x00) { |
44 | int systemstatus =float(float((int((x[2])+( (x[3])<<8))))/100); |
45 | |
46 | ESP_LOGD("main", "Der SYSTEM_SATUS ist %f", systemstatus); |
47 | }
|
48 | - lambda: |- |
49 | if(x[0]==0x30 and x[1]==0x00) { |
50 | float leistung =float(float((int((x[2])+( (x[3])<<8))))/100); |
51 | id(ladestrom_ampere).publish_state(leistung); |
52 | ESP_LOGD("main", "Der Ladestrom ist %f", leistung); |
53 | }
|
Hallo Udo, Danke, werde es am Wochenende mal testen. Manual vom Netzteil mit den Canbus Adressen/Befehlen usw. habe ich mir schon heruntergeladen. Werde mir mal einen Testaufbau mit zwei Canbus ESP32 erstellen und die ersten versuche starten. Falls ich irgendwo hänge, melde ich mich wieder. Gruß Giuseppe
Hallo Udo, habe nun die ersten Tests gemacht. Mit zwei ESP32 und Canbus Transceiver SN65HVD230. Senden und empfangen klappt schon mal. Ich habe mir auch Deinen Codeschnipsel oben angesehen und die Bedienungsanleitung vom Netzteil. In Deinem Beispiel oben ist das Auslesen des Ladestroms drin.
1 | time: |
2 | - platform: homeassistant |
3 | on_time: |
4 | seconds: /5 |
5 | then: |
6 | - canbus.send: |
7 | canbus_id: my_mcp2515 |
8 | use_extended_id: True |
9 | data: [0x30, 0x00] |
10 | can_id: 0x000C0103 |
11 | - lambda: |- |
12 | ESP_LOGD("CAN Strom abfragen","","");
|
13 | - delay: |
14 | milliseconds: 100 |
Könntest Du mir noch den Codeschnipsel senden wie man den Ladestromwert setzt? Reicht es wenn einfach bei data an die 0x30 der gewünschte Wert angehängt wird?
Hallo Giuseppe, ich habe den Ladestrom über einen Schieberegler gelöst. Dadurch kann ich den Ladestrom je na übrigen Sonnenstrom automatisch ändern. hier mal der Code:
1 | number:
|
2 | - platform: template |
3 | optimistic: True |
4 | max_value: 50 |
5 | min_value: 10 |
6 | step: 1 |
7 | id: "ladestrom" |
8 | name: "Ladestrom" |
9 | on_value: |
10 | then: |
11 | - if: |
12 | condition: |
13 | lambda: |- |
14 | return (id(ladestrom).state == 10); |
15 | then: |
16 | - lambda: |- |
17 | ESP_LOGD("10 Ampere","id(ladestrom).state", int(id(ladestrom).state)); |
18 | uint32_t can_id = 0x000C0103; |
19 | bool use_extended_id = 1; |
20 | std::vector< uint8_t > data{ 0x30, 0x00, 0xE8, 0x03 }; |
21 | id(my_mcp2515)->send_data(can_id, use_extended_id, data); |
22 | - if: |
23 | condition: |
24 | lambda: |- |
25 | return (id(ladestrom).state == 11); |
26 | then: |
27 | - lambda: |- |
28 | ESP_LOGD("11 Ampere","id(ladestrom).state", int(id(ladestrom).state)); |
29 | uint32_t can_id = 0x000C0103; |
30 | bool use_extended_id = 1; |
31 | std::vector< uint8_t > data{ 0x30, 0x00, 0x4C, 0x04 }; |
32 | id(my_mcp2515)->send_data(can_id, use_extended_id, data); |
Hallo Udo, vielen Dank. Jetzt verstehe ich wie ich die Werte ans Netzteil senden kann. Damit müsste ich es hinbekommen. Ich muss bei mir halt noch den Überschuss, den ich ja AC seitig habe, noch umrechnen für DC Seite und dann möchte ich ebenfalls automatisiert den Akku Ladestrom einstellen. Wenn das Netzteil endlich da ist und ich das ganze in die Praxis umgesetzt habe, gebe ich noch mal Rückmeldung. Gruß Giuseppe
Kurze Zwischeninfo. Netzteil ist leider noch nicht da. Aber ich ich habe schon einiges mit Canbus getestet. Wie ich geschrieben hatte würde ich bevorzugt IP-Symcon (https://www.symcon.de/de/) einsetzen. Deshalb habe ich esp-idf-can2mqtt ausprobiert (https://github.com/nopnop2002/esp-idf-can2mqtt). Damit kann ich Canbus Befehle über das ESP Gateway mit IPS senden und empfangen. Aktuell versuche ich esp-idf-can2mqtt auf einen Olimex EVB Bord zu packen. Dann hätte ich ein Ethernet Gateway mit can2mqtt und mqtt2can. Damit kann ich mein Projekt sicherlich realisieren. Nochmals vielen Dank für die sehr hilfreiche Unterstützung. Wenn das Projekt fertig ist, gebe ich noch mal Rückinfo. Gruß Giuseppe
Hallo, ich brauche wohl doch noch weitere Hilfe. Wie geschrieben, versuche ich can2mqtt auf den Olimex EVB zu flashen. Ich bin auch soweit gekommen, dass es tatsächlich läuft, aber eben nur per WLAN. Ich würde aber gerne LAN nutzen. Deshalb die Frage hier in die Runde, kennt sich hier jemand gut mit der ESP IDF aus und könnte mich in die richtige Richtung führen damit ich den Olimex LAN Treiber in das can2mqtt Projekt einbinden kann? https://github.com/OLIMEX/ESP32-EVB/tree/master/SOFTWARE/ESP-IDF%20examples/ESP32-EVB_Ethernet_v5.1.1
Angehängte Dateien:
Netzteil ist zwischenzeitlich angekommen. Olimex EVB hat per WLAN und MQTT wie erwartet funktioniert. Da ich es aber unbedingt mit LAN realisieren wollte, habe ich mir ein Can to Eth Gateway besorgt. https://www.waveshare.com/wiki/2-CH-CAN-TO-ETH Damit kann ich nun den Ladestrom mit meiner Smarthome Software regeln (siehe Bild).
Hallo zusammen, ich habe heute mein NPB-450 erhalten und wollte es auch bedarfsgerecht steuern. Das Kommando 0x0030 (IOUT_SET) scheint keinen wirklichen Einfluss auf den Ladestrom zu haben. Gesetzt wird es aber wohl richtig, weil ich den gesetzten Wert auch zurücklesen kann. Über 0x00B0 (CURVE_CC) kann ich den Ladestrom steuern (ergibt auch Sinn, solange sich das Ladegerät in der Konstantstromphase befindet), aber hier wird eine neuer Wert erst übernommen, wenn ich den Lader einmal aus- und wieder einschalte. Ist das bei euch genauso? Viele Grüße Philipp
Angehängte Dateien:
Hallo, Worüber ich ganz zu Beginn gestolpert bin ist, dass Netzteil hat von Haus aus Ladekurve eingestellt. Du musst das aber abschalten und auf Manuelle Ladekurve gehen. Bit 7 musst auf 0 stellen, erst dann nimmt er Ladestromänderungen per Canbus an. Die 3 DIP Schalter müssen auf off sein und der Jumper für Remote On/Off sollte dran bleiben. Wenn das BIT 7 auf 0 gestellt hast nicht vergessen das Netzteil Stromlos zu machen und neu zu starten.
Giuseppe M. schrieb: > Hallo, > Worüber ich ganz zu Beginn gestolpert bin ist, dass Netzteil hat von > Haus aus Ladekurve eingestellt. Du musst das aber abschalten und auf > Manuelle Ladekurve gehen. > Bit 7 musst auf 0 stellen, erst dann nimmt er Ladestromänderungen per > Canbus an. > Die 3 DIP Schalter müssen auf off sein und der Jumper für Remote On/Off > sollte dran bleiben. > Wenn das BIT 7 auf 0 gestellt hast nicht vergessen das Netzteil Stromlos > zu machen und neu zu starten. Vielen Dank, darüber bin ich jetzt auch zufällig gestolpert :) Was auch viel gebracht hat, war das aktuelle Datenblatt online anzuschauen. Dort sind viele Dinge erklärt, die in dem Manual, welches beim Netzteil dabei war gar nicht erwähnt sind (z.B. was sofort umgesetzt wird und was erst beim aus- und einschalten). Leider kann mein Netzteil das Schreiben ins EEPROM noch nicht abschalten. Kennt jemand eine Quelle, aus der man ein NPB bekommt, welches schon die neueste Firmware hat? Hat jemand schon versucht den Strom noch kleiner einzustellen, als es eigentlich vorgesehen ist? Der Trucki-Stick, der in vielen Youtube Kanälen angepriesen wird scheint dies zu können. Wenn ich es richtig verstehe, dann wird dazu die Spannung reduziert. Viele Grüße Philipp
Hallo, warum möchtest du das Ladegerät nicht kleiner einstellen? Bei meinem sind es 10A. Das entspricht ca. 200-300W. Was ist die kleinste Stufe bei deinem? Gruß Udo
Udo E. schrieb: > warum möchtest du das Ladegerät nicht kleiner einstellen? > Bei meinem sind es 10A. Das entspricht ca. 200-300W. > > Was ist die kleinste Stufe bei deinem? Ich würde es gerne nahezu von 0A einstellen können. Ich habe aktuell ein 450W 12V Ladegerät. Dieses startet bei 5A. Ich habe nicht das 750W Modell genommen, weil dies bei noch größerem Strom startet (wobei das passender gewesen wäre). Aktuell kann ich zwischen 5A und 25A einstellen. Das entspricht ca. 75W bis 380W. Verwendet hier noch jemand ESPHome um das NFB zu steuern? Ich benutzte einen MCP2515 CAN Controller an einem ESP32 mit ESPHome. (Vielen Dank für den Code, das hat den Einstieg sehr erleichtert, Udo!) Ab und zu lese ich zB bei der Akkuspannung 18V zurück. Hier scheint ab und zu etwas nicht ganz sauber in der Kommunikation zu sein. Viele Grüße Philipp
Hey, You won't be able to set the charging current below the minimum that is stated in the datasheet. I haven't used ESPHome but my code in c++ works well for setting and reading, have no problems with that. You'd have to either hook up a logical analyser or or look into the controller's response somehow else. I guess you sorted out the termination correctly? Keep in mind that NPBs have an internal termination resistor already. Matej
Wenn du noch Hilfe benötigst, melde dich einfach. Ich war lange auf der Suche nach der richtigen Verkabelung usw. Ich nutze das ganze über ESP Home an Homeassistant. Hier noch ein Tipp. Falls du ein BMS verwendest, würde ich das Entladen schon bei unter 5% beenden, da das Ladegerät sonst Macken bezüglich der Erkennung des Akkus macht. Ich schalte das Ladegerät auch nicht aus, sonder nutze die ein/aus Funktion über den CANBus. Gruß Udo
Hallo, hier mal Link in dem ich meine Umsetzung / Regelung genauer beschrieben habe. https://community.symcon.de/t/canbus-ladegeraet-in-symcon-einbinden/136578 Vielleicht hilft es den ein oder anderen weiter. Gruß Giuseppe
Hallo, Matej L. schrieb: > You won't be able to set the charging current below the minimum that is > stated in the datasheet. Kleinere Ströme sind möglich, wenn man VOUT reduziert und diese einfach nur wenige 10mV über die aktuelle Batteriespannung setzt. Udo E. schrieb: > Falls du ein BMS verwendest, würde ich das Entladen schon bei unter 5% > beenden, da das Ladegerät sonst Macken bezüglich der Erkennung des Akkus > macht. Mein BMS hat leider keine Schnittstelle. Ich habe zwei 12V 100Ah Akkus parallel (12V, weil ich dafür schon einiges hatte). Ich würde nun bei 12,0V abschalten, um die Akkus nicht zu weit zu entladen. Laden würde ich am NPB bei 14,0V einstellen. Giuseppe M. schrieb: > https://community.symcon.de/t/canbus-ladegeraet-in-symcon-einbinden/136578 > Vielleicht hilft es den ein oder anderen weiter. Super! Genau sowas habe ich anfangs gesucht und leider nicht gefunden. Viele Grüße Philipp
Ah ok, guess you want to trickle charge? My application is different, as I use the charger to do emergency charging with a backup gasoline generator. Meaning I want to pump as much as safely possible in the shortest period of time.
Hallo zusammen, ich hoffe, dass in diesem Thread noch was los ist. @grisu74 ich versuche es im Moment eigentlich, glaube ich, fast genau wie du. Ich habe ein NPB-750-24 und versuche dieses anzusteuern mit einem dieser China-Boards mit MCP2515/TJA1050 an einem ESP32(S3). Dass mir der Transceiver allein auch gereicht hätte und der ESP CAN bzw. TWAI anbietet, habe ich erst danach mitbekommen, aber seis drum, jetzt versuche ich das eben über SPI. Und (noch) ohne Level Shifter, sondern mit 4,7kOhm an MISO. Allerdings gehen mir langsam die Ideen aus. Da du aber geschrieben hast, du hattest auch einige Versuche nötig mit der Verkabelung, versuche ichs mal und hoffe auf den entscheidenden Tipp, um um den Level Shifter/extra umsteigen auf Transceiver + wieder andere Implementierung mit ESP-CAN rumzukommen und einfach das vorhandene MCP2515 Modul zu verwenden. - CANH und CANL sind mit dem MCP verbunden, GND (Signal, Pin 4 am NT) mit dem ESP. - Der MCP am ESP mit CS (GPIO10), MOSI (GPIO11), SCK (GPIO12), MISO (GPIO13), sowie VCC an 5VBUS und natürlich GND. - ESPHome wirft keine Fehler bei der CAN/SPI Initialisierung, außer wenn ich was an der Verkabelung (zum falschen) ändere, also da gehe ich aktuell mal vom richtigen aus und dass sich was mit den Pins in die Quere kommt, 10-13 sollte auch safe sein - Pins 7 und 8 am NT sind gebrückt, die DIPs alle auf off (und waren nie anders). Beim aus- und wieder einstecken des Steckers schaltet das NT auch kurz in den Charging Modus, mangels Akku aber gleich wieder aus - aber den brauchtest du ja auch nicht zum Testen, richtig? - Sender ID 0x000C0103, Receiving ID 0x000C0003, 8MHz Clock und 250 kbps in ESPHome gecheckt (A0 und A1 sind unverbunden, also high laut Manual) - ich habe alle möglichen Nachrichten schon implementiert, aber erstmal würde mir eine einfache Antwort auf 0x0000 (OPERATION) schon reichen, das sollte ja klappen auch ohhne Bit 7 der CURVE_CONFIG auf 0 gesetzt zu haben. Du hattest geschrieben, du hast den MCP2515 letztlich tauschen müssen, von welchem zu welchem bist du da gegangen, oder hattest du zwei gleiche von denen einfach einer blöd war? Vielen Dank im Voraus! Gruß Fabian
Hallo. Ich hatte 2 MCP2515. Einer war anscheinend defekt. Oder es lag an meinem Versuchsaufbau. Seitdem ist alles perfekt. Gruß Udo
Hallo, ach danke für die schnelle Antwort. Okay, ich habe auch zwei und der zweite macht die selben Faxen, bzw. halt gar nichts. Mir fällt auf, dass die Spannung an CANH und CANL nahezu identisch sind. Das kommt mir merkwürdig vor. Ich bin jetzt auch bald kurz davor alles einfach fest zu verlöten.. Davor prüfe ich noch die selbe Pinbelegung wie bei dir. Das GND(Signal) am NT hast du einfach vom ESP genommen oder kommt das bei dir auch von der MCP-Platine? Hast du den INT-Pin vom MCP belegt/angesteuert?
Fabian B. schrieb: > Hallo, ach danke für die schnelle Antwort. Okay, ich habe auch zwei und > der zweite macht die selben Faxen, bzw. halt gar nichts. Mir fällt auf, > dass die Spannung an CANH und CANL nahezu identisch sind. Das kommt mir > merkwürdig vor. > Ich bin jetzt auch bald kurz davor alles einfach fest zu verlöten.. > Davor prüfe ich noch die selbe Pinbelegung wie bei dir. > > Das GND(Signal) am NT hast du einfach vom ESP genommen oder kommt das > bei dir auch von der MCP-Platine? > Hast du den INT-Pin vom MCP belegt/angesteuert? Hallo, CAN H und L müssen gleiche Spannung haben. GND ist sozusagen in der Mitte. Das Ladegerät hast du richtig eingestellt? Die Dipschalter und die Brücke? Genaueres müsste ich erst noch nachsehen. Mein ESP läuft noch mit Probeverkabelung. Ich würde die Kabel nochmals prüfen. Ich schicke dir meine Belegung. Dauert allerdings ein wenig. Nicht aufgeben. Gruß Udo
Hi, Udo hmm ok. Den MCP hast du aber schon auch an +5V oder? Das Board soll ja angeblich 5V benötigen, der MCP scheint sich an und für sich aber auch mit 3,3V zu begnügen. Dann wäre das Logic Level gleich erledigt... oder benötigt das NPB explizit einen 5V Pegel? Da find ich jetzt nichts dazu... Das Ladegerät würde ich als richtig eingestellt bezeichnen, immer und immer wieder hab ich die Pins geprüft. - die 3 DIPs sind auf links wie im Originalzustand (off). - Pin 7 und 8 sind gebrückt also Remote ON ist short - CANL an 12 und CANH an 11, GND vom ESP an Pin 4... Der Rest ist frei. Ich dank dir ganz herzlich schonmal im Voraus und keine Eile, aufgegeben wird nicht bis es sich beugt :D Ich bin gespannt auf deine Verkabelung.
Fabian B. schrieb: > Hi, Udo hmm ok. Den MCP hast du aber schon auch an +5V oder? Das Board > soll ja angeblich 5V benötigen, der MCP scheint sich an und für sich > aber auch mit 3,3V zu begnügen. Dann wäre das Logic Level gleich > erledigt... oder benötigt das NPB explizit einen 5V Pegel? Da find ich > jetzt nichts dazu... > > Das Ladegerät würde ich als richtig eingestellt bezeichnen, immer und > immer wieder hab ich die Pins geprüft. > - die 3 DIPs sind auf links wie im Originalzustand (off). > - Pin 7 und 8 sind gebrückt also Remote ON ist short > - CANL an 12 und CANH an 11, GND vom ESP an Pin 4... Der Rest ist frei. > > Ich dank dir ganz herzlich schonmal im Voraus und keine Eile, aufgegeben > wird nicht bis es sich beugt :D Ich bin gespannt auf deine Verkabelung. GND nicht anschließen. Nur CAN H und L Es gibt kein GND bei CAN
Fabian B. schrieb: > CANH und CANL sind mit dem MCP verbunden Ich hoffe doch mit dem TJA-Transceiver... Eine GND-Verbindung braucht man bei CAN normalerweise nicht. > Den MCP hast du aber schon auch an +5V oder? Das Board > soll ja angeblich 5V benötigen, der MCP scheint sich an und für sich > aber auch mit 3,3V zu begnügen. Der MCP2515 würde auch mit 3,3V funktionieren, aber der TJA-Transceiver braucht 5V. Deshalb betreibt man die China-CAN-Boards mit 5V. Den MOSI vom ESP kann man bei 3,3V direkt an den MCP2515 klemmen. Der MCP erkennt die 3,3V als High-Pegel. Den MISO vom MCP zum ESP, also von 5V Ausgang auf 3.3V Eingang spendiert man einen Widerstand in Reihe, 4k/ wie du hast passt auch. INT schliesst man an wenn man CAN-Botschaften interruptgesteuert empfangen will.
Danke euch.. - GND hatte ich zuerst auch gar nicht dran, dann damit versucht, jetzt wieder weg, leider immer noch ohne Erfolg - MCP bleibt dann wie er ist auf 5V mit dem 4,7k an MISO - INT ist und bleibt unverbunden.. - beide MCP Module machen ähnlich wenig - ich habe sogar den 5V auf 3,3V LDO vom ESP aufgemotzt, um hier einen eventuellen Spannungsabfall/-engpass auszuschließen, wobei der ESP32 mit sonst gar nichts außer einem SPI doch wohl nicht exorbitant Strom ziehen sollte - ein zweites NPB werde ich noch ausprobieren ich ziehe langsam in Betracht, dass ich wohl vielleicht einfach zwei Mist-MCPs bekommen habe. Aber noch glaub ich nicht ganz dran :D
Fabian B. schrieb: > Danke euch.. > - GND hatte ich zuerst auch gar nicht dran, dann damit versucht, jetzt > wieder weg, leider immer noch ohne Erfolg > - MCP bleibt dann wie er ist auf 5V mit dem 4,7k an MISO > - INT ist und bleibt unverbunden.. > - beide MCP Module machen ähnlich wenig > - ich habe sogar den 5V auf 3,3V LDO vom ESP aufgemotzt, um hier einen > eventuellen Spannungsabfall/-engpass auszuschließen, wobei der ESP32 mit > sonst gar nichts außer einem SPI doch wohl nicht exorbitant Strom ziehen > sollte > - ein zweites NPB werde ich noch ausprobieren > > ich ziehe langsam in Betracht, dass ich wohl vielleicht einfach zwei > Mist-MCPs bekommen habe. Aber noch glaub ich nicht ganz dran :D Ich mach morgen mal ein Bild von meinem Aufbau. Dann kannst du genau vergleichen. Die Befehle stimmen auch? Gruß Udo
Udo E. schrieb: > GND nicht anschließen. > Nur CAN H und L > Es gibt kein GND bei CAN was erzählt ihr denn da, natürlich gibt es GND über gemeinsame Masse
das mit der Masse muss wohl noch geklärt werden, ich habe dann auch nachgelesen dass es eigentlich ein 3-Wire Aufbau sein sollte, aber gut, wenn es bei Udo ohne GND geht.. hm bei den Nachrichten sehe ich keinen Fehler. für OPERATION habe ich bspw. folgenden Template-Button
1 | button: |
2 | - platform: template |
3 | id: get_operation_status |
4 | name: Get operation status |
5 | on_press: |
6 | - canbus.send: |
7 | canbus_id: can_mcp2515 |
8 | data: [0x00, 0x00] |
9 | - lambda: |- |
10 | ESP_LOGD("main", "CAN get OPERATION (0x0000)", "");
|
ich glaube da kann nicht viel falsch laufen, da ich ja einfach nur 0x0000 sende.. wobei canbus wie folgt definiert ist:
1 | spi: |
2 | id: mcp2515_spi |
3 | clk_pin: GPIO12 |
4 | mosi_pin: GPIO11 |
5 | miso_pin: GPIO13 |
6 | canbus: |
7 | - platform: mcp2515 |
8 | id: can_mcp2515 |
9 | spi_id: mcp2515_spi |
10 | cs_pin: GPIO10 |
11 | can_id: 0x000C01FF |
12 | use_extended_id: true |
13 | clock: 8MHZ |
14 | bit_rate: 250KBPS |
15 | on_frame: |
16 | - can_id: 0x000C0003 |
17 | can_id_mask: 0x1fffff00 |
18 | use_extended_id: true |
19 | then: |
20 | - lambda: |- |
21 | std::string b(x.begin(), x.end()); |
22 | ESP_LOGD("main", "Received: %s", &b[0]);
|
die can id habe ich gerade zwischenzeitlich auch mal in 0x000C01FF geändert statt 03, als Controller to Charger Broadcast wie im Manual angegeben. Andert auch nix. Dann noch die can_id_mask dazu genommen beim on_frame, um die letzten 2 Stellen zu ignorieren. Auch ohne Erfolg. Wenn ich ein bisschen an den Kabeln rüttel, meldet der ESP sofort einige angebliche Nachrichten, also irgendwas tut es ja... Mal nochmal zur Sicherheit: Pins 7 und 8 müssen SHORT sein am Netzteil, richtig?
Udo E. schrieb: > GND nicht anschließen. > Nur CAN H und L > Es gibt kein GND bei CAN Wenn man sich den Transceiver zerschießen will, nur zu. Natürlich benötigen CAN H und CAN L ein Bezugspotential.
GND macht hier keinen Sinn, da kein gemeinsames Potential. Den Wiederstand 120Ohm hast du gebrückt? Gruß Udo
guten Morgen! den 120er auf dem MCP muss man brücken? ne, das wusste ich noch nicht.. wird getestet. bin gestern noch mit Flussmittel über ESP und MCP drüber um eventuelle kalte Lötstellen o.ä. zu eliminieren, leider war offenbar bereits alles gut.. ein Wechsel auf ESP8266 stünde heute noch an.
Hallo bei mir sieht das funktionierende Setup so aus:
canbus:
- platform: mcp2515
id: my_mcp2515
spi_id: McpSpi
cs_pin: GPIO27
bit_rate: 250KBPS
can_id: 123
on_frame:
- can_id: 0x000C0003
#can_id_mask: 0x1fffffff
use_extended_id: true
then:
- lambda: |-
if(x[0]==0x30 and x[1]==0x00) {
float leistung =float(float((int((x[2])+( (x[3])<<8))))/100);
ESP_LOGD("main", "Der Ladestrom ist %f", leistung);
}
ich habe die Mask auskommentiert und einfach in den Lambdas nach der
Nachricht geschaut (ist nicht nur das hier reinkopierte)
Viele Grüße
Philipp
Thomas F. schrieb: > Ich hoffe doch mit dem TJA-Transceiver... > Eine GND-Verbindung braucht man bei CAN normalerweise nicht. Die braucht man genau dann nicht, wenn alle Steuergeräte die gleiche Masse haben. So ist das im Auto. Am Labortisch liegt der eine Teilnehmer über den USB auf Schutzleiter-Potential, und der andere über die Masseklemme des Oszis. Das tut es auch, zumindest wenn PC und Oszi an der selben Steckdosenleiste hängen. Falls sich in der Firma IT-Strom und Versorgung des Labortisches erst im Keller treffen, können die beiden Schutzleiter auch mal 10 V auseinander sein. Dann funktioniert es ein paar Tage und plötzlich wird der Controller heiss. Daher besser die Masse mitführen. Das Signal bei CAN ist U_CAN = (U_CANH - U_GND) - (U_CANL - U_GND). Mathematisch gesehen kürzt sich U_GND raus. Physikalisch gesehen werden aber beide Spannungen gegen Masse gemessen.
also den 120 Ohm Widerstand auf dem MCP zu brücken hat auch nichts geändert. GND nun doch mal an Pin 4 hinzufügen? schadet ja nicht? @e61_phil danke, sieht bei mir ja quasi genauso aus. Udo hat die Vorlage ja dankenswerterweise schon gepostet, daran habe ich mich auch orientiert. Danke an alle Kommentatoren.
Also, GND wieder an Pin 4, keine Änderung, auch mit dem ESP8266 (GPIOs 12-15) kommt nix an, jetzt würde ich noch einen anderen ESP32 ausprobieren oder gleich einen 74HCT125 Level Shifter dazwischen hängen...
Angehängte Dateien:
-
PXL_20240723_141006071.jpg
240 KB -
PXL_20240723_140933362.jpg
230 KB -
PXL_20240723_140823704.jpg
220 KB -
PXL_20240723_140806437.MP.jpg
230 KB -
PXL_20240723_140722562.MP.jpg
240 KB
Hallo, anbei mein Aufbau. Gruß Udo
Angehängte Dateien:
Hier noch eine Idee. Ich sende an die 103!! Bitte nochmal prüfen.
danke an alle und besonders dich Udo für deine Mühe. Achtung, jetzt wird's peinlich. Ich habe falsch verstanden, was du meintest mit den Widerstand brücken... Wenn man den Jumper (J1) setzt, dann geht's auch. Mir war nicht klar, dass der Widerstand sonst vom Bus getrennt ist. Heilige Sch... Ich hoffe, das wird wenigstens zukünftigen Lesern einige blöde Fehlersucherei ersparen! Danke nochmal! Zusätzlich, um auch was sinnvolles beizutragen, würde ich gerne noch teilen, wie ich meine SET_IOUT Funktion umgesetzt habe - nämlich mit einer Template Number als Ziel-Stromvorgabe. Sieht aus wie folgt:
1 | number: |
2 | - platform: template |
3 | optimistic: yes |
4 | max_value: 22.5 |
5 | min_value: 4.5 |
6 | step: 0.1 |
7 | id: target_current |
8 | name: Target charging current |
9 | set_action: |
10 | - delay: |
11 | milliseconds: 100 |
12 | - button.press: set_current |
13 | |
14 | button: |
15 | - platform: template |
16 | id: set_current |
17 | name: Set charging current |
18 | on_press: |
19 | then: |
20 | if: |
21 | condition: |
22 | lambda: |- |
23 | return (id(target_current).state); |
24 | then: |
25 | - lambda: |- |
26 | uint32_t can_id = 0x00C0103; |
27 | bool use_extended_id = 1; |
28 | float x = float(id(target_current).state); |
29 | uint16_t current = x*100; |
30 | ESP_LOGD("main", "Target current is %f, must become %d then %02x", x, current, current);
|
31 | uint8_t hex1 = current >> 8; |
32 | uint8_t hex0 = current | hex1; |
33 | std::vector<uint8_t> data{0x30, 0x00, hex1, hex0};
|
34 | ESP_LOGD("main", "CAN set IOUT_SET (0x0030) to %f (%02x %02x)", x, hex1, hex0);
|
35 | float curr = float(float((int((hex0) + ((hex1) << 8)))) / 100); |
36 | ESP_LOGD("main", "Charging current set to %f Amps", curr);
|
37 | id(can_mcp2515)->send_data(can_id, use_extended_id, data); |
38 | - delay: |
39 | milliseconds: 100 |
40 | else: |
41 | - lambda: |- |
42 | ESP_LOGD("main", "Target current is invalid, skip", "");
|
43 | - platform: template |
44 | id: bit7_disable |
45 | name: Switch to PSU mode |
46 | on_press: |
47 | - canbus.send: |
48 | canbus_id: can_mcp2515 |
49 | data: [0xB4, 0x00, 0x04, 0x00] |
50 | - lambda: |- |
51 | ESP_LOGD("main", "CAN set CURVE_CONFIG (0x00B4) Bit 7 = 0 (0x0004), please power cycle NPB afterwards", "");
|
52 | - platform: template |
53 | id: bit7_enable |
54 | name: Switch to Charger mode |
55 | on_press: |
56 | - canbus.send: |
57 | canbus_id: can_mcp2515 |
58 | data: [0xB4, 0x00, 0x84, 0x00] |
59 | - lambda: |- |
60 | ESP_LOGD("main", "CAN set CURVE_CONFIG (0x00B4) Bit 7 = 1 (0x0084), please power cycle NPB afterwards", "");
|
In meinem Fall (NPB-750-24) kann ich laut Manual zwischen 4,5 und 22,5 A einstellen, entsprechend habe ich die Template Number begrenzt. Bei Änderung wird automatisch der Template Button gedrückt, der dann das Kommando absetzt und den Wert der Number in Hex übersetzt. Vielleicht kanns ja jemand gebrauchen. Dazu habe ich zwei Template Buttons für den CURVE_CONFIG Bit7 Toggle eingebaut. Habe noch mehr Spielereien eingebaut... bei Fragen gerne fragen.
Da braucht dir nichts peinlich zu sein. Bei mir war es auch nur eine Kleinigkeit. Gruß Udo
Vielen Dank euch hier für das Teilen, dieser Thread hat mir damals auch
geholfen.
Den Strom stelle ich bei mir direkt über eine Number ohne extra Button:
number:
- platform: template
name: "Charge Current"
unit_of_measurement: "A"
optimistic: true
min_value: 5
max_value: 25
step: 0.01
mode: box
id: iout_set
on_value:
then:
- lambda: |-
int setpoint = id(iout_set).state * 100;
byte a = setpoint;
byte b = setpoint >> 8;
uint32_t can_id = 0x000C0103;
bool use_extended_id = 1;
std::vector< uint8_t > data{ 0x30, 0x00, a, b };
id(my_mcp2515)->send_data(can_id, use_extended_id, data);
PS: Mein Lader kann 5-25A
Wie oft setzt ihr bei euch den Strom um das EEPROM nicht zu schnell zu
zerstören?
EEPROM Zerstören?? Ich setze sekündlich den Ladestrom rauf oder runter. In 1 A Schritten, da ich ja die überschüssige Sonnenenergie nutzen möchte. Gruß Udo
Die Konfiguration wird wohl bei jedem Setzen im EEPROM abgelegt. Bei neuerer Firmware kann man das auch über CAN abschalten. Mein Lader kann das leider noch nicht. Ich meine im Handbuch steht irgendwo etwas von 4 Millionen Schreibzyklen oder so. Warum in 1A Schritten? Der Lader kann doch auch 0,1A? Noch eine Sache: Es gibt einen Trucki-Stick, der wohl auch unter dem minmalen Ladestrom des Laders gehen kann. Ich denke, dass er das über die Spannungsbegrenzung macht. Ich habe damit mal gespielt und bei so auch Ladeströme unter 5A einstellen können. Nutzt das jemand von euch?
das EEPROM hab ich noch im Blick und die Begrenzung. Hast du da einen kurzen Tipp wie der Befehl wäre? Hab in meinem Manual dazu nichts gefunden aber es mal irgendwo gelesen. Gleiches gilt für die Spannungsbegrenzung. Das wollte ich mir auch noch ansehen, jedoch noch nichts weiter. Mein Akku ist auch noch gar nicht da. Also wenn ich mit SET_VOUT etwas runtergehe nimmt SET_IOUT auch geringere Werte entgegen? Sind auf jeden Fall zwei Dinge die ich noch umsetzen will. PS: Code kannst du hier auch einfach in [ code ] Tags setzen für die Formatierung. Danke fürs Teilen!
Philipp C. schrieb: > Wie oft setzt ihr bei euch den Strom um das EEPROM nicht zu schnell zu > zerstören? Ich habe nicht den ganzen Thread durchgelesen aber ... Man muss ja nicht immer in die gleiche Speicherstelle schreiben. Es gibt Techniken (Software) die das über den gesamten Speicher verteilt und ihn erst löscht wenn er voll ist. So kann die Lebensdauer vervielfacht werden.
Obelix X. schrieb: > Ich habe nicht den ganzen Thread durchgelesen aber ... > > Man muss ja nicht immer in die gleiche Speicherstelle schreiben. Es gibt > Techniken (Software) die das über den gesamten Speicher verteilt und ihn > erst löscht wenn er voll ist. So kann die Lebensdauer vervielfacht > werden. Machen Sie vermutlich auch, um auf die genannten 4 Million zu kommen. Wenn man 1x pro Sekunde schreibt sind das nur 4 Millionen Sekunden. Gehen wir mal davon aus, dass man maximal 10h am Tag diese Regelung laufen hat, dann macht das 4e6s / (10 * 3600) = 111 Tage Damit wäre das Teil wohl nach einem Jahr hin. https://www.meanwell.com/Upload/PDF/NPB,NPP-E.pdf in dem Manual auf S. 6 SYSTEM_CONFIG und dann Bit 10 EEP_OFF "Bit 10 EEP_OFF: Disable to write voltage and current parameters to EEPROM 0= Write the voltage and current parameters into EEPROM in real time （Default） 1= Disable to write the voltage and current parameters into EEPROM in real time Please refer to Chapter 6.4.4 for details." Leider kann meiner das noch nicht. Es taucht in meinem Handbuch auch nicht auf. Ich habe es trotzdem mal probiert, aber leider geht es wirklich nicht. In 6.4.4. steht dann: "Description of EEP_OFF: 1. When the EEP_OFF, the bit 10 of the high byte of SYSTEM_CONFIG is 0 ( default) : These seven commands 0xB0 to B3, 0xB9, 0x20, and 0x30 are written into EEPROM in real time. 2. When the EEP_OFF, the bit 10 of the high byte of SYSTEM_CONFIG is 1: These seven commands: 0xB0 to B3, 0xB9, 0x20, and 0x30 cannot write into EEPROM." Die Anzahl der Zyklen habe ich auf die schnelle nicht gefunden Zum Laden bei kleinerem Strom: Nein, einfach die Spannung reduzieren gibt einem keinen weiteren Einstellbereich beim Strom, aber bei entsprechend kleiner Spannnung fließt einfach weniger Strom und den liefert das Ladegerät bis zu gewissen Grenzen dann auch, auch wenn der unter dem einstellbaren Minimum liegt.
danke, ich habe noch zwei "buttons" eingefügt zum EEPROM bit setzen in der SYSTEM_CONFIG:
1 | - platform: template |
2 | id: mw_eeprom_enable |
3 | name: "${mw_name} enable writing to EEPROM (0x00C2)"
|
4 | on_press: |
5 | - canbus.send: |
6 | canbus_id: can_mcp2515 |
7 | data: [0xC2, 0x00, 0x03, 0x00] |
8 | - lambda: |- |
9 | ESP_LOGD("${mw_name}", "CAN set SYSTEM_CONFIG (0x00C2) Bit 10 = 0 (0x0003), please power cycle NPB afterwards", "");
|
10 | - platform: template |
11 | id: mw_eeprom_disable |
12 | name: "${mw_name} disable writing to EEPROM (0x00C2)"
|
13 | on_press: |
14 | - canbus.send: |
15 | canbus_id: can_mcp2515 |
16 | data: [0xC2, 0x00, 0x03, 0x04] |
17 | - lambda: |- |
18 | ESP_LOGD("${mw_name}", "CAN set SYSTEM_CONFIG (0x00C2) Bit 10 = 1 (0x0403), please power cycle NPB afterwards", "");
|
scheint bei meinem zu klappen, jedenfalls gibt SYSTEM_CONFIG nachher den geänderten Output zurück. Bei dir bleibt er einfach bei high byte = 0?
Fabian B. schrieb: > Bei dir bleibt er einfach bei high byte = 0? Ja, leider schon. Ich teste heute Abend deinen Code aber noch einmal. Aktuell habe ich ein 12V System mit 400Ah LFP (4x 100Ah) daran einen NPB 480-12. Ich würde gerne auf den NPB 1700-12 gehen, aber natürlich ungern einen für 400EUR bestellen um dann zu merken, dass der das auch nicht abschalten kann. Womit macht ihr die Einspeisung? Und welche Akkuspannung nutzt ihr? Ggf. wäre ein Umbau bei mir ohnehin sinnvoll. Viele Grüße Philipp
Ah Mist.. okay.. ärgerlich. Ich habe das Netzteil direkt aus China geordert und die Sache war mir gar nicht bewusst, hatte jetzt einfach Glück. Das Herstellungsdatum habe ich ausgelesen, 27.05.2024. Ich habe geplant auf 8x 100Ah LiFePo zu gehen. Warte aber aktuell noch auf die Lieferung, hängt wohl im Zoll. Entsprechend habe ich ein NPB-750-24 und einen SoyoSource GTN-1000W-24. Abgerundet wird's von einem JK B2A8S20P BMS. Den WR versuche ich jetzt auch noch anzusprechen über RS485, soll beides der selbe ESP32S3 übernehmen. Mach das alles aber auch zum ersten Mal, entsprechend kann ich leider gar keine Aussagen treffen, vor allem Mangels Akku noch, alles nach bestem Wissen nach Recherche zusammengetragen :D Welchen WR und BMS hast du?
Hallo, Ich habe das NPB 1700-24. Hier finde ich nichts über EEP_OFF Gruß
Udo E. schrieb: > Hier finde ich nichts über EEP_OFF du kannst ja mal 0x00C2 senden und schauen was zurückkommt:
1 | - lambda: |- |
2 | if(x[0] == 0xC2 and x[1] == 0x00) {
|
3 | int config = int(x[2] + (x[3] << 8)); |
4 | char buf[7]; |
5 | sprintf(buf, "0x%04X", config); |
6 | id(ts_mw_system_config).publish_state(to_string(buf)); |
7 | ESP_LOGD("${mw_name}", "Got SYSTEM_CONFIG: %i (Hex: %02X %02X)", config, x[3], x[2]);
|
8 | } |
oder die Firmwareversion und Herstellungsdatum abfragen mit 84 bzw. 86:
1 | - lambda: |- |
2 | if(x[0] == 0x84 and x[1] == 0x00) {
|
3 | float fw_rev = float(x[2])/10; |
4 | char buf[5]; |
5 | sprintf(buf, "%.02f", fw_rev); |
6 | id(ts_mw_mfr_revision).publish_state(to_string(buf)); |
7 | ESP_LOGD("${mw_name}", "Got MFR_REVISION_B0B5: %f / (Hex: %02X)", fw_rev, x[2]);
|
8 | } |
9 | - lambda: |- |
10 | if(x[0] == 0x86 and x[1] == 0x00) {
|
11 | std::string mfr_date = ""; |
12 | mfr_date += (char)x[2]; |
13 | mfr_date += (char)x[3]; |
14 | mfr_date += (char)x[4]; |
15 | mfr_date += (char)x[5]; |
16 | mfr_date += (char)x[6]; |
17 | mfr_date += (char)x[7]; |
18 | id(ts_mw_mfr_date).publish_state(mfr_date); |
19 | ESP_LOGD("${mw_name}", "Got MFR_DATE_B0B5: %c%c%c%c%c%c", x[2], x[3], x[4], x[5], x[6], x[7]);
|
20 | } |
Ich habe FW Rev 1.6 und Datum wie gesagt 240527
Philipp C. schrieb: > Zum Laden bei kleinerem Strom: Nein, einfach die Spannung reduzieren > gibt einem keinen weiteren Einstellbereich beim Strom, aber bei > entsprechend kleiner Spannnung fließt einfach weniger Strom und den > liefert das Ladegerät bis zu gewissen Grenzen dann auch, auch wenn der > unter dem einstellbaren Minimum liegt. Ja gut, also mit VOUT runtergehen leuchtet mir ein, aber wie(so) sollte deswegen der Ladestrom auch sinken? Leider kann man IOUT ohne Akku nicht setzen, bzw. READ_IOUT ergibt immer 0, sodass ich da im Moment das effektive Minimum noch nicht herausfinden kann. Bei der Spannung sind es ziemlich genau 21 Volt, die das Netzteil noch zulässt. Allerdings krieg ich damit ja auch keinen 8-Zellen LFP Akku voll.. Irgendwas scheine ich da noch nicht verstanden zu haben, aber eine andere Lösung/Möglichkeit die Ladeleistung zu reduzieren erschließt sich mir auch nicht? Und wirklich weit runter käme man damit ja auch nicht. Ich hatte bei der o.g. Funktion zum Ladestrom setzen übrigens einen Dreher bei hex0/hex1.. Ups. Hier korrekt, mit dem Analogon zur Spannung/VOUT_SET:
1 | - platform: template |
2 | id: mw_set_voltage |
3 | name: "${mw_name} set charging voltage"
|
4 | on_press: |
5 | then: |
6 | if: |
7 | condition: |
8 | lambda: |- |
9 | return (id(mw_target_voltage).state); |
10 | then: |
11 | - lambda: |- |
12 | uint32_t can_id = id(global_can_sender_id); |
13 | bool use_extended_id = 1; |
14 | float x = float(id(mw_target_voltage).state); |
15 | uint16_t voltage = x*100; |
16 | ESP_LOGD("${mw_name}", "Target voltage is %f, must become %d then %02x", x, voltage, voltage);
|
17 | uint8_t hex1 = voltage >> 8; |
18 | uint8_t hex0 = voltage | hex1; |
19 | std::vector<uint8_t> data{0x20, 0x00, hex0, hex1};
|
20 | ESP_LOGD("${mw_name}", "CAN set VOUT_SET (0x0020) to %f (%02x %02x)", x, hex1, hex0);
|
21 | float v = float(float((int((hex0) + ((hex1) << 8)))) / 100); |
22 | ESP_LOGD("${mw_name}", "Charging voltage set to %f V", v);
|
23 | id(can_mcp2515)->send_data(can_id, use_extended_id, data); |
24 | - delay: |
25 | milliseconds: 100 |
26 | else: |
27 | - lambda: |- |
28 | ESP_LOGD("${mw_name}", "Target voltage is invalid, skip", "");
|
29 | - platform: template |
30 | id: mw_set_current |
31 | name: "${mw_name} set charging current"
|
32 | on_press: |
33 | then: |
34 | if: |
35 | condition: |
36 | lambda: |- |
37 | return (id(mw_target_current).state); |
38 | then: |
39 | - lambda: |- |
40 | uint32_t can_id = id(global_can_sender_id); |
41 | bool use_extended_id = 1; |
42 | float x = float(id(mw_target_current).state); |
43 | uint16_t current = x*100; |
44 | ESP_LOGD("${mw_name}", "Target current is %f, must become %d then %02x", x, current, current);
|
45 | uint8_t hex1 = current >> 8; |
46 | uint8_t hex0 = current | hex1; |
47 | std::vector<uint8_t> data{0x30, 0x00, hex0, hex1};
|
48 | ESP_LOGD("${mw_name}", "CAN set IOUT_SET (0x0030) to %f (%02x %02x)", x, hex1, hex0);
|
49 | float curr = float(float((int((hex0) + ((hex1) << 8)))) / 100); |
50 | ESP_LOGD("${mw_name}", "Charging current set to %f Amps", curr);
|
51 | id(can_mcp2515)->send_data(can_id, use_extended_id, data); |
52 | - delay: |
53 | milliseconds: 100 |
54 | else: |
55 | - lambda: |- |
56 | ESP_LOGD("${mw_name}", "Target current is invalid, skip", "");
|
Würde dann noch eine Funktion schreiben, der man einfach die Ladeleistung vorgibt, die dann je nach dem den Strom setzt und ggf. auch noch mit der Spannung runtergeht. Dafür brauchts dann aber erstmal den Akku hier, wie gesagt.
[06:53:10][D][CAN SYSTEM_CONFIG abfragen:090]:
[06:53:10][D][${mw_name}:343]: Got SYSTEM_CONFIG: 2 (Hex: 00 02)
[06:53:11][D][CAN Firmware abfragen:189]:
[06:53:11][D][${mw_name}:325]: Got MFR_REVISION_B0B5: 1.100000 / (Hex:
0B)
[06:53:11][D][CAN HSD abfragen:198]:
[06:53:11][D][${mw_name}:336]: Got MFR_DATE_B0B5: 231128
Kann damit jemand was anfangen?
Gruß Udo
Hallo Udo, dann ist dein Netzteil wohl vom 28.11.23 mit der FW Rev. 1.10 und damit leider zu alt für die EEPROM Funktion :( Trotzdem würde ich einfach mal versuchen, SYSTEM_CONFIG mit 0x0403 zu setzen wie oben geschrieben. NT neustarten und nochmal kucken, was bei der Abfrage von SYSTEM_CONFIG dann raus kommt.
Fabian B. schrieb: > Ja gut, also mit VOUT runtergehen leuchtet mir ein, aber wie(so) sollte > deswegen der Ladestrom auch sinken? Weil Du eine Spannung zwischen der Zelle und dem Ladegerät brauchst, damit Strom fließen kann. Die Spannung musst Du dann natürlich auch nachführen, darum benutze ich das bisher nicht. Zudem fängt es bei mir auch schon bei etwa 70W an. Fabian B. schrieb: > Würde dann noch eine Funktion schreiben, der man einfach die > Ladeleistung vorgibt, die dann je nach dem den Strom setzt Das mache ich in Home Assistant. Ich rechne da einfach aus welchen Strom ich für die gewünschte Leistung setzen muss.
Dear people of this thread, Thanks a million! I also ordered a MeanWell NPB (-1700-48) for my DIY home battery to be steered by CAN-BUS. I'm now gathering all bits and pieces (do not have a actual battery yet). But like the title of this tread, the charger did not listen to commands (it did acknowledge the CAN-BUS messages though). Again just for reference (like Matej L. in a previous contribution): COMMANDS HAVE TO BE SENT WITH SWAPPED LOW AND HIGH BYTES, thus reading from the manual e.g. set system_config (0x00c2), you have to sent 0xc2, 0x00. I know, it is in the manual, but I guess many of us are first time CAN-BUS users. Next, some fields from the charger (e.g. manufacturer date) where messed up (showing 160119, a number that showed up again in the serial number of the charger: 000076 + 160119) I do not know. Firmware shows: 0f 0b ff ff ff ff So, if I divide (like some previous code sample showed) the first byte, firmware is 1.5 (?) Anybody know the purpose of the second byte that has value 0x0b? I could write 0x03, 0x04 to 0xc2, 0x00 and the value of 4 (the famous bit 10) was sustained after power up, indicating it has the disabled EEPROM write function. (again, I do not have a battery yet, so it all has to prove itself). That's all I have to share. Great thread. Happy to help others (using raspberry pi 3B+ (lan), Waveshare 2-CH-CAN-Hat, NPB-1700-48 as charger and OpenDTU together with Hoymiles HMS-500 as inverters) And, oh yeah, the search term for the connector on the MeanWell NPB: JST PHDR-14VS
:
Bearbeitet durch User
Hallo zusammen, da ich noch eine alte Firmware habe und denke, dass der Lader in Zukunft den Geist aufgibt, überlege ich mir gerade einen anderen Lader zu kaufen. Kennt jemand den victron skylla-i 24/100? Der funktioniert ebenfalls mit CANBUS. Gruß Udo
Hello Udo, Greetings from India...I am going nuts over this CAN communication with NPB-1700.. I have used, Arduino UNO board with MCP2515, Waveshare USB- CAN Converter and other peripherals, But i am just unable to get the CAN Data from Charger or communicate with it. I Have followed your instruction about 120ohm resistance but still no luck. Can you please share link to your Arduino code code where i can check how you have done he addressing. That will be really helpful..
since we all used espressif controllers and esphome to program it, there's no arduino implementation. however it should be no problem to adapt. take note of the initialization with 8MHz clock and 250KBPS bit rate, right adresses as well as the swapped low and high bytes as @markjoe stated. and yes, you're correct, the CAN bus must be terminated by the mentioned resistor. in my case I didn't notice my MCP2515 module needed the jumper on its pcb to be bridged in order to terminate, which caused the communication to not work at all. jumper set and it's all good. what MCP2515 board do you use? furthermore you have to make sure the power supply itself has the right pin/jumper configuration. usually you should not need any jumpers or extra wires besides of the CAN bus wires. I'll attach some esphome code where you can see the addressing and so on.
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.