# Maskierung PED PAD



## wee (18 Dezember 2010)

Hallo,

ich darf mich in letzter Zeit vermehrt in die SPS Programmierung einarbeiten und stoße doch des öfteren auf Probleme, deren Lösung ich zwar in den Griff bekomme, diese für mich aber immer wieder recht umständlich erscheinen.

Ich habe ein aktuelles Beispiel für euch und wäre um jeden weiteren Ratschlag dankbar.


Ein SSI Absolutwertgeber hängt auf einer VIPA SSI Baugruppe, die Karte liefert ein PED und besitzt ein PAD. E und A Bereich haben bei mir die Adresse 310.

Das PED ist so aufgeteilt 

PEB 310  Statusbits der Karte       
PEB 311         PEB 312        PEB 313 Hier steht der Absolutwert dualcodiert
Um den Absolutwert in Reinform zu bekommen benutze ich 
L PEB 310
SLD
SRD
T MD 300

Die nicht benötigten Statusbits sind somit erledigt.

Über das PAD kann man der Karte einen Sollwert schicken, bei erreichen des Wertes setzt die Karte einen parametrierbaren Ausgang.

Hier fängt mein Problem an, den Sollwert lege ich im PAB 311 bis PAB 313 ab
das funktioniert auch, nun muss ich die parametrierung des Ausgangs auch auf das PAD schreiben.

In der Anleitung wird verlangt das 25. Bit auf 1 zu setzen um den Ausgang anzuwählen.

Meine Lösung:

L MD 400 // Hier steht der Sollwert drin
L 2#10000000000000000000000000 / Bit 25 ...
OD
T PAD 310

geht das nicht irgendwie "besser" ?


Gruß wee


----------



## Sarek (18 Dezember 2010)

setze das BIT direkt

z.B. so:


```
SET
S M 400.1          // Bit 25 (Doppelwort Bits 0..31)
 
L MD 400
T PAD ....
```


----------



## Larry Laffer (19 Dezember 2010)

Hallo,
ich würde bei solchen Sachen ganz grundsätzlich immer so vorgehen, dass ich mir einen Baustein bauen würde, der innen die Hantierung übernimmt uns mir nach aussen die von mir benötigten Informationen in Reinform liefert (Stichwort Kapselung). Das könnte in deinem Fall z.B. ein FB sein, dem du auf der Schnittstelle die Perepherie-Adresse des Gebers übergibst, der innen dann das PED zerlegt und/oder das PAD aufbereitet und der dir über die Schnittstelle die Status-Bits (im Klartext) und die Ist-Position ausgibt. Wenn du ihn noch irgendwie parametrieren willst dann geht das genauso ...

Das wäre dann elegant ... 

Gruß
Larry


----------



## wee (19 Dezember 2010)

Danke, manchmal sieht man den Wald vor lauter Bäumen nicht


----------



## godi (20 Dezember 2010)

wee schrieb:


> Hallo,
> 
> 
> Das PED ist so aufgeteilt
> ...



Hallo!

Für den Absolutwert hast du die Möglichkeit das du es direkt machst:

```
L PEB 311
T MB 300
L PEW 312
T MW 301
```
Oder über eine Maske:

```
L PED 310
L 0xFFFFFF00
UD
SRD 8
T MD 300
```
Natürlich solltest du das in einem FB machen so wie es Larry schon vorgeschlagen hat. Als keine direkten Adressen verwenden.
Im FB würde ich die Methode mit der Maske verwenden weil da ersparst du dir eine indirekte Adressierung.

Für das 25igste Bit setzten kannst du das ruhig so machen wie du es vorgeschlagen hast.
Oder so wie es Sarek gemacht hat jedoch wenn du einen FB verwendest solltest du da auch nicht mit Absoluter Adressierung auf die Speicherbereiche zugreifen. Nur symbolisch! Dadurch müsstest du auch wieder indirekte Adressierung anwenden und darauf Achten das dein FB Multiinstanzfähig bleibt falls du ihn Multiinstanzfähig haben willst.

