Division von INT Zahlen

HonestAnnie

Level-1
Beiträge
10
Reaktionspunkte
1
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,
ich habe eine Frage zur Division von INT Zahlen.

Mein Programm sieht so aus:
Code:
L     #ARC_NEXT_NR
L     2
/I                //Teile durch 2 
T     #ARC_NEXT_NR

Die Variable soll durch 2 geteilt und das Ergebnis in die Variable geschrieben werden. Dabei kommt jedoch nur Murks raus. Die SPS errechnet jedoch bei #ARC_NEXT_NR=49 ein Ergebnis von "1103364096". Ich hätte aber gerne 24 (Zahlen hinterm Komma wegschneiden).

Vielen Dank für jeden konstruktiven Beitrag.

Ich benutze momentan:
312C
Step 7 V5.33
 
Hallo,
ich habe eine Frage zur Division von INT Zahlen.

Mein Programm sieht so aus:
Code:
L     #ARC_NEXT_NR
L     2
/I                //Teile durch 2 
T     #ARC_NEXT_NR

Die Variable soll durch 2 geteilt und das Ergebnis in die Variable geschrieben werden. Dabei kommt jedoch nur Murks raus. Die SPS errechnet jedoch bei #ARC_NEXT_NR=49 ein Ergebnis von "1103364096". Ich hätte aber gerne 24 (Zahlen hinterm Komma wegschneiden).

Vielen Dank für jeden konstruktiven Beitrag.

Ich benutze momentan:
312C
Step 7 V5.33

Das wird bei jedem Zyklus aufgerufen (#ARC_NEXT_NR wird jedes mal durch 2 geteilt)
Es ist ja kein Wunder dass du nur Mist bekommst

johnij
 
Hallo,
ich habe eine Frage zur Division von INT Zahlen.

Mein Programm sieht so aus:
Code:
L     #ARC_NEXT_NR
L     2
/I                //Teile durch 2 
T     #ARC_NEXT_NR

Die Variable soll durch 2 geteilt und das Ergebnis in die Variable geschrieben werden. Dabei kommt jedoch nur Murks raus. Die SPS errechnet jedoch bei #ARC_NEXT_NR=49 ein Ergebnis von "1103364096". Ich hätte aber gerne 24 (Zahlen hinterm Komma wegschneiden).

Vielen Dank für jeden konstruktiven Beitrag.

Ich benutze momentan:
312C
Step 7 V5.33
Was darauf schließen lässt dass Dein "#ARC_NEXT_NR unmöglich eine INT-Var sein kann.
Was für ein Datenformat hat die Variable denn?
.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Habe das Problem gelöst, mein Programm schaut nun so aus:

Code:
L     #ARC_NEXT_NR
SRW   1
T     #ARC_NEXT_NR

Das ist einfacher und funktioniert. Vielen Dank für die Beiträge,

Mfg
HonestAnnie
 
@johnij: alles blödsinn! da kommt null raus! fertig!

@ohgn: ich teile deine vermutung, irgendwas scheint da mit der anzeige nicht zu stimmen

@honestannie: SRW 1 ist nicht anderes als durch zwei ... war zu S5-zeiten sehr beliebt weil schneller ... SLW 1 ist im gegenzug natürlich mal zwei
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Wenn Du einen Integerwert per -> /I teilst, ist das Ergebnis aufgeteilt in das Ergebnis und den Divisionsrest. (HB-LB)

Edit:

Natürlich ist das mit dem HB-LB so nicht richtig. Gemeint war, dass das Ergebnis und der Rest aufgeteilt werden auf Akku1-L und Akku1-H. Mea Culpa.....

Wenn du dann dieses Ergebnis wieder in einem Wort abspeicherst, stehen dann halt in diesen beiden Bytes diese beiden Ergebnisse. Diese wieder als Integer interpretiert ergeben halt "seltsame" Ergebnisse....
 
Zuletzt bearbeitet:
Wenn Du einen Integerwert teilst, ist das Ergebnis aufgeteilt in das Ergebnis und den Divisionsrest. (HB-LB)

Wenn du dann dieses Ergebnis wieder in einem Wort abspeicherst, stehen dann halt in diesen beiden Bytes diese beiden Ergebnisse. Diese wieder als Integer interpretiert ergeben halt "seltsame" Ergebnisse....

möööp, FALSCH ... also nicht, dass der rest nicht verfügbar wäre, aber er steht nicht im transferierten wort!

[edit] um das mal etwas genauer zu machen:

akku1 / akku2 ... was anderes ist es ja nicht
jeder akku hat 32bit ... die integerzahl steht in 16 bit und zwar in akku1-L und akku2-L
der quotient wird in akku1-L abgelegt (16bit)
der rest in akku1-H (16bit)
mit transfer in ein wort schiebst du nur akku1-L also den quotienten in dein ergebnis [/edit]
 
Zuletzt bearbeitet:
@Grubba: Ja vermutlich liegt es daran. In den ersten 8Bit steht anscheinend der Rest der Division und in den zweiten das Ergebnis. Sowas in der Richtung steht zumindest in der Hilfefunktion.
 
Zuletzt bearbeitet:
Werde das bei Gelegenheit ausprobieren, In der Hilfe steht aber etwas von High und Low Byte, das würde auch den "riesigen Wert" erklären.

Hier mal das was dazu in der Hilfe steht:

Code:
/I  //Dividiere AKKU2-L durch AKKU1-L, speichere das Ergebnis in AKKU 1: AKKU1-L: Quotient, AKKU1-H: Divisionsrest
 
Wenn Du einen Integerwert per -> /I teilst, ist das Ergebnis aufgeteilt in das Ergebnis und den Divisionsrest. (HB-LB)

Wenn du dann dieses Ergebnis wieder in einem Wort abspeicherst, stehen dann halt in diesen beiden Bytes diese beiden Ergebnisse. Diese wieder als Integer interpretiert ergeben halt "seltsame" Ergebnisse....


häää?

ein Totaler Blödsinn

johnij
 
Zuviel Werbung?
-> Hier kostenlos registrieren
ein Totaler Blödsinn

und wer ist jetzt der motski? ...boah johnij ... langsam reißt mir der geduldsfaden mit dir ...


so...topic:

wo steht denn das akku1-L ein byte ist? es ist ein wort, weil der akku1 eben ein doppelwort ist! zweimal 16 bit! und aufbauend darauf kannst du mit:

Code:
*
      L     MW    10
      L     2
      /I    
      T     MD     8

im MW 10 den Quotienten und im MW 8 den divisionsrest ablesen
 
Wen das Ergebnis bei Honest Annie 1103364096 ist, muss Arc_next_Nr ein Longint sein.

Dann ergibt z.B.

L 5
L 3
/I
T MD100

mit anschließendem

L MD100 -> 20001
 
und wer ist jetzt der motski? ...boah johnij ... langsam reißt mir der geduldsfaden mit dir ...


so...topic:

wo steht denn das akku1-L ein byte ist? es ist ein wort, weil der akku1 eben ein doppelwort ist! zweimal 16 bit! und aufbauend darauf kannst du mit:

Code:
*
      L     MW    10
      L     2
      /I    
      T     MD     8

im MW 10 den Quotienten und im MW 8 den divisionsrest ablesen

@ 4L
ich habe den Beitrag vorhin nicht gelesen.


johnij
 
Zurück
Oben