# Division von INT Zahlen



## HonestAnnie (16 Juli 2008)

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

Mein Programm sieht so aus:

```
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


----------



## johnij (16 Juli 2008)

HonestAnnie schrieb:


> Hallo,
> ich habe eine Frage zur Division von INT Zahlen.
> 
> Mein Programm sieht so aus:
> ...


 
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


----------



## HonestAnnie (16 Juli 2008)

Hallo,

müsste ich dann nicht zumindest 0 herausbekommen? 49/2 = 24 /2 = 12 usw. ?


----------



## johnij (16 Juli 2008)

HonestAnnie schrieb:


> Hallo,
> 
> müsste ich dann nicht zumindest 0 herausbekommen? 49/2 = 24 /2 = 12 usw. ?


 
Der Zyklus ist zu schnell (je kliener das Projekt desto kleine s ist dein Zyklus) ,so dass man es nicht sieht

Limit (49/ (2^n))=0 falls  n-->unendlich

johnij


----------



## OHGN (16 Juli 2008)

HonestAnnie schrieb:


> Hallo,
> ich habe eine Frage zur Division von INT Zahlen.
> 
> Mein Programm sieht so aus:
> ...


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?
.


----------



## HonestAnnie (16 Juli 2008)

Habe das Problem gelöst, mein Programm schaut nun so aus:


```
L     #ARC_NEXT_NR
SRW   1
T     #ARC_NEXT_NR
```
 
Das ist einfacher und funktioniert. Vielen Dank für die Beiträge,

Mfg
HonestAnnie


----------



## Ludewig (16 Juli 2008)

Also zum Teilen durch zwei ohne Rest würde ich einfach "Rechts Schieben".


----------



## vierlagig (16 Juli 2008)

@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


----------



## Grubba (16 Juli 2008)

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....


----------



## vierlagig (16 Juli 2008)

Grubba schrieb:


> 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]


----------



## HonestAnnie (16 Juli 2008)

@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.


----------



## OHGN (16 Juli 2008)

HonestAnnie schrieb:


> @Grubba: Ja daran lag es. In den ersten 8Bit steht anscheinend der Rest der Division und in den zweiten das Ergebnis.


 Das ist definitiv Unsinn!


----------



## johnij (16 Juli 2008)

vierlagig schrieb:


> @johnij: alles blödsinn! da kommt null raus! fertig!
> 
> /quote]
> 
> ...


----------



## HonestAnnie (16 Juli 2008)

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:


```
/I  //Dividiere AKKU2-L durch AKKU1-L, speichere das Ergebnis in AKKU 1: AKKU1-L: Quotient, AKKU1-H: Divisionsrest
```


----------



## vierlagig (16 Juli 2008)

johnij schrieb:


> Es geht nämlich darum zu erklären, woher das kommt



dann lies dir bitte meine erklärung aus meinem *letzten post* durch!


----------



## johnij (16 Juli 2008)

Grubba schrieb:


> 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


----------



## johnij (16 Juli 2008)

Sag mal Honestannie, bist du eine Dame?ROFLMAO
johnij


----------



## vierlagig (16 Juli 2008)

johnij schrieb:


> 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:


```
*
      L     MW    10
      L     2
      /I    
      T     MD     8
