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. 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
  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
  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 Zyklusz
  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? We
  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
  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 Di
  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
  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 DualRe
×
×
  • Create New...