Arnim

Der Gedanke ist in der Tat, das ein Reset am Rechner auch ein Reset an die USB-Ports sendet. Vermutlich ist das nicht der Fall. Aber dann benutze ich eben beide Relais und definiere das zweite derart, dass es 200ms nach dem ersten Relais floppt und den Reset-Impuls wieder unterbricht. Dann startet der Rechner auf jeden Fall neu und irgendwann bekommt der Stack dann auch wieder sein Init und beide Relais fallen ab... fällt jetzt zuerst das zweite Relais bekomme ich natürlich gleich noch mal nen (super kurzen) Reset. Aber dann bootet die Kiste auf jeden Fall durch. Denkfehler? Bleibt nach wie vor die Frage: Wo läuft der Monoflop: PC, Brick, Bricklet?

Hallo zusammen, ich habe ein kurze Frage zum DualRelay, bzw. zur Monoflop-Funktion. Ich realisiere derzeit ein Gebäudezugangssystem über TF und im Prinzip läuft so weit (im Testaufbau) alles super. Gesteuert wird alles über einen zentralen Server der über einen Master eine RS485-"Netz" aufspannt und alle Zugänge kontrolliert (RF-ID-Reader, Display, Keypad, Türöffner). Mein Sorge liegt in einem "Serverabsturz" (Kernel hängt, Treiber hängen, Steuersoftware hängt, ...) um das System in so einem Fall einem Hardwarereset zu unterziehen kam mir folgender Gedanke: Ich nehme mir ein DualRelay, definiere "high" (also Relay angezogen) als "Ruheposition" für den Monoflop und eine Monoflopzeit von z.B. 10 Sekunden. In der Software schalte ich das jetzt scharf und triggere aus der Software das DualRelay z.B. jede Sekunde, so dass der Monoflop nie zuschlägt. Außer eben wenn mein Trigger ausbleibt. Das Relay zieht an, löst direkt einen PC-Reset aus und fällt (weil ja ein USB-Reset kommt) sofort wieder ab. Das System startet (hoffentlich) und alles beginnt von vorne. Läuft der Monoflop im Brick/Bricklet oder über den Daemon? Soll heißen: Flopt das Relay selbst dann wenn der steuerende PC tot ist? Könnte das so klappen oder habe ich hier einen Denkfehler? Freue mich über Feedback!

Muss man schon sagen: Sieht toll aus!

Ich würde sagen der "Trick" sind die Lichtschranken. Der Speed ist ja im Prinzip nur durch die langsame Anbindung über ein IOx begrenzt - viele Ticks pro Sekunde sind da nicht drin. Aber zumindest geht es so natürlich. Ist hier noch jemand "älteren" Semesters dabei? In meiner Jugend gab es von Fischer-Technik einen 3-Achen-Roboterarm mit Computer-Interface (C64). War ein geiles Teil, habe ich viele Stunden und Tage und Wochen mit verbracht. Da waren es auch DC-Motoren (an oder aus!) und Gabellichtschranken mit ich schätze um die 60 Ticks je Rotation. Das Teil konnte auch repetiert sehr exakt vorgegebene Wege abfahren! Siehe hier: Das ganze gabe es auch als 2D-Plotter mit der gleichen Technik - war auch überraschend exakt. Natürlich geht es DC, aber ob das für eine Fräse der optimale Ansatz ist?

Mag sein, dass das jetzt nicht hilfreich ist, aber es erscheint mir physikalisch völlig ausgeschlossen, mit einem DC-Motor etwas (egal wie grob) positionieren zu wollen. So lange nicht irgend eine Art von Positionsgeber hinter dem Motor/Getriebe exakt mitschreibt wo man sich genau befindet ist liegt der Fehler sicher schon nach wenigen Millisekunden im dreistelligen Prozentbereich. Selbst unter _idealsten_ Bedingungen führt ja schon der minimalste Schlupf in der Lagerung zu deutlichen Wegänderungen. Anlaufreibung/Luftfeuchtigkeit/Luftdruck/Mondphase und ähnliches mal völlig außen vor gelassen. Aber dafür sind sie ja auch nun wirklich nicht gedacht, genau dafür gibt es Schrittmotoren und sogar ein entsprechendes Brick von TF - oder? ;-)

