Step 7 Step 7 , schieben mit berechneter verschiebezahl

Booster

Level-1
Beiträge
5
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Hey,
ich habe da mal eine Frage.. und zwar habe ich einen FC erzeugt, um div. Motorenzustaende in einer Visualisierung darzustellen. Das habe ich mit dem Schiebebefehl SLW probiert.
Als Eingang fuer den FC gebe ich im Programm eine fest vergebene Motorennummer an (Motornummer fuers Word 0-3), sodass ich in der Visualisierung später die einzelnen bits anspreche.
Bsp. bei einer Stoerung vom Motor "0"(Stoerbit ist das 4. bit): SOLL DB10.dbw2 = 0000 0000 0000 1000; IST: 0000 1000 0000 0000
Habe die Verschiebezahl errechnet:
L #Mot_nr_Word
L 4
*I
T #Temp

und dann mit der Verschiebezahl verschoben
L #Temp
L MW 140 (von dem MW werden einzelne Bits vorher belegt )
SLW
T #AusgabeWord

Also das Problem ist, dass es halt um ein Byte verschoben ist.
Habe es jetzt anders geloest aber wollte mal fragen, weshalb das so ist. Hat das mit dem AKKU1 und 2 zu tun ?
Vielen Dank im voraus für die Antwort!;)
 
Es ist nicht ganz verschoben sondern verdreht.
Das liegt an Siemens.
Vielleicht hilft Dir dieses weiter, damit habe ich es am besten verstanden und lösen können.

edit:
mittels TAW und TAD Anweisungen können sie in Step 7 einfach gedreht werden.

Also
Code:
L MW40
TAW
T MW50
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich vermute, irgendwo verwendest Du H-Byte und L-Byte vertauscht. Das Ergebnis ist nicht um 1 Byte verschoben, sondern die beiden Bytes des Words sind gegenüber Deiner Erwartung vertauscht. Die Bytes (zurück-)tauschen kann man mit TAW.

Harald
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Okay schonmal danke für den Link :) ist wirklch gut verständlich erklärt!
aber auch wenn es an den vertauschten Bytes liegt, müsste ich trotzdem irgendein Ergebnis bei den Verschiebezahlen>7 sehen. Deshalb dachte ich ja, dass es mit den Akku's zu tun haben könnte. Habe ich dummerweise vergessen in die Fragestellung mit rein zu schreiben :p
 
Mit #Mot_nr_Word = 0,1,2,3 kann #Temp nur die Werte 0,4,8,12 haben. #Temp ist die Verschiebezahl. Dein MW140 wird dementsprechend um 0, 4, 8 oder 12 Bits nach links geschoben. Dabei macht es Sinn, wenn im MW140 nur die unteren 4 Bits (M141.0 .. M141.3) für Informationen benutzt sind und alle anderen Bits 0 sind, weil die Bits .4 bis .15 je nach Schiebezahl aus dem Word herausgeschoben werden (verschwinden).

Ist das nicht das was Du gewollt/erwartet hast?

Harald
 
Ja genau. Ich habe nur die Bits 0-3 belegt und diese sollen dann eben um 0,4,8 oder 12 Bits nach links geschoben werden. Es funktioniert ja soweit.. außer das bei der Motornummer 2 und 3 garkein Bit mehr im Word gesetzt ist. Sobald das Bit in das nächste Byte verschoben wird, ist es nichtmehr gesetzt.
Es wird bei der Motornr 2 erwartet: 0000 0100 0000 0000
aber es kommt überall 0 heraus.
Das Word wird auch nirgendwo anders benutzt..
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Kann es sein daß Du davon ausgehst, daß M140.0 .. M140.3 die Bits 0 bis 3 sind? Dann würden die Bits bei Motornummer 2 und 3 komplett verschwinden.
Dann versuche mal so:
Code:
L #Mot_nr_Word
SLW 2
T #Temp         //Zwischenspeichern in #Temp ist hier nicht nötig