godi


----------



## Drutbluck (7 Januar 2011)

Weniger umständlich als die genannten Beispiele geht es nicht. Deine Version war noch die einfachste. Im Gegenteil, ich wundere mich nicht, wenn noch umständlicher als nötig programmiert wird.

Außerdem scheint mir eher, dass es heißen müsste:
L PED 310;
SLD 8;
SRD 8;

Ich würde auf den ersten Blick ein UD 00FFFFFF oder ähnliches bevorzugen, aber deine Idee führt weiter: mit "SSD 8" statt "SRD 8" wird auch noch das Vorzeichen korrekt auf 32bit gebracht.

Selbstverständlich programmiere ich auch mit Variablennamen, nicht mit Adressen. Das schließt einige Varianten aus (M400.1 oder MB300).


----------



## Larry Laffer (7 Januar 2011)

@Drutbluck:
 was wolltest du uns mit deinem Beitrag sagen ? Ich kann da leider den Zusammenhang nicht so recht herstellen ...


----------



## Drutbluck (7 Januar 2011)

Larry Laffer schrieb:


> @Drutbluck:
> was wolltest du uns mit deinem Beitrag sagen ? Ich kann da leider den Zusammenhang nicht so recht herstellen ...



Genau das, was drinsteht. Mit besonderem Bezug auf die Aussage, dass es umständlich erscheint. 

Übrigens halte ich hier einen FB aus verschiedenen möglichen Grunden auch für sinnvoll und benutze selbst einen. Der "umständliche" Code steht dann an genau einer Stelle 1x, und ich kann eine Schnittstelle realisieren, die für verschiedenartige Zähler gleich ist (na gut, das geht auch ohne FB).


----------



## MarkusP210 (10 Januar 2011)

Wie wär's mit:

L PED311
SRD 8
T --> Ziel

Markus


----------



## PN/DP (10 Januar 2011)

MarkusP210 schrieb:


> Wie wär's mit:
> 
> L PED311
> SRD 8
> T --> Ziel


Ich habe sowas noch nicht ausprobiert, doch ich meine, wenn die Baugruppe nicht auch PEB314 enthält, dann funzt das lesen von PED311 nicht.

Harald


----------



## PN/DP (10 Januar 2011)

Hallo wee,

ich würde die Statusbits und den Absolutwert so trennen:

```
L     PED 310
RLD   8
T     #StatusByte
SSD   8
T     #Absolutwert
```

Das Setzen des Bit .25 würde ich genauso machen, wie Du es im Beitrag #1 geschrieben hast (mit OD).

```
L     MD 400    // Hier steht der Sollwert drin (max 24 Bit)
L     2#10_00000000_00000000_00000000 // Bit .25 (26. Bit von LSB/rechts)
OD
T     PAD 310
```

Für solche Sachen, wie Sarek in Beitrag #2 vorschlägt, benutze ich einen so deklarierten Schmiermerkerbereich:

