Jump to content

uwet

Members
  • Gesamte Inhalte

    27
  • Benutzer seit

  • Letzter Besuch

uwet's Achievements

Newbie

Newbie (1/14)

0

Reputation in der Community

  1. Ihr könntet mal schauen, ob eine bessere Eingangsfilterung sinnvoll ist. Ihr könntet verschiedene Kabelkategorien anbieten. je einfacher ein System zu benutzen ist, umso mehr sollte man darauf achten, daß Fehler durch den Nutzer minimiert werden (Sicherungen, Filter, fall backs, ..). Siehe auch Eure Terminal, die mit "Only Output" gekennzeichnet sind. Da gibt es keine Sicherung und promt zerschießt es das Modul (siehe anderen Thread). Herr Murphy - und seht darin bitte keine Häme - hätte seine Freude. Ist Euer Filter für die Eingangsfrequenz der ADC steil genug, um zu hohe Frequenzen wirksam zu begrenzen? Je einfacher nach außen, umso sicherer innen notwendig. In einigen Bereichen scheint es schon gut realisiert. Doch sonst kommt Ihr bald zu nichts anderem mehr, als Fragen zu beantworten und Nutzerprobleme zu lösen. gruss uwet
  2. Da steht nichts mehr, aber ein Vlies-Pullover sollte als Referenz ausreichen. Alles, was beim Ausziehen funkt und zischt, sollte den gleichen Effekt erzielen lassen. Parallel laufende Stepperkabel könnten eine ähnliche Wirkung haben, wie auch Relais. gruss uwet
  3. Moin moin, so, jetzt hatte ich etwas Zeit, um das Thema weiter zu behandeln. Ich habe mir entsprechend meiner Vermutung nach ESD-Problemen eine Schirmung für mein Kabel gebaut. In erster Linie besteht es aus Metallflechtschlauch, der wenigstens einseitig an Masse angeschlossen ist. Und das Ergebnis ist, daß ich auch mit dem beschriebenen Polluver das lange Kabel und auch das LCD anfassen darf, ohne daß die Funktion darunter leidet (zum Vergleich: vorher durfte ich nichteinmal in die Nähe des Kabels kommen). Ihr solltet eventuell doch darüber nachdenken, in der Zukunft etwas für die elektromagnetische Verträglichkeit zu tun - auch wenn Ihr kein CE-Zeichen oder den rauhen Industriealltag anstrebt. Die Störungen im System sind nicht zu unterschätzen. Die vorgeschlagenen Tests habe ich nicht gemacht, da sie nicht zielführend erscheinen. Einzig ein kürzeres Kabel hat wahrscheinlich Einfluß auf das Verhalten. gruss uwet
  4. Das Verhalten ändert sich nicht: * Pullover an -> es regt sich nichts mehr, wenn ich in die Nähe komme * Pullover aus -> ich darf sogar anfassen Und ich habe das auch mit ESD-Schutzarmband an der "bösen" Hand probiert;o) Aber es ist dann besser! Ich nehme nicht an, daß Ihr Messungen im ESD-Labor gemacht habt?! Gibt es Maßnahmen zum Schutz vor ESD? Beim USB sehe ich nichts. gruss uwet
  5. Die Situation: * LCD ist an Master-Brick angeschlossen * am Master ist auch IO16 angeschlossen * Step-Down vorhanden * USB angeschlossen * externe Stromversorgung mit ca. 19V * Kabel sind alle je 59cm lang, nicht parallel zueinander * Brickv läuft als einziges Programm mit Zugriff auf den Stack * Master-FW ist 1.1.7 * LCD-FW ist 1.1.0 * OS ist WinXP * Das System liegt auf einer ESD-Matte oder auch isoliert (is hier egal) Nach dem Reset des Stapels werden in Brickv alle Komponenten korrekt erkannt, es kann ein Text eingegeben und am Licht "gespielt" werden. Ich kann das Einfrieren des LCD-Zugriffs durch Annäherung meiner Hand provozieren. Komme ich dichter ran, reagiert das Modul nicht mehr (Schalter werden weiter gemeldet). Lasse ich nach dem Reset die Finger weg, hat das Programm auch weiter Zugriff auf das LCD. Ziehe ich den Pullover (so ein Plasitk-Hightech-Vlies-Teil ;o) aus, darf ich das Modul sogar anfassen und es funktioniert weiter. Ziehe ich ihn wieder an, habe ich die Situation wie vorher. Es scheint also schon etwas mit el. Feldern zu tun zu haben. Das würde auch zu der Situation mit dem Relais, das als Problem bereits beschrieben wurde ("diverse Probleme"), passen. Das sagt noch nichts darüber aus, ob das LCD-Modul spinnt oder Euer Bricklet der Verursacher ist. gruss uwet
  6. Und das geht auch, wenn ich einen drehenden Motor anhalten möchte? Ist dann der gewünschte Stillstand das Ereignis "Position reached" und wird somit der vollzogene Stillstand gemeldet? gruss uwet
  7. Ja, so ungefähr. Eben so nach dem Motto: "Warte mal und halt gesittet an, da ist was im Weg... Und jetzt mach einfach weiter wie vorher besprochen!" (vorwärts oder rückwärts, zähl weiter deine Schritte oder fahr weiter zu der vereinbarten Position) Vielleicht - und das ist erstmal nur so eine Überlegung - könnte man die Zwischenstop-Funktion wie so eine generelle Bewegungsfreigabe betrachten. Wenn ich wieder freigebe, muß ich nicht wissen, was der Motor vorher machen sollte. Ich muß also nicht merken, ob er einfach so drehte, ob er eine Position anfahren sollte oder soundsoviele Schritte machen sollte. Es würde vieles vereinfachen. Ich kann mir auch eine Art Rundruf an alle Stepper/Servos/DCs oder auch an Gruppen vorstellen. Da gibt es definitiv unbegrenzte Möglichkeiten. Es sollte aber die Möglichkeit geben, die Motoren im Zustand des Zwischenstops umzuprogrammieren - neue Schritte, Richtung usw. Da fällt mir noch eine Frage ein: Wie sieht es mit einer Funktion wie IsStop(&Stepper, &StopTrue) aus, die liefert, ob der Motor noch dreht? Vielleicht auch als Callback. Jetzt teste ich die Änderung der Positionen, bis keine Änderung mehr vorliegt. gruss uwet
  8. Moin, ich wünsche mir: * den Stepper für eine Bewegung zu programmieren, * ihn anhalten (quasi Stop) zu können (geht natürlich schon), * ihm sagen zu können, daß er seine Fahrt wie vorher programmiert wieder aufnehmen soll. Bsp. 1: Ich lasse einen Stepper vorwärts laufen, muß anhalten und möchte dann, daß er auf Befehl einfach weiterfährt (incl. Anfahren). Bsp. 2: Ich gebe einem Stepper den Befehl, 12000 Steps zu fahren, muß ihn im Verlauf aber stoppen und möchte, daß er auf Befehl einfach so weitermacht, als hätte man ihn nicht angehalten. Ich kann es natürlich auf Umwegen mit Merken des ursprünglichen Befehls und der Abfrage der Position nach dem Stop bereits jetzt realisieren, aber... Oder seht Ihr noch eine andere Möglichkeit der einfachen Realisierung mit vorhandenen Mitteln? gruss uwet
  9. Moin, mir fehlt ein Modul, das I2C-Schnittstellen zur Verfügung stellt. I2C ist ja schon im System, doch bedarf es der API. Diese sollte dann aber möglichst flexibel ausgelegt sein (Adressen, Subadressen mit 8 und 16 Bit, SCCB, ACK erwartet oder nicht, ...). Eine weitere sinnvolle Schnittstelle wäre dann noch SPI. SPI sollte dann natürlich diverse Select-Leitungen haben und mit einfachen und doppelten Datenleitungen funktionieren. Ob es als Brick oder Bricklet realisiert wäre, wäre mir eigentlich egal. Sicher müssen beide Schnittstellen auch nicht zwangsläufig auf eine Platine gebaut werden. Wie sieht es aus? Es würde auf jeden Fall die Verwendbarkeit des Systems stark erweitern und Raum für eigene Erweiterungen schaffen. gruss uwet
  10. okay, aber dann ist "Distance 16" definitiv außerhalb dieser Namenskonvention, da ich mit dem dritten Parsen nur die "16" geliefert bekäme und Ausnahmebehandlungen vorsehen müßte. Ohne euch das jetzt aufdrängen zu wollen, aber eine FunktionsID hätte schon gewisse Vorteile. gruss uwet
  11. Moin moin, ich hätte da wieder einen Wunsch: Ich möchte mehrere Stepper in Rampe, Endgeschwindigkeit und Endposition konfigurieren und dann quasi einen Trigger setzen, der alle entsprechend konfigurierten Stepper gleichzeitig lossteppen läßt. Das gleiche gilt für die synchrone Digitalisierung z.B. von Spannungswerten und/oder den dabei vorhandenen IO-Zuständen. Die Rückgabe der Werte kann natürlich nicht gleichzeitig erfolgen. Etwas Ähnliches liegt vor, wenn ich die aktuellen Zustände im System wissen möchte. Per Trigger werden alle Daten auf den Brick/lets generiert und dann wie gewohnt gesendet. Wäre das technisch möglich? Und wenn ja, würdet Ihr die API vielleicht dementsprechend erweitern wollen? gruss uwet gruss uwet
  12. Ich glaube, ich habe mich noch nicht verständlich genug ausgedrückt, was die Nomenklatur angeht. Ich möchte gerne wissen, ob ihr für Vergabe der Namen für Module eine Namenskonvention in z.B. Stepper.Name festgelegt habt. Siehe "Stepper Brick 1.0" oder "IO-16 Bricklet 1.0". Gibt es eine bestimmte Struktur, die man parsen und aus dem Ergebnis genau auf ein Gerät schließen könnte? Wie würde der Name für ein I/O16-Modul mit galvanischer Trennung heißen? Und sollte das IR-Modul nicht "Distance-IR Bricklet 1.0" statt "Distance IR Bricklet 1.0" heißen? Es könnte ja auch ein "Distance-Laser Bricklet 1.0" geben. Oder ein "LED-Rot Bricklet 1.0", "LED-Blau Bricklet 1.0", ... Dann könnte man wenigstens auf Leerzeichen parsen. Und eben so weiter. Oder kann man nicht in den Namen eine ID einbauen, die für diese Baugruppe einzigartig ist? Z.B. Master-Brick 0x00010101 (Bit 31..24 Reserve,Bit 23..16 FunktionsID, Bit 15..8 VariantenID, Bit 7..0 RevisionID) oder so ähnlich. "LED-Rot Bricklet 1.0" könnte dann 0x000a0101 und "LED-Blau Bricklet 1.0" 0x000a0201 sein. gruss uwet
  13. Danke für die Änderung. Die Werte sind nun recht gleichmäßig über den Lastzustand. Das sieht gut und nachvollziehbar aus. gruss uwet
  14. Als eingestellt sind: max. Strom 800mA, Velocity 2000Steps/s, Decay 12000. Strom aus Powersupply lt. Amperemeter Strom halt: 240mA Strom forward frei: 268mA Strom forward last: 420mA Strom lt. Stepper Strom halt: 14...33mA Strom forward frei: 9...268mA Strom forward last: 18...120mA Die Werte sind mir zu weitläufig. Unter Last kann es noch sein, da ich mit der Hand bremse. Aber im freien Lauf? Ob ich einen gemittelten Wert haben will? Wenn klar ist, woher der Strom stammt, kann vielleicht jeder mit dem Wert machen was er will. Die API könnte sonst zu unübersichtlich/verzettelt werden, weil jeder etwas anderes will (gleitenden MW, MW über ein Intervall, ...).
×
×
  • Neu erstellen...