Hallo Batti, ja natürlich macht das nur Sinn wenn es tut. Ich habe hier ne 80 Meter Rolle von dem besagten 2x2x0.8 rumliegen und werde wohl die Tage selber mal den Leitungsverlust bei 5V messen. Vermutlich mehr als ich erwarten würde. ;-) Trotzdem wäre so ein Versorgungspunkt an der Extension ne feine Sache. Der Strom muss ja nicht über den Klingeldraht kommen. An abgesetzten Bricks mit Extension wird man eher selten einen USB-Adater haben, sondern vermutlich häufig ein Netzteil das (u.u.) die 5V liefert - dann könnte man die direkt einspeisen. Aber wie so häufig ist das jetzt vermutlich so ein Sonderwunsch eines Kunden, sonst hätte sich ja vermutlich schon jemand weiteres zu der Idee geäußert. Also blos kein Stress, ich bekomme den Saft schon in den Stack.

@Borg: "Für gewöhnlich" halte ich für dehnbar. Wie viele User setzen RS485 über mehr als 40 Meter ein und - als Gegenüberstellung - wie viel mehr würde es kosten, den Stecker auf 4-Pin zu erweitern und auf dem Board an die 5V anzubinden (ca. 5 Cent?). War nur ein Gedanke, aber ist natürlich - wie vieles - sicher eine Abwägung in Kosten und Nutzen. In meinem Fall wäre es die perfekt Lösung gewesen, jetzt speise ich eben um die Ecke ein.

Nur mal so als Idee/Frage in den Raum gestellt: Warum hat die RS485-Extension nicht noch einen vierten PIN mit 5V-Einspeisung? Ich habe mehrere Slaves verteilt im Gebäude über ein 2x2x0.8 Kabel angeschlossen. Da ich nur Sensorik und ein LCD je Slave daran betreibe läuft nur eine geringer Strom über die 5V-Leitung. Optimal wäre es jetzt natürlich wenn ich die 5V direkt an der Extension anschließen könnte anstatt den Umweg über die Einspeisung z.B. am IO16 oder einem extra USB-Stecker zu gehen. Natürlich würde mit größerem Strombedarf der Slaves und größeren Leitungslängen die Verlustleistung ein Problem werden und man sollte wohl besser 24V über die Versorgungsleitungen schicken und dann die Step-Down-Versorgung wählen, aber in meinem Fall ist das absolut nicht notwendig und da wäre der direkt Anschluss wirklich klasse. Nur so als Idee. Aber ich schätze es gibt einen Grund, warum ihr das nicht gemacht habt? VG, Arnim.

@Nic: Das habe ich schon gelesen. Darum ja meine Frage: _Warum_ nicht über den USB-Port? Der USB-Port schreit ja förmlich danach und ist explizit dafür geeignet. Stecker sind günstig und wie Gizmo schreibt, ein altes USB-Kabel hat man eigentlich fast immer rumliegen.

Ich schließe mich mal AuronX an wieso nicht über einen USB-Stecker? Die gibt es auch bei Conrad uns Co. zu kaufen. Kabel anlöten und fertig.

Aber wo wir schon beim Thema sind: Ich habe das Ganze jetzt über einen UART16550 direkt am IO16 realisiert und es läuft gut. Sollte jemand Interesse an der Umsetzung haben kann ich hier gerne ein paar Worte drüber verlieren.

@zarquon: Weil RS232 und RS485 zwar ähnlich klingen, aber eigentlich nichts miteinander zu tun haben. RS485 ist eine physikalische Mehrgeräte-Bus-Definition, die nichts über Protokolle und die zu übertragenden Daten definiert. Und RS232 ist eine Schnittstelle zur bidirekten Kommunikation zwischen zwei Endgeräten (z.B. PC und Modem) mit klar definiertem Protokoll. Ein x-beliebiges RS485-Gerät kann also nicht die Bohne mit dem Anfangen, was aus einem "RS232-RS485"-Wandler rauskäme. In unserem konkreten Fall wären das die Master-Brick-Extensions die den RS485-Bus aufbauen und sich nicht sonderlich für "fremde" Datenpakete auf dem BUS interessieren (mit Recht!). So geht das also nicht. Ist quasi ein Apfel mit Cola-Flasche Vergleich. Beides spritzt wenn man drauf tritt, aber mehr gemeinsamm ist da nicht.

@AuronX: Dir zuliebe - und aus Neugier - habe ich jetzt einfach mal meine drei möglich Verbindungen zum Brick getestet. Identische Software. Identischer Bricks. Einmal direkt am PC per USB, einmal über einen zweiten Brick per RS485 und einmal per W-Lan. Die Zeiten gelten für einen Lesecycle (2x SetPort und 1x GetPort): - USB ca. 1-2ms/C - RS485 ca. 6-7ms/C - W-Lan ca. 1200ms/C Der Ping auf das W-Lan-Modul beträgt 2-3ms und die Empfängsstärke am Modul liegt bei ca. -60dB. Der Signalweg ist: PC->Zyxel GBit-Switch->Fritz-Box-7390->Brick. Der Weg erscheint mit jetzt nicht zu ausgefallen. Die Kabelstrecken sind alle GBit. Ganz schön zäh... ist das "Normal"?