L #Temp         //hier nicht nötig
L MW 140
TAW
SLW
T #AusgabeWord
Je nachdem wie das AusgangsWord erwartet wird, dann vielleicht auch so:
Code:
L #Mot_nr_Word
SLW 2
L MW 140
TAW
SLW
TAW
T #AusgabeWord

Harald
 
Hat das mit dem AKKU1 und 2 zu tun ?
Mit Akku1: ja - siehe vorausgegange Beiträge bezüglich möglicherweise vertauschter Bytes.
Mit Akku2: nein - da steht doch ("rechtsbündig") drin, um wieviele BitPositionen der Akku1-Inhalt geschoben werden soll.
SchiebeRichtung: vielleicht. Je nach dem, was Du erreichen willst.
"SchiebeArt": vielleicht willst Du gar nicht schieben, sondern den Akku1-Inhalt rotieren?

Das Problem mit den "möglicherweise vertauschten Bytes" rührt daher, dass ein Teil der Menscheit es gewohnt ist, von links nach rechts zu lesen, aber die Zahlen von rechts nach links "aufbaut" (Z.B. werden deshalb In Excel standardmässig Texte linksbündig und Zahlen rechtsbündig in den Zellen ausgerichtet).
Das hat dazu geführt, dass man wie selbstverständlich Bytes von links nach rechts mit aufsteigender ByteNr darstellt.
Funktioniert gut, wenn die Bytes Buchstaben enthalten und der Text somit von links nach rechts gelesen werden kann. Zusätzliche Bytes werden rechts angefügt.
Funktioniert nicht gut, wenn die Bytes Zahlen enthalten. Wenn z.B. von INT auf DINT erweitert werden muss, um eine höhere StellenZahl zu ermöglichen, dann erwarten wir wie selbstverständlich, dass das/die zusätzliche[n] Byte links angefügt werden, weil die höherwertigen Stellen im höherwertigen Byte - dank unserer ZahlenDarstellung links - stehen sollen.
Die Bytes, die wir aber "links" anfügen, haben kleinere ByteNrn, jedenfalls nach dem bisher beschriebenen System.
Die Wertigkeit der Bits in einem Byte oder Wort oder DoppelWort oder ... steigt von rechts nach links und die Wertigkeit der Bytes in dem Wort oder DoppelWort oder ... ebenfalls.
So ist es im Akku immer.
Und bei Siemens wird diese Reihenfolge der Bytes beibehalten, wenn der AkkuInhalt in den Speicher kopiert wird. D.h. höherwertiges Byte landet in dem Byte mit der niederwertigeren ByteNr.
Intel hat damit "aufgeräumt" und das Verfahren dadurch - oh Wunder - durcheinander gebracht. Hier landet das höherwertige Byte des Akkus im Speicher in einem Byte mit einer höherwertigen ByteNr.
Diese Bytes müsste man aber mit von rechts nach links steigenden ByteNrn zu Papier bringen bzw. auf dem Bildschirm darstellen, um sie in gewohnter Weise lesen zu können.
Bei den SpeicherAdressen sind Kriterien wie von links nach rechts oder von rechts nach links natürlich irrelevant. Das "Problem" betrifft ausschliesslich unsere Lese- und SchreibGewohnheiten und wurde durch einerseits mehr und andererseits weniger Rücksichtnahme darauf geschaffen.
Siemens hat sich von der wortweisen Zählung in DatenBausteinen bei S5 zur byteweisen Zählung bei S7 weiter(oder zurück?)-entwickelt und sogar die bitweise fortlaufende Zählung eingeführt - was eigentlich nur konsequent ist, aber ständig zur Verwirrung bei "S7-Frischlingen" beiträgt. Eigentlich kein schlechter Weg für SPS-Anwendungen, wo man häufig BitInformationen verküpft und diese Bits sich in Gruppierungen finden, die Bytes heissen oder Worte oder ... .
Parallel dazu sind die SpeicherKosten so sehr gesunken und in anderen Bereichen (jenseits der SPS und jenseits der BetriebsSystemEbene) auch das Interesse daran, einzelne Bits aus Bytes, Worten, DoppelWorten u.s.w. zu betrachten, sodass für BOOL-Variablen mittlerweile ganze Bytes oder Worte u.s.w. "spendiert" (verschwendet) werden, weil die Prozessoren damit schneller rechnen können.
Früher hatte man nicht so viele Möglichkeiten wie heute und gerade darum war alles "viel einfacher".

