Funktionsbaustein mit IN/OUT 1Byte+4xINT

[Computerliebe]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo habe einen Motorbaustein erstellt als FB. Dieser wird mehrmals in einem anderen FB(Multiinstanz) aufgerufen . Im dazugeörigen FB sind
ja alle relevanten Bytes usw. abgelegt. Mein Problem ist das ich in WINCC
eine Structur erstellt habe die ich mehrmals benutze,sodas die Variablen automatisch hintereinander erzeugt werden. Bei meinem FB sind die "verstreut" angelegt . Nun wollte ich die mit Angabe von DB und Länge in Byte (z.B) aussen an den FB dranschreiben und dan im Prog des FBs verwenden. Geht das mit Pointer oder any .. oder wie
Vielen Dank für eure Antwort.

 

[godi]

Wenn ich das richtig verstanden habe dann willst du die selbe Struktur in deinem DB haben wie in WinCC?
Naja dann mach keine Multiinstanz sondern gib jeden FB einen eigenen DB. Die Statischen werte im FB legst du dir so an dass sie mit WinCC zusammenpassen und im FB führst du einfach den Befehl L DINO aus und schreibst den Wert an einem Ausgang. Somit weißt du auch welcher DB den FB zugewiesen wird.

godi

 

[Unregistrierter gast]

Zuviel Werbung?
-> Hier kostenlos registrieren

zusammenpassen und im FB führst du einfach den Befehl L DINO aus und schreibst den Wert an einem Ausgang. Somit weißt du auch welcher DB den FB zugewiesen wird.

godi

Gute Idee.

 

[godi]

Gute Idee.

Gel, das glaubt man gar nicht welche Ideen einfache Instandhalter haben!

 

[Computerliebe]

Leider habe ich ca 250 Antriebe und will natürlich nicht das für jeden ein DB angelegt wird . Daher habe ich mich ja für die Multiinstanz entschieden aber trotzdem danke. Neue Vorschläge ??

 

[borromeus]

Zuviel Werbung?
-> Hier kostenlos registrieren

Leider habe ich ca 250 Antriebe und will natürlich nicht das für jeden ein DB angelegt wird . Daher habe ich mich ja für die Multiinstanz entschieden aber trotzdem danke. Neue Vorschläge ??

warum "natürlich nicht"?
In einem PCS7- Projekt (also S7400+WinCC+...) gibts für jeden Messwert, jeden Regler, jeden Sollwert, Motor, Ventil, usw (also alles was auch im WinCC vorkommt) einen DB.... und das geht auch sehr gut.
Man sollte bei OS- Systemen- egal ob Intouch, WinCC oder was auch immer keine Scheu haben VIELE DB's zu verwenden.... macht eigentlich die ganze Sache übersichtlicher.
Ist aber vielleicht auch Geschmackssache.

 

[Larry Laffer]

Ich habe die oben erwähnte Problemstellung möglicherweise nicht ganz verstanden.
Mein Vorschlag zu dem Thema wäre ein ARRAY [1..250] of STRUCT. Da du den Aufbau deiner Structur ja kennst, kannst du mit einem von "aussen" vorgegebenen Index dir immer jeweils den Abschnitt in deinen Arbeitsbereich laden (und natürlich nach Bearbeitung wieder zurückschreiben) , den du im Moment benötigst.

@Borromeus: Ich bin nicht unbedingt ein Freund von vielen DB's für eine Visualisierung. Von Seiten der (internen) Kommunikation her muss jeder DB erst adressiert werden (er kann ja im SPS-Programm theoretisch an jeder beliebigen Adresse stehen) und kann kann dann erst geladen werden. Wenn du das für 250 DB's machst aus denen von jedem nur ein paar Bytes geladen werden erhälst du zig-mal soviele Kopfdaten wie Nutzdaten ...

 

[borromeus]

Ich habe die oben erwähnte Problemstellung möglicherweise nicht ganz verstanden.
Mein Vorschlag zu dem Thema wäre ein ARRAY [1..250] of STRUCT. Da du den Aufbau deiner Structur ja kennst, kannst du mit einem von "aussen" vorgegebenen Index dir immer jeweils den Abschnitt in deinen Arbeitsbereich laden (und natürlich nach Bearbeitung wieder zurückschreiben) , den du im Moment benötigst.