```

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


----------



## Grubba (16 Juli 2008)

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


----------



## johnij (16 Juli 2008)

vierlagig schrieb:


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


 
@ 4L
ich habe den Beitrag vorhin nicht gelesen.


johnij


----------



## OHGN (16 Juli 2008)

HonestAnnie schrieb:


> ```
> /I  //Dividiere AKKU2-L durch AKKU1-L, speichere das Ergebnis in AKKU 1: AKKU1-L: Quotient, AKKU1-H: Divisionsrest
> ```


 Was aber nichts mit dem LOW und High-Byte zu tun hat...


----------



## HonestAnnie (16 Juli 2008)

@Vierlagig: Hätte ich geahnt, dass um so ein simples Problem eine so heiße Debatte entbrennt, hätte ich die Frage lieber nicht gestellt ;-). Ich glaube das Problem liegt z.T. daran, dass ich einfach nur T #Variable und nicht T MB #Variable geschrieben habe. Dadurch hat er alles in die Variable geschrieben, die komplette 32 Bit aus dem Akku.

@Johnij: Nein ich bin keine Frau, der Nick stammt aus einem SciFi-Roman von Lem.


----------



## Grubba (16 Juli 2008)

@ OHGN und johnij

Lest doch mal meinen Post#19 und probierts mal aus...


----------



## vierlagig (16 Juli 2008)

Grubba schrieb:


> Wen das Ergebnis bei Honest Annie 1103364096 ist, muss Arc_next_Nr  ein Longint sein.



ist doch wurscht ob du da ein INT oder ein DINT lädst, solange es in den wertebereich von INT passt, was 49 definitiv tut. wenn du eine größere zahl nimmst wird diese als negativ gewertet, das könnte zu ungewünschten ergebnissen führen!

/I interessiert der AKKU1-H und der AKKU2-H vor der division nicht, es werden nur die 16bit der INT-Zahl ausgwertet PUNKT!

@johnij: dann lies du v**lpf**t*N!


----------



## Grubba (16 Juli 2008)

@ vierlagig 

Probiers auch mal aus. Lädst Du das Ergebnis in ein Doppelwort ist das Ergebnis so wie ichs gepostet habe.


Edit:

Weil irgendwo ja nun auch der Divisionsrest bleiben muss...


----------



## vierlagig (16 Juli 2008)

Grubba schrieb:


> Lest doch mal meinen Post#19 und probierts mal aus...



ist doch klar, dass im MD100 etwas verwirrendes steht, wird ja als DINT gewertet, schaust du dir aber MW100 und MW102 an, hast du REST und QUOTIENT

[edit] lies das nochmal: http://www.sps-forum.de/showpost.php?p=144697&postcount=18 [/edit]


----------



## vierlagig (16 Juli 2008)

HonestAnnie schrieb:


> @Vierlagig: Hätte ich geahnt, dass um so ein simples Problem eine so heiße Debatte entbrennt, hätte ich die Frage lieber nicht gestellt ;-). Ich glaube das Problem liegt z.T. daran, dass ich einfach nur T #Variable und nicht T MB #Variable geschrieben habe. Dadurch hat er alles in die Variable geschrieben, die komplette 32 Bit aus dem Akku.



du kannst nicht MB #Variable schreiben, wenn schon MB [#variable] aber selbst dann ... MB ist übrigens kein INT, nur ein byte und eine INT zahl hat 2 byte, also ein wort also im schlimmsten fall ein MW


----------



## Grubba (16 Juli 2008)

Mein Gott....

Der Wert Arc_Next_Nr ist ein Doppelwort. (zumindest bei dem angegebenen Ergebnis)

Das Beispiel:

L 5
L 3
/I
T MD X (Oder von mir aus T ArcNextNR)

führt nach anschließendem Laden
von ArcNextNr zu einem Ergebnis von 20001.
Wo ist Dein Problem? 2 im HW für den Rest, 1 als Ergebnis.




> ist doch klar, dass im MD100 etwas verwirrendes steht, wird ja als DINT gewertet, schaust du dir aber MW100 und MW102 an, hast du REST und QUOTIENT


 
und da liegt ja auch das Problem. Wenn er es als Doppelwort (Dint) deklariert hat, ist der Wert halt nicht der, den er erwartet.


----------



## vierlagig (16 Juli 2008)

Grubba schrieb:


> Wo ist Dein Problem? 2 im HW für den Rest, 1 als Ergebnis.



1. ich versteh dein problem nicht
2. solltest du die darstellungsform angeben ... deine ist HEX, wir reden hier von INT, vielleicht DINT, maximal DEZIMAL!
3. das einzige problem, dass bei einer verwendung eines doppelwortes auftreten könnte ist die interpretation als negative zahl oder andere 
... aber nach ein paar zyklen kommt *definitiv 0 raus!*


----------



## OHGN (16 Juli 2008)

HonestAnnie schrieb:


> Hallo,
> ich habe eine Frage zur Division von INT Zahlen.
> 
> Mein Programm sieht so aus:
> ...


Um mal auf die Eingangsfrage zurückzukommen....
Klar ist inzwischen, dass es sich bei der Variable von HonestAnnie nicht um eine 16 Bit Integer sondern um eine 32 Bit Doppelinteger handelt.

der code müsste hier also lauten:


```
L     #ARC_NEXT_NR
L     L#2
/D
T     #ARC_NEXT_NR
```
 
Dann funktioniert das auch...


----------



## Grubba (16 Juli 2008)

Wenn irgendjemand hingeht, eine Variable als Dint deklariert, und 

5 mittels /I durch 3 teilt, ist das Ergebnis, sofern er es in einem Dint abspeichert, nicht 1.

Um mehr gehts doch garnicht. Ob irgendwann mal 0 rauskommt ist für die Diskussion der letzten 10 Posts doch völlig nebensächlich.


Edit:

OHGN hats ja auch gerade geschrieben, wie richtig geht.


----------



## vierlagig (16 Juli 2008)

OHGN schrieb:


> Klar ist inzwischen, dass es sich bei der Variable von HonestAnnie nicht um eine 16 Bit Integer sondern um eine 32 Bit Doppelinteger handelt.



glaub ich nicht, dass das klar ist... aber möglich!



Grubba schrieb:


> Um mehr gehts doch garnicht. Ob irgendwann mal 0 rauskommt ist für die Diskussion der letzten 10 Posts doch völlig nebensächlich.



nein, war es nicht, denn es war die ausgangssitution "da müßte doch wenigstens null rauskommen" stand da irgendwo ...

@honestannie: welchen datentyp hat denn nun deine nummer?

mit SRW 1 funktioniert das nämlich auch nur, solange der dividend <= 32767 ist


----------



## HonestAnnie (16 Juli 2008)

@Vierlagig: Der Datentyp ist INT, der Speicherbereich der temp Variable ist von 38.0 bis 40.0, also zwei Byte


----------



## Grubba (16 Juli 2008)

... wollt ja schon aufhören aber:

Wie kommst Du an Dein Ergebnis von

-> 1103364096 

Passt normalerweise nicht in 2 Byte ???


----------



## HonestAnnie (16 Juli 2008)

Diese Zahl stand rechts im Beobachten Fenster. Also ich danke euch allen für eure Beiträge, aber die Lösung mit dem Bitshift ist für meine Zwecke wirklich perfekt.


----------



## vierlagig (16 Juli 2008)

HonestAnnie schrieb:


> Diese Zahl stand rechts im Beobachten Fenster. Also ich danke euch allen für eure Beiträge, aber die Lösung mit dem Bitshift ist für meine Zwecke wirklich perfekt.



so kommste uns nicht davon - mindestens ich will einen screenshot sehen!


----------



## Grubba (16 Juli 2008)

@ HonestAnnie !!

Böse !

In deinem Eingangsposting hast Du

/I

gepostet.

Das Ergebnis ->1103364096

bekommt man aber zufälligerweise genau dann, wenn man

L 49
L 2
*/R*
T IntErgebnis

rechnet. Kann es sein, dass das /I ein /R war?

Wenns wirklich nicht so war, bitte ich um Entschuldigung und verneige mich vor dem Gott des Zufalls....


----------



## johnij (16 Juli 2008)

HonestAnnie schrieb:


> Hallo,
> ich habe eine Frage zur Division von INT Zahlen.
> 
> Mein Programm sieht so aus:
> ...


 
das Ergebnis "1103364096".  

Das mit 

L X_Int
L 2     (oder Srw 1)
/I
T L X_Int


muss das richtige Ergebnis liefern.

Wenn das Zyklisch aufgerufen ist--> 0

und wenn:
                U X_Bool
                FP Var_Shit 
                    = Var_sch 
                 U Var_sch 
                 SPBN End

                L X_Int
                 L 2     (oder Srw 1)
                 /I
                T L X_Int
            End: NOP 1


denn hat man wie gesagt das richtige Resultat (<>0)


johnij


----------



## vierlagig (16 Juli 2008)

@johnij:

1. code-tags!!!
2. T L x_int wird wohl nicht funktionieren
3. das da 0 rauskommt bestrittest du erst noch, freu mich für dich, dass es bei dir angekommen ist - herzlichen glückwunsch!
4. 
	
	



```
*
        = Var_sch 
        U Var_sch
