Jump to content

brb

Mitglieder
  • Content Count

    12
  • Joined

  • Last visited

  1. Guten Tag, ich bin auf der Suche nach einer Möglichkeit mittels Regressionsanalyse ein Polynom 3. Grades aus einem X/Y Chart zu ermitteln. Wie kann man das mit DASYLab realisieren? Einfaches Beispiel NTC: Ich lese auf einem Kanal die Widerstandswerte und gleichzeitig auf einem anderen Kanal dazu die Temperatur ein und gebe das ganze auf ein X/Y-Chart. X-Achse -> Widerstandswerte, Y-Achse -> Temperatur. Wie kann ich nun den Zusammenhang über ein Polynom 3. Grades ermitteln, bzw. die Koeffizienten des Polynoms? Das Modul Regression ist dafür ja ungeeignet, da auf der X-Achse immer die Zeit liegt. Grüße brb
  2. ok, danke! Eigentlich passiert das Malheur schon weit vorher, aber auch das ist in V13 behoben. Mein Worksheet versucht beim ersten Start aus einer Datei zu lesen die es noch nicht gibt. Und da wird dann in den ersten zu lesenden String "NOP" reingeschrieben. Wenn das niemand ändert und die Strings speichert, dann steht da eben "NOP" drin mit den beschriebenen Folgen. Danke, und beste Gruesse brb
  3. Hallo, in einer Datei wurden Strings gespeichert, z.B. mit Action "Write string range (file)". Aus irgendwelchen Gründen enthält ein String die Zeichenfolge NOP Werden die Strings zurückgelesen, z.B. mit Action "read string range (file)", so bricht DASYLab den Lesevorgang ab diesem String ab und meldet in der Console "file does not exist". a.) wie kann man das verhindern? (beachte: ich kann nicht verhindern, daß ein Kunde irgendwo NOP reinschreibt) b.) Ist NOP das einzige Triggerwort, oder gibt es noch andere "Befehle" die die Funktion von DASYLab beeinflussen? MNY THX!
  4. Super, funktioniert. Keine Nebeneffekte. Danke!
  5. Hallo! Hier ein Problem das durchaus auch für andere Peripherie so bestehen könnte. Im Lantronix-Modul WiPort gibt es GPIOs die sich nach Belieben als digitale In oder OUT konfigurieren lassen. Es werden einige als IN und einige als OUT konfiguriert. Das Lantronix Modul soll mit DASYLab gleichzeitig über ICom Input und Output kommunizieren. Das setzen des ersten GPIO geht über den Port 30704 im ICom Out Modul z.B. mit dem Befehl \x1A\x01\x00\x00\x00\x01\x00\x00\x00 Zurücksetzen geht mit \x1A\x01\x00\x00\x00\x00\x00\x00\x00 Die Konfiguration im ICom Setup lautet dabei Interface=TCP/IP,Host IP Address=192.168.0.20:30704 "Single commands" und "Enable control input" aktiviert. Das funktioniert. Es sollen andere GPIOs zyklisch abgefragt werden, also diejenigen, die als IN konfiguriert sind. Auch das geht über port 30704: ICom Input (Master) Data request = enabled Sampling interval in s = 1,00 Measurement data request = \x13\x00\x00\x00\x00\x00\x00\x00\x00 measurement data format = "\x13" b Die Konfiguration muß deshalb ebenfalls sein: Interface=TCP/IP,Host IP Address=192.168.0.20:30704 Auch das funktioniert. Aber Setzen und Abfrage zusammen in einem worksheet funktioniert nicht. ICom Out scheint blockiert zu sein. Wie kann man das bewerkstelligen? Vielen Dank für Vorschläge!
  6. Hallo! Modul "write data" möchte ich gerne bei "Unit" einen String verwenden, z.B. weil ich die Einheit während der Laufzeit vom Worksheet ändern will. Bei anderen Modulen funktioniert das auch, z.B. bei "digital meter". Leider nicht beim "write data"-modul. In den aufgezeichneten Ascii-Dateien ist immer die Einheit enthalten, welche zum Start des worksheets im String war. Meine Lösung besteht darin, daß ich den String im channel name eingefügt habe. Da geht es. Wie bekomme ich aber die leere eckige Klammer von den units weg? THX brb
  7. > ... stellt ... im Grunde keinen Fehler dar: ja, hatte ich erwartet, daß nicht beliebig große Werte zu verarbeiten sind. Deswegen der Hinweis auf die Begrenzung. > "Dass der Filter in Unendlich bzw. NaN steckenbleibt ist eigentlich zu erwarten, Nicht unbedingt. Bei FIR-Filtern müßte der zu große Wert irgendwann durchgelaufen sein. Bei IIR und Biquads ja. Offensichtlich sind die Filtermodule rekursiv aufgebaut. Daher wäre eine Action "Filter - Reset oder Restart" ganz nützlich. Eventuell automatischer Reset, denn wenn es blockiert macht es keinen Sinn fortzufahren. Das wäre auch viel effektiver, wie wenn man das sowieso Notwendige zu Fuß programmieren muß. > Einen 'echten' Filter könnte man auch nicht mit so hohen Amplituden füttern." Schon, aber ich sehe das anders. 1e9 oder 1e12 ist noch sehr weit weg von 3.4e38. Ein vorteil der digitalen Verarbeitung liegt doch gerade darin, analog unmögliche Sachen zu realisieren. Und wo liegt die Grenze? Was darf ich gerade noch und was darf ich nicht? Wenn ERR kommt ist das klar. Wenn es schleichend kommt, dann wirds schwierig. Mein Wunsch wäre, wenn die Entwickler das auf der to-do-Liste lassen würden. Grüße brb
  8. ok, die Formalen sollten heissen: a) ( (IN(0) < 3.4e38) AND (IN(0) > -3.4e38) ) *IN(0) siehe a) c) ( (IN(0) < 3.4e38) AND (IN(0) > -3.4e38) ) * 5 Anbei das Worksheet. Im Layout kann man zum Testen oben links mit Doppelclick eine Variable ändern, die regelmäßig eingelesen wird und zu den Filtern bzw. Formula Interpretern geht. Falls die Filter 1. Ordnung getestet werden sollen müssen die zuerst von 2. Ordnung auf 1. umgestellt werden. Der gesamte Effekt scheint von der Timebase abhängig zu sein. Bei Timebase 10Hz und Blocksize 1 z.B. ist alles ok. Vielen Dank&Grüße brb Filter Test.DSB
  9. wieder falsch. der will meine Formeln nicht... ratlos, brb
  10. Moment, hier stimmt etwas nicht. Beim Posting sind Sachen verloren gegangen. Die erste Formel sollte heissen: ((IN(0)-3.4e38))*IN(0) 2. Formel auch wieder: ((IN(0)-3.4e38))*IN(0) und die 3. Formel: ((IN(0)-3.4e38))*5
  11. ja klar, meine Methode war: ((IN(0)-3.4e38))*IN(0) Und genau das funktioniert nicht! In Ihrer Lösung habe ich allerdings das "+ 0" noch nicht verstanden. Was bringt das? Der letzte Teil meines 1. Postings ist noch mißverständlich und inzwischen habe ich mehr herausgefunden: ((IN(0)-3.4e38))*IN(0) geht bei Werten >3.4e38 im Formula Interpreter nicht, d.h. bei zu großen Werten am Eingang gibt es am Ausgang keine 0. Hingegen ((IN(0)-3.4e38))*5 ist immun gegen Werte >3.4e38. Es wird korrekt 5 ausgegeben, falls sich die Werte innerhalb der Grenzen befinden. Es wird 0 ausgegeben, wenn "böse" Werte am Eingang erscheinen. Damit kann ich den Latch steuern und die Filter vor dem Locked-in-Syndrom bewahren. Statt einem Latch könnte man auch ein Relay nehmen, nur ist dann der Datenstrom unterbrochen, was in meiner Anwendung zu blocklength u. time information mismatch führen würde. Und jetzt kommt noch etwas hinzu, was in meiner Anwendung ebenfalls zum sonderbaren Verhalten beigetragen hat: Ein Tiefpass 1.Ordnung geht nicht mehr auf 0 zurück, wenn am Eingang ein Sprung von sehr großen Werten nach 0 erfolgt. Dabei hängt die Abweichung von 0 im Endzustand davon ab, wie groß der Sprung war. Es reicht auch aus, wenn der Sprung nicht auf 0 geht und einfach nur mehrere Zehnerpotenzen umfaßt. Bei einem Sprung von 1e9 nach 0 bleiben 6.3e-8 übrig, bei 1e18 nach sind es schon 3.56, und bei 1e30 nach 0 sind es 2.8e13. Wenn also wie in meinem Fall versehentlich viel zu große Werte in den TP laufen, dann geht das Filter nie wieder auf 0 zurück. Eventuell ist das immer so, auch bei kleinen Werten, nur merkt das da niemand. Für mich sieht das so aus, also ob es intern irgendwo ein Rundungsproblem gibt? Bitbreite reicht nicht, Rekursionsfehler, ... Bei Filtern höherer Ordnung konnte ich dieses Verhalten bis jetzt nicht beobachten. Ich werde ein Worksheet zur Demo vorbereiten...
  12. Hallo & guten Abend allerseits, nachdem ich hier hin und wieder ohne Anmeldung reingesehen habe, glaube ich doch den ein oder anderen sinnvollen Hinweis zu Fragen geben zu können und hoffe im Gegenzug auf einen kompetenten Austausch. In diesem Sinne beste Grüße ins Forum. Der erste Hinweis/Frage gilt dem Modul "Digital Filter": An einer COM Schnittstelle werden Daten eines Sensors entgegengenommen. Es kann vorkommen, daß der Anwender den Sensor einfach ab- und wieder ansteckt. Das System muß weiterlaufen. Dadurch werden in einigen Fällen für sehr kurze Zeit fehlerhafte Daten eingelesen, z.B. Werte >3.4e38, weil jede Menge \xFF reinkommen. In der nachfolgenden Signalkette befindet sich ein digitales Filter. Filter kommen offensichtlich mit Werten >3.4e38 nicht klar. Das wäre nicht weiter störend, wenn nicht ein Filter für alle Zeit danach nur noch "ERR" produziert. Es ist sogar so, daß vorgeschaltete andere Module mit großen Werten klarkommen, die zu großen Werte zu 0 machen und das Filter dann trotzdem die Signalverarbeitung lahmlegt. Beispiel: Die zu großen Werte werden mit dem Formula Interpreter zu 0 gemacht. Am Ausgang des Formula Interpreters zeigt ein Digital Meter im Fehlerfall korrekt 0 an. Ein nachfolgendes Filter und ein darauf folgendes Digital Meter produzieren trotzdem nur noch "ERR", auch dann wenn die Werte wieder unter 3.4e38 gehen. Meine Lösung besteht aus einem Formula Interpreter, der einen Latch steuert, also eine Art Limiter. Dann funktioniert es. Hat das schon mal jemand beobachtet und gibt es eine bessere/andere/einfachere Lösung? Eine andere Lösung vor allem im Hinblick auf möglichst wenig Rechenaufwand? Grüße, brb
×
×
  • Create New...