Version 4.1.g - EasyLase Adressierung

[equal]

Hallo tschosef,

ich glaube in der aktuellen Version ist ein schwer zu findener Fehler in der Adressierung der EasyLase USB D/A Karten. EasyLase1 sollte CardNumber 0 sein, EasyLase2 sollte CardNumber 1 sein - und so weiter.

Das funktioniert auch bis Easylase9 <=> CardNumber 8. EasyLase10 ist dann aber CardNumber 484, Easylase11 <=> CardNumber 0 - und so weiter. Ok - wenige Leute haben so viele EasyLase USB D/A Karten - aber ich dachte das interessiert Dich sicher.

Das Bild im Anhang verdeutlicht das Adressierungsproblem.

Gruß aus Essen ... Erik

[equal]

Hallo tschosef,

ich habe die Ausgabe nun auch mit Version 4.1.h probiert. Das Verhalten ist unverändert. Ab Easylase10 wird der Wert für CardNumber, welcher mittels EasyLaseWriteFrame oder EasyLaseWriteFrameNR übergeben wird, falsch berechnet.

CardNumber ist ja eine vorzeichenbehaftete 32 Bit Ganzzahl. Der Wert für EasyLase10 ist nach jedem Programmstart ein wenig anders. Hier mal 3 Werte welche die Version 4.1.h bei drei aufeinanderfolgenden Programmstarts angenommen hat:

&b00000000000010000000000110000001
&b00000000000010000000000100111011
&b00000000000010000000000100111101

Richtig aber wäre:

&b00000000000000000000000000001001

Interessant ist auch das die Werte für EasyLase10 und EasyLase20 gleich sind. Die Werte für EasyLase11-19 sind eine Wiederholung der richtigen Werte für EasyLase1-9.

Gruß aus Essen ... Erik

[tschosef]

halli hallo...

jou, diese Angelegenheit hab ich vööööölllig vergessen.
Nun.. mein erster vorschlag ist wohl erstmal: einfach keine 10 easyLase karten anschließen
es laufen ja eh nur 4 mit der software.
aktuell mach ich ja TutorialVideos. Daher mein Vorschlag. könntest du die Angelegenheit als ToDo auf die homepage schreiben (www.he-laserscan.de) ???
evtl mit einem Link auf diesen Post. dann kann ich mich drum kümmern, wenns weiter geht.. okay?

viele Grüße
Erich

[tschosef]

hm.... schreib ich nochmal..

also irgendwieeeee... komm ich nu durcheinander, was überhaupt die sache ist.
FRAGE:
1) Hast du so viele EasyLase drann, oder hast du ein Simulationsprogramm??? oder wie machst du das überhaupt?

2)

Ab Easylase10 wird der Wert für CardNumber, welcher mittels EasyLaseWriteFrame oder EasyLaseWriteFrameNR übergeben wird, falsch berechnet.

was heißt falsch berechnet
nun... die sache is so:
die EasyLase dll gibt mir die zahl der karten, diese geht von 1 bis x
Die Software trägt dann x karten in die hardwareAuswahlliste ein.
Wählt man eine karte, dann wird in ein (jetzt kommts, dass is VB Faulheit) VariantVariable Array namens "Port(a,b)" die Kartennummer = X -1 eingetragen. (folgich bei 10 Karten gibts karte 0 bis karte 9 usw..)

Jeder Aufruf lauten dann:

EasyLaseXXX(port(a,b), xxx,xxx,xxx)
XXX = api aufruf
xxx sind die parameter

der api aufruf verwertet den parameter Kartennummer as LONG
Long nach msdn:

Variablen vom Datentyp Long (lange Ganzzahl) werden als 32-Bit-Zahlen (4 Bytes) mit Vorzeichen im Bereich von -2.147.483.648 bis 2.147.483.647 gespeichert. DasTypkennzeichen für Long ist das Zeichen (&).