PS:
Es wird bei der Motornr 2 erwartet: 0000 0100 0000 0000
Das kann doch gar nicht sein!? Nach dem Verschieben des AkkuInhaltes um 8 BitPositionen nach links taucht der vorherige Inhalt des rechten Bytes nicht im linken Byte auf?
Was steht denn wirklich im Akku2? Wirklich die 8?
Oder wird die Passage zyklisch durchlaufen und Du siehst erst, was nach n-mal um 8 BitPositionen verschieben übriggeblieben ist?
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Es wird bei der Motornr 2 erwartet: 0000 0100 0000 0000
Das kann doch gar nicht sein!? Nach dem Verschieben des AkkuInhaltes um 8 BitPositionen nach links taucht der vorherige Inhalt des rechten Bytes nicht im linken Byte auf?
Wenn der TE davon ausgeht daß die niederwertigen Bits des Words im Byte mit der niedrigeren Adresse stehen müssten (M140.0 bis M140.3), dann sieht das Bitmuster nach dem Laden des MW140 in den AKKU schon vor der Verschiebung so aus wie nach der Verschiebung um 8 Bitstellen erwartet, und nach der Verschiebung (der 8 Bits aus MB141 (rechtes Byte) an die Position der Bits aus MB140 (linkes Byte)) sind die Bits weg :sad: :cry:

Harald
 
Wenn der TE davon ausgeht daß die niederwertigen Bits des Words im Byte mit der niedrigeren Adresse stehen müssten (M140.0 bis M140.3), dann sieht das Bitmuster nach dem Laden des MW140 in den AKKU schon vor der Verschiebung so aus wie nach der Verschiebung um 8 Bitstellen erwartet, und nach der Verschiebung (der 8 Bits aus MB141 (rechtes Byte) an die Position der Bits aus MB140 (linkes Byte)) sind die Bits weg :sad: :cry:
Allerdings, Harald.
Habe leider wieder EmpfangsStörungen in meiner GlasKugel und weiss nicht so recht, was sich tatsächlich abspielt.
Könnten wir mal 4 Beispiele für die 4 MotorNrn 0 .. 3 mit meinetwegen immer demselben Bitmuster (z.B. 0001 0011 0101 0111) erhalten, wo man jeweils den Akku1-Inhalt vor dem Schieben und nach dem Schieben sehen könnte ... aber damit könnte der TE schon selbst erkennen, was tatsächlich abläuft. Oder er könnte zumindest konkret sagen, wie die tatsächliche Wirkung von der erwarteten abweicht.

Aber die Suche nach einer ganz anderen Lösung für die noch nicht ganz klare Aufgabenstellung klingt eigentlich noch interessanter. ;)
Gruss, Heinileini
 
Ich würde lieber verstehen wozu überhaupt geschoben wird, wie sieht die Darstellung in der Visu aus?

Und: versteht das Konstrukt jemand in 4 Jahren?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hab meine fehler schon selber bemerkt :D
es sollen auf einer Bildvorlage 24 Motoren durch div. farbliche Darstellungen auf die akt. Motorenzustände hinweisen (an, aus, Störung usw.) Ich dachte dabei an das verschieben der Bits in einem FC, um dann später im DB einzelne Bits für die Gestaltung abzufragen. Den FC hätte ich dann dementsprechend oft aufgerufen. Funktiontiert ja schonmal nicht, da ich ja nicht das MW zig mal überschreiben kann ohne das dabei nur mist raus kommt.
Wie würdet ihr so eine Problemstellungen lösen?
 
