Zuviel Werbung? - > Hier kostenlos beim SPS-Forum registrieren

Ergebnis 1 bis 6 von 6

Thema: Indexierte Bitabfrage im SCL

  1. #1
    Registriert seit
    01.06.2012
    Ort
    Liechtenstein
    Beiträge
    39
    Danke
    5
    Erhielt 3 Danke für 2 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Hallo zusammen

    Bin auf der suche für eine Lösung von einer indexierten bitabfrage vom eigenen Instanz DB mit scl.
    Bei einem Globalen DB oder von einem dritt DB funktioniert dieses!

    Folgende Aufgaben Stellung:
    Habe in einem FB bei den Statischen Variablen ein Struct mit 100bit.
    Ist es überhaut möglich diese indexiert abzufragen bzw. indexiert zu bearbeiten?

    Array würde funktionieren, kann aber dort den einzelnen Bit's kein Kommentar hinterlegen!

    Im Anhang ein Auszug aus der Variablen Tabelle und einmal eine Schleifenabfrage von Bits aus einem Globalen DB.

    Danke im Voraus für die Info!!
    Angehängte Grafiken Angehängte Grafiken
    Zitieren Zitieren Indexierte Bitabfrage im SCL  

  2. #2
    Registriert seit
    24.04.2013
    Beiträge
    309
    Danke
    23
    Erhielt 160 Danke für 88 Beiträge

    Standard

    Hallo zobs01

    arbeitest du mit einer 300/400 oder mit einer 1200/1500?

    Für die 300/400 kann man sich mittels ANY-Pointer einen Zugriff basteln und denn dann auch verschieben. Aber eigentlich will man das gar nicht. Es ist weder bequem, noch ist es schnell.

    Für die 1200/1500 geht das mit dem selbst geschnitzten ANY noch schlechter. Es geht nur für Standard Bausteine und damit ebenfalls sehr langsam.
    Dann gibt es noch zwei Funktionen PEEK und POKE, die einem direkten Zugriff auf die Adressen eines Standard Bausteins geben. Also, du machst den FB nicht optimiert, dann wird auch der DB nicht optimiert. Damit kannst du mittels PEEK jedes Bit dieses DB lesen. Sogar in einer Schleife. Mit POKE kann man in den DB rein schreiben. Das ist alles nicht besonders schnell.

    Deswegen solltest du doch ein Array verwenden. Es gibt keinen Ärger mit standard oder optimiert. Die Lese Zugriffe in den optimierten DB sind dreimal schneller als in den standard DB. Die Schreibzugriffe sogar sechs mal. Das sind Daumenwerte für eine 1516. Bei der 1200 gibt es diesen Unterschied nicht. Für beide CPU gilt, dass das deutlich schneller ist als PEEK und POKE -- Faktor 15. Wenn in deiner Struktur die Elemente x1 x2 x3 ... heißen, dann hast du doch in Wirklichkeit ein Array.

    Ja, es hat Nachteil, dass man keinen Kommentar an die einzelnen Elemente des Array schreiben kann. Aber, würdest du wirklich an jedes der 100 bits einen anderen schreiben?


    'n schön' Tach auch
    HB

  3. #3
    Registriert seit
    27.06.2009
    Ort
    am Nordharz
    Beiträge
    3.717
    Danke
    443
    Erhielt 919 Danke für 740 Beiträge

    Standard

    Zitat Zitat von zobs01 Beitrag anzeigen
    Array würde funktionieren, kann aber dort den einzelnen Bit's kein Kommentar hinterlegen!
    Wenn's nur ums Kommentieren des Arrays geht, hilft Dir vlt. sowas in der Art:




  4. #4
    Registriert seit
    24.04.2013
    Beiträge
    309
    Danke
    23
    Erhielt 160 Danke für 88 Beiträge

    Standard

    Hi hucki

    AT ist gut für nicht optimierte Daten. Wer genug Zeit im Zyklus hat, der kann das verwenden. Wenn's pressiert, dann tu es besser nicht.
    Und AT sorgt auch gerne für nette Überraschungen bei der Inbetriebnahme: Wer hat denn von meinem Tellerchen gegessen -- sprich auf den Wert geschrieben.

    viel Spaß beim Fehler suchen
    HB

  5. #5
    Registriert seit
    22.03.2007
    Ort
    Detmold (im Lipperland)
    Beiträge
    11.718
    Danke
    398
    Erhielt 2.400 Danke für 2.000 Beiträge

    Standard

    Zitat Zitat von HelleBarde Beitrag anzeigen
    AT ist gut für nicht optimierte Daten. Wer genug Zeit im Zyklus hat, der kann das verwenden. Wenn's pressiert, dann tu es besser nicht.
    Und AT sorgt auch gerne für nette Überraschungen bei der Inbetriebnahme.
    Woher hast du denn die Weisheit ?

  6. #6
    Registriert seit
    24.04.2013
    Beiträge
    309
    Danke
    23
    Erhielt 160 Danke für 88 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Hallo Larry

    messen und leiden.

    Wie man an vielen meiner Beiträge feststellen kann, versuche ich immer nachzumessen. Die 1500 machen mir zwar das Messen schwer, weil die Ergebnisse stark streuen und von so vielen Unbekannten abhängen, dass man damit alles und nichts beweisen kann, aber es gibt eindeutige Tendenzen. Vor allem bei den teureren 1500.

    So wie es sich mir darstellt, hat S. die optimierten Bausteine erfunden um sich besser an die in der PLC verbauten µ-Controller anzupassen.

    Wenn man sich die Mühe macht mit Wireshark das Laden auf die PLC zu beobachten, dann stellt man trotz aller Verschlüsselung fest, dass die optimierten DB der 1500 im Little-Endian übertragen und die nicht optimierten im Big-Endian übertragen werden. Bei 300/400 war es immer Big. Bei der 1200 ist auch alles Big. Wie man das rausbekommt? Dazu lege man einen DB mit einem Array aus 1000 DWORD an und setze das 333te Element auf 16#12345678 alles andere lasse man auf 0. Also findet man im Datenstrom viele 0 und irgendwo die 12 34 56 78 oder eben 78 56 34 12. Das kannst du auch mit allen anderen Datentypen machen, du musst dir eben einen "hübschen" Wert raussuchen.

    Jetzt vergleiche man die Preise für die verschiedenen Prozessoren und deren Eigenschaften. Die von Intel sind meistens Little. Bei manchen kann man es einstellen, z.B. ARM und MPIS. Bei den Controllern, die Little bevorzugen, ist S. mit ihren bisherigen Big natürlich blöd dran. Lesen von MD7 kostet laufzeit und Assembler-Code, egal welche Controller-Familie nun wirklich drin ist. Je besser die Prozessoren sind desto schlechter können sie MD7 lesen. Auf einer Assembler-Schulung, die ich vor Jahren genossen habe hat man mir den Code gezeigt, der für das Lesen von MD7 bei x86-Intel-Prozessoren nötig ist. Der x86 mag es, wenn die Daten so liegen, wie sie auch breit sind. MD4 lesen geht schnell und MD8 auch. Aber bei allem dazwischen, muss man praktisch jedes Byte einzeln lesen und zum DW zusammen schubsen. Das machte statt einem MOV eine Kette aus MOV, SHL, MOV, OR, SHL, MOV, OR, SHL, MOV, OR. Das ist völlig unabhängig von der Endianness. Und genau das kann man nachmessen. Der Zugriff auf optimierte Daten ist bei der 1516 etwa 4 mal schneller als auf nicht optimierte. S. kocht eben auch nur mit Wasser. Es wird ja spekuliert, dass in den 1500 ein MIPS drin ist und in der 1518 sogar ein Intel.

    Jetzt bietet TIA das AT nur noch für Standard-Daten an ... merkste was? Durch die von uns mittels AT festgelegte Platzierung der Daten auf für den µ-Controller ungünstige Adressen, kann der sein Potential nicht entfalten. Das kostet Zeit. Sollte dir die Zykluszeit egal sein, dann ist sie dir eben egal.

    Kannst du dein Programm aber umschreiben/anpassen, dass du auf AT und AWL und die ganzen Adressregister/ANY Patina -- ach ich kann ja so toll optimierte Programme schreiben -- verzichten kannst, dann reicht ja vielleicht eine 1513 wo du vorher eine 1516 gebraucht hast. OK, keiner zahlt Liste, aber wenn es eine Serienmaschine ist, dann rechnet sich das ziemlich schnell.

    Und dass AT unheimlich Spaß beim Fehlersuchen macht, dass habe ich leider viel zu oft erleben müssen.

    'n schön' Tach auch.
    HB

  7. Folgende 6 Benutzer sagen Danke zu HelleBarde für den nützlichen Beitrag:

    Bits_And_More (27.10.2016),kapo666 (07.09.2014),NBerger (20.08.2014),Onkel Dagobert (19.01.2017),UniMog (31.08.2014),VLT_RealDrive (31.08.2014)

Ähnliche Themen

  1. SCL: FB Aufruf unter SCL mit Variablen DB
    Von ThorstenK im Forum Programmierstrategien
    Antworten: 32
    Letzter Beitrag: 10.02.2011, 19:15
  2. Bitabfrage AKKU direkt
    Von Simatiker im Forum Simatic
    Antworten: 26
    Letzter Beitrag: 04.09.2008, 15:31
  3. Bitabfrage bei parametrierten Bausteinen
    Von nikolic im Forum Simatic
    Antworten: 4
    Letzter Beitrag: 04.12.2006, 09:45
  4. Antworten: 4
    Letzter Beitrag: 07.10.2006, 00:34
  5. Brauche Hilfe bei SCL.SFC Aufrufen in SCL
    Von Gerold im Forum Simatic
    Antworten: 10
    Letzter Beitrag: 06.10.2005, 10:47

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •