Jump to content

HolWo

Administratoren
  • Gesamte Inhalte

    248
  • Benutzer seit

  • Letzter Besuch

  • Tagessiege

    3

HolWo hat zuletzt am 11. Oktober 2016 gewonnen

HolWo hat die beliebtesten Inhalte erstellt!

Über HolWo

  • Rang
    DASYmatrix 001

Profile Information

  • Gender
    Not Telling

Letzte Besucher des Profils

Der "Letzte Profil-Besucher"-Block ist deaktiviert und wird anderen Benutzern nicht angezeit.

Aktivieren
  1. HolWo

    Skriptmodul-Zeitbasis

    Hallo! Hier fehlt leider im Skript in der Funktion SetupFifo die explizite Rückgabe von True. Ohne explizites return True bzw. return False wird automatisch None zurückgegeben. Wenn das DASYLab-Subsystem den Rückgabewert None erkennt, dann wird die SetupFifo-Funktion des Skripts ignoriert und die Optionen des Dialogs Kanal-Eigenschaften werden stattdessen angewendet -- aber ohne die Information über Abtastrate und Blockgröße auf die Ausgänge anzuwenden: Da man aber im Beispiel eine Datenquelle als Modul vorliegen hat, muss man über die SetupFifo-Funktion nachfolgenden Modulen mitteilen, mit welchen Eigenschaften die Daten während der laufenden Messung ankommen werden (u.a. Abtastrate und Blockgröße). Da die SetupFifo durch das fehlende return True aber gar keine Auswirkung hat, bleiben die Eigenschaften des ausgegebenen Datenstroms nach dem Laden des fehlerhaften(!) Skripts in das Modul aber unverändert (hier: info.timebaseID = 2, also Treiber-Zeitbasis). Ändert man nun im Dialog die Zeitbasis-Einstellung, dann werden in der ProcessData-Funktion zwar die von der nun ausgewählten Zeitbasis vorgegebene Abtastrate und Blockgröße an den leeren angeforderten Block (Funktion GetOutputBlock) geschrieben... aber der leere Block ist weiterhin mit den Eigenschaften der Treiber-Zeitbasis vorkonfiguriert, weil das return True fehlt in der SetupFifo-Funktion! Konkret für das Beispiel heisst das: In der info-Klasse ist die Zeitbasis-ID 2 vorgegeben, die Eigenschaften der Ausgänge werden also von der Treiber-Zeitbasis abgeleitet. Die Treiber-Zeitbasis ist im Schaltbild auf 10 Hz, Blockgröße 4 eingestellt. Startet man die Messung funktioniert alles wie erwartet. Ändert man nun die Zeitbasis auf DASYLab (10000 Hz, BG 1000 im Beispiel), dann werden in der ProcessData-Funktion die Eigenschaften zwar von der DASYLab-Zeitbasis abgefragt, aber durch Funktion GetOutputBlock stellt DASYLab nachwievor einen leeren Block bereit, der eine maximale(!) Blockgröße von 4 hat -- weil die SetupFifo-Funktion des Skripts keine Auswirkung hat und Eigenschaften der Ausgänge nicht an die Zeitbasis-Änderung im Dialog angepasst werden. Die Eigenschaft BlockSize, die an jeden Datenblock noch einmal explizit drangeschrieben wird, ist die reale Blockgröße, die immer kleiner oder gleich der maximalen Blockgröße ist, niemals größer. Da die "alte" maximale Blockgröße aber in diesem Beispiel quasi fest 4 ist (auch wenn's langsam langweilig wird : wegen des fehlenden return True in der SetupFifo-Funktion!), hat der angeforderte Datenblock Platz für höchstens vier Datenwerte. Durch die Umstellung im Dialog auf die DASYLab-Zeitbasis aber sollen 1000 Werte in den Block geschrieben werden. Hier kommt es dann zum Fehler FIFO data mismatch, weil die durch die in der SetupFifo vereinbarte maximale Blockgröße durch das Falschbelegen in der ProcessData-Funktion nicht eingehalten wird -- 1000 Werte passen nunmal nicht in einen Block mit nur 4 Plätzen. Lange Rede, kurzer Sinn: die SetupFifo-Funktion explizit mit return True abschliessen!
  2. Hallo, ich habe ein Beispiel angehängt von dem Sie sich inspierieren lassen können: die Excel-Tabelle müssen Sie zunächst im Windows ODBC Administrator** als Datenquelle namens "Obst-DB" einrichten (s. Schaltbild, ODBC-Module). Das Beispielschaltbild kann ab einschließlich DASYLab 13 verwendet werden. ** Unbedingt die 32-Bit-Version verwenden, wenn Sie ein 64-Bit-Betriebssystem einsetzen: c:\windows\syswow64\odbcad32.exe DASYLab 13_ODBC_Obst-Beispiel.zip
  3. HolWo

    PID PWM Signal erzeugen

    Das PID-Modul gibt keine PWM-Signale aus. Wenn bspw. die Parameter P=1, I=0 und D=0 gewählt sind, dann gibt das Modul die Differenz zwischen den Eingängen (Sollwert oben, Istwert unten) aus.
  4. HolWo

    Verwendung von 2 x NI cDAQ-9174

    DASYLabs bis einschließlich Version 12 sind empfindlich ggü. nicht lauffähigen Tasks, unabhängig davon, ob die Tasks fehlerhaft konfiguriert sind oder verknüpfte Geräte nicht angeschlossen sind. Es kann durchaus sein, dass die "ersten" Tasks, die im MAX lauffähig sind, im DASYLab 12 ebenfalls funktionieren. D.h. alle bis zum ersten nicht lauffähigen Task erfolgreich importierten Tasks können genutzt werden, alle folgenden Tasks -- selbst funktionierende, die nach einem fehlerhaften Task importiert werden -- nicht mehr. Die Fehlermeldung zeigt "nur" an, dass der Abgleich nicht erfolgreich gewesen ist; das bedeutet aber nicht, dass gar nichts importiert werden konnte. Ab einschließlich DASYLab 13 wurde das Verhalten angepasst, sodass bereits im MAX nicht lauffähige Tasks übersprungen werden und die Tasks, die im MAX funktionieren, ins DASYLab importiert werden können. Unabhängig davon sollten Sie Ihren MAX/DAQmx aktualisieren: die "frühen 15er-Versionen" sind nicht empfohlen, wenn DASYLab zum Einsatz kommt. Ab MAX/DAQmx 15.5 und neuer ist man wieder auf der sicheren Seite.
  5. HolWo

    DASYLab – Grundlagenschulung

    bis
    DASYLab – Grundlagenschulung
  6. HolWo

    DASYLab – Skript-Modul

    bis
    DASYLab – Skript-Modul
  7. HolWo

    DASYLab – Grundlagenschulung

    bis
    DASYLab – Grundlagenschulung
  8. HolWo

    DASYLab – Skript-Modul

    bis
    DASYLab – Skript-Modul
  9. HolWo

    DASYLab – Grundlagenschulung

    bis
    DASYLab – Grundlagenschulung
  10. HolWo

    DASYLab – Skript-Modul

    bis
    DASYLab – Skript-Modul
  11. HolWo

    DASYLab – Grundlagenschulung

    bis
    DASYLab – Grundlagenschulung
  12. HolWo

    DASYLab – Skript-Modul

    bis
    DASYLab – Skript-Modul
  13. HolWo

    Zeitbegrenzter Puls an digitalem Ausgang

    Hallo! Das Verzögerungsmodul verzögert nur den Datenstrom für die eingestellte Dauer, d.h. ein Impuls wird nicht in die Länge gezogen, sondern nur "später" aus dem Modul ausgegeben. Sie benötigen vmtl. einen High-Pegel, der für x Sekunden anliegt und dann wieder auf Low zurückfällt. Probieren Sie hierzu einen Schalter (Impulstaster) und ein Trigger-Modul. In der Lite-Version steht nur der Vor-/Nach-Trigger zur Verfügung, der eigentlich für eine Bereichsüberwachung (Ober-/Untergrenze) gedacht ist. Der Schalter gibt entweder 0.0V (AUS) aus oder 5.0V (EIN). Der Impuls-Taster-Modus bewirkt, dass das Schaltermodul beim einschalten einmal kurz 5.0V ausgibt und automatisch wieder auf 0.0V zurückspringt. Diesen Peak nach TTL-High kann man mit dem Trigger "abfragen": - Untergrenze=0.0V - Obergrenze=5.1V - Bereich: innerhalb Wenn das Triggermodul nun den kurzen Peak nach 5.0V vom Schalter ampfängt, gibt das Modul seinerseits 5.0V aus, und fällt wieder auf 0.0V zurück sobald 0.0V vom Schalter kommt. Das hilft bisher noch nicht viel -- solange man die Mindestdauer des Triggers nicht anpasst: Hier kann man die gewünschte Zeit (oder die Anzahl d. Werte) einstellen, die der Trigger weiterhin 5.0V ausgeben soll, selbst dann, wenn das Eingangssignal schon längst wieder aus dem Überwachungsbereich ausgetreten ist! Den Trigger nun mit einem Ausgangsmodul verbinden und durch einmalige Betätigung des Schalters kann man x Sekunden lang 5.0V an das Ausgangsmodul liefern.
  14. Ja, das ist aber kein Fehler, sondern liegt daran, dass man beim Formelinterpreter in jedem Kanal eine Formel hinterlegen kann, die Daten von beliebigen Eingängen verrechnen kann. D.h. die Formel in Kanal 0 gibt ihr Ergbnis an Ausgang 0 aus, nutzt aber z.B. Daten der Eingänge 8 und 11 -- hier gibt es eine beliebige Zuordnung von Eingängen zu Ausgängen, sodass man kaum ermitteln kann, welchen Kanalnamen eines Eingangs man "durchschleifen" soll. Daher "muss" man beim Formelinterpreter für jeden Kanal selber den Namen vergeben.
  15. HolWo

    DASYLab – Skript-Modul

    bis
    DASYLab – Skript-Modul
×