Sodele, 16:06 - nach erfolgreich gut 360.000 gelesen Karten und dem (IO16) bedingt 37 Neustart ist der Brickd tot. Wäre es möglich, den den Remote-Brick zu reseten UND dann am Master die RS485-Slaves neu zu scannen wäre es wohl absolut kein Problem. Alternativ dürfte eben der Brickd nicht nach ca. 40 Zyklen schlapp machen. Beides sollte sich ja - auf einen Streich - mit V2 von alleine lösen. Lasst euch nur bitte keine 40 Jahre Zeit, sonst muss ich womöglich doch von Hand neu Starten. Wegen dem LCD-Problem mache ich mir jetzt mal Gedanken.

Das dachte ich mir auch. ;-) Ich muss das noch genauer Untersuchen.

@photron: Scheint so, als würde ich mich auf Version V2 freuen! ;-) @borg: Nein, natürlich nicht im laufenden Betrieb. Da habe ich mich schlecht ausgedrückt. Wenn ich die Bricks ohne das LCD angesteckt starte und meine Software läuft ist alles in Zeitlupe. Habe ich beim Start das LCD eingsteckt (wie gesagt, in der Software ist es NICHT gebunden oder verwendet) dann läuft alles super flott und so wie ich es erwarten würde. Wacky. :-/

Ich habe jetzt mein IO16 und den UART mit deutlich kürzeren Kabeln verbunden (5cm statt 30cm). Seither läuft das System praktisch perfekt. In einem Dauerlauf seit gestern 18:30 Uhr (läuft noch) bin ich (also der Computer) jetzt bei 260.000 erfolgreichen Karten-ID-Lesungen. Nicht ein einziges Byte wurde falsch gelesen. Lediglich mehr oder weniger direkt nach dem Start hat der IO16 einmal nicht mehr reagiert und die Software hat die Bricks resetet. Gestern - als ich die Abstürze des Daemon hatte - lief das System (wohl auf Grund der längeren Kabel) sehr unzuverlässig und hat etwa 40 Reset in 10 Minuten gefahren. So beim ca. 40sten Reset hat sich dann der Daemon verabschiedet. Ich lasse es mal über den Tag weiter laufen und beobachte, wie sich das System verhält. Aber bei aktuell 260.000 Lesungen ohne Fehler und geschätzen 25 Türöffnungen je Tag (im Schnitt) läuft das System jetzt schon knapp 30 Jahre stabil, das reicht mir. ;-) Völlig OT, aber ich will nicht extra noch mal was aufmachen, zwei Dinge: - Kann ich am Master die RS485 Slaves neu abfragen ohne Reset? Also per Software. - An meinem Slave-Brick hängen ein IO16 und ein LCD. Alles läuft gut. Hänge ich das LCD ab, wird das Lesen am IO16 plötzlich _extrem_ langsam. Das LCD wird in der Software aber weder aktiviert noch angesprochen! Jemand ne Idee? Ich untersuche das aber mal weiter und mache dann evtl. noch nen Thread auf. Danke für die Antworten, Arnim.

Ich habe jetzt mal die Kabel zwischen IO16 und der UART-Platine deutlich gekürzt (von 30cm auf 5 cm) und beide Platinen auch dicht übereinander verbunden. Das System hat jetzt die ganze Nacht IDs gelesen (aktuell sind wir so bei etwa 250.000 Lesungen) und es gab lediglich einmal den Fall (direkt am Anfang), dass ich den Brick zurücksetzten musste, weil der IO16 nicht mehr reagiert hat. Ich schätze das hat was mit Leitungslängen und möglichen Störungen von außen zu tun, jetzt läuft es super.

Oh, ja! Drei mal haben wir dies: 2013-01-10 10:56:05 <ERROR> <usb_device.pyo:393> Could not write to USB Device Traceback (most recent call last): File "usb_device.pyo", line 389, in write_loop File "libusb\usb1.pyo", line 520, in submit USBError: LIBUSB_ERROR_NO_MEM [-11] Und einmal folgt auf die Meldung oben noch 2013-01-10 10:58:59 <ERROR> <usb_device.pyo:137> Could not create USB Device Traceback (most recent call last): File "usb_device.pyo", line 117, in __init__ File "usb_device.pyo", line 146, in add_read_transfer File "libusb\usb1.pyo", line 520, in submit USBError: LIBUSB_ERROR_NO_MEM [-11] 2013-01-10 10:59:18 <ERROR> <usb_device.pyo:67> Could not create extra USB context Traceback (most recent call last): File "usb_device.pyo", line 65, in __init__ File "libusb\usb1.pyo", line 1530, in __init__ USBError: LIBUSB_ERROR_OTHER [-99] Am USB sollte es aber so direkt nicht liegen, da wie gesagt eine Restart des Daemon (ohne an den Bricks oder dem USB etwas zu berühren) alles wieder ans Laufen bringt. Ideen?

