MMS

Es liegt an der Position im Stack. Ich kann die Master vertauschen oder auch andere Master einsetzen. Das Problem bleibt das selbe. Kann ich leider nicht testen, da schon alles fest verbaut ist. Ich teste überall nur mit PTC Bricklets. Diese funktionieren am unteren ohne Prbleme, wenn ich sie nach oben stecke tritt das Problem auf. Ich hatte zunächst noch andere Bricklets dran (Humidity, Ambient Light, IO16). Diese habe ich allerdings für die Tests abgesteckt. Nun hängen überall nur PTC Bricklets, die einzeln alle funktionieren. Da der 2er Stack mit Spannungsversorgung vom Laptop und der 3er mit der Step-Down Supply läuft denke ich, dass die Art der Spannungsversorgung eine Grund ist. Aber scheinbar nicht der einzige.

Ich habe jetzt herausgefunden, dass ich an den unteren Master so viel Bricklets (PTC) hängen kann wie ich will und es funktioniert. Sobald ich aber an den 2ten Master mehr als 1 Bricklet hänge dauert es 2 min bis ich eine funktionierende Verbindung bekomme. Auch wenn der untere Master mit keinen Bricklets belegt ist. Das erklärt auch warum der Test an dem 1er Stack mit zusätzlichen Mastern kein negatives Ergebnis brachte, da ich keine zusätzlichen Bricklets zum anschließen hatte.

Gemessen habe ich mit einem Digitalmultimeter, direkt an der Verbindung vom Anschlusskabel zum USB Stecker. Firmware: 2.3 Hardware: 2.1 Nein, die blauen LEDs leuchten nur am Anfang beim Einstecken des USB Kabels. Dieser Stack funktioniert mit zwei und auch mit drei Master und 4 Bricklets. Ich habe nicht mehr zum testen. Mangels Step-Down Power Supply kann ich das nicht testen, aber da es mit USB vom Laptop geht, würde ich sagen das geht auch. Das komische ist ja, dass ich zunächst leere Antworten bekomme, dann schweigen und nach 2min gehts dann einwandfrei. Ich habe auch schon beide Master und den RS485 ausgetauscht. Ohne Verbesserung. EDIT: Könnte es denn an der Potentialerhöhung der Masse, durch die Kabellänge, liegen? Diese sollte etwa 0,05V bei 200mA sein.

Ja, jeder 3er Stack hat ein Step-Down. An einem hängt ein 1er an dem anderen ein 1er und der 2er. Eingespeist wird über den USB Port. Ohne den zweiten Master, aber mit den Bricklets und der RS485 Extension. Versorgt werden die Step-Down Power Supplies über einen 100Ah 12V Bleiakku. Dieser ist über 10m 2x2x0,5mm² (Spannungsvers. und RS485) Kabel angeschlossen. Danach geht es weiter mit den 5V über 7m zu dem 2er Stack mit dem gleichen Kabel. Der 1er Stack ist auch mit ca 7m Kabel angeschlossen.

Sorry hab da was verwechselt. Ich versorge den Stack nicht über den DC Brick, sondern über die Step-Down Power Supply. Die ist doch aber normal dafür gedacht.

Habe das Problem gefunden, wenn ich die Master einzeln betreibe oder den ganzen Stack zur Stromversorgung an den Laptop hänge laufen sie einwandfrei. Aber wie kann das sein, wenn ich 5,1V am USB Anschluss habe? Brauchen die Master während der Kommunikation mehr Strom? Wieso gehts nach 2 Min?

Ok. Werde ich testen. Was ich bis jetzt noch rausgefunden habe ist, dass kurz nach dem Reset noch ca. 20 leere Antworten kommen, darunter manchmal eine mit Daten. Danach ist wie gesagt für 2 min absulute Stille. Die Sequence number hat keinen Einfluss.

Ich habe zwei Stacks mit 3, einen mit 2 und zwei mit 1 Master. Der fehlerhafte ist der einzige mit 2 und bekommt 5V (sind genau 5,1V am Anschluss) von einem DC Brick, der an einem 3er Stack hängt. Genauso wie die 2 mit 1 Master. Überall hängen PTC Bricklets. An diesem Stack, als einziger, auch ein IO-16. Firmwares sind alle gleich. 38400 baud Zunächst mal bekomme ich eine Zeit lang gar keine Antwort. Wenn ich eine Antwort bekomme ist es dann die Nummer dich geschickt habe. Hier die ersten zwei Antworten des Stacks (Anfrage eines PTC Bricklet) in HEX: 0d640200000000080000006423 (leere Antwort) 0d640281d767000c011800ae090000f395 (richtige Antwort) Manchmal bekomme ich auch nur leere Antworten. Nach ca 2 min geht dann alles wieder wie bei den anderen Stacks.

Ok. Danke, da hätte ich doch genauer lesen sollen. Ich habe jetzt insgesamt 5 Stacks mit insgesamt 40 Sensoren über RS485 verbunden. Die Abfragen funktionieren ganz gut. Wenn ich aber die Versorgungsspannung ab und wieder anschalte braucht ein Stack über eine Minute, bis er auf Anfragen antwortet. Alle anderen sind nach ca. 20s wieder online. Hat jemand eine Idee an was das liegen könnte? Gruß MMS