```
TmpUnion_Bit24	M     220.0	BOOL	temporäres DWord für Zugriff auf .0 ... .31
TmpUnion_Bit25	M     220.1	BOOL	temporäres DWord für Zugriff auf .0 ... .31
TmpUnion_Bit26	M     220.2	BOOL	temporäres DWord für Zugriff auf .0 ... .31
TmpUnion_Bit27	M     220.3	BOOL	temporäres DWord für Zugriff auf .0 ... .31
TmpUnion_Bit28	M     220.4	BOOL	temporäres DWord für Zugriff auf .0 ... .31
TmpUnion_Bit29	M     220.5	BOOL	temporäres DWord für Zugriff auf .0 ... .31
TmpUnion_Bit30	M     220.6	BOOL	temporäres DWord für Zugriff auf .0 ... .31
TmpUnion_Bit31	M     220.7	BOOL	temporäres DWord für Zugriff auf .0 ... .31
TmpUnion_Bit16	M     221.0	BOOL	temporäres DWord für Zugriff auf .0 ... .31
TmpUnion_Bit17	M     221.1	BOOL	temporäres DWord für Zugriff auf .0 ... .31
TmpUnion_Bit18	M     221.2	BOOL	temporäres DWord für Zugriff auf .0 ... .31
TmpUnion_Bit19	M     221.3	BOOL	temporäres DWord für Zugriff auf .0 ... .31
TmpUnion_Bit20	M     221.4	BOOL	temporäres DWord für Zugriff auf .0 ... .31
TmpUnion_Bit21	M     221.5	BOOL	temporäres DWord für Zugriff auf .0 ... .31
TmpUnion_Bit22	M     221.6	BOOL	temporäres DWord für Zugriff auf .0 ... .31
TmpUnion_Bit23	M     221.7	BOOL	temporäres DWord für Zugriff auf .0 ... .31
TmpUnion_Bit8	M     222.0	BOOL	temporäres DWord für Zugriff auf .0 ... .31
TmpUnion_Bit9	M     222.1	BOOL	temporäres DWord für Zugriff auf .0 ... .31
TmpUnion_Bit10	M     222.2	BOOL	temporäres DWord für Zugriff auf .0 ... .31
TmpUnion_Bit11	M     222.3	BOOL	temporäres DWord für Zugriff auf .0 ... .31
TmpUnion_Bit12	M     222.4	BOOL	temporäres DWord für Zugriff auf .0 ... .31
TmpUnion_Bit13	M     222.5	BOOL	temporäres DWord für Zugriff auf .0 ... .31
TmpUnion_Bit14	M     222.6	BOOL	temporäres DWord für Zugriff auf .0 ... .31
TmpUnion_Bit15	M     222.7	BOOL	temporäres DWord für Zugriff auf .0 ... .31
TmpUnion_Bit0	M     223.0	BOOL	temporäres DWord für Zugriff auf .0 ... .31
TmpUnion_Bit1	M     223.1	BOOL	temporäres DWord für Zugriff auf .0 ... .31
TmpUnion_Bit2	M     223.2	BOOL	temporäres DWord für Zugriff auf .0 ... .31
TmpUnion_Bit3	M     223.3	BOOL	temporäres DWord für Zugriff auf .0 ... .31
TmpUnion_Bit4	M     223.4	BOOL	temporäres DWord für Zugriff auf .0 ... .31
TmpUnion_Bit5	M     223.5	BOOL	temporäres DWord für Zugriff auf .0 ... .31
TmpUnion_Bit6	M     223.6	BOOL	temporäres DWord für Zugriff auf .0 ... .31
TmpUnion_Bit7	M     223.7	BOOL	temporäres DWord für Zugriff auf .0 ... .31
TmpUnion_HH_B	MB    220	BYTE	temporäres DWord Bits .24 ... .31
TmpUnion_HL_B	MB    221	BYTE	temporäres DWord Bits .16 ... .23
TmpUnion_LH_B	MB    222	BYTE	temporäres DWord Bits .8 ... .15
TmpUnion_LL_B	MB    223	BYTE	temporäres DWord Bits .0 ... .7
TmpUnion_H_W	MW    220	WORD	temporäres DWord Bits .16 ... .31
TmpUnion_L_W	MW    222	WORD	temporäres DWord Bits .0 ... .15
TmpUnion_DW	MD    220	DWORD	temporäres DWord Bits .0 ... .31
```

Harald


----------



## MarkusP210 (12 Januar 2011)

> Ich habe sowas noch nicht ausprobiert, doch ich meine, wenn die Baugruppe nicht auch PEB314 enthält, dann funzt das lesen von PED311 nicht.


 
Das PAE ist ein Systemdatenbereich welcher durch das Betriebssystem nach der Initialisierung im Rahmen der eingesetzten CPU alloziert und bereitgestellt wird. Solange der Zugriff innerhalb des PAE bleibt, funktioniert das einwandfrei.

