Matlab: for-Schleife beschleunigen

[pfeili (Gast)]

Liebe Leute,

ich bin seit wenigen Monaten Verantwortlicher für ein Labor, in welchem 
mein Vorgänger Schrittmotoren mittels DAS1600-Karte (Firma Keithley) 
über das Programm Viewdac (DOS) angesteuert hatte. Nun möchte ich die 
Messtechnik aktualisieren und alles MATLAB-tauglich machen. Dazu habe 
ich mir das KUSB3116 von Keithley angeschafft, seine Programme 
durchgesehen und versucht in Matlab zu übertragen. Es geht um das Senden 
von 8bit-Output in einer Schleife. Ich gebe vielleicht gleich mal ein 
beispiel an, welches in der callback eines start-pushbuttons auftauchen 
sollte:

if (~isempty(daqfind))
    stop(daqfind)
end

% Registering the Hardware Driver Adaptor
daqregister('C:/Programme/Keithley Instruments/DAQAdaptorforMATLAB/dtol.dll');

% Erzeugen eines digitalen I/O-Objektes mit dem verwendeten
% KUSB-Matlab-Adapter
dio = digitalio('dtol');

% Definieren des Outputkanals für Drehrichtung (Pin 23 am DIO)
addline(dio, 3, 1, 'Out');
% Definieren des Outputkanals für Takt (Pin 35 am DIO)
addline(dio, 15, 1, 'Out');

% Winkel abgreifen
winkel = str2double(get(handles.rotedit, 'String'));

% Schrittzahl
schritte = 32 * winkel;

% Drehrichtung ändern
putvalue(dio.line(1), 1)

for n =1:schritte
    putvalue(dio.line(2), 1)        % Takt, steigende Flanke (high)
    putvalue(dio.line(2), 0)        % Takt, fallende Flanke (low)
end

delete (dio);
clear dio;

Der angesprochene Schrittmotor dreht in die entsprechende Richtung, aber 
im Vergleich zur DOS-Ansteuerung zu langsam. Nun habe ich sowohl bei der 
DOS-Ansteuerung als auch bei meinem Matlab-Programm mit dem Oszi die 
Sendesignale (Rechteckimpulse) gemessen und festgestellt:

- beim Matlab-Skript: 4.5ms high und 4.5ms low-Signale
- im Vergleich dazu beim DOS-Programm: 2ms high und nur 0.8ms 
low-Signale ("Nadelimpulse")

Nun meine Frage, wie kann ich die Zeit festlegen, wie lange high bzw. 
low anliegen soll? Kann ich in irgendeiner Art meine Sendefrequenz 
erhöhen, also etwas schnelleres, als meine Schleife generieren?

Für Unterstützung wäre ich sehr dankbar.

Mit freundlichen Grüßen

Felix Rothe

[lowlevel (Gast)]

Halli Hallo,

das könnte schwer werden, da du in deiner momentanen schleife keinerlei 
timing drin hast. Also keine wartezeit zwischen den ausgaben. das heisst 
das der treiber mit seiner max. geschwindigkeit arbeitet und das sind 
4.5ms. da müsstest du mal schauen wie der treiber genau arbeitet.

Gruß Stephan Storm ;-D

[Thorsten O. (Firma: mechapro GmbH) (ostermann)]

Hallo!

Matlab ist kein Echtzeit-System. Unter DOS sah die Lage etwas anders 
aus, da ein Programm da mangels Multitasking die CPU für sich alleine 
hatte. Wenn Du das Echtzeitfähig machen willst, sehe ich nur 2 Lösungen:
1.) Matlab xPC Target auf einem Slave-PC verwenden
2.) Eine externe Hardware (µC) einsetzen, die du über eine DLL aus 
Matlab ansprechen kannst.

Lösung 1 dürfte ausserhalb von Universitäten schon an den Lizenzkosten 
scheitern, falls die entsprechenden Toolboxen nicht schon vorhanden 
sind. Lösung 2 erfordert u.U. etwas mehr Programmierkenntnisse. Aber die 
scheinen ja vorhanden zu sein.

Ich habe wärend meiner Zeit an der RWTH Treiber für den Einsatz von 
Adlink DAC/ADC-Karten für xPC entwickelt, würde aber trotzdem Lösung 2 
bevorzugen. Für Labview haben wir hier schon für einen Kunden eine 
Wrapper-DLL gebaut, die den Zugriff auf unseren 
USB-Schrittmotorcontroller so gekapselt hat, dass man das Ding unter 
Labview ansteuern kann.

Mit freundlichen Grüßen
Thorsten Ostermann

[pfeili (Gast)]

Danke für eure Anworten.

@Stephan: Wo genau kann ich das einsehen? Was kann ich daran ändern? 
Scheinbar sind 4.5ms wirklich das höchste der Gefühle, obwohl mir das 
unerklärlich ist: ein 3,4 GHz Prozessor mit 2 GB Ram verliert gegen 
einen Dos-Rechner mit vielleicht 33 MHz und 16 MB RAM.

@Thorsten: Was kannst du mir für MikroController empfehlen. Ich habe 
mich schon mal auf eurer HP umgesehen, habe aber keine Erfahrungen mit 
MikroControllern. Problem ist natürlich (wie überall) das beschränkte 
Budget. Kaufen könnte man alles, aber ich muss eben aus der vorhandenen 
Technik das Beste herausholen. Ich könnte ja auf Dos-Ebene 
weiterarbeiten, halte das allerdings in heutiger Zeit für umständlich. 
Es schreckt die Studenten wahrscheinlich teilweise sogar ab. ;)

Für eure Antworten bin ich euch sehr dankbar.

Beste Grüße

pfeili

[Artur R. (artur2000)]

Versuch mal im Taskmanager den Matlab Task die Priorität "Echtzeit" 
einzustellen.

[Andreas S. (andreas) (Admin)]

Das Problem ist nicht die for-Schleife, die ist mehr als schnell genug, 
sondern der DLL-Aufruf bzw. das was die DLL tut.

[Thorsten O. (Firma: mechapro GmbH) (ostermann)]

Hallo Pfeili!

Welchen Controller du nimmst ist eigentlich egal. Es reicht ja, wenn der 
eine serielle Schnittstelle und ein paar I/Os hat. Da tut's jeder kleine 
AVR, PIC oder 8051 (wenn man sich die noch antun will).

Mit freundlichen Grüßen
Thorsten Ostermann

[pfeili (Gast)]

Hallo Leute,

danke wiederum für eure Antworten.


@Artur: Das habe ich schon probiert, brachte jedoch keinen Erfolg.

@Andreas: Habe ich eine Chance daran etwas zu ändern bzw. die DLL zu 
beschleunigen?

@Thorsten: Danke. Ich schau mich mal um.


Beste Grüße

pfeili

[Peter D. (pdiener)]

Also in Ubuntu mit RTAI Kernelmodul kann man Schrittmotoren gerade so 
ansteuern, allerdings direkt über den Parallelport. Ich schaffe damit an 
meinem PC eine Taktfrequenz von 36kHz für die Schrittsignale (hab danach 
noch einen Schrittmotorcontroller). Unter Windows kann ich mir nicht 
vorstellen, dass das auch nur ansatzweise funktionieren kann. Niemand 
garantiert einem dort die zeitnahe Ausführung von Prozessen.

Das nächste Problem ist, dass USB nicht dafür gedacht ist und viele 
Treiber nur auf Millisekundenbasis Blöcke senden.

Eine Lösung mit externem Mikrocontroller ist dagegen sehr einfach, 
solange man das Niveau der Datenübertragung vom PC dorthin hoch hält. 
Damit meine ich z.B. Anfragen wie "fahre Position 32Grad mit 
Maximalgeschwindigkeit 50Grad/Sekunde und Rampen von 25Grad/Sekunde² an"

Grüße,

Peter

[Thorsten Ostermann (Gast)]

Hallo Peter!

