# Programmierwettbewerb: Diskussion



## Kai (16 Juni 2011)

Kleiner Hinweis:



> *Umwandlung BCD nach INT*
> 
> Die Anweisung BIT interpretiert den im rechten Wort des Akkumulators 1 stehenden Wert (die Bits 0 bis 15) als BCD-codierte Zahl mit 3 Dekaden.
> 
> ...


 
Es gilt also:

*BCD-Zahl positiv: *

Bits 12 bis 15 = 0 0 0 0 

*BCD-Zahl negativ:* 

Bits 12 bis 15 = 1 1 1 1 

Gruß Kai


----------



## Jochen Kühner (16 Juni 2011)

Kai schrieb:


> Es gilt also:
> 
> *BCD-Zahl positiv: *
> 
> ...



Laut meiner Step 7 Hilfe:


```
... Bit 15 das Vorzeichen (0 = positiv, 1= negativ) der BCD-Zahl an. Bit 12 bis Bit 14 werden bei der Umwandlung nicht verwendet.
```

Also müssen die Bits 12-14 auch nicht geprüft werden da BTI unabhänig von deren Zustand funktioniert!


----------



## M-Ott (16 Juni 2011)

Die Siemens-Informationen sind in diesem Fall unklar: Je nachdem, wohin man schaut, heißt es entweder Minus entspricht Bit 12-15 = 1 oder minus entspricht Bit 15 = 1. Testen ergibt: BTI funktioniert mit einem beliebigen Wert im Vorzeichen-Nibble. Jeder Wert außer 0000 wird als minus interpretiert. ITB führt zu einem Vorzeichen-Nibble von 1111.
Es ist also nicht zwingend nötig, das Vorzeichen-Nibble zu überprüfen. BTI führt nicht aufgrund eines falschen Vorzeichen-Nibbles zu einem BCD-Fehler.


----------



## vierlagig (16 Juni 2011)

da jetzt schon in dem anderen thread eine diskussion aus zu brechen droht hier die entsprechende spielwiese dazu... (vielleicht erbarmt sich ja ralle die letzten drei beiträge hier mit ran zu tun...)

zur ersten aufgabe:
ich stelle fest, siemens hat BCD stiefmütterlich behandelt - vielleicht zu recht, stirbt ja langsam... div 0 holt OB121 nicht raus aber eine ungültige BTI ... naja, was solls. die letzte lösung gefällt mir übrigens bisher am besten, kurz und knackig


----------



## vierlagig (16 Juni 2011)

ferner stelle ich fest: helmut findet alles gut...


----------



## rostiger Nagel (16 Juni 2011)

Aber natürlich ich bin ein positiver Mensch :-D

Komm bekommst auch noch ein Danke von mir.....schulterklopf bei 4l


----------



## Kai (16 Juni 2011)

> *Umwandlung INT nach BCD*
> 
> Die Anweisung ITB interpretiert den im rechten Wort des Akkumulators 1 stehenden Wert (die Bits 0 bis 15) als Zahl mit
> dem Datentyp INT und wandelt sie in eine BCD-codierte Zahl mit 3 Dekaden.
> ...


 
*INT Zahl positiv*

Umwandlung* INT nach BCD* setzt in der BCD-Zahl die Bits 12 bis 15 = 0 0 0 0

*INT-Zahl negativ*

Umwandlung *INT nach BCD* setzt in der BCD-Zahl die Bits 12 bis 15 = 1 1 1 1

Wenn also ein WORD auf eine gültige BCD-Zahl geprüft werden soll, dann müssen meiner Meinung nach in der BCD-Zahl die 
Bits 12 bis 15 auf den Signalzustand geprüft werden, auch wenn bei der Umwandlung *BCD nach INT* nur der Signalzustand des 
Bits 15 berücksichtigt wird.

Gruß Kai


----------



## Kai (16 Juni 2011)

Larry Laffer schrieb:


> ```
> // 4. (Vorzeichen-) Nibble ausmaskieren
> //    wenn Vorzeichen dann ist das höchste Bit gesetzt (= w#16#8000) sonst Null
> L     #InBCD;
> ...


 


Nordischerjung schrieb:


> ```
> //Vorzeichen Nibbel abfragen
> L     #inWORD; //BCD Word als IN
> SRW   12; //Bit 12-15 nach Rechts schieben und auf Bit 0-3
> ...


 


LargoD schrieb:


> ```
> L     #inBCD;
> UW    W#16#7000; // Illegales Bit im Vorzeichen-Nibble?
> SPP   BAD; // Ja
> ```


 
Bei einer BCD-Zahl mit dem Vorzeichen in den Bits 12 bis 15 werden die obigen Programmbeispiele nicht funktionieren.

Gruß Kai


----------



## vierlagig (16 Juni 2011)

helmut, mich dolcht der kai ignoriert uns


----------



## SPSKILLER (16 Juni 2011)

Hi Kai,

es ist doch scheißegal was in den Bits 12-15 steht. 
Wenn nicht alle auf 0 sind, dann ist's halt ne negative Zahl. 

Um den CPU Stopp zu umgehen müssen nur die Bits 0-11 plausibel sein.

Ich persönlich finde die Lösung von 4L bisher am nächsten an der Praxis, und somit am besten. 
Würde ich auch so machen.


----------



## Kai (16 Juni 2011)

Entschuldigung, ich habe gerade erst diesen Thread gesehen. 

Ich würde euch beide doch nie ignorieren. 

Gruß Kai


----------



## vierlagig (16 Juni 2011)

Kai schrieb:


> Ich würde euch beide doch nie ignorieren.



na klaaaar .... 

unds killersche verspottet mich, och mal wieda scheen


----------



## Kai (16 Juni 2011)

SPSKILLER schrieb:


> es ist doch scheißegal was in den Bits 12-15 steht.
> Wenn nicht alle auf 0 sind, dann ist's halt ne negative Zahl.


 
Es ist eben nicht egal, was in den Bits 12 bis 15 der BCD-Zahl steht.

Wenn man eine negative INT-Zahl mit der Anweisung ITB in eine BCD-Zahl umwandelt, dann bekommt man eine gültige BCD-Zahl mit 
dem Signalzustand 1 in den Bits 12 bis 15 für das Vorzeichen der BCD-Zahl.

Wenn man dann diese gültige BCD-Zahl mit den Programmbeispielen von Larry Laffer, Nordischerjung und LargoD prüft, bekommt man 
als Ergebnis, dass die BCD-Zahl ungültig ist, obwohl sie ja gültig ist. Die Programmbeispiele funktionieren also nicht richtig.

Gruß Kai


----------



## SPSKILLER (16 Juni 2011)

... wird ich nie machen. Du zeigst den Wandlungsfehler wenigstens direkt an der HW an


----------



## vierlagig (16 Juni 2011)

Kai schrieb:


> Entschuldigung, ich habe gerade erst diesen Thread gesehen.
> 
> Ich würde euch beide doch nie ignorieren.
> 
> Gruß Kai



tust du wohl!


----------



## SPSKILLER (16 Juni 2011)

@Kai
Ok. Ich hab verstanden was du meinst. 
Ich sollte mal besser lesen...

Aber ich wollte eigentlich nur sagen, dass für den BTI Befehl an sich nicht relevant ist, was in den Vorzeichenbits steht. 
Deshalb müssen diese nicht ausgewertet werden...


----------



## Kai (16 Juni 2011)

SPSKILLER schrieb:


> Aber ich wollte eigentlich nur sagen, dass für den BTI Befehl an sich nicht relevant ist, was in den Vorzeichenbits steht.
> Deshalb müssen diese nicht ausgewertet werden...


 
Das ist richtig.

Gruß Kai


----------



## rostiger Nagel (17 Juni 2011)

Also der vom Micha (SPSKILLER) im Beitrag #8 gefällt mir eindeutig am besten;
Pfiffig gemacht mit der Schleife so kann der Eingangswert mal
schnell erweitert oder gekürzt werden, gut Auskommentiert (vor allen
Dingen Sinnvoll, da ist mir der von Harald schon wieder zu überladen und
somit Unübersichtlich). Eindeutig hervor zu heben ist das er eine Info
über "QERR" herausgibt ob der Wert überhaubt gültig ist. Das vermisse
ich bein den anderen und macht die Bausteine für die Praxis unbrauchbar,
da nicht unterschiden werden kann, ob jetzt Null das richtige Ergebnis
ist oder ob es der Ersatztwert ist.
Das Higlight wäre gewesen wenn er für Fehlermeldung den "RET_VAL"
genutzt hätte, so wie mann es bei den Siemens Biblotheken gewohnt ist,
so hätte mann z.b. mit Fehlercodes Kennzeichnen können an welcher
Stelle der Fehler auftritt.

0000 Es ist kein Fehler aufgetreten
8001 Pseudotetrade an der ersten stelle
8002 Pseudotetrade an der zweiten stelle
8003 Pseudotetrade an der dritten stelle
und was ein noch so alles einfällt.

Im Allgemeinen sollten wir später den besten Baustein überarbeiten und
dann im FAQ eine Biblothek mit diesen Bausteinen erstellen.


----------



## M-Ott (17 Juni 2011)

Helmut_von_der_Reparatur schrieb:


> Im Allgemeinen sollten wir später den besten Baustein überarbeiten und dann im FAQ eine Biblothek mit diesen Bausteinen erstellen.


Eine sehr gute Idee. Wäre schade wenn dieses geballte Brainstorming verloren geht.

BCD wird von Siemens sehr stiefmütterlich behandelt und ist auch sehr schlecht (von Siemens selbst) dokumentiert. Eine verkehrtes Vorzeichen-Nibble führt nicht zu einem BCD-Fehler. ITB führt zu einem Vorzeichen-Nibble 1111, somit würden die Lösungen die das Vorzeichen auf 1000 überprüfen alle dazu führen, dass eine mit ITB gewandelte Zahl als fehlerhaft interpretiert wird.


----------



## Larry Laffer (17 Juni 2011)

Interessant ...
Da habe ich dann wohl den Fehler gemacht, mich auf die Siemens-Beschreibung zu verlassen. Das blöde daran ist, dass ich es hätte wissen müssen - denn das Siemens (wie auch viele Andere) nicht in der Lage ist zu ihren Produkten eine korrekte Dokumentation zu liefern hatte ich eigentlich gewußt.
Egal - c'est la vie ... 

Bezüglich der gemachten Beiträge würde mein Votum klar an 4L gehen. Es erinnert mich ein bißchen an absolut übliche Vorgehensweisen in der OOP, wo ich mit "Try - Catch" auf Fehler überprüfe und im Bedarfsfall abfange.

Gruß
Larry


----------



## vierlagig (17 Juni 2011)

@PN/DP: LW0? das ist nicht dein ernst, oder? da spuck ich drauf!

@larry: genau so war es gedacht... warum es in steuerungen noch kein try{}catch{} gibt ist mir schleierhaft


----------



## PN/DP (17 Juni 2011)