Markus


----------



## Larry Laffer (12 Januar 2011)

MarkusP210 schrieb:


> Das PAE ist ein Systemdatenbereich welcher durch das Betriebssystem nach der Initialisierung im Rahmen der eingesetzten CPU alloziert und bereitgestellt wird. Solange der Zugriff *innerhalb des PAE* bleibt, funktioniert das einwandfrei.
> 
> Markus


 
Na toll ...
Dann sag mir doch mal, bei welcher CPU du davon ausgehen kannst, dass die Adresse 311 noch standardmäßig innerhalb des PAE bleibt ...? Oder anders ... wie kannst du das hier voraussetzen ?

Für mich ist dieser Vorschlag in dieser Form unbrauchbar - sorry ...

Gruß
Larry


----------



## MarkusP210 (12 Januar 2011)

> Na toll ...
> Dann sag mir doch mal, bei welcher CPU du davon ausgehen kannst, dass die Adresse 311 noch standardmäßig innerhalb des PAE bleibt ...? Oder anders ... wie kannst du das hier voraussetzen ?


 
Von standardmässig war hier nie die Rede, sondern von der kürzest möglichen Lösung der Aufgabe. Ausserdem spricht nichts dagegen, die Basisadresse der SSI-Baugruppe ins PAE zu verschieben.



> Für mich ist dieser Vorschlag in dieser Form unbrauchbar - sorry


 
Unbrauchbar ist vor allem Dein Ton!

Markus


----------



## PN/DP (12 Januar 2011)

MarkusP210 schrieb:


> Wie wär's mit:
> 
> L PED311
> SRD 8
> T --> Ziel





PN/DP schrieb:


> Ich habe sowas noch nicht ausprobiert, doch ich meine, wenn die Baugruppe nicht auch PEB314 enthält, dann funzt das lesen von PED311 nicht.





MarkusP210 schrieb:


> Das PAE ist ein Systemdatenbereich welcher durch das Betriebssystem nach der Initialisierung im Rahmen der eingesetzten CPU alloziert und bereitgestellt wird. Solange der Zugriff innerhalb des PAE bleibt, funktioniert das einwandfrei.


Achtung - nicht verwechseln!
Mit *L PED311* wird *nicht* auf das PAE zugegriffen, sondern auf die Baugruppe, unabhängig davon, wie groß das PAE ist.
Soll auf das PAE zugegriffen werden, dann muß *L ED311* benutzt werden und das PAE muß groß genug sein.

Harald


----------



## PN/DP (12 Januar 2011)

MarkusP210 schrieb:


> > Für mich ist dieser Vorschlag in dieser Form unbrauchbar - sorry
> 
> 
> Unbrauchbar ist vor allem Dein Ton!
> ...


Ich empfinde den Vorschlag eines derartig "krummen" Zugriffs aus mehreren Gründen ebenfalls unbrauchbar (selbst wenn es funktionieren sollte), ich hätte das aber nicht so freundlich wie Larry ausdrücken können. 

Besonders unbrauchbar empfinde ich Halbwissen, Schnellschuß-Programmierung, ohne genau zu wissen was man tut, und eingeschnappte Leberwürste ... 

Harald


----------



## Larry Laffer (12 Januar 2011)

Danke Harald ...

@Markus_P210:
Es geht hier nicht um irgendwelche Kunstgriffe sondern um "zumindestens ansatzweise saubere Programmierung".
Und was das angeht hast du da m.E. nicht getroffen - auch wenn es unter den genannten Einschränkungen vielleicht funktionieren würde (ich habe es nicht erwogen, das zu testen).
Und einen "unbrauchbaren Ton" wirst du hier im Forum von mir noch nicht gelsen haben ... 

Gruß
Larry


----------

