WinCC VBS Laufzeitfehler Überlauf

Zuviel Werbung?
-> Hier kostenlos registrieren
Hier nochmal zur Bekräftigung des Problems.
Code:
On Error Resume Next
Dim objTag
Dim TestVar1, TestVar2, TestVar3, TestVar4


TestVar1 = [COLOR=#ee82ee]&H80020000[/COLOR]
TestVar2 = TestVar1 And [COLOR=#ee82ee]&H80020000[/COLOR]
HMIRuntime.Trace "Err1 " & Err.Description & vbCrLf        [COLOR=#008000]'Fehlerfrei[/COLOR]


Set objTag = HMIRuntime.Tags("Digi_S7_WinCC1_DWORD")
TestVar3 = objTag.Read                                     [COLOR=#008000]'Wert &H8002000 per EA-Feld eingetragen[/COLOR]
TestVar4 = TestVar3 And [COLOR=#ee82ee]&H80020000[/COLOR]
HMIRuntime.Trace "Err2 " & Err.Description & vbCrLf        [COLOR=#008000]'Liefert überlauf
[/COLOR]
Sobald im EA-Feld vor der Ausführung des objTag.Read ein &H70020000 steht gehts...
 
Zuletzt bearbeitet:
@Martin3G & PN/DP
Was passiert denn, wenn man im ursprünglichen ...
... die Reihenfolge der beiden Abfragen tauscht, also ...

es wird ebenfalls ein Ueberlauf festgestellt
Direkt schon beim ersten Aufruf von objTag_extern.read in der "If"-Zeile oder beim zweiten in der "Elseif"-Zeile?

Ist eigentlich jetzt auch egal, weil mir Ronin in #20 sagt, dass eigentlich nur PN/DPs Vorschlag in #17 "eine HMI-Variable mit nur den oberen 16 Bits angelegt" weiterhilft.
Obwohl, seine Alternative "oder noch besser die Prüfung in der SPS ausgeführt werden mit einfachem Ergebnis 0, 1 oder 2 in eine dritte Variable" klingt wirklich verlockend.
In der SPS haben wir also nicht das Problem, dass sich Bit31 beim Holen aus dem HMI querlegt? Oder kommen die 32 Bits ausschliesslich aus der SPS und werden im HMI nicht verändert, so dass kein Grund vorliegt, sie aus dem HMI wieder zurückzuschaufeln?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Für mich ist das ein Bug. Jetzt könnte man Warten bis/ob Siemens den Fehler irgendwann beseitigt, oder man programmiert einen Workaround. Leider habe ich kein WinCC 7.4 zum Testen.
(EDIT: das ist doch kein Bug, siehe Beitrag #34)

Liefert schon das .Read nicht den korrekten Wert, wenn im Wert das Bit .31 gesetzt ist, bzw. welchen Wert liefert das .Read?
Welchen Wert hat objTag_extern.LastError bzw. objTag_extern.ErrorDescription nach dem objTag_extern.Read?
Oder tritt der Fehler erst auf, wenn man versucht, den objTag_extern.Value mit And &H... zu maskieren?
Ist "If objTag_extern.Value < 0" wahr wenn das Bit .31 gesetzt ist?

Ändert sich das Verhalten, wenn Du "Digi_S7_WinCC1" als "Vorzeichenbehafteten 32-Bit-Wert" einstellst?


PS: irgendwo kommt doch der Wert HMIRuntime.Tags("Digi_S7_WinCC1") her - können dort nicht andere Bits festgelegt werden, oder eine HMI-Variable mit nur den oberen 16 Bits angelegt werden oder noch besser die Prüfung in der SPS ausgeführt werden mit einfachem Ergebnis 0, 1 oder 2 in eine dritte Variable?
Leider nein, wurde im alten Projekt so Festgelegt auf dem ich aufbaue bzw. das Sps-Programm aufbaut.
Verstehe ich das richtig, Du bist nicht in der Lage oder darfst es nicht, die Bits in der SPS auf eine dritte Variable zu kopieren und in WinCC abzufragen, auch nicht zur Umgehung eines Fehlers??? :confused:

Harald
 
Zuletzt bearbeitet:
Liefert schon das .Read nicht den korrekten Wert, wenn im Wert das Bit .31 gesetzt ist, bzw. welchen Wert liefert das .Read?
Oder tritt der Fehler erst auf, wenn man versucht, den objTag_extern.Value mit And &H... zu maskieren?

.Read flippt aus. AND würde gerne aktiv werden, wird aber vorher ausgebremst.

Verstehe ich das richtig, Du bist nicht in der Lage oder darfst es nicht, die Bits in der SPS auf eine dritte Variable zu kopieren und in WinCC abzufragen, auch nicht zur Umgehung eines Fehlers??? :confused:
"never change a running system" oder alternativ "never run a changing system"!
 
Liefert schon das .Read nicht den korrekten Wert, wenn im Wert das Bit .31 gesetzt ist, bzw. welchen Wert liefert das .Read
Hab hierzu noch ein wenig probiert. Anscheinend gerät die Sache beim "And" aus den Fugen.
Aber die Sache wird noch seltsamer, seht euch mal das an.
Code:
On Error Resume Next
Dim objTag
Dim TestVar1, TestVar2, TestVar3, TestVar4




'----------------------------------------------------------    [COLOR=#008000] 'Wertursprung von WinCC-Tag[/COLOR]
Set objTag = HMIRuntime.Tags("Digi_S7_WinCC1_DWORD")            [COLOR=#008000]'Vorzeichenloser 32Bit Wert[/COLOR]
TestVar1 = objTag.Read                                          [COLOR=#008000]'Wert &H80020000 per EA-Feld eingetragen[/COLOR]
HMIRuntime.Trace "Err1 " & Err.Description & vbCrLf            [COLOR=#008000] 'Kein Fehler[/COLOR]
HMIRuntime.Trace "TestVar1= " & CStr(TestVar1) & vbCrLf        [COLOR=#008000] '2147614720 - Unsigned32 sollte gar nicht gehen....[/COLOR]
HMIRuntime.Trace "Err2 " & Err.Description & vbCrLf            [COLOR=#008000] 'Kein Fehler[/COLOR]




TestVar2 = TestVar1 And &H80020000
HMIRuntime.Trace "Err4 " & Err.Description & vbCrLf           [COLOR=#008000]  'Liefert Überlauf[/COLOR]
Err.Clear




'----------------------------------------------------------     [COLOR=#008000]'Werte direkt[/COLOR]
TestVar2 = &H80020000
TestVar3 = TestVar2 And &H80020000
HMIRuntime.Trace "Err3 " & Err.Description & vbCrLf         [COLOR=#008000]    'Kein Fehler[/COLOR]
HMIRuntime.Trace "TestVar2= " & CStr(TestVar2) & vbCrLf        [COLOR=#008000] '-2147352576 Signed[/COLOR]
HMIRuntime.Trace "TestVar3= " & CStr(TestVar3) & vbCrLf         [COLOR=#008000]'-2147352576 Signed[/COLOR]
Also wenn ich vom .Read in die TestVar schreibe habe ich unsigned und wenn ich den HextWert direkt in die TestVar schreibe ist signed?
Was geht den hier hab?


Ändert sich das Verhalten, wenn Du "Digi_S7_WinCC1" als "Vorzeichenbehafteten 32-Bit-Wert" einstellst?
Code:
On Error Resume Next
Dim objTag
Dim TestVar1, TestVar2




'----------------------------------------------------------   [COLOR=#008000] 'Wertursprung von WinCC-Tag[/COLOR]
Set objTag = HMIRuntime.Tags("Digi_S7_WinCC1_DINT")         [COLOR=#008000]   'Vorzeichenbehafteter 32Bit Wert[/COLOR]
TestVar1 = objTag.Read                                        [COLOR=#008000] 'Wert &H8002000 per EA-Feld eingetragen[/COLOR]
HMIRuntime.Trace "Err1 " & Err.Description & vbCrLf          [COLOR=#008000]  'Kein Fehler[/COLOR]
HMIRuntime.Trace "TestVar1= " & CStr(TestVar1) & vbCrLf        [COLOR=#008000]'-2147352576[/COLOR]
HMIRuntime.Trace "Err2 " & Err.Description & vbCrLf           [COLOR=#008000] 'Kein Fehler[/COLOR]




TestVar2 = TestVar1 And &H80020000
HMIRuntime.Trace "Err4 " & Err.Description & vbCrLf           [COLOR=#008000] 'Kein Fehler[/COLOR]
HMIRuntime.Trace "TestVar2= " & CStr(TestVar2) & vbCrLf      [COLOR=#008000]  '-2147352576[/COLOR]
Err.Clear
Das Problem scheint dort zu liegen dass die .Read-Methode irgendwie den Wert 2147614720 in die TestVar schreiben kann.
Eigentlich sollte vbScript ja nur den Long-Datentypen können oder? (VbScript - Liste der Datentypen)
2.147.614.720 ist größer 2.147.483.647... deswegen führen "And" und auch andere Operationen zum Überlauf
 
Zuletzt bearbeitet:
Ich glaube jetzt zu verstehen was da passiert.
@Heinileini, du hast schon recht, zunächst sind die TestVar noch ohne Datentyp, aber durch die Zuweisung mit dem .Read wird einer vergeben.
Und da liegt der Hund anscheindend begraben, siehe Beispiel.
Code:
Dim objTag_DWORD, objTag_DINT
Dim TestVar1, TestVar2




Set objTag_DWORD = HMIRuntime.Tags("Digi_S7_WinCC1_DWORD")                'Vorzeichenloser 32Bit - EA-Feld &H8002000
Set objTag_DINT = HMIRuntime.Tags("Digi_S7_WinCC1_DINT")                  'Vorzeichenbehafteter 32Bit - EA-Feld &H8002000


TestVar1 = objTag_DWORD.Read										
HMIRuntime.Trace "TestVar1: Value= " & CStr(TestVar1) &_                  [COLOR=#ff0000]'Value = 2147614720[/COLOR]
                 "TypeName= " & TypeName(TestVar1) & vbCrLf               [COLOR=#ff0000]'DataType = Double[/COLOR]
                 
TestVar2 = objTag_DINT.Read
HMIRuntime.Trace "TestVar2: Value= " & CStr(TestVar2) &_                 [COLOR=#ff0000] 'Value = -2147352576[/COLOR]
                 "TypeName= " & TypeName(TestVar2) & vbCrLf              [COLOR=#ff0000] 'DataType = Long[/COLOR]
Ist der WinCC-Tag ein DWORD, dann wird dem Variant die Type Double zugewiesen, und 16#80020000 als 2147614720 interpretiert.
Mit dem Double lässt sich 2147614720 dann auch darstellen das es in VbScript anscheinend keinen Unsingend-32Bit gibt.
Ist der WinCC-Tag ein DINT, dann wird dem Variant die Type Long zugewiesen, und 16#80020000 als -2147352576 interpretiert.


Das "And" arbeitet aber mit Ganzahlen, also Long.
Wenn die verarbeiteten Werte außerhalb des Long liegen dann kommt es zum Überlauf.
Ein einfacher Test bestätigt das...
Code:
Dim TestVar1


TestVar1= 2147614720 And 2147614720                                      [COLOR=#008000]'Überlauf[/COLOR]
Damit scheitert die Funktion von Martin3G einfach daran dass "And" nicht mit dem Wert 2147614720 umgehen kann.
Das Problem kann man wohl nur umschiffen in dem man sich seine eigene "And"-Funktion baut.

Das würde die Sache für mich erklären, bin mir aber nicht 100 Prozent sicher.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Mein Wissen reicht noch nicht um euch auch ueberall folgen zu koennen.

Aber koennte man nicht da der And befehl in Kombination mit dem bit 31 nicht funktioniert und ein Ueberlauf (wegen wechselnden Datentyp) produziert, einfach nacheinander die bits pruefen.
bzw. meinst du das mit der "eigenen And - Funktion" eine verschachtelte IF - Anweisung?

Bit 30 = 40000000 = M1_Mot
Bit 31 = 80000000 = M1_Gen
Bit 17 = 20000 = M2_Mot
Bit 18 = 40000 = M2_Gen

Mit der man erst bit 30 und dann bit 18 Prueft, um dann in der zweiten Anweisung auf bit 31 und bit 17 zu pruefen?

Waere das eine Moeglichkeit und wie wuerde diese Aussehen?

So wie ich das jetzt geloest habe funktioniert es ja auch, weiss aber nicht ob das so ausreicht.

Habe mir "Digi_S7_WinCC1" als Hex. und Dez. bei den beiden Betriebsarten ausgeben lassen.

Digi_S7_WinCC1
Datentyp: Vorzeichenlose 32-Bit Wert
Formatanpassung: DwordToUnsignedDword

MotorGenerator Betrieb = Hex. 40043300 = Dez. 1074017024
GeneratorMotor Betrieb = Hex. 80023300 = Dez. 2147627776

und es einfach so geloest:

Code:
'On Error Resume Next


Set objTag_extern = HMIRuntime.Tags("Digi_S7_WinCC1")


If (objTag_extern.read = 1074017024) Then 


'MsgBox "Motorgenerator"
motorgenerator = 1
generatormotor = 0


Elseif (objTag_extern.read = 2147627776) Then


'MsgBox "Generatormotor"
motorgenerator = 0
generatormotor = 1
Else 
MsgBox "Keine Betriebsart für Maschine 1 und Maschine 2 angegeben"
Exit Sub
End If

Ist dies ausreichend oder decke ich damit nicht alle Eventualitaeten ab?

mfg Martin3G
 
Zuletzt bearbeitet:
Ist dies ausreichend oder decke ich damit nicht alle Eventualitaeten ab?

Mit Deiner Lösung prüfst Du nicht nur die Bits 17/18/30/31 sondern ob alle 32 Bits exakt &H40043300 bzw. &H80023300 ergeben. Können sich im Betrieb Bits (außer 17/18/30/31) ändern? Wenn ja, dann taugt Deine Abfrage nichts; wenn nicht, dann "Wer hat sich diesen Scheixx ausgedacht?"


Mit der man erst bit 30 und dann bit 18 Prueft, um dann in der zweiten Anweisung auf bit 31 und bit 17 zu pruefen?

Wie willst Du die einzelnen Bits prüfen wenn Du wegen dem Bug "And" nicht benutzen kannst wenn Bit 31 gesetzt ist?


Hast Du schon diesen Vorschlag ausprobiert?
Ändert sich das Verhalten, wenn Du "Digi_S7_WinCC1" als "Vorzeichenbehafteten 32-Bit-Wert" einstellst?


Laut den fleißigen Tests von RONIN (siehe Beitrag #25) sollte Dein Code dann funktionieren:
Code:
[COLOR="#008000"]'Der Tag "Digi_S7_WinCC1" muß als "Vorzeichenbehafteter 32-Bit-Wert" eingestellt sein![/COLOR]

Set objTag_extern = HMIRuntime.Tags("Digi_S7_WinCC1")
Tag_extern = objTag_extern.Read

If (Tag_extern And &H40040000) = &H40040000 Then
  motorgenerator = 1
  generatormotor = 0
ElseIf (Tag_extern And &H80020000) = &H80020000 Then
  motorgenerator = 0
  generatormotor = 1
Else
  MsgBox "Keine Betriebsart für Maschine 1 und Maschine 2 angegeben"
  Exit Sub
End If

Harald
 
Ok, du hast recht mit dem Bit wechsel.
Jetzt hab ichs auch gepeilt.
Hab mein VBS angepasst und es Funktioniert super.
Ich bedanke mich für eure Bemuehungen.


mfg Martin3G
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Mit Deiner Lösung prüfst Du nicht nur die Bits 17/18/30/31 sondern ob alle 32 Bits exakt &H40043300 bzw. &H80023300 ergeben. Können sich im Betrieb Bits (außer 17/18/30/31) ändern? Wenn ja, dann taugt Deine Abfrage nichts; wenn nicht, dann "Wer hat sich diesen Scheixx ausgedacht?"
Moooment mal, Harald! Ich bin wahnsinnig oft Deiner Meinung, ganz einfach, weil Du eigentlich immer Recht hast. Insbesondere bewundere ich an Dir, wie oft Du die in den Aufgabenstellungen fehlenden Angaben völlig zutreffend errätst, wie sich dann erst im weiteren Verlauf der Threads herausstellt.
Aber "Wer hat sich diesen Scheixx ausgedacht?" finde ich daneben gegriffen. Die verwendete Methode, in einem Status-Byte, -Wort oder -Doppelwort die relevanten Bits auszufiltern und somit gezielt abzufragen, ist nicht nur absolut OK, sondern geradezu vorbildlich!
Selbst bzw. gerade wenn zum Zeitpunkt der Programmierung die "irrelevanten" Bits noch nicht belegt sein sollten, dürfte man von Weitsicht sprechen, wenn sie "vorsorglich" ausgeblendet werden.
Bleib bitte lieber bei Deiner Meinung, in dem hier umkämpften Phänomen des widerspenstigen Bit31 einen Bug zu sehen.
Workarounds sind schön und gut, solange sie (leider) unverzichtbar sind. Aber sie sollten in erster Linie verzichtbar sein und bleiben, oder zumindest werden!

Häwenaissuiikend! Gruss, Heinileini

PS: Nach wiederholtem Lesen des oben zitierten Satzes, komme ich so laaangsam dahinter: Du meinst mit "Scheixx" gar nicht die ursprüngliche Lösung, sondern die VerzweiflungsTat, ersatzweise die durch Beobachtung ermittelten, zufälligen Zustände der "Begleit"-Bits in den Abfragen festzunageln, statt sie zu ignorieren!?
Dann: Zustimmung!!! Und eine wichtige Ergänzung zu WorkArounds: WorkArounds, die nur zufällig in AusnahmeSituationen ein WorkAround bewirken, sind doch gar keine WorkArounds, sondern "Scheixx".
 
Unter "Scheixx" meinte ich, eine Information über 3 oder 4 Zustände derartig redundant und in dieser "unmöglichen" Anordnung in 32 Bits unterzubringen.

Da hat man vermutlich nicht die Informationen extra für die Visu zusammengestellt, sondern die Visu greift direkt auf (womöglich Ablauf-interne) Variablen des Programms zu. Die Belegung dieses Bitfeldes kann nun im Programm nicht mehr geändert werden ohne die Visu zu beeinflussen - vermutlich ist das Bitfeld auch nicht als Schnittstelle zur Visu dokumentiert. Und: was würde passieren, wenn die Visu versehentlich/dummerweise auf die Variable schreibt?

Harald
 
Ich erinnere mich, daß ich bei irgendeinem VB-Dialekt in irgendeiner Version Probleme mit AND hatte, wenn das .31 gesetzt ist.
Mir ist wieder eingefallen, in welchem VBS das so war: in WinCC flexible. Deshalb konnte ich heute mal ausführlicher testen.


Für mich ist das ein Bug.
Das Verhalten ist doch kein Bug sondern eine Systemeigenschaft und wird deshalb ziemlich sicher auch nicht geändert werden. (Das Bit31-Problem tritt vermutlich nicht auf, wenn 64-Bit-Ganzzahl-Datentypen verfügbar sind.)

Werte >= 2.147.483.648 können nicht als Ganzzahl-Datentyp verwendet werden, weil es in VBS kein unsigned Long gibt. Sie werden als "Double" (Fließkommawert) verwendet.
Bitweise-"And" ist nur mit Ganzzahl-Datentypen möglich und deshalb kommt der Runtime-Error beim Versuch, einen Wert >= 2.147.483.648 mit "And" zu maskieren. (Es muß noch nichtmal explizit das Bit31 angesprochen werden, es reicht wenn das Bit31 gesetzt ist!) Daß es bei Werten < 2.147.483.648 ohne Runtime-Error funktioniert ist dem automatischen Datentyp-"Hopping" von VBS zu verdanken.

Will man in WinCC oder WinCC flexible ein DWORD in VBS sicher als Bitfeld bzw. Ganzzahl-Datentyp verarbeiten (z.B. Bits maskieren) dann muß die HMI-Variable als "Vorzeichenbehafteter 32-Bit-Wert" (flex: "DInt" oder "Long") deklariert werden, damit VBS sie unabhängig vom aktuellen Wert (Bitmuster) als "Long" ansieht. Allerdings beachtet WinCC flexible das nicht bei symbolischer Variablen-Anbindung, da wird aus dem DWORD der PLC ein DWord im HMI, was dann bei "And" zum Runtime-Error führt, wenn in dem DWord das Bit31 = 1 ist. Ändert man den Datentyp manuell zu DInt, dann geht die Symbolanbindung verloren - dafür funktioniert dann die Bit-Maskierung ohne Runtime-Error (ziemlich verwirrend).

Man bräuchte in VBS quasi einen Typecast wie in SCL ala DWORD_TO_LONG, wo das Bitmuster des DWORD direkt in den gewünschten Datentyp übernommen wird. Gibt es aber nicht.

So kann man einen 32-Bit-Ganzzahl-Wert sicherheitshalber in ein Long-Bitfeld umwandeln:
Code:
[COLOR="#008000"]'Der Tag "Digi_S7_WinCC" kann als "Vorzeichenbehafteter 32-Bit-Wert" (DInt, Long)
'oder als "Vorzeichenloser 32-Bit-Wert" (DWord, ULong) eingestellt sein
'(oder auch als 8-Bit- oder 16-Bit-Ganzzahl-Variante)[/COLOR]

[COLOR="#008000"]'myX32var = SmartTags("Digi_S7_WinCC") 'in WinCC flexible[/COLOR]

Set objTag = HMIRuntime.Tags("Digi_S7_WinCC") [COLOR="#008000"]'WinCC Professional[/COLOR]
myX32var = objTag.Read

[COLOR="#008000"]'sicherheitshalber in Long-Bitfeld umwandeln[/COLOR]
[COLOR="#0000FF"]If myX32var >= 2147483648 Then                     [COLOR="#008000"]'Werte >=2147483648 (&H80000000) sind Double![/COLOR]
  myX32var = (myX32var - 2147483648) Or &H80000000 [COLOR="#008000"]'Bit31 entfernen und als Long wieder zufügen[/COLOR]
End If[/COLOR]

If (myX32var And &H80000000) Then  [COLOR="#008000"]'kann jetzt gefahrlos ausgewertet werden[/COLOR]
...

Danke RONIN für den Denkanstoß durch Deine fleißigen Tests, insbesondere die Erkenntnis wie WinCC/VBS bei der Verwendung von U32 trickst (als Double).

Bei den Tests habe ich allerdings bemerkt, daß das VBS sich bei der automatischen Datentyp-Hopserei im Variant selber auf die Füße tritt und merkwürdige Ergebnisse produziert bei der Verwendung von hex-Konstanten wie &H8000, wenn das höchste gesetzte Bit das Bit 31 oder 15 ist. Vorsicht - Programmcode immer ausführlich testen!
z.B.
Code:
hex(&H8000)  [COLOR="#FF0000"]'ergibt: FFFF8000 !!![/COLOR]

Testvar = &HFFFFFFFF        [COLOR="#FF0000"]'ergibt FFFF (Integer) !!![/COLOR]
Testvar = CLng(&HFFFFFFFF)  [COLOR="#008000"]'ergibt FFFFFFFF (Long)[/COLOR]

Testvar = &H12348123
If (Testvar And &H8000) = &H8000 Then  [COLOR="#FF0000"]'ergibt FALSCH !!![/COLOR]
[COLOR="#008000"]weil:[/COLOR] Testvar = &H12348123 And &H8000  [COLOR="#FF0000"]'ergibt 12348000 !!![/COLOR]

Testvar = &H12340123 And &H0[COLOR="#0000FF"]4[/COLOR]000  [COLOR="#008000"]'ergibt 0[/COLOR]
Testvar = &H12340123 And &H0[COLOR="#FF0000"]8[/COLOR]000  [COLOR="#FF0000"]'ergibt 12340000 !!![/COLOR]
Testvar = &H12340123 And &H[COLOR="#0000FF"]1[/COLOR]0000  [COLOR="#008000"]'ergibt 0[/COLOR]

Harald
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich habe jetzt nicht den ganzen Thread gelesen, aber zu dem Verhalten gibt es auch einen FAQ von Siemens zu WinCC von 2008:

https://support.industry.siemens.com/cs/ww/de/view/27039111

Ein Grund mehr VBS nicht zu verwenden, aber in WinCC Faceplates lässt sich leider nur VBS verwenden. Ich habe damals das Bit in meiner DWord Variable nicht verwendet um diesem Verhalten zu entgehen und den Code im Faceplate sauber zu halten.
 
Das Bit 15 kann man in VBS faktisch auch nicht verwenden - doch davor warnt der FAQ nicht (hatte da wohl noch niemand bemerkt?)
Zum Bit 31 wird nur gesagt "darf nicht verwendet werden". Eine Abhilfe/Workaround wird nicht angeboten, dabei ist der Workaround so einfach, wenn man verstanden hat warum die Abfrage den Runtime Error wirft (siehe Beitrag #34)

Als Hilfe für den TE hatte ich zuerst lange versucht, die oberen 16 Bit zu den unteren 16 Bit zu verschieben, doch ich kam zu aberwitzigen Ergebnissen (z.B. &H8002 ist ungleich &H8002 !) - wegen dem ebenfalls problematischen Bit 15 in hex-Konstanten.

Harald
 
PN/DP schrieb:
#34: Das Verhalten ist doch kein Bug sondern eine Systemeigenschaft und wird deshalb ziemlich sicher auch nicht geändert werden. (Das Bit31-Problem tritt vermutlich nicht auf, wenn 64-Bit-Ganzzahl-Datentypen verfügbar sind.)
Moin Harald! Darf man daraus schliessen, "Das Bit15-Problem tritt vermutlich nicht auf, wenn 32-Bit-Ganzzahl-Datentypen verfügbar sind."?
Also kein Bug, sondern nur eine Systemeigenschaft. Welchen Begriff wollen wir denn für solche KatastrophenFälle verwenden? Ich schlage vor "Scheixx" - Dein Einve®ständnis vorausgesetzt.

Das Bit 15 kann man in VBS faktisch auch nicht verwenden - doch davor warnt der FAQ nicht (hatte da wohl noch niemand bemerkt?)
Zum Bit 31 wird nur gesagt "darf nicht verwendet werden". Eine Abhilfe/Workaround wird nicht angeboten, dabei ist der Workaround so einfach, wenn man verstanden hat warum die Abfrage den Runtime Error wirft (siehe Beitrag #34)

Als Hilfe für den TE hatte ich zuerst lange versucht, die oberen 16 Bit zu den unteren 16 Bit zu verschieben, doch ich kam zu aberwitzigen Ergebnissen (z.B. &H8002 ist ungleich &H8002 !) - wegen dem ebenfalls problematischen Bit 15 in hex-Konstanten.
Für die Verwendung von Hex-Konstanten möchte ich hiermit den Begriff "Hexerei" vorschlagen und für die WorkArounds gegen die Nebenwirkungen der Hexerei schwebt mir der Begriff "HeXORzismus" vor.
Verwendet man Binär-Konstanten statt der Hex-Konstanten, so könnte man das als "Duales System" bezeichnen - denn einige davon funktionieren, andere nicht - und System hat es ja allemal.
Die wenigen, die lieber mit oktalen Konstanten arbeiten, sollen auch bedacht werden: "Octserei" (nachlässig gesprochen: Ochserei).

Gruss, Heinileini
 
Ja, da hab ich wieder was gelernt wo wieder Fallstricke vergraben sind.
Wäre da nie auf die Idee gekommen das VBS Probleme mit 32Bit-Unsigned hat....
Das mit Bit15 und HEX muss ich mir auch nochmal anschauen... Programmieren gleicht oft wirklich einer Hexerei.
 
Das Bit 15 kann man in VBS faktisch auch nicht verwenden
So ist das falsch formuliert. :oops:
Man kann zum And-maskieren eines 32-Bit-Wertes keine hex-Konstante verwenden wo als höchstes Bit das Bit15 gesetzt ist, weil dabei unsichtbar auch die Bits 16 bis 31 ins Ergebnis eingehen. Das Problem muß man umgehen, indem man eine dezimale Konstante verwendet:
Code:
Testvar = (myX32var And [COLOR="#FF0000"]&H8000[/COLOR]) <> 0 [COLOR="#FF0000"]'ergibt 1, wenn irgendein Bit 15..31 gesetzt ist![/COLOR]
Testvar = (myX32var And [COLOR="#0000FF"]32768[/COLOR]) <> 0  [COLOR="#008000"]'ergibt nur dann 1, wenn Bit 15 gesetzt ist - korrekt[/COLOR]
Testvar = (myX32var And [COLOR="#0000FF"]2^15[/COLOR]) <> 0   [COLOR="#008000"]'ergibt nur dann 1, wenn Bit 15 gesetzt ist - korrekt[/COLOR]
Will man mehrere Bits maskieren und das höchste davon ist Bit 15, dann wird es leider unübersichtlich, weil man &H8... nicht verwenden kann.

Harald
 
Zurück
Oben