VEEforum.de deutschsprachiges Forum für VEE Entwickler

Normale Version: Win32 Wait-Funktionen
Du siehst gerade eine vereinfachte Darstellung unserer Inhalte. Normale Ansicht mit richtiger Formatierung.
Gibt es im VEE eine art "Win32 Wait-Funktionen".
Würde es für ein Event Handle bei einem CAN-Interface benötigen.
Bisher sende ich immer den Befehl CAN-Lesen. Der API Treiber kann
aber auch eine Windows Event-Objekt einsetzte.
Hat von euch Erfahrungen in diesem Bereich?
Hi,

egal wie du es anstellst, ohne die "Repeat-Objekte" geht's nicht.
Ob du das Buffer-Register ausliest (was du ja mit CAN-Lesen machts) oder auf ein einzelnen Status-Event wartest, ist eigentlich schnuppe.

Abfragen kannst du immer nur über die API in einer Schleife oder halt manuell.
Das sollte aber generell funktionieren. Ich habe eine CAN-Abfrage/Steuerung damit http://www.peak-system.com/db/de/pcanusb.html erstellt, das geht wunderbar. :wink:
hi bratbaecker,

genau den selben dongle habe ich auch.
Eine CAN-Abfrage schaut momentan bei mir so aus das
ich permanent die Funktion CAN_Read aufrufe.
Ist nichts am Bus oder im Buffer, bekomme ich 0x20 zurück
(CAN_ERR_QRCVEMPTY 0x0020 // Receive queue is empty)
Wenn was da ist, bekomme ich 0x00 zurück.
Mittels "IF" frage ich halt den Return_Value immer ab.
Was mich halt stört drann ist die Auslastung: 99% CPU

Mich würd auch Interessieren wie du die Library importiert hast.
Genaugenommen das Definition-File (.h).
Hab die Anpassen müssen, weil die Header-Datei Zeiger auf Strukturen usw. hat, und gewisse variablen-deklarationen die VEE nicht erkennt.

aus
DWORD __stdcall CAN_Read(TPCANMsg* pMsgBuff );
wurde bei mir:
long __stdcall CAN_Read(short* pMsgBuff );

Beim Ausführen von CAN_Read sind die Informationen irgendwie (weis
jetzt nicht mehr in welcher Reihenfolge) in pMsgBuff drinnen.

Wie hast du das gelöst?
hier ein ausschnitt
Hi,

ich poste morgen mal was dazu.
Hier habe ich ein Beispiel für dich ->
http://www.veeforum.de/forum/downloads.p...l&df_id=13
Die Definitionsdatei .h ist in der UserFunktion Load_PCAN_USB
Die Daten werden in 4 Integer32 Werte ver/entpackt, Details der CAN Werte befinden sich im Record. So kann man die Daten komfortabel als Byte manipulieren (ohne wilde Umrechnungen).

Zitat:Mittels "IF" frage ich halt den Return_Value immer ab.
Was mich halt stört drann ist die Auslastung: 99% CPU
Normalerweise fragt man ja den Bus nach der Sendung von Daten (z.B. Bite) wieder ab.
Ab einem gewissen Abfragezyklus wir die CPU-Auslastung unweigerlich hoch gehen <0.3 sec, wie man das vermeiden kann weiß ich allerdings auch nicht, es stört aber normalweise auch nicht.

Falls du Anregungen oder Verbessungen zum Programm hast, dann posten. :wink:
sehr interessant wie du das geschrieben hast, kann ich viel draus lernen.
im prinzip hab ich genau das selbe gemacht wie du.
die messagebytes die als integer pMsgBuff übergeben werden,
convertiere ich als Hex-String.
Beim Eingeben einer Message mach ich auch das selbe.
Das zyklische Abfragen ist deshalb so wichtig, weil bei uns die Steuergeräte permanent am Bus kommunizieren, und das ziemlich schnell.
Die Daten müssen natürlich gelesen werden bzw. darauf reagieren.
Andersrum gibt es auch wieder Geräte mit denen ich statisch kommuniziere, sprich auf einer Frage kommt eine Antwort.
Du hast in deiner CAN_Read funktion einen Counter mit 10 reingegeben
(kann man da statt dem auch eine FOR COUNT Schleife mit dem Wert 10 reingeben?) ohne delay dazwischen, d.h ein TimeOut wird nach 10x Lesen gegeben. Wenn ich z.b viele Analog, Frequenz oder Digital Eingänge abfrage, bekomme ich eine Antwort erst nach ca. 50-100ms, d.h deshalb bau ich eine kurzes delay nach jedem Read Befehl ein um auf eine definiertes Timeout zu kommen (z.b nach 100ms kommt der Fehler TIMEOUT)

Hat es einen Grund das du die Header nicht als Fixe Datei irgendwo auf der Festplatte (z.b dort wo die DLL steht) stehen hast? Ich hab sie im selben Verzeichniss wie die DLL
Genau, in der Read_CAN Funktion kann der Counterwert erhöht oder durch ein Delay ersetzt werden. Man wartet halt auf die CAN-Antwort.

Zitat:Hat es einen Grund das du die Header nicht als Fixe Datei irgendwo auf der Festplatte (z.b dort wo die DLL steht) stehen hast? Ich hab sie im selben Verzeichniss wie die DLL
Ja, damit ist sie ans Programm gebunden und du kannst sie gleich mitdownloaden, als separates Files geht natürlich auch.

Hier noch ein Beispiel, wie man den Bus abfragen könnte.
ne gute idee nur bei einem leerem buffer ein delay reinzumachen!
ich hab mir im VEE ein Menü gemacht, wo ich mir die fertigen funktionen reinladen kann. ich überlege mir ob ich die CAN funktionen über die Merge funktion reinlade. angenommen ich habe sehr viele funktionen gemerged, bremst das mein programm auch wenn ich die funktionen nicht verwende?
bei den Peak-USB adapter hab ich einen treiber wo man 16 Adapter ansteuern kann. man muss den Adaptern eine Hardware adresse zuweisen und dann clients und netze. hab das schon probiert mehrere gleichzeitig anzusteuern. problem war halt nur das ich eine funktion für CAN_Read und CAN_Write geschrieben habe, als Input war quasi die Donglenummer, ID und Message defininiert. d.h diese funktion wurde bei allen ansteuerungen, die gleichzeitig passieren hätten sollen, aufgerufen.
das bremste die perfomance ein wenig. Vielleicht wird diese schneller
wenn ich statt der funktion ein objekt nehme. obwohl der treiber an sich der gleiche ist. und es nur einen gibt.
Besse wäre es mit "Import Library" (User funktion) die CAN-Funktionen zu laden. Merge ist nur zum Dazufügen der Programmteile geeignet.
Du mußt dir allerdings dann mal Gedanken über die Variablen machen.

Ich würde dir empfehlen eine Init-Funktion im CAN-Modul zu kreien, wo die CAN-Variablen Baudrate, Extended usw. den Typ "Local to Library" haben, aber von außen geändert werden können.
Die ganzen CAN-Variablen sollten überhaupt nur in dieser "Library" deklariert werden. Da ich gerade sowieso dabei bin, zeige ich dir mal wie ich das meine. Hab bitte etwas Geduld, ich poste was, wenn's fertig ist.

Dabei muß man sich genau überlegen wie und was man anlegt, denn sonst muß man bei Änderungen später alle Programme, die Library nutzen, auch wieder ändern.

Zitat:ich habe sehr viele funktionen gemerged, bremst das mein programm auch wenn ich die funktionen nicht verwende?
Nein, aber es wird schnell unübersichtlich. Deshalb ist gerade die Nutzung von Libraries sehr sinnvoll, da man nur das einbindet was man braucht.
Eine kleine Einschränkung kann es geben, wenn zu viel Speicher (sehr große Arrays) reserviert wurde, wird das System evtl. ausgebremst (> einige GB).
Zitat:Vielleicht wird diese schneller
wenn ich statt der funktion ein objekt nehme.
Glaube ich nicht, der Zugriff erfolgt immer über dieselbe DLL. Bei Änderungen der User-Objekte muß man jede Einzelne ändern, was im Endeffekt nur mehr Aufwand erfordert. Aber Versuch macht klug ... :shock:
Hi,

im Download-Bereich stehen Beispiele für einen CAN-Library Aufruf bereit.
:wink:
Hallo zusammen,
ich hänge ebenfalls beim Thema PCan-dll im VEE verwenden:
Bei mir funktioniert das Lesen, wenn ich schreibe kommen auf dem CAN-Bus aber die Nachrichten verschoben an.
Weiter oben im Thread hat bratbaecker auf Beispiele zum Download verwiesen. Kommt man noch an diese dran?
Die wären für mich zum Vergleichen hilfreich, da ich bei mir noch Fehlerquellen sehe:
- Die Header-Datei hab ich selbst von der mitgelieferten C++-Notation auf ANSIC-C fürs VEE umgeschrieben. Bei manchen Definitionen bin ich nicht sicher ob das passt.
- Eingangspins des Call richtig belegt? Habs mit Concatenator und Record probiert, hat nie funktioniert. Anscheinend erwartet VEE für CAN_Write am Eingangspin immer 16Bit (wandelt der Concatenator selbst?), in der Header sind aber verschiedene Typen defniert.

Danke schon mal,
Zäher_Hund[attachment=411]
Referenz-URLs