Sodele, ich nähere mich so langsam einem stabilen System, aber jetzt habe ich ein ganz neues Problem: Der Brickd bleibt hängen (ist aber im Status noch "Wird ausgeführt") und muss in der Dienststeuerung (Windows 7, 64 bit) zurückgesetzt werden. Kurz zum System: Ein Master-Brick hängt per USB am Rechner. Per RS485 (etwa 40cm, Testaufbau) geht's zu nem anderen Master-Brick. An dem hängt ein IO16 das direkt an einem UART16550 hängt. Am UART hängt eine Towitek RF-ID-Leseantenne. Die Antenne sendet zyklisch (alle 220ms) ein 5 Byte-Paket an den UART (16 Byte Buffer) und diesen Frage ich per IO16 ab. Da ich es mit einem Interrupt auf die DataReady-Leitung nicht zuverlässig hinbekommen habe polle ich die DataReady-Leitung im 100ms Takt. Gibt es nix zu lesen passiert auch nix. Gibt es Daten, so lese ich diese aus. Im Dauerlauf läuft das recht gut. Ab und zu bleibt der IO16 hängen und liefert keine plausiblen Daten mehr. Ein automatischer Reset beider Master-Bricks über die Software bringt aber wieder alles ins fließen. So weit so toll. Aber nach so ca. 4000 erfolgreichen Abfragen (= ca. 15 Minuten) bleibt mein Programm mit einem Timeout an einem (willkürlichen) GetPort hängen. Und auch der Brickv bekommt keine Verbindung mehr zum Brick. Ein Reset am Brick hilft auch nicht, aber der Restart vom Brickd (ohne Restart der Bricks) bringt wieder alles zum Laufen. Lange Rede kurzer Sinn: Sonst noch jemand das Problem oder eine Idee was hier hängen könnte? Danke, Arnim.

Ich habe jetzt von W-Lan nach RS485 gewechselt - so läuft es top. W-Lan werde ich daher nicht mehr weiter untersuchen. Aber das hier ein ziemlicher Overhead zustande kommt wenn Programm und Brick über mehrere Switches kleine Paketchen schieben leuchtet ein.

Ich habe bei meinem IO16 das Phänomen, das alles super läuft so lange ich nicht in der Nähe bin. Berühre ich das Bricklet oder nähere mich ihm nur kommt es zu Fehlern beim Lesen von Portwerten (ca. 1% bei etwa 60 GetPorts je Sekunde). Nach einer undefinierten Zeit (Minuten, Stunden) verliere ich die Verbindung zum Bricklet komplett. Der Stapel reagiert normal, allein das IO16 liefert keine Daten mehr (Timeout-Exception beim Lesen). Gibt es eine Möglichkeit ein Bricklet unabhängig vom Stapel per Software zu reseten? Kann ich den Stapel per USB Reseten (C#)? VG, Arnim.

@photron: Ich habe ganz scharf geschaut, aber die 100ms will ich nicht beschwören. Evtl. muss ich an hier an meiner Eyeball-To-Brain-Schnittstelle tweaken und sehen, ob ich die System.Diagnostics.Stopwatch hier einbinden kann. ;-) Die anderen Hinweise werde ich jetzt mal genauer unter die Lupe nehmen.

@photron: Danke für die ausführliche Erläuterung. Aber leider kann es daran nicht liegen. Das Ganze ist auch langsam, wenn ich von Hand im Trace durch das Programm laufe. Ich steppe also Zeile für Zeile durch (in humanoidem Tempo) und komme zum GetPort dieser einzelne Aufruf hängt dann 200ms fest und weiter geht's.

Die Extension hängt "ganz normal" im WLAN per WPA2. Ich setze den Power-Mode nicht explizit (das heißt doch, dass Full-Power aniegt, oder?). Ein Zugriff auf ein angehängtes LCD-Bricklet geht auch super schnell (Löschen, komplett neu schreiben in etwa 100 Ticks). Auch das Setzen von Bits am IO16 ist gewohnt schnell, nur eben das GetPort lässt sich ein knappes Lichtjahr Zeit. Ist etwas strange. Ich schätze andere Nutzer setzen ja sicher auch ein IO16 am WLAN unter C# ein? Wie sind da die Erfahrungen?