Helmut_von_der_Reparatur schrieb:


> gut Auskommentiert (vor allen
> Dingen Sinnvoll, da ist mir der von Harald schon wieder zu überladen und
> somit Unübersichtlich)


Hey Helmut, wo genau findest Du meine Kommentare "überladen und unübersichtlich"? 
Stören Dich die Abschnittsüberschriften oder die Ergebnisdarstellung der SLW-Operationen oder sind es die Kommentare bei der bedingten Ergebnisausgabe?
Ich finde, meine Kommentare sind genau richtig für diejenigen Anwender, die eine solche Fertig-Funktion als Fremd-Quelle nötig haben.
Naja, meine Auslassungen sind halt immer etwas umfangreicher 



Helmut_von_der_Reparatur schrieb:


> Eindeutig hervor zu heben ist das er eine Info
> über "QERR" herausgibt ob der Wert überhaubt gültig ist. Das vermisse
> ich bein den anderen und macht die Bausteine für die Praxis unbrauchbar,
> da nicht unterschiden werden kann, ob jetzt Null das richtige Ergebnis
> ist oder ob es der Ersatztwert ist.


Also ich gebe den Fehlerstatus wie bei Siemens üblich über das BIE-Bit aus.



Helmut_von_der_Reparatur schrieb:


> Das Higlight wäre gewesen wenn er für Fehlermeldung den "RET_VAL"
> genutzt hätte


Der RET_VAL ist nicht gut für die Rückgabe von Fehlermeldungen. Der RET_VAL ist dafür da, daß solche AWL-FC in Hochsprachen wie SCL als echte Function für verkettete Operationen benutzt werden können. [Nachtrag] bzw. allgemein als Ausdruck auf der rechten Seite von Zuweisungen. [/Nachtrag]



Helmut_von_der_Reparatur schrieb:


> Im Allgemeinen sollten wir später den besten Baustein überarbeiten und
> dann im FAQ eine Biblothek mit diesen Bausteinen erstellen.


*ACK*
Meine ich auch, es sollte eine zentrale Sammelstelle/Sammelthread für die Endversion solcher Bausteine ohne die Diskussionsbeiträge geben.
In dem jeweiligen FAQ-Beitrag sollte jeweils ein Link auf die ursprüngliche Diskussion sein, damit User später nachvollziehen können, warum dieser Baustein als für die Problemlösung am besten geeignet ausgewählt wurde und warum er mehr tut als auf den ersten Blick nötig.

Harald


----------



## PN/DP (17 Juni 2011)

vierlagig schrieb:


> @PN/DP: LW0? das ist nicht dein ernst, oder? da spuck ich drauf!


Ist aber immer noch besser (gekapselt) als die Verwendung eines Schmiermerker-Words (das ich auch erwähnte).
Der FUP/KOP-Editor kommt mit dem LW0 jedenfalls problemlos klar.
Wie all die Knowhow-geschützten Bausteine realisiert sind interessiert doch auch niemanden, solange sie funktionieren.

Harald


----------



## rostiger Nagel (17 Juni 2011)

PN/DP schrieb:


> Hey Helmut, wo genau findest Du meine Kommentare "überladen und unübersichtlich"?
> Stören Dich die Abschnittsüberschriften oder die Ergebnisdarstellung der SLW-Operationen oder sind es die Kommentare bei der bedingten Ergebnisausgabe?
> Ich finde, meine Kommentare sind genau richtig für diejenigen Anwender, die eine solche Fertig-Funktion als Fremd-Quelle nötig haben.
> Naja, meine Auslassungen sind halt immer etwas umfangreicher


 
Im Prinzip der Bausteinkommentar, das kann mann schmaller gestalten, die
Step 7 zu Zittieren ist mehr als überflüssig, da drücke ich doch lieber F1.

Dann sind die mir die Zeilenkommentar (finde ich) so unpraktisch gesetzt
das den Code zerschlägt.

Manchmal ist halt weniger mehr.....meine oberste Devise.





PN/DP schrieb:


> Also ich gebe den Fehlerstatus wie bei Siemens üblich über das BIE-Bit aus.


 
Mmh...ist dann das Bit für das Binärergebnis bei dir richtig angewand worden...?
Du wertest es bei einen Fehler aus und setzt es auf "0", aber 
was ist den wenn es beim Einsprung des Bausteins schon auf "0" war?
Deine "SPA" Sprünge und Vergleiche haben doch erstmal keinen Einfluss
auf das BIE und somit könntest du doch bei einen Fehlerfreien Durchlauf
den Baustein trotzdem mit "0" am BIE verlassen.
Eindeutiger wäre da für mich erstmal in den ersten zwei Zeilen das Binär-
ergebnis geziehlt auf "1" zu setzen.

```
SET
SAVE  //BIE = "1"
```
 




PN/DP schrieb:


> Der RET_VAL ist nicht gut für die Rückgabe von Fehlermeldungen. Der RET_VAL ist dafür da, daß solche AWL-FC in Hochsprachen wie SCL als echte Function für verkettete Operationen benutzt werden können. [Nachtrag] bzw. allgemein als Ausdruck auf der rechten Seite von Zuweisungen. [/Nachtrag]


 
Die Anwendung für den RET_VAL kann mann so oder so nehmen, in diesen
Fall hätte ich ihn lieber für einen Fehlercode, wenn ich so eine BCD wandlung
mache, bekomme ich die Werte oft von außen z.b. über Profibus / RS485
Gateway, da kann es schon ganz nützlich sein zu sehen was da jetzt
wirklich schief gelaufen ist.


PS. bitte die Kritik nicht Persönlich nehmen, kann ja auch Konstruktiv sein


----------



## Larry Laffer (17 Juni 2011)

Helmut_von_der_Reparatur schrieb:


> Im Prinzip der Bausteinkommentar, das kann mann schmaller gestalten, die
> Step 7 zu Zittieren ist mehr als überflüssig, da drücke ich doch lieber F1.
> 
> ...
> ...


 
Hallo Helmut,
der Meinung bin ich nicht unbedingt. Gute Kommentare sind nie oversized und wie weit man mit der Siemens-F1-Geschichte kommt haben wir ja nun gerade gesehen ... 

Darüber hinaus ist es ggf. (wegen dem "weniger ist mehr") auch sogar sinnvoller mehr Code zu haben, wenn man den dann besser durchblickt ...

Gruß
Larry


----------



## Larry Laffer (17 Juni 2011)

PN/DP schrieb:


> Ist aber immer noch besser (gekapselt) als die Verwendung eines Schmiermerker-Words (das ich auch erwähnte).
> Der FUP/KOP-Editor kommt mit dem LW0 jedenfalls problemlos klar.
> Wie all die Knowhow-geschützten Bausteine realisiert sind interessiert doch auch niemanden, solange sie funktionieren.


 
Hallo Harald,
Naja ... wir wollen doch besser werden (sein).
Ich hätte in dem genannten Beispiel dann vielleicht auch eine Struktur verwendet und daraus einen Pointer gebildet und dann dahin transferiert - das wäre dann zwar mehr Code ... aber vielleicht auch schöner ... .
Ich denke, das meinte der 4L ...

Gruß
Larry


----------



## rostiger Nagel (17 Juni 2011)

Larry Laffer schrieb:


> Hallo Helmut,
> der Meinung bin ich nicht unbedingt. Gute Kommentare sind nie oversized und wie weit man mit der Siemens-F1-Geschichte kommt haben wir ja nun gerade gesehen ...
> 
> Darüber hinaus ist es ggf. (wegen dem "weniger ist mehr") auch sogar sinnvoller mehr Code zu haben, wenn man den dann besser durchblickt ...
> ...


 
Wenn die Step 7 Hilfe falsch ist, dieses ohne augenscheinlichen vermwerk
zu Zitieren, finde ich ist das ganz schlecht......bei überlangen Kommentaren über-
lese ich das doch.


----------



## PN/DP (17 Juni 2011)

Larry Laffer schrieb:


> Naja ... wir wollen doch besser werden (sein).
> Ich hätte in dem genannten Beispiel dann vielleicht auch eine Struktur verwendet und daraus einen Pointer gebildet und dann dahin transferiert - das wäre dann zwar mehr Code ... aber vielleicht auch schöner ... .


Richtig, wir wollen besser sein.
Doch das, was Du vielleicht machen würdest, ist in FUP/KOP leider nicht möglich. Mein Zweit-Beispiel sollte aber in FUP/KOP sein.
Diese Schweinekrücke LW0 habe ich nur deshalb drin, weil es in FUP/KOP nur so geht (oder über das andere Übel Schmiermerker-Word).

Harald


----------



## vierlagig (17 Juni 2011)

PN/DP schrieb:


> Richtig, wir wollen besser sein.
> Doch das, was Du vielleicht machen würdest, ist in FUP/KOP leider nicht möglich. Mein Zweit-Beispiel sollte aber in FUP/KOP sein.
> Diese Schweinekrücke LW0 habe ich nur deshalb drin, weil es in FUP/KOP nur so geht (oder über das andere Übel Schmiermerker-Word).
> 
> Harald



sfc20 geht auch noch ... direkt auf ein struct kopiert


----------



## PN/DP (17 Juni 2011)

Helmut_von_der_Reparatur schrieb:


> Wenn die Step 7 Hilfe falsch ist, dieses ohne augenscheinlichen vermwerk
> zu Zitieren, finde ich ist das ganz schlecht......bei überlangen Kommentaren über-
> lese ich das doch.





Helmut_von_der_Reparatur schrieb:


> Im Prinzip der Bausteinkommentar, das kann mann schmaller gestalten, die
> Step 7 zu Zittieren ist mehr als überflüssig, da drücke ich doch lieber F1.


Ich meine, wenn ein Baustein bei kritischen Eingabewerten andere Ergebnisse liefert, als vom Anwender "gefühlsmäßig" erwartet werden, dann gehört eine Begründung in den Bausteinkommentar, warum genau dieses Verhalten implementiert ist. Da das Verhalten hier von einer Siemens-Definition abhängt, fand ich es angebracht, diese anscheinend nicht geläufige Definition zu zitieren.

Der Witz ist ja, daß die Step7 Hilfe in dem Vorzeichen-Punkt NICHT falsch ist, sondern genau beschreibt, wie sich echte S7-CPU bei BTI verhalten. Gibt es eine international verbindliche Norm, wie das Vorzeichen in der Vorzeichen-Tetrade kodiert sein muß? Siemens hat für S7 definiert, daß nur das Bit 15 relevant ist und die Bits 12 bis 14 nicht berücksichtigt werden. Daß der umgekehrte ITB "vorsichtshalber" alle Bits 12 bis 15 auf 0 oder 1 setzt, widerspricht nicht dieser Definition.

Ich habe mich entschieden, nicht kleinlich vermeintliche Vorzeichen-Formatfehler abzuweisen, mit denen der ITB-Befehl doch definitionsgemäß klarkommt.
Ich habe einzig das Ausblenden der Bits 12 bis 14 zusätzlich eingefügt, damit sich dieser Baustein in PLCSIM genauso verhält wie auf einer echten S7-CPU.



Helmut_von_der_Reparatur schrieb:


> Dann sind die mir die Zeilenkommentar (finde ich) so unpraktisch gesetzt
> das den Code zerschlägt.


Und ich finde, daß die eingefügten Kommentarzeilen nicht den Code zerschlagen, sondern gut in einzelne Verarbeitungsschritte gliedern.



Helmut_von_der_Reparatur schrieb:


> PS. bitte die Kritik nicht Persönlich nehmen, kann ja auch Konstruktiv sein


Keine Angst, die Kritik nehme ich nicht persönlich.
Deshalb ja auch meine Nachfrage, was genau Du als "überladen und unübersichtlich" gemeint hast.
Vielleicht kann ich ja wirklich meinen Kommentierstil verbessern bzw. an die allgemeinen Erwartungen anpassen.

Harald


----------



## PN/DP (17 Juni 2011)

Helmut_von_der_Reparatur schrieb:


> Mmh...ist dann das Bit für das Binärergebnis bei dir richtig angewand worden...?
> Du wertest es bei einen Fehler aus und setzt es auf "0", aber
> was ist den wenn es beim Einsprung des Bausteins schon auf "0" war?
> Deine "SPA" Sprünge und Vergleiche haben doch erstmal keinen Einfluss
> ...


Ja, es ist richtig angewandt worden. Es ist egal, welchen Zustand das BIE-Bit beim Einsprung in den Baustein hat. Am Bausteinende zeigt es auf jeden Fall richtig Fehler/Fehlerfrei an.
Siehe den "überflüssigen" Kommentar:

```
SPA   Ausg;            // hier ist immer VKE=1
```
Das VKE wird hier auf 1 gesetzt und für die "fehlerfrei"-Anzeige genutzt:

```
SPB   Err;             // Einer zu groß
```
Das VKE wird IMMER nach der Ergebnisausgabe an RET_VAL ins BIE gespeichert, nicht nur bei Fehlern.

Harald


----------



## PN/DP (17 Juni 2011)

vierlagig schrieb:


> sfc20 geht auch noch ... direkt auf ein struct kopiert


SFC20 mag aber keine Pointer auf INPUT-Parameter 

Harald


----------



## vierlagig (17 Juni 2011)

PN/DP schrieb:


> SFC20 mag aber keine Pointer auf INPUT-Parameter
> 
> Harald




```
*
      L     #wIn
      T     #wTemp
      NOP   0
```


----------



## PN/DP (17 Juni 2011)

*LW0 im KOP-Beispiel*

Peinlich ist allerdings meine Verwendung des LW0 zwischen WAND_W und BCD_I. 
Dafür sollte man besser ein ordentlich deklariertes TEMP-Word nehmen ...

Harald


----------



## PN/DP (17 Juni 2011)

vierlagig schrieb:


> ```
> *
> L     #wIn
> T     #wTemp
> ...


Und wie bekomme jetzt an der Adresse des wTemp meine Einzelbits deklariert?

[EDIT]Ahh, jetzt fällt der Groschen ... SFC20 soll von wTemp auf die Struktur kopieren ...[/EDIT]

Harald


----------



## PN/DP (17 Juni 2011)

*Code optimiert*

So, nun sieht es sauber aus. Und nicht zu viele Kommentare. 
Allerdings wird es nun wirklich langsam Oversized. Und es nutzt eine externe Funktion, was allerdings auch nicht ausgeschlossen wurde ...

```
FUNCTION "BCD2INTG" : INT
TITLE =BCD zu INT (FUP/KOP)
AUTHOR : PN_DP
FAMILY : SPSforum
NAME : BCD2INTG
VERSION : 0.4

VAR_INPUT
  InBCD : WORD ;	
END_VAR
VAR_TEMP
  TS : STRUCT 	
   TH_1 : BOOL ;	
   TH_2 : BOOL ;	
   TH_4 : BOOL ;	
   TH_8 : BOOL ;	
   TV_1 : BOOL ;	
   TV_2 : BOOL ;	
   TV_4 : BOOL ;	
   TV_8 : BOOL ;	
   TE_1 : BOOL ;	
   TE_2 : BOOL ;	
   TE_4 : BOOL ;	
   TE_8 : BOOL ;	
   TZ_1 : BOOL ;	
   TZ_2 : BOOL ;	
   TZ_4 : BOOL ;	
   TZ_8 : BOOL ;	
  END_STRUCT ;	
  Temp_Word : WORD ;	
  Temp_Int : INT ;	
