Jump to content

Arnim

Members
  • Content Count

    50
  • Joined

  • Last visited

Everything posted by Arnim

  1. Hallo zusammen, mich würde interessieren, ob evtl. ein MIDI-Bricklet in Planung ist, bzw. ob das für andere auch interessant wäre, bzw. ob man das evtl. mit einem vorhandenen (RS232?) Bricklet leicht umsetzen kann? Ich denke das wäre eine tolle Ergänzung zum DMX-Bricklet und würde vielfältige Steuerungsmöglichkeiten im Audio-Bereich ermöglichen. Etwa auch eigene Sequenzer und ähnliches. Hat hier jemand eine Idee, Erfahrungen? Bin gespannt, Arnim.
  2. Arnim

    Infrarot Empfänger

    Ich schubse diesen Thread noch mal... ... gibt es Pläne einen IR-Empfänger mit dem ich meinen Stack quasi aus dem Wohnzimmersessel steuern kann als Bricklet zu realisieren? Spontan würden mir dutzende tolle Szenarien einfallen. Weiß jemand evtl. einen kostengünstigen und vor allem praktikable Work-Around um meinen Master (RED-Brick) per Fernbedienung (IR-Codes) zu steuern? Freue mich, Arnim.
  3. Danke für die super schnelle Reaktion. Also das Problem tritt unabhängig von der Displaynutzung auf. Aktuell schafft er es keine 5 Minuten am Stück. Das RS232-Bricklet ist bereits über eine geschirmte Leitung angebunden (siehe Aufbau). Der Aufbau ist nicht mit dem PC verbunden und läuft komplett autonom. Das Netzteil liefert 1,5 A bei 13 Volt - hier sollte also eigentlich kein Problem vorliegen. Ist schon etwas mysteriös... :-/
  4. Das RS232-Bricklet läuft auf Version 2.0.2. Alle Bricks und Bricklets sind laut Info auf aktuellem Stand. Der RED läuft auf SW 1.7 (Full).
  5. Ich habe folgende Konfiguration: Step-Down -> RED (+Touch-Display) -> Master (2.0) am Master hängen Industrial In 4, Industrial Quad Relay und RS232. Ordentlich gestapelt und mit den kürzesten Kabeln. Es läuft ein ganz einfaches Test-Programm (C# lokal auf dem RED): - Lese per Callback RS232-Codes und schreibe diese aufs Display - Toggele bei Touch ein Quad-Relay - Toggele bei Inputänderung (Interrupt) ein Quad-Relay Am RS232 hängt eine RFID-Leseantenne die alle 250 ms ein Paket aus 5 Byte schickt. Nun zum Problem: Lasse ich den Aufbau stehen, so läuft alles gut, die Codes wandern brav übers Display und die LED am Quad-Relay lässt sich per Touch oder Schalter am In4 schalten. Irgendwann jedoch enden plötzlich die RS232-Codes. Das passiert einfach irgendwann. Alles andere läuft weiter, es kommt auch keine Fehler oder ähnliches. Greife ich parallel per USB vom PC aus auf den RED zu, so erhalte ich auch hier im RS232-Bricklet keine Codes mehr. Resete ich nun - im laufenden Programmbetrieb auf dem RED(!) - das Master-Brick per Brickviewer, so erhalte ich im Programm sofort wieder Codes und auch im Brickviewer erscheinen diese wieder. Ich habe das Gefühl, dass das Problem von der Verkabelung abhängt. Bzw. in irgend einer Form eine Störung durch Felder von parallelen Kabeln ist. Der aktuelle Aufbau lief nun autonom über Nacht (allein im dunkeln) 10 Stunden am Stück fehlerfrei (etwa 150000 tausend Codes!) aber jetzt habe ich heute morgen nur fünf Minuten daneben gesessen und ein paar mal am Display geklickt und schon war die Übertragung plötzlich wieder tot. Jemand eine Idee, woran es liegen könnte? Es liegt nicht an der Leseantenne, diese kann ich im laufenden Betrieb ab- und wieder ausstecken und die Übertragung läuft sofort wieder. Es liegt also am Master-Brick oder am Bricklet. Aber was kann man hier machen? Danke, Arnim.
  6. RS232 über USB am RED klingt doch nach einem tollen Plan. Leider sind meine Linux-Fähigkeiten in etwa bei Null (0). Hat dies evtl. schon jemand (erfolgreich) ausprobiert/implementiert und mag das Forum daran teilhaben lassen? Mein Wunsch ist einfach: Schnittstelle überwachen und wenn Daten kommen diese prüfen und verarbeiten. Konkret geht es um eine RFID-Leseantenne die beim Anlegen einer Karte fünf Byte mit der ID alle 0.2-0.5 Sekunden sendet. Aktuell mache ich das über einen C-Controll (Conrad) der dann über einen IO16 mit meinem Brick spricht der das dann wieder über das Netzwerk schickt. Diese Vier-Ecken-Lösung würde ich gerne komplett auf den RED legen.
  7. Habe mich jetzt doch mal unter http://de.wikipedia.org/wiki/Personalausweis_(Deutschland)#Der_elektronische_Personalausweis_.28nPA.29 schlau gemacht. Ohne PIN ist wohl gar keine Kommunikation möglich und selbst mit PIN ist es vermutlich alles andere als trivial ein Protokoll aufzubauen. Schade.
  8. Ich stocher mal im Nebel: Der neue Personalausweis hat ja - soweit ich weiß - auch einen RFID/NFC-Chip drauf. Kann ich diesen, evtl. zukünftig, am NFC-Bricklet auslesen, bzw. zumindest eindeutig identifizieren? Mein Wunsch wäre den Ausweis z.B. als Zugangskarte zu verwenden. Oder spricht hier technisch etwas völlig dagegen? VG, Arnim.
  9. Das IO16-Bricklet ist ja eine nette Bastelllösung mit seinen vielen Schraubklemmen, aber zur sicheren Anbindung externer Module wäre eine zweireihige Steckerleiste im Standardraster deutlich praktischer. Ist hier etwas in Planung? Dadurch würde das Bricklet natürlich auch deutlich kompakter. Ich stelle mir das in etwa vor wie das Multi-Touch-Bricklet. VG, Arnim.
  10. Hallo, alle Jahre wieder komme ich mit der gleichen Frage: Gibt es inzwischen eine Möglichkeit, RS232-"Geräte" per Bricklet oder gar dem neuen RED "direkt" anzusprechen? Also Pakete zu Senden und zu Empfangen? VG, Arnim.
  11. @borg: Danke für die Antwort. Habe ich die deutliche Latzenz in der Doku eigentlich nur überlesen oder ist das bisher noch nirgends thematisiert? Ich kann mich nur erinnern, irgendwo von den 2Mbit im RS485 gelesen zu haben und wie flott alles geht. Aber knapp 10ms pro GetPort sind ja gerade mal 100 Zyklen je Sekunde, also nicht mal ein Kbit effektiver Durchsatz. Ich denke das sollte man schon deutlich erwähnen - für meine Anwendung bedeutet das leider - in dieser Form - das aus. Ich bin immer von 2-3ms maximal ausgegangen. Ich muss auch feststellen, dass sich mir bei einer direkt Zykluszeit von unter 1ms (direkt am Brick per USB) nicht erschließt wo die Daten für weitere 7ms im System hägen bleiben, die werden ja vermutlich nicht per Buschtrommel über die RS485-Leitung geschickt. Bitte versteht das nicht als Meckern, sondern als Wunsch, klare Gegebenheiten auch deutlich zu dokumentieren - fast 10ms Zyklus für ein einziges GetPort ist (in meinen Augen) einfach völlig aus der Welt wenn man sich den Hightech rund um euer System anschaut. Zumindest sollte man es eben wissen. Was den kombinierten GetPort angeht: Das wäre genial!
  12. @Batti: Wenn Du schon so fragst: Hast Du Vergleicheswerte was eigentlich zu erwarten sein müsste? Und liege ich das völlig aus der Welt? Ich habe das RS485 recht simpel eingerichtet: - 2Mbit - Keine Parität - 1 Stop-Bit - Einen Master + Einen Slave (beide Termination on) - 30 cm verdrilltes Kabel dazwischen
  13. Eine Frage an TF (oder wer immer sich hier kompetent sieht): Ich betreibe an einer RS485-Verbindung mehrere Master mit IO16 und fahre hier einen GetPort. Ein GetPort benötigt hierbei ca. 8ms vom Aufruf bis zur Rückgabe, also eine Ewigkeit. Ist das die normale Latenz bei RS485? (Win7, C#, SW2.x) Betreibe ich den Brick direkt am USB liegt der Zyklus eines GetPort bei unter 1ms. Und dazu gleich die zweite Frage: Wenn das schon so gemutlich ist, wäre es dann nicht zumindest möglich in der Software einen GetPort zu implementieren, der beide Ports direkt, also in einem Rutsch abfragt? Wenn ich davon ausgehe, dass dieser Aufruf nicht langsamer wäre, würde dies meine Anwendung um 50% beschleunigen, da ich immer beide Ports abfragen muss. Danke, Arnim.
  14. @Borg: Das nenne ich mal ein Wort! Ich hoffe die ToDo ist nicht so lang wie meine, sonst wird's dieses Jahr nix mehr. ;-) Thanx!
  15. @Nic: Eine _Lösung_ reicht mir. ;-)
  16. Es gibt eine Sperre zwischen mehreren Suchanfragen. Suche ich also nach Brik äh natürlich Brick dann muss ich erstmal 5 Sekunden warten obwohl ich mich nur vertippt habe. Gleiches gilt wenn ich nach "Mindstorm", dann nach "Lego" und dann direkt nach "Stecksystem" suche. Ich sehe ja auf den ersten Blick, ob die gefundenen Antworten auf mich passen - vor allem wenn man nix findet. Aber vor jedem neuen Begriff muss man wieder 5 Sekunden warten. Aber wie es scheint bin ich der einzige der schnell mal zwei drei Begriff im Forum suchen will. ;-)
  17. Wenn es natürlich systemunabhängig sein soll ist es problematisch. Da ich jedoch ausschließlich Windows-Systeme einsetze (bitte nicht steinigen) und der Zugriff auf das Ereignisprotokoll aus C# ziemlich trivial ist wäre die Lösung über die Datei fast komplizierter. Aber wie gesagt, mir ist nicht wichtig "warum" das System neu startet, hauptsache es startet neu.
  18. Eine OnDevice API wäre hier natürlich eine Lösung, aber evtl. wäre es für TF "leicht" dies einfach direkt zu implementieren. Stellt sich eben die Frage ob auch andere Kunden das System in einem Umfeld einsetzen wo ein Disconnect am Display angezeigt werden soll, oder ob ich der einzige bin der dies benötigt. Was sind die "neuen" Callbacks? Alles was vom Brick zurück an den PC geht bringt mir in diesem Kontext nichts.
  19. Na eine Kritik hätte ich schon, betrifft aber das Forum (wo sich wohl die meisten von uns mehr oder weniger ausschließlich tummeln): Wenn ich mich bei der Suche vertippe muss ich fünf Sekunden warten - und das bereits beim ersten Anlauf und auch dann wenn nichts gefunden wird. Bei der schnellen Recherchen nach bestimmten Begriffen kann das schon ganz schön Nerven. Wozu die Sperre? Bots? Da würde es auch eine Sekunde tun. ;-)
  20. @Arcane: Da es ein Windows-System ist würde ich bei Interesse einfach in die Ereignisanzeige schauen (also die Software schauen lassen), dann weiß ich, ob der Reboot Absicht war oder nicht. Ich schätze unter Linux gibt es sicher etwas ähnliches, oder? Aber ich denke ich werde das die Tage mal Testen und mitteilen, ob das tut oder nicht. :-)
  21. Danke für die vielen Antworten. In der Tat geht es mir um den Reset-Pin am Mainboard, einen Kaltstart erachte ich nicht unbedingt als notwendig, auch wenn das natürlich sicherer wäre. Natürlich sollte der Prozess der den Watchdog triggert softwareseitig über einen zweiten Prozess überwacht und wenn nötig/möglich neu gestartet werden und der Timer so gewählt werden, dass hier auch etwas Luft bleibt. @Arcane: Was bezweckst Du mit den Dateien? Ob ich mit dem Brick noch sprechen kann kann ich ja leicht über eine kurzes Rückfrage (GetMonoflop) prüfen. Sollte ich hier keine Antwort bekommen kann man es mit einem Reset auf dem Brick versuchen. Oder?
  22. Noch ein Gedanke: Ich bin noch immer bei meinem Zugangssystem. Jede Tür hat ein Display das zum Scan der Karte auffordert und dann die Eingabe der Pin kommentiert, ... Verliere ich die RS485-Kommunikation oder bleibt sonst im System etwas stehen, so bleibt das LCD natürlich da stehen wo es eben steht. Super wäre eine Funktion ähnlich dem Monoflop der Relays. Ich hinterlege einen Default-Text und einen Timeout. Erhält das LCD innerhalb der definierten Zeit keinen Impuls (neuen Text, Rückstellung des Timers, ...) wird automatisch der Default-Text angezeigt. Auf diese Weise wäre am Display "sofort" ersichtlich, dass etwas nicht tut und die Nutzer wären nur halb so frustiert. Ist so etwas denkbar TF-Team? VG, Arnim.
  23. 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?
  24. 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!
×
×
  • Create New...