Kann mir denn niemand helfen?

Hallo, kann ich mit der modbus und tcp/ip sequence number einfach bei 0x01 beginnen und immer um eins erhöhen oder muss ich da etwas beachten? Bei manchen seq# bekomme ich keine Antwort. Ist die Master ACK Message: 0x01, 0x64, modbus_sequence, crc16 richtig? Danke. Gruß MMS

Hallo, ich würde gerne mehrere Stacks über ein längeres Kabel mit einer Zentralen 5V Spannungsversorgung betreiben. Was ist denn die minimale Versorgungsspannung (an der USB Buchse) eines Stapels aus 4 Master und einem RS485 Brick? Edit: Und was wäre die maximale Eingangsspannung an der USB-Buchse?

Hallo, zur Hardware: -Rasperry Pi mit aktuellem Raspian und Python 3 -Raspicomm Erweiterung für RS485 (andere RS485 Boards bei denen man den RTC Pin für die Datenrichtung manuell setzen muss gehen auch, machen das programmieren aber sehr aufwändig) -ein Stück dreiadriges Kabel -Masterbrick mit RS485 Extension Hier der Python Code. Er funktioniert ist aber ein erster Entwurf und noch nicht optimiert. @borg: passt denn die Bestätigung nach erfolgreicher Abfrage: 0x01, 0x64, modbus_sequence, crc16 import serial import time import crc16 def get_value(port, mod_adr, mod_seq, tcp_seq, func_id): #Abfrage des Bricks flag = True #Flag True bis Abfrage erfolgreich req = bytearray([0x01, 0x64, mod_seq, mod_adr[0], mod_adr[1], mod_adr[2], mod_adr[3], 0x08, func_id, tcp_seq, 0x00]) #bytearray für modbus/tcp Abfrage crc_req = 0xFFFF for x in range (0, 11): #Prüfsumme berechnen crc_req = crc16.calcByte( int.from_bytes(req[x:x+1], byteorder='big'), crc_req) req[11:13] = crc_req.to_bytes(2, byteorder='little') #Prüfsumme anhängen ack = bytearray([0x01, 0x64, mod_seq]) #bytearray für modbus Bestätigung crc_ack = 0xFFFF for x in range (0, 3): #Prüfsumme berechnen crc_ack = crc16.calcByte( int.from_bytes(ack[x:x+1], byteorder='big'), crc_ack) ack[3:5] = crc_ack.to_bytes(2, byteorder='little') #Prüfsumme anhängen while flag: #solange Abfrage nicht erfolgreich port.write(req) #Abfrage schicken ans = b'\x00' ans = port.read(20) #Antwort empfangen leng = int.from_bytes(ans[7:8], byteorder='big') #Länge des TCP Packets bestimmen crc_ans = 0xFFFF for x in range (0, leng+3): #Prüfsumme der Antwort berechnen crc_ans = crc16.calcByte( int.from_bytes(ans[x:x+1], byteorder='big'), crc_ans) if bytearray([0x01, 0x64, mod_seq, mod_adr[0], mod_adr[1], mod_adr[2], mod_adr[3]]) in ans[0:7]: #Antwort mit Abfrage vergleichen (Adresse) if (int.from_bytes(ans[leng+3:leng+5], byteorder='little')) == crc_ans: #Prüfsumme kontrollieren port.write(ack) #Bestätigung senden if leng > 8: #wenn Daten vorhanden val = int.from_bytes(ans[11:11+leng-8], byteorder='little') #Daten ausgeben return val else: return 0 flag = False else: flag = True #fehlerhafte Antwort, erneuter Versuch if __name__ == "__main__": #Hauptprogramm port = serial.Serial(port='/dev/ttyRPC0', baudrate=115200, timeout=2) #Port öffnen, 115200 Baud, 8N1 time.sleep(.1) mod_adr = bytearray([0x98, 0x83, 0x00, 0x00]) #Adresse des Brick/Bricklet mod_seq = 0x01 #Modbus sequence number tcp_seq = 0x01 #TCP sequence number func_id = 0x01 #Funktions ID value = get_value(port, mod_adr, mod_seq, tcp_seq,func_id) #Abfrage print ("Wert: %d\n" % value) #Wert ausgeben Verbesserungsvorschläge und Fragen sind natürlich wilkommen.

Habe meinen Fehler gefunden. Lag am Receiver Enable. Ich habe am RS485 Wandler zu früh auf Empfangen umgeschaltet, so wurden die letzten bits nicht gesendet. Jetzt bekomme ich eine Antwort. Danke für die Hilfe!!!

Baudrate überall 250000, Parität und Stopbits passen auch. Als Master verwende ich einen Raspberry mit einem RS485 zu UART Wandler. Die gesendeten Daten passen und wurden mit einem Terminalprogramm überprüft. Sie kommen auch am Stack an, habs mit nem Oszi gemessen.