```
kann man weg lassen, da fühlt man sich nur Va_rscht

@honestannie:

screenshot!


----------



## OHGN (16 Juli 2008)

vierlagig schrieb:


> .....
> @honestannie:
> 
> screenshot!


 
@vierlagig: Ich will Dir ja nicht die Laune verderben, aber ich fürchte da wirst Du lange drauf warten können.:s3:


----------



## johnij (16 Juli 2008)

vierlagig schrieb:


> @johnij:
> 
> 1. code-tags!!!
> 2. T L x_int wird wohl nicht funktionieren
> ...


 

Das hat aber bei mir funktioniert 


johnij


----------



## vierlagig (16 Juli 2008)

johnij schrieb:


> Das hat aber bei mir funktioniert



T L x_int?
ich glaube nicht!
auch von dir: screenshot!


----------



## johnij (16 Juli 2008)

vierlagig schrieb:


> T L x_int?
> ich glaube nicht!
> auch von dir: screenshot!


 

Der Code war:

U X_Bool
FP Var_Shit 
= Var_sch 
U Var_sch 
SPBN End

L   X_Int
L 2 (oder Srw 1)
/I
T  X_Int             (T  L X_Int  Tippfehler )
End: NOP 1


johnij


----------



## Grubba (16 Juli 2008)

@ HonestAnnie

Mach Dir nichts draus, kommt in den besten Familien vor.

@vl

wo ich gerade schon mal dabei bin, gibts zumindest mal einen Ersatz-Screen...

Und, ja, das ist nur das Beispiel mit 49. 

Aber:



> 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).


 
Verstehe ich so, das 49 ein Beispiel war, und auch sonst nur Murks rauskam.

Und nein,  bei der /R Geschichte endet die Divisionsschleife nicht bei 0.


----------



## vierlagig (16 Juli 2008)

johnij schrieb:


> Der Code war:



sag mal ... ich meine du hast doch studiert oder? zumindest verweist du ja immer wieder darauf, dass dich das zur elite macht, auch wegen deinem job da in erlangen bei dieser ominösenfirma, die dich, aus welchen gründen auch immer, als entwickler beschäftigen ...

was muß ich tun um dir in den schädel zu bringen, das code hier wesentlich leserlicher dargestellt wird, wenn man die *code-tags* verwendet? muß man dir das rektal einführen? und wenn du nicht weißt wie es geht, dann lies es nach und wenn du nicht lesen kannst, dann frag nach, was zwar wenigstens vorraussetzt, dass du schreiben kannst, an einem von beidem hege ich zweifel...


----------



## Grubba (16 Juli 2008)

zum letzten noch einen von mir, und das auch noch OT:

Wenn Ihr in diesem sehr höflichen Ton weitermacht, melden sich hier bald noch Franjo Pooth und Oliver Pocher an, um sich hier gegenseitig anzumachen.

Vielleicht gehts ja auch ein bischen höflicher. (Aber lustig zu lesen ists schon*ROFL*)


----------



## OHGN (16 Juli 2008)

Grubba schrieb:


> .....
> 
> Verstehe ich so, das 49 ein Beispiel war, und auch sonst nur Murks rauskam.
> 
> Und nein, bei der /R Geschichte endet die Divisionsschleife nicht bei 0.


Bei mir schon....


----------



## vierlagig (16 Juli 2008)

OHGN schrieb:


> Bei mir schon....



bei mir ist es wie bei grubba ... also bist du in der beweispflicht


----------



## Grubba (16 Juli 2008)

Seltsam...

Habe jetzt gerade den Simulator laufen.

Wenn ich Test als Int definiere und Test dann einen Wert zuweise
(12345, 4321, -123 etc)

endet Test dann immer mit 512. 


```
L Test      // -> endet hier immer bei 512
L 2
/R
T Test    // hier kommt immer 1132462080
```


----------



## OHGN (16 Juli 2008)

Also wenn ich schreibe:

```
L  MW100
L  2
/R
T  MW100
```
dann endet das bei null. Egal welchen Wert ich in das MW100 schreibe.
Verwende ich statt Dessen ein Doppelwort bleibt das Ganze bei 2139095040 hängen.


----------



## vierlagig (16 Juli 2008)

OHGN schrieb:


> dann endet das bei null.



das endet nicht bei null - das ist schon nach dem ersten zyklus null, muß es ja auch irgendwie wenn man sich REAL mal anguckt ... die letzten 16bit sind mantisse 2^-7 - 2^-23 und die sind null, da hat selbst ein rundungsfehler keine chance


----------



## johnij (16 Juli 2008)

vierlagig schrieb:


> sag mal ... ich meine du hast doch studiert oder? zumindest verweist du ja immer wieder darauf, dass dich das zur elite macht, auch wegen deinem job da in erlangen bei dieser ominösenfirma, die dich, aus welchen gründen auch immer, als entwickler beschäftigen ...
> 
> was muß ich tun um dir in den schädel zu bringen, das code hier wesentlich leserlicher dargestellt wird, wenn man die *code-tags* verwendet? muß man dir das rektal einführen? und wenn du nicht weißt wie es geht, dann lies es nach und wenn du nicht lesen kannst, dann frag nach, was zwar wenigstens vorraussetzt, dass du schreiben kannst, an einem von beidem hege ich zweifel...


 
Du hast eine große Fresse.
Wer bist du denn? Fourier, Riemann oder Bill Gate
na mal den Ball flach halten
Ich finde, es ist schade , dass keiner hier im Forum, den Mut hat das zu sagen.

johnij


johnij


----------



## vierlagig (16 Juli 2008)

johnij schrieb:


> Ich finde, es ist schade , dass keiner hier im Forum, den Mut hat das zu sagen.



ich hab doch den mut, wo ist dein problem?


----------



## OHGN (16 Juli 2008)

vierlagig schrieb:


> das endet nicht bei null - das ist schon nach dem ersten zyklus null, muß es ja auch irgendwie wenn man sich REAL mal anguckt ... die letzten 16bit sind mantisse 2^-7 - 2^-23 und die sind bei der ganzzahligen operation null, da hat selbst ein rundungsfehler keine chance


Aber das spricht trotzdem gegen die Version, dass HonestAnnie in seinem code /R statt /I geschrieben haben könnte, vorrausgesetzt es handelte sich bei seiner Variable wirklich um 16-Bit.


----------



## johnij (16 Juli 2008)

vierlagig schrieb:


> ich hab doch den mut, wo ist dein problem?


 
Du verstehst gar nix
Welchen Mut?? in die Hose zu sch....

johnij


----------



## Grubba (16 Juli 2008)

@OHGN

Schliesse mich ganz plötzlich Deiner Meinung an.

(Schäm, hatte im Simulator noch ein paar Testgeschichten laufen, die mir mein MW100 versaut haben )

Endet doch bei 0...

.. Neverending Story....


----------



## Ludewig (16 Juli 2008)

Bitte Schluss jetzt!


----------



## OHGN (16 Juli 2008)

Ludewig schrieb:


> Bitte Schluss jetzt!


@Ludewig:
Wenn Du das Geplänkel zwischen vierlagig und johnij meinen solltest:
*ACK*

Ansonsten sehe ich eigentlich keinen Grund warum man das hier nicht ausdiskutieren dürfen sollte.
Nur weil HonestAnnie sich entschieden hat das Problem durch Austauschen der Division durch einen Schiebebefehl zu lösen, heist das ja nicht dass das Thema damit erledigt wäre.
Die Division hätte genauso gut funktionieren müssen!
Und warum das nicht so war, muß man ja wohl mal ergründen wollen dürfen....


----------



## Ludewig (16 Juli 2008)

Meinte  definitiv nur Ersteres.


----------

