Bytetranfer über Profibus

Beiträge
226
Reaktionspunkte
27
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Kollegen

Ich hab ein kleines Problem mit einem Temperaturregler mit dem ich via Profibus kommunizieren soll.

So sieht die gsd aus:

http://www.sps-forum.de/[URL=http:/...1/6743/tic407.jpg[/IMG][/URL] Uploaded with Uploaded with ImageShack.us

Mein Problem ist nun, das Byte am Anfang der Eingangsstruktur. Normalerweise leg ich entsprechende Ein-/Ausgangsstrukturen als Lokaldaten in einem FB an und transferiere diese mit SFC14/15 (wenns mich nicht täuscht) an den Teilnehmer. Nun hab ich das Problem mit diesem Byte. Da Step7 egal ob bei Lokaldaten imk FB oder global in einem DB bei einem Byte auf welches wie hier ein Realwert gleich ein zweites Byte reserviert. Somit stimmt meine Struktur nicht mehr. Wenn ich die Bereiche einzeln transferiere (also x mal SFC14 und x-mal SFC16) müsst ich dieses Byte alleine übertragen. Dabei wird ja sicher auch wieder das zweite Byte dazugesetzt und somit 2 Byte übertragen. Was mir meines Erachtens das erste Byte des Realwerts auf dem Busteilnehmer überschreiben würde.
Ich hab mir schon überlegt, die gesamten Daten Byteweise zu lesen/schreiben und dann auf die effektiven Strukturen zu schreiben,
frei a la Vierlagig : http://www.sps-foren.de/showthread.php?t=23433
Dann müsste ich die einzelnen Bytes teilweise zu einem Real-Wert zusammenbasteln. Gefällt mir auch nicht so diese Lösung. Hauptsächlich nicht, weil beispielsweise Bytes von Realwerten durch die Bytedrehung beim Übertragen gemischt werden.
Aber scheint mir nach meinem aktuellen Wissensstand die einzige Lösung zu sein.

Evtl. Hat noch jemand eine bessere Idee.

Ich hoff ich habs verständlich erklärt. Sonst bitte nochmals nachfragen.

Grüsse Anis
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Kannst du bei dem Teil die einzelnen Adressen anpassen?

Ansonsten SFC14/15 kannst du in dem Fall prinzipbedingt vergessen,
weil der Bereich hier konsistent zusammenhängen muss,
was hier offensichtlich nicht der Fall ist,
also ist das Problem so gesehen eigentlich keins, da du sowieso einzeln mit (P)EB/(P)EW/(P)ED arbeiten musst.

Mfg
Manuel
 
Zuletzt bearbeitet:
@ Paule

Klar, aber für das erste Byte wird aus konsistenzgründen gleich ein zweites Byte reserviert. Dies jedoch nur wenn wie hier zBsp ein Realwert folgt. Wenn nach den erste Byte wiederum ein zweites Byte deklariert wird, ist die Struktur selbst ja schon konsistent. Somit wird kein Byte reserviert.

@ MSB

Wenn ich Dich recht verstehe würdest einfach die einzelnen Variabeln hin und her "moven"??

EDIT: @ MSB ja die Adressbereiche kann ich zu jedem Element einzeln vergeben.
EDIT 2: @ MSB Ich denke ich weis worauf Du hinaus willst. Aber die CPU wird des ned lang mitmachen wenn du auf nicht existierende Bereiche schreibst.
 
Zuletzt bearbeitet:
@Schnick Schnack
Sorry, aber deine Antwort mich betreffend verstehe ich irgendwie nicht ...

Du hast hier laut der Anzeige nun also mehr oder weniger viele Real-Zahlen bzw. Status/Mode-Bytes,
welche alle einzeln eine Adresse haben.

d.h. SFC14/15 ist hier nicht sinnvoll anwendbar, also wäre deine einzige Möglichkeit (neben den o.g. Zugriff mit PE* bzw. PA*) der SFC20,
was wiederum aber bedingt, das die EA-Adressen im Prozessabbild liegen müssen.
Sobald diese aber im Prozessabbild liegen, kannst du deinem obiges Byte 665 die Adresse 664 geben.
Da du "nur" aufs Prozessabbild schreibst, ist es vollkommen egal ob die Adresse nun projektiert ist oder nicht.

Mfg
Manuel
 
Hi,

so wie meine Erfahrung ist, würde ich dem ersten Byte zunächst eine gerade Anfangsadresse vergeben, also z.B. EB664, wobei EB665 frei bzw reserviert bleibt. Also EW664 ist belegt.
Für die nächsten Module dann mit ED666 ff. weitermachen.
Dann kann man auch mit den entsprechenden SFC's draufzugreifen.

Gruß
Move
 
Zurück
Oben