Hallo ich versuche grade ein altes Oscilloscope TDS 540A von Textronic über eine Gpib Schnittstelle zum laufen zu bekommen. Habe ein kleines C Programm (ab)geschriebes. Hab auch ehrlich gesagt nicht wirklich viel Ahnung vom Programmieren. Im Prinzip funktionierts(senden und empfangen von Daten), aber wenn ich einen leeren Puffer auslese stürzt das Programm ab. Die Funktion von win xp die, die Schnittstelle ausliest heißt ibrd. hat jemand eine Idee? Hab versucht eine Try catch Funktion einzubauen um diesen Fehler zu beheben. Aber leider funktioniert das nicht. Wäre schön wenn jemand noch eine Idee hat.
> Die Funktion von win xp die, die Schnittstelle ausliest heißt ibrd.
Hä?
ibrd ist zumindest keine C funktion. http://www-user.tu-chemnitz.de/~heha/viewzip.cgi/messtech/ddegpib.zip/SRC/DDEGPIB.RTF auf Seite zwölf wird sie ein wenig erklärt. da scheint es wohl auch Probleme zu machen: Beitrag "GBIP Prob." besser?
Nein, keinen Deut besser. Du setzt zur Kommunikation mit GPIB eine Softwarelösung "DDEGPIB" ein, die Henrik Haftmann entwickelt hat: http://www-user.tu-chemnitz.de/~heha/viewzip.cgi/messtech/ddegpib.zip/ Und mit dieser Software hast Du ein Problem. Das hat mit Beitrag "GBIP Prob." rein gar nichts zu tun, da dort diese Software nicht eingesetzt wird. Henrik hat zwei Varianten seiner Softwarelösung veröffentlicht, eine 16-Bit und eine 32-Bit-Version; Du verlinkst auf die 16-Bit-Version. Möglicherweise ist das ja schon das Problem. Da Henrik den Sourcecode zur Verfügung gestellt hat, sollte es für Dich ein Leichtes sein, einen Debugger zu verwenden und die Absturzursache zu finden.
Nein, diese Links sollten nur illustrieren das schon jemand Probleme mit dem Befehl ibrd hat: Beitrag "GBIP Prob." und der andere sollte vielleicht etwas licht ins Dunkel über das Geheimnis ibrd bringen. Jetzt hab ich auch den Quelltext wieder gefunden. Quelltext: #include <windows.h> #include "Decl-32.h" nach etwas Quelltext folgt: char gpibreadbuf[255], gpibwritebuf[255], termstr[3], gpibreadbufbin[220000] nach etwas noch mehr Quelltext folgt: char* gpibreceive(int i) { int e; memset(&gpibreadbuf,0,sizeof(gpibreadbuf)); Try { //die Try funktion ibrd(device[i],(void*)gpibreadbuf,sizeof(gpibreadbuf)-1);//Auslesen! } Catch (e) return (char*) "Error"; if (ibsta & ERR) { lastError = iberr; return (char*)lastError; } return gpibreadbuf; } und dies ist aus der Header Datei Decl-32.h: extern int __stdcall ibrd (int ud, PVOID buf, long cnt); Beim Aufrufen des Befehls gpibreceive stürzt das Prog. bei leerem Puffer ab. **In Hoffnung verstanden zu werden**
Das habe ich zur Funktion stdcall gefunden: http://msdn.microsoft.com/en-us/library/zxk0tw93(VS.71).aspx was mich vermuten lässt, dass dieser Befehl nicht zur GPIB-Karte bzw. dessen Treiber sondern zu Windows gehören müsste. Ich habe des Manuell für die GPIB-Karte drangehangen. Dort wird auf Seite 2-26 dieser Befehl mehr oder weniger dokumentiert. Dort werden auch zwei Errors erklärt, die aber in meinem Verständis (gut das muss nichts heißen) trotzdem nicht zum Absturz führen sollten, wenn grade nichts im Puffer der Schnittstelle steht stehen.
Aha. Du scheinst also eine DLL und zugehörigen Krempel von National Instruments zu nutzen. Ganz toll. Warum kannst Du das nicht von vornherein erwähnen? Was Du bislang gemacht hast, ähnelt dem Versuch, ein Problem mit Windows zu lösen, das Du anhand von Linux-Dokumentation schilderst. > Beim Aufrufen des Befehls gpibreceive stürzt das Prog. bei > leerem Puffer ab. Das ist kein Befehl, sondern eine (von Dir geschriebene?) Funktion. Und wenn "das Prog." dabei abstürzt, dann könntest Du es ja mal im Debugger laufenlassen, um herauszufinden, was exakt schiefgeht. > Das habe ich zur Funktion stdcall gefunden: > http://msdn.microsoft.com/en-us/library/zxk0tw93(VS.71).aspx stdcall ist keine Funktion, sondern eine Aufrufkonvention. Die beschreibt, wie der C-Compiler Funktionen aufruft, es gibt die übliche Konvention, daß der Aufrufer sich um das Aufräumen des Stacks kümmert, und die aus der Pascal-Welt stammende Variante, daß das von der aufgerufenen Funktion erledigt wird. > was mich vermuten lässt, dass dieser Befehl nicht zur GPIB- > Karte bzw.dessen Treiber sondern zu Windows gehören müsste. Was exakt meinst Du jetzt mit "diesem Befehl"? stdcall oder ibrd?
läuft bei dir schon? was für eine GPIB-Karte hast du? "ibrd" ist eine Fuktion von National Instruments. Gruß Andreas
>"ibrd" ist eine Fuktion von National Instruments.
Sowas findet man auch in HP-Basic-Programmen.
Um den GPIB zu programmieren, bieten die Schnittstellenkarten-Hersteller
i.d.R. auch Bibliotheken für verschiedene Programmiersprachen an.
Eine Art Norm gibt es auch: VISA
Hallo erstmal vielen Dank für die schnelle Antwort, vorallem von Rufus das Problem ist gelöst leider nicht von mir. Offensichtlich tritt der Fehler nicht auf wenn man eine Liste anstatt einer Zahl als Fehlerindex übergibt. Versuche noch den Quelltext zu bekommen, würde ihn dann Posten Bei der Karte handelt es sich um die KPCI-488LPA GPIB Gruß diag
na dann sind die Befehle von Keithley und National eben gleich... Dein Auslesebuffer ist sehr gross (220000 char's). Werden da die ganze Plots ausgelesen? Haste schon mit SRQs probiert? Vielleicht ist der Oszi noch nicht fertig und du fragst schon ab? Mach Anzahl der Werte kleiner (z.B. 10) und eine Wartezeit zwischen setzen und lesen einfügen. Gruß Andreas
Hallo, hier ist wie versprochen der Quelltext zu dem ibrd Problem bei dem beim Auslesen der Schnittstelle kein Absturz mehr kommt. void gpibreceive(int index) { memset(&gpibreadbuf,0,sizeof(gpibreadbuf)); // Clear buffer ibrd(device[index],(void*)gpibreadbuf,sizeof(gpibreadbuf)-1); // Try to read if (ibsta & ERR) { returnvalues(GPIBIBRDERROR, (DWORD) iberr); return; } MLPutFunction(stdlink, "List", 2); MLPutInteger(stdlink, 0); MLPutString(stdlink, gpibreadbuf); return;
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.