Das geht unter Windows auch. Allerdings muss man dann, ähnlich wie bei 
RT-Linux, dem Windows-Kernel einen echtzeitfähigen Scheduler 
unterschieben. Kommerzielle CNC-Programme, die das so machen, sind 
WinPCNC (light/economy) und Mach3. Andere Anbieter setzen dagegen auf 
externe µC, z.B. bei pcdreh für Windows.

Mit freundlichen Grüßen
Thorsten Ostermann

[Peter D. (pdiener)]

Das mit dem Echtzeit-Scheduler unter Windows hab ich noch nicht gewusst.
Trotzdem kann ich mir nicht vorstellen, dass das über eine GPIO-Karte, 
die über USB angeschlossen ist, flüssig funktioniert. Da müsste der 
USB-Treiber auch noch echtzeitgeeignet sein.

Grüße,

Peter

[pfeili (Gast)]

Hallo Leute,

hier einmal die Antwort vom Hersteller:

"[...]beim KUSB-3116 sind die DIO’s rein Software gesteuert. Es gibt 
leider keine Möglichkeit diese schneller anzusteuern, als über eine 
Softwareschleife. Eine Taktvorgabe ist also nicht möglich. Das die 
Ansteuerung über DOS schneller ist, liegt einfach daran das DOS deutlich 
weniger Ressourcen beansprucht als Windows. Folge: Schleifen laufen 
deutlich schneller .[...]"

Diese Antwort stimmt mich natürlich nicht optimistisch. Scheinbar kann 
ich mich davon verabschieden, die Schrittmotoren auf diese Weise 
ordentlich angesteuert zu bekommen, was mich den enormen 
Anschaffungspreis des Geräts sehr in Frage stellen lässt. Natürlich kann 
ich das Gerät für andere Sachen gut gebrauchen, aber ich dachte eben, 
dass ich damit flexibel an verschiedenen Versuchsständen arbeiten kann.

Wäre ich mit einer PCI-DIO-Variante besser gekommen, also würde sie 
schneller arbeiten?

Hat noch jemand eine Idee? Kann ich die DLL evtl. noch beschleunigen?

Beste Grüße

pfeili

[Thorsten O. (Firma: mechapro GmbH) (ostermann)]

Hallo Pfeili!

Mit einer PCI-I/O Karte sollte das deutlich schneller gehen. Echte 
Echtzeit (sprich Frequenzen im 2-stelligen kHz Bereich und niedrigen 
Jitter) wirst du aber auch damit nicht hinbekommen. Schau mal bei 
Acceed.de, die haben solche Karten, die zu den guten alten 8255 
kompatibel sind. Mit den Karten von Adlink (z.B. PCI-7224) habe ich auch 
gute Erfahrungen gemacht, auch mit xPC Target.

Alternativ geht es weiterhin über USB, aber dann mit high-level 
Fahrbefehlen. Da hätte ich ein passendes Produkt für bis zu 4 Achsen 
incl. DLL im Programm. Bitte melde Dich bei Bedarf, eine 
Matlab-Anwendung haben wir bisher noch nicht gemacht, das wäre eine 
schöne Referenz.

Mit freundlichen Grüßen
Thorsten Ostermann

[l0wside (Gast)]

pfeili schrieb:
> Liebe Leute,
>
> ich bin seit wenigen Monaten Verantwortlicher für ein Labor, in welchem
> mein Vorgänger Schrittmotoren mittels DAS1600-Karte (Firma Keithley)
> über das Programm Viewdac (DOS) angesteuert hatte. Nun möchte ich die
> Messtechnik aktualisieren und alles MATLAB-tauglich machen. Dazu habe
> ich mir das KUSB3116 von Keithley angeschafft, seine Programme
> durchgesehen und versucht in Matlab zu übertragen.

Warum belässt Du nicht den alten PC und machst nur die Drehzahl- bzw. 
-richtungsvorgabe in Matlab? Läuft ungefähr auf die µC-Lösung hinaus und 
braucht minimal bis keine Zusatzhardware/Bastelei. Ist nur ein bisschen 
groß und "unmodern".