es sollen auf einer Bildvorlage 24 Motoren durch div. farbliche Darstellungen ...
24 Motoren. Also 6 Worte alias 12 Byte alias 3 DoppelWorte. Es wird also auch darum gehen, das Verfahren auf mehrere Worte (oder Bytes oder DoppelWorte) anzuwenden, also verschiedene Worte ( ... ) MotorNrn-abhängig zu adressieren.
Funktiontiert ja schonmal nicht, da ich ja nicht das MW zig mal überschreiben kann ohne das dabei nur mist raus kommt.
MW sind sehr geduldig - wie andere Worte (und Bytes und DoppelWorte) übrigens auch. Man kann sehr viel damit machen, nicht nur Mist.
Wenn es darum geht, dass Du (MaschinenNr-abhängig) nur bestimmte Bits beeinflussen willst, alle anderen aber nicht (sie sollen so bleiben, wie sie sind), dann heisst das ZauberWort "maskieren".

Wie immer, gänzlich ungetestet:
Code:
      L    MotorNr         // 0 .. 23
      L    4
      /I
      T    WortMotorNrDiv4 // "Index" für Wort bzw. SprungVerteiler
      SRD  16              // WortMotorNrMod4
      L    4
      *I
      T    WortTempSchiebeZahl
      L    15
      SLW
      INVI
      T    WortTempMaske  
      L    WortMotorNrDiv4 // Wort für betroffene MotoNr lesen
      SPL  SPL1
      SPA  M100
      SPA  M104
      SPA  M108
      SPA  M112
      SPA  M116
      SPA  M120
SPL1: SPA  ERR
M100: L    MWvonMotor00bis03
      SPA  CON1
M104: L    MWvonMotor04bis07
      SPA  CON1
M108: L    MWvonMotor08bis11
      SPA  CON1
M112: L    MWvonMotor12bis15
      SPA  CON1
M116: L    MWvonMotor16bis19
      SPA  CON1
M120: L    MWvonMotor20bis23
CON1: L    WortTempMaske
      UW            // neu zu definierende BitPositionen löschen
      T    WortTempMaskiert
      L    WortTempSchiebeZahl
      L    Bits0..3 // Bits, die geschoben werden sollen
      UW   W#16#F   // restliche Bits löschen
      SLW
      L    WortTempMaskiert
      OW            // neue Bits einfügen
      L    WortMotorNrDiv4 // Ergebnis in das Wort für betroffene MotoNr schreiben 
      SPL  SPL2
      SPA  M200
      SPA  M204
      SPA  M208
      SPA  M212
      SPA  M216
      SPA  M220
SPL2: SPA  ERR
M200: TAK
      T    MWvonMotor00bis03
      SPA  CON2
M204: TAK
      T    MWvonMotor04bis07
      SPA  CON2
M208: TAK
      T    MWvonMotor08bis11
      SPA  CON2
M212: TAK
      T    MWvonMotor12bis15
      SPA  CON2
M216: TAK
      T    MWvonMotor16bis19
      SPA  CON2
M220: TAK
      T    MWvonMotor20bis23
CON2: NOP  0
ERR:  NOP  0
Für bis zu 24 Motoren (Nrn von 0 bis 23). Belegt also 6 verschiedene Worte mit den Bitmuster[Tertrade]n.
Bei MotorNr > 23 wird zum Label ERR gesprungen. Ggfs noch um sinnvolle FehlerBehandlung ergänzen!
Ganz ohne Pointer und ohne Array, sondern mit Sprungverteilern realisiert, also sehr "zu Fuss". ;)
 
okay.. Ich werde das nächste Woche zum Spaß mal eintippen :D Vielen Dank für das Beispiel! Habe jetzt für jeden Motor ein seperates Word genommen und lasse den Motor dann noch drehen. Ein wenig spielerei dann eben :D
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich werde das nächste Woche zum Spaß mal eintippen
Mit copy+paste in einen Editor schaufeln,
dann mit suchen+ersetzen die VariablenNamen durch die ersetzen, die Du schon verwendest,
dann mit copy+paste ins S7-Programm schaufeln.
Eintippen kling so mühsam.
Habe jetzt für jeden Motor ein separates Word genommen und lasse den Motor dann noch drehen.
Passt das BeispielProgramm dann überhaupt noch zu Deiner Anwendung? Das solltest Du Dir vor dem mühsamen Eintippen überlegen! ;)
 
Zurück
Oben