END_VAR
BEGIN
NETWORK
TITLE =Eingabewert in Teststruktur kopieren
//und dabei die Vorzeichenbits 12 bis 14 wegen PLCSIM ausblenden
      U(    ; 
      L     #InBCD; 
      L     W#16#8FFF; 
      UW    ; 
      T     #Temp_Word; 
      SET   ; 
      SAVE  ; 
      CLR   ; 
      U     BIE; 
      )     ; 
      SPBNB _001; 
      CALL "BLKMOV" (
           SRCBLK                   := #Temp_Word,
           RET_VAL                  := #Temp_Int,
           DSTBLK                   := #TS);
_001: NOP   0; 
NETWORK
TITLE =Prüfung und Umwandlung BCD zu INT
//bei unzulässigem Eingabewert wird 0 ausgegeben
      U(    ; 
      O     #TS.TE_2; 
      O     #TS.TE_4; 
      )     ; 
      U     #TS.TE_8; 
      O     ; 
      U(    ; 
      O     #TS.TZ_2; 
      O     #TS.TZ_4; 
      )     ; 
      U     #TS.TZ_8; 
      O     ; 
      U(    ; 
      O     #TS.TH_2; 
      O     #TS.TH_4; 
      )     ; 
      U     #TS.TH_8; 
      =     L      6.0; 
      U     L      6.0; 
      SPBNB _002; 
      L     0; 
      T     #RET_VAL; 
_002: NOP   0; 
      U     L      6.0; 
      NOT   ; 
      SPBNB _003; 
      L     #Temp_Word; 
      BTI   ; 
      T     #RET_VAL; 
_003: NOP   0; 
END_FUNCTION
```

Harald


----------



## rostiger Nagel (17 Juni 2011)

@Harald, 
Jetzt helfe mir mal gerade auf die Sprünge, wo kommt das VKE = "1" her?




> // Eingabewert ist im gültigen Format -> in INT wandeln
> L     #InBCD;
> UW    W#16#8FFF;       // Vorzeichen-Bugfix für PLCSIM
> BTI   ;
> SPA   Ausg;            // hier ist immer VKE=1


----------



## PN/DP (17 Juni 2011)

Helmut_von_der_Reparatur schrieb:


> @Harald,
> Jetzt helfe mir mal gerade auf die Sprünge, wo kommt das VKE = "1" her?




```
// Einerstelle prüfen, dazu Zehnerstelle entfernen
      SLW   4;               // EEEE_0000_0000_0000
      <D    ; 
[COLOR="Blue"]      SPB   Err;             // Einer zu groß[/COLOR]

// Eingabewert ist im gültigen Format -> in INT wandeln
      L     #InBCD; 
      UW    W#16#8FFF;       // Vorzeichen-Bugfix für PLCSIM
      BTI   ; 
      SPA   Ausg;            // hier ist immer VKE=1
```
Wird der Sprung "SPB Err" nicht ausgeführt, dann wird das VKE auf 1 gesetzt.
(die Step7 Hilfe zu SPB wollte ich nicht zitieren - es gibt ja F1  ).

Harald


----------



## Jochen Kühner (17 Juni 2011)

*Gewinner...*

Ja wer bestimmt den nun den Gewinner?

Ich bin für die Lösung von LargoD, da am kürzesten.
Doch die Prüfung des Vorzeichen Nibble sollte ganz rausfliegen.

Das SAVE und RET_VAL nutzen von PN/DP war ja nicht Teil der Aufgabe, wenn der Baustein jedoch dann später in eine Bibliothek soll, sollte das noch rein.

Den Aufruf von SFC20 in dem Korrigierten Beispiel, nur um Direktaddressierung von Lokaldaten zu vermeiden finde Ich ein wenig Oversized, für eine Baustein in eine Bibliothek wäre mir dieser dann auf jeden Fall zu groß und zu lahm!


----------



## PN/DP (17 Juni 2011)

Jochen Kühner schrieb:


> Ja wer bestimmt den nun den Gewinner?


Dazu müßte sich wohl zunächst M-Ott als Aufgabensteller äußern, wann er den Wettbewerb für beendet hält. Ein konkreter Termin wurde nicht vorgegeben.

Völlig andere Lösungswege wird nun wohl niemand mehr präsentieren (oder wollen wir noch auf Thomas_v2.1 warten?).
Die bekannten Standard-Algorithmen serielle Einzelzifferprüfung und parallel-Bitprüfung wurden in verschiedenen Ausführungen gezeigt.
Wie sieht eigentlich die Lösung des Aufgabenstellers M-Ott aus?

Hier mal die meßbaren Fakten der bisher geposteten Lösungen (in Reihenfolge der Beiträge):

```
Anw.   MC7  Anzahl
                  Algorithmus           Zeilen  Byte  Danke  Besonderheiten
----------------------------------------------------------------------------------------------------------------
[URL="http://www.sps-forum.de/showpost.php?p=338023&postcount=3"]1[/URL]  vierlagig      try & catch                6    24    3    führt leider ohne OB121 zum STOP
[URL="http://www.sps-forum.de/showpost.php?p=338051&postcount=5"]2[/URL]* Larry Laffer   Einzelzifferprüfung       29    98    1    sehr leicht verständlich
[URL="http://www.sps-forum.de/showpost.php?p=338075&postcount=6"]3[/URL]* Nordischerjung Einzelzifferprüfung       28    98    1    verarbeitet nur positive BCD-Zahlen
[URL="http://www.sps-forum.de/showpost.php?p=338088&postcount=7"]4[/URL]* LargoD         Parallelbitprüfung 8&4|2  18    64    5    würde auch für BTD nicht mehr Anweisungen benötigen
[URL="http://www.sps-forum.de/showpost.php?p=338155&postcount=8"]5[/URL]  SPSKILLER      Schleife Zifferprüfung    22    80    3    extra 3 Anw.: Fehlerstatus QERR-Ausgang
[URL="http://www.sps-forum.de/showpost.php?p=338210&postcount=10"]6[/URL]  PN/DP          Einzelzifferprüfung       19    60    1    extra 3 Anw.: Fehlerstatus BIE, PLCSIM-Fix

[URL="http://www.sps-forum.de/showpost.php?p=338287&postcount=11"]7[/URL]x PN/DP          KOP 8&4|2 mit dirty LW0   42   140    0    Absolute Zugriffe auf LW0! PLCSIM-Fix
[URL="http://www.sps-forum.de/showpost.php?p=338374&postcount=36"]8[/URL]x PN/DP          KOP 8&4|2 vollsymbolisch  46   226    0    SFC20 für symbolischen Zugriff, PLCSIM-Fix
```

* Die Lösungen 2, 3 und 4 klassifizieren bestimmte Eingabewerte als Fehler (wegen Vorzeichen-Format), welche BTI nach Siemens-Definition korrekt verarbeiten würde.
x Die Lösungen 7 und 8 sind nur Vergleichs-Demonstrationen, wie aufgeblasen Code wird, der unbedingt in FUP/KOP realisiert werden soll.

Eine Laufzeit-Ermittlung ist bei den Mini-Programmen wohl entbehrlich.

PS: Die Lösung 4 könnte auch die mit dem geringsten MC7-Speicherbedarf werden, wenn LargoD noch etwas optimiert. 

Harald


----------



## Thomas_v2.1 (17 Juni 2011)

PN/DP schrieb:


> PS: Die Lösung 4 könnte auch die mit dem geringsten MC7-Speicherbedarf werden, wenn LargoD noch etwas optimiert.


Ich hatte auch so wie LargoD gedacht, etwas kompakter sieht es dann so aus:

```
L     #BCD
      UW    W#16#888
      SRW   1
      PUSH  
      SRW   1
      OW    
      L     #BCD
      UW    W#16#666
      UW    
      SPP   err
      SET   
      L     #BCD
      BTI   
      SPA   out
err:  CLR   
      L     0
out:  T     #RET_VAL
      SAVE
```


----------



## Thomas_v2.1 (17 Juni 2011)

PN/DP schrieb:


> Völlig andere Lösungswege wird nun wohl niemand mehr präsentieren (oder wollen wir noch auf Thomas_v2.1 warten?).


Ich habe überlegt ob es was vertracktes gibt, glaube da sieht es aber schlecht aus.
Mein Gedanke ging in Richtung kgV/ggT oder sowas, wenn alle falschen Bitkombinationen teilerfremd sind. So auf den ersten Blick sieht man allerdings nichts.


----------



## PN/DP (17 Juni 2011)

Thomas_v2.1 schrieb:


> Ich hatte auch so wie LargoD gedacht, etwas kompakter sieht es dann so aus:


Sag ich doch: 18 Anweisungen, MC7-Speicherbedarf 56 Byte inklusive BIE-Fehlerstatus. 
	

	
	
		
		

		
			





Ein völlig anderer Algorithmus fällt mir auch nicht ein. Als ich gestern abend den Wettbewerb sah, da war die Lösung von LargoD schon da. Damit meine Lösung nicht wie abgeschrieben aussieht, blieb mir nur, die Einzelzifferprüfung zu optimieren.

Harald


----------



## PN/DP (17 Juni 2011)

Ah doch. Eine Variante hatte ich mir noch durchdacht: zu jeder BCD-Ziffer 6 addieren. Wenn das einen Übertrag in die nächste Tetrade ergibt, dann war die Ziffer >9. Allerdings läßt sich das nicht parallel für alle Stellen gleichzeitig machen. Der Aufwand, das für jede Stelle einzeln zu tun und den Übertrag zu erkennen, liegt weit über den hier gezeigten Lösungen. Da kann man auch gleich auf >9 abfragen.

Harald


----------



## LargoD (18 Juni 2011)

Thomas_v2.1 schrieb:


> ... etwas kompakter sieht es dann so aus:
> 
> ```
> L     #BCD
> ...


noch kompakter sieht es so aus:

```
L     #BCD
      UW    W#16#888
      SRW   1
      PUSH  
      SRW   1
      OW    
      L     #BCD
      UW    
      SPP   err
      SET   
      L     #BCD
      BTI   
      SPA   out
err:  CLR   
      L     0
out:  T     #RET_VAL
      SAVE
```
AWL-Spezialisten vor. Wer optimiert weiter?
Gruß
Erich


----------



## PN/DP (18 Juni 2011)

LargoD schrieb:


> Wer optimiert weiter?


Kandidaten wären noch 
* das SET und CLR - doch keine Chance, wenn man das BIE beibehalten will
* das L 0 - da geht noch eine Kleinigkeit
Der Rest ist für den Algorithmus unverzichtbar.
(daß der Vorzeichencheck rausgeflogen ist fällt gar nicht auf)

```
L     #BCD
      UW    W#16#888
      SRW   1
      PUSH  
      SRW   1
      OW    
      L     #BCD
      UW    
      SPP   err
      SET   
      L     #BCD
      BTI   
      SPA   out
err:  CLR   
      L     B#16#0
out:  T     #RET_VAL
      SAVE
```
50 Byte MC7

Harald


----------



## Jochen Kühner (18 Juni 2011)

PN/DP schrieb:


> Kandidaten wären noch
> * das SET und CLR - doch keine Chance, wenn man das BIE beibehalten will
> * das L 0 - da geht noch eine Kleinigkeit
> Der Rest ist für den Algorithmus unverzichtbar.
> ...



Ich finde so sollte das Programm dann in die Bibliothek, aber mit Kommentaren.

Un wer bewertet jetzt das Siegerprogramm? Wo bleibt M-Ott?


----------



## PN/DP (19 Juni 2011)

LargoD schrieb:


> Hier mal die Parallelbitprüfung in SCL
> 
> 
> ```
> ...


In SCL sehr schön lesbar, der erzeugte AWL-Code sieht allerdings grauenhaft aus.
Ergebnis: *166 *Byte MC7 (generiert vom SCL Übersetzer Version: SCLCOMP K05.03.05.00_01.03.00.01 release)

Für relativ effizienten Code muß man dem SCL-Compiler etwas unter die Arme greifen.
Hier eine Compiler-optimierte Version

```
FUNCTION BCD2INT2 : INT
VAR_INPUT
  inBCD : WORD;
END_VAR
BEGIN
  BCD2INT2 := 0;
  IF (DWORD_TO_WORD(    SHR(IN:=WORD_TO_DWORD(inBCD AND 16#888),N:=1) 
                     OR SHR(IN:=WORD_TO_DWORD(inBCD AND 16#888),N:=2)
                   ) AND inBCD) = 0 THEN 
    BCD2INT2 := BCD_TO_INT(IN:=inBCD);
  END_IF;
END_FUNCTION
```
*102 *Byte MC7 (generiert vom SCL Übersetzer Version: SCLCOMP K05.03.05.00_01.03.00.01 release)

Allerdings merkt der SCL-Compiler nicht selbständig, wann der beste Zeitpunkt zum temporären Speichern eines Zwischenergebnisses ist und baut dann TAK's in den Code ein, um in einer bereits angefangenen Zweitrechnung doch noch das vorherige Ergebnis zu speichern. Klammern setzen ändert daran nichts.
So kann man dem SCL-Compiler aber helfen:

```
FUNCTION BCD2INT2 : INT
VAR_INPUT
  inBCD : WORD;
END_VAR
VAR_TEMP
    dwTemp : DWORD ;
END_VAR
BEGIN
  BCD2INT2 := 0;
  dwTemp := SHR(IN:=WORD_TO_DWORD(inBCD AND 16#888),N:=1);
  IF (DWORD_TO_WORD( dwTemp OR SHR(IN:=WORD_TO_DWORD(inBCD AND 16#888),N:=2)
                   ) AND inBCD) = 0 THEN 
    BCD2INT2 := BCD_TO_INT(IN:=inBCD);
  END_IF;
END_FUNCTION
```
*98 *Byte MC7 (generiert vom SCL Übersetzer Version: SCLCOMP K05.03.05.00_01.03.00.01 release)

Es ist übrigens egal, welchen Operanden des OR man vorberechnet. Der Compiler-Optimierer weiß immerhin, daß man OR-Operanden vertauschen kann.

Die überflüssigen "UD DW#16#FFFF" bei jedem WORD_TO_DWORD kann man dem Compiler leider nicht abgewöhnen.

Harald


----------



## PN/DP (19 Juni 2011)

dalbi schrieb:


> Hi,
> 
> so jetzt will ich auch mal in AWL .
> [...]
> ohne CPU Stop mit Hilfe des SFC36 und SFC37.


Gute Idee. 
Wenn Du jetzt auch noch das vollmüllen des CPU-Diagnosepuffers abstellen könntest?

Leider hat man bei dieser Lösung keine Information darüber, daß der Eingangsparameter ein unzulässiges Format hatte. Immerhin wird aber die geforderte 0 als Ersatzwert ausgegeben. (das steht nun allerdings nicht in der Step7 Hilfe, daß BTI eine 0 ausgibt, wenn es keinen CPU-Stop gibt)

Für weitere Programmieraufgaben würde ich nun als Zusatzregel einführen wollen, daß außer OB121 auch die Fehler-Demaskierungs-SFC nicht zur Verhinderung des CPU-Stops eingesetzt werden dürfen.

Harald


----------



## Jochen Kühner (19 Juni 2011)

PN/DP schrieb:


> Leider hat man bei dieser Lösung keine Information darüber, daß der Eingangsparameter ein unzulässiges Format hatte.
> 
> Harald



War ja aber auch nicht gefordert!


----------



## PN/DP (19 Juni 2011)

Jochen Kühner schrieb:


> PN/DP schrieb:
> 
> 
> > Leider hat man bei dieser Lösung keine Information darüber, daß der Eingangsparameter ein unzulässiges Format hatte.
> ...


Das habe ich auch nicht behauptet. Ich schrieb nur "Leider"


PN/DP schrieb:


> Leider hat man bei dieser Lösung keine Information darüber, daß der Eingangsparameter ein unzulässiges Format hatte. Immerhin wird aber die geforderte 0 als Ersatzwert ausgegeben.



Wobei: Dafür, daß BTI im Fehlerfall eine 0 in den Akku1 schreibt, kann ich keine Siemens-Dokumentation finden. Ich würde mich nicht darauf verlassen, auch wenn BTI unter PLCSIM das tut. (doch BTI funktioniert bekanntlich unter PLCSIM sowieso anders als auf echten S7-CPU; warum also davon ausgehen, daß BTI auf allen echten S7-CPU eine 0 in den Akku1 schreibt?)

Siemens dokumentiert nur, daß BTI keinerlei Statusflags beeinflußt, auch nicht im Fehlerfall. Die Lösung von vierlagig funktioniert also anders als sie aussieht. Der Sprung SPU wird nie ausgeführt.

Harald


----------



## M-Ott (20 Juni 2011)

PN/DP schrieb:


> Dazu müßte sich wohl zunächst M-Ott als Aufgabensteller äußern, wann er den Wettbewerb für beendet hält. Ein konkreter Termin wurde nicht vorgegeben.


Ich denke, da kommte nichts mehr, schreib ich auch gleich noch im Wettbewerbsthread.


PN/DP schrieb:


> Wie sieht eigentlich die Lösung des Aufgabenstellers M-Ott aus?


Fast haargenau wie die von Larry, nur ohne Vorzeichennibbleprüfung.


----------