@Borromeus: Ich bin nicht unbedingt ein Freund von vielen DB's für eine Visualisierung. Von Seiten der (internen) Kommunikation her muss jeder DB erst adressiert werden (er kann ja im SPS-Programm theoretisch an jeder beliebigen Adresse stehen) und kann kann dann erst geladen werden. Wenn du das für 250 DB's machst aus denen von jedem nur ein paar Bytes geladen werden erhälst du zig-mal soviele Kopfdaten wie Nutzdaten ...

Kann ja sein, vielleicht bin ich nur deswegen begeistert weil wir meistens IE verwenden, bei PCS7 einen CP1613 (oder eine 08/15 Lan Karte) nehmen, bei anderes Visualisierungen verwenden wir Applicom- Baugruppen.
Bei 500 PO's (=DB's) ist die Aktualisierungsrate sicher kleiner 1s. Wieso das so gut funktioniert weiss ich nicht, in der S5- Welt haben wir die Daten auch immer in DB's aufgelegt, weil sonst die Übertragung zu langsam wurde.
Von der Seite der Optimierung stimmt das was Du schreibst sicher, liegt aber schon daran, dass alleine bei einem Motor zig-Daten gemappt werden, egal ob man diese braucht oder nicht.

 

[Larry Laffer]

Zuviel Werbung?
-> Hier kostenlos registrieren

@Borromeus: Hast vieleicht recht. Es ist ja auch eine Frage, wieviele Visu-Teilnehmer man am Bus hat ...

 

[borromeus]

@Borromeus: Hast vieleicht recht. Es ist ja auch eine Frage, wieviele Visu-Teilnehmer man am Bus hat ...

Ich will keineswegs DARÜBER wettstreiten- da viele hier enorme Erfahrung und grosses Wissen haben, entwickeln sich auf Dauer individuelle Vorlieben.
Soll nur als Info dienen, aus unserer Erfahrung:

PCS7- Projekt: 2 x AS400, ein OS- Serverpaar, 6 OS-Clients (bekommen Daten nicht vom Prozess sonden vom LAN), ca 35000 WinCC Variablen, Zeiten < 1s, Bussystem: IE, redundanter Ring 100MBit

IntouchProjekt: 1x135U, 3xAS400, 1 Intouch "Server" (zweiter cold StandBy), ca 32000 Intouchvariablen (in VIELEN DB's bei den 400er Steuerungen aufgeteilt) im "Server" ist eine Applicombaugruppe eingebaut, 6 Clients greifen über die Applicom-Baugruppe im Server auf den Prozess zu. Ebenfalls Antwortzeiten <1s, Bussystem: IE, 10/100MBit.

Da ich noch aus der S5- Welt stamme ist mir das ehrlichgesagt schleierhaft wieso das heute alles so schnell geht- damals haben wir sogar für jeden DB einen eigenen Auftrag im CP geschrieben damit die Reaktionzeiten schneller werden.

 

[Larry Laffer]

Ich will keineswegs DARÜBER wettstreiten ...

Das war auch nicht mein Ziel. Das würde auch glaube ich am eigentlichen Thema dieses Threads ein "bißchen" vorbeigehen ...

Aber zu deiner Anmerkung : Ich hatte da auch so ein ähnliches Ding im Hinterkopf. 6 * 135U (davon eine als Konzentrator eigesetzt), 4 * PC's mit InTouch 7.1, IE mit 100 MBit, Variablenzahl bei InTouch weiß ich nicht mehr (aber bestimmt nicht so hoch wie bei dir), Bus-Auslastung 6 - 7% und ständig Kollisionen. Vor Einsatz der Konzentrator-SPS war von Anwortzeiten nicht zu reden - danach im Bereich von 1 s, da nicht mehr so viele unterschiedliche Objekte abgefragt wurden. Deshalb mein Einwand - sollte keine Belehrung sein.