Laut api beschreibung ( jojo) ist es so:
xxxLaseWriteFrame(CardNumber :integer,....
xxx = Net oder Easy

so, das is KEIN VB INTEGER.. ein VB Integer ist eine 16 Bit zahl mit vorzeichen!!!!! das geht hier nicht (mit dem problem haben VB user schon immer zu kämpfen)

die Integer welche die dll erwartet is eine 32 bit zahl OHNE vorzeichen (soweit ich mich korrekt erinnere)

Soooo... nu erklähr mir mal, was falsch ist, oder was ich tun kann, um das problem zu beheben, welches nach meiner Meinung noch keins is, da eh nur 4 karten von HE-LS unterstützt werden

falls du ein testprogramm oder so hast, schick mal zu mir

Grüße derweil
Erich

[equal]

Hallo Erich,

sicher das ist mehr ein theoretisches Problem - denn wer hat schon mehr als 9 EasyLase? Ich selber habe auch nur eine EasyLase - programmiere aber schon lange Zeit an einer Ausgabesoftware. Nein - nichts was vergleichbar wäre mit HE-LaserScan - es geht nicht um einen ShowEditor. Wenn man Software für X Ausgabegeräte schreibt - selber aber nur eins hat - schreibt man sich natürlich einen Simulator. Mit dem kann man dann auch die Bugs in den (eigenen) Optimierungsalgorithmen finden. (Vor allem an der ColorShift Funktionalität habe ich lange gebastelt - sie funktioniert etwas anders als Deine). In dem Zusammenhang - Dein Optimierungsalgorithmus für Kreise ist Spitze - ich hatte immer Probleme mit der Sichtbarkeit von Anfangs- und Endpunkt und mich immer gewundert das Deine Software das Problem nicht hat. Ich bin versucht Deine Idee zu übernehmen - darf ich?

Ok - nun zum eigentlichen Thema. Der Parameter CardNumber ist in der Orginal Doku ein dword Zeiger auf ein Integer. Der Funktionsaufruf in der Doku legt den Schluss nahe das hier Delphi oder ein anderer Pascal Compiler verwendet wurde. In Delphi ist ein integer ein alias für long integer. Im Gegensatz zum short integer (16 Bit Vorzeichenbehaftet) ist long integer 32 Bit Vorzeichenbehaftet. Dieser Wert wird aber nicht über den Stack übergeben - sondern nur ein dword Zeiger auf den Speicherort.

Laut Microsoft -> http://msdn.microsoft.com/de-de/library/06bkb8w2.aspx ist der Datentyp integer auch in VB 32 Bit Vorzeichenbehaftet. Also kann es eigentlich kein Problem geben.

Allerdings speicherst du die CardNumber in einem Variant Array. Die automatische Typumwandlung muss dann daraus ein long integer machen ... vielleicht passiert es da? Der Datentyp Variant war mir noch nie geheuer ... und ... funktioniert die Typumwandlung überhaupt ... immerhin wird die Variable nicht übergeben ... sondern nur der Zeiger darauf. Nun ja, ich bin kein VB Experte. In den Compiler Sprachen in denen ich mich ein wenig auskenne würde ich immer eine explizite Typumwandlung machen - oder - besser - ein long integer Array verwenden.

Nun denn - ich sehe das auch so, dass dies kein Fehler ist, welcher irgendeine Auswirkung hat ... aber interessant ist das Verhalten schon ... ! Erst dachte ich das meine Software den Fehler macht - ein Debugging mit Stacktrace konnte mich aber von dem Gegenteil überzeugen.

Den Simulator sende ich Dir gerne zu ... ist nur eine kleine DLL ... bevor hier Diskussionen anfangen ... nein - es ist kein ILDA Export Modul enthalten - ich werde auch keins implementieren.

Gruß aus Essen ... Erik

[tschosef]

Hai hai...

jou, also erstmal mercy, ja ich probier das mal aus.
wegen Kreise... da optimiere ich im prinzip einfach garnix die kreise haben halt ne spezielle form... sag ich mal. jou jou... kannst natürlich auch übernehmen... ich seh meine soft schon untergehen aber is ja auch okay.

wegen Variant datentyp.. jaaa, das is extrem faul und gefährlich, und stammt noch aus zeiten, wo ich nicht den Peil hatte, wie es jetzt ist.
eigentlich (vermutlich ändere ich das mal) is es absolute Faulheit, denn in der variable Port stecken 2 Infos für jede Ausgabekarte drinn.
in
Port(0, AusgabehardwareNr) steckt der TYP der Karte (easyLase, netlase, lumax und co...)
in
Port(1,AusgabehardwareNr) steckt die Addresse der Karte drinn (Handle, Kartennummer, je nach dem....)

DAS IST SEHR FAUL!! weil diese beiden infos unterschiedliche Datentypen sind, Noch schlimmer, schon die Adresse der jeweiligen karten hat unterschiedliche datentypen.

desshalb Variant.
NATÜRLICH kann man mit Cint(wert)... oder CLng(wert) usw... die Datentypen explicit umwandeln, was ich wohl tun sollte, evtl aber zeit kostet. Bis jetzt hab ich drauf verzichtet, weil ich mir dachte "geht ja eh... was solls".

korrekt währe natürlich, diese beiden infos zu trennen und nicht in ein array rein zu klatschen. Das is extrem faul, und stammte eben aus meiner Anfangszeit.

grüße derweil
Erich

[equal]

Hallo Erich,

vielen Dank für die Erlaubnis Deine spezielle Form der Kreise zu nutzen. Konkurrenz musst Du wirklich nicht befürchten. Ich programiere nie Dinge die es schon gibt. Auch glaube ich nicht das es eine Notwendigkeit für noch einen Laser Show Editor gibt. (Bestimmt würde ich so ein großes Projekt auch nicht durchhalten. )

Ich habe im Internet ziemlich wenig Informationen zum Datentyp Variant gefunden. Informationen zur Darstellung des Datentyps Variant im Speicher habe ich überhaupt nicht gefunden. Aber es ist wohl so das der eigentliche Datentyp erst zur Laufzeit festgelegt wird. Das erfolgt wohl automatisch. Damit verliert man die Kontrolle über die Darstellung der Werte im Speicher. Aber die ist bei der Übergabe eines Zeigers auf den Wert im Speicher ja gerade wichtig.

Auch sprichst Du von der Perfomance des Zugriffs auf die Variableninhalte. Da die Verwaltung einer Variant Variable aufwändig ist (jedes mal müssen die Verwaltungsinfomationen gelesen werden, der Datentyp muss bestimmt werden) ist die Verwendung von festen Datentypen performanter. Um die Performance zu verbessern ist auch die bevorzugte Verwendung von Datentypen mit 32 Bit Darstellung zu empfehlen. Zumindest wenn man für einen 32 Bit Prozessor programmiert. Diese können direkt in den Registern des Prozessors bearbeitet werden und auch der Speichertransfer ist meist effizienter. Aber Du hast recht - eine explizite Umwandlung in den benötigten Datentyp ist aus Performance Sicht zu vermeiden. Wenn möglich sollte man den Datentyp der Arbeitsvariablen genau so setzen wie für die Ein- und Ausgabe benötigt.

Gegen die gemeinsame Speicherung von verschiedenen Infomationen in einem Array spricht nichts. Im Gegenteil - die gesamte Objektorientierte Programierung beruht auf diesem Ansatz. Im vorliegenden Fall würde ich eine struct Variablendefinition verwenden und mit doppelten Zeigern arbeiten. So kann man über einen Zeiger auf den Zeiger auf die CardNumber oder Ausgabeadresse zugreifen. Diesen zweiten Zeiger kann man dann auch direkt an die Ausgabe DLL übergeben. Ob das in VB möglich ist?

Gruß aus Essen .... Erik