Indirekter Bausteinaufruf

Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo zusammen,

ich dachte, ich hätte die Anwendung schon beschrieben!? :confused:

Guckst du hier:

Hi Larry,

danke für die Tipps! Das mit dem "BLOCK_DB" und "BLOCK_FB" habe ich bis jetzt noch nie ausprobiert. Da muss ich erst ein bischen rumprobieren. Klingt aber sehr interessant.

Als Multiinstanz geht das ganze aber auch nicht, da der aufzurufende FB nicht multiinstanzfähig ist. Und ich meine, bei Multiinstanzen müssen alle FB multiinstanzfähig sein (stimmt doch, oder?). :confused:

Symbolische Adressierng fällt auch weg, da der Baustein auch gerne mal vom Anwender einen anderen Namen bekommt.

Aber was zur Anwendung:
Es existiert ein FB (Sendebaustein) für ein Profibus-CAN-Gateway. Dieser Sende-FB nimmt als Eingangsparameter Eigenschaften einer CAN-Nachricht entgegen (z.B. ID-Nummer, DLC, Datenbytes 1 bis 8, etc.) und schreibt diese Daten an die A-Adressen des Profibus-CAN-Gateways, welches daraus eine CAN-Nachricht generiert.
Ich möchte nun einen Baustein erstellen, der für einen SDO-Transfer genommen werden kann (SDO als expedited transfer, CANopen). Mein SDO-Baustein nimmt also entsprechende Eingangsparameter (Node-ID, Index, Subindex, etc.) entgegen, verwurschelt die intern und übergibt diese Parameter an den Sendebaustein für das Profibus-CAN-Gateway. Dazu muss aber mein SDO-Baustein den Sendebaustein intern aufrufen. Und da fangen die Probleme an, weil alles eben bibliotheksfähig sein soll.

Gruß! ;)

Nur, um das ganze nochmal zu verdeutlichen:

-Es existiert ein FB (genannt: Sendebaustein). Dieser ist vom Code her unantastbar. Die Nummer dieses FBs ist standardmäßig "FB2", kann aber je nach Umstand jede andere beliebige Nummer haben. Also z.B. FB10 oder FB15 etc.. Das gleiche gilt für den symbolischen Namen. Dieser Name ist ja nicht fest und kann in beliebige Bezeichnungen umbenannt werden.

-Ich will nun (eher gesagt: muss) einen zweiten FB oder FC erstellen (SDO-Baustein), der den FB2-Sendebaustein "benutzt". Dieser neue Baustein soll einen SDO-Transfer durchführen (expedited transfer, SDO download initiate => siehe Spezifikation "CANopen"). Dazu brauche ich ein paar wenige Eingangsparameter, die intern verarbeitet werden und an den FB2-Sendebaustein übergeben werden müssen. Da kommt jetzt die Angabe der FB-Nummer mit ins Spiel. Da die Nummer vom FB-Sendebaustein nicht fest ist, muss der SDO-Baustein doch wissen, welche Nummer der FB-Sendebaustein hat, damit er ihn intern aufrufen kann.

-Das ganze soll wiederverwendbar programmiert werden, also bibliotheksfähig (der FB2-Sendebaustein ist dies schon).

-Es existieren hinterher also zwei Bausteine: der bestehende FB-Sendebaustein und der neue SDO-Baustein

-es sind alle notwendigen Bausteine und InstanzDB in einer Bibliothek verfügbar (FB-Sendebaustein und sein InstanzDB, etc.)

-der neue SDO-Baustein soll dann flexibel in beliebigen Programmteilen zum Einsatz kommen (natürlich wird der FB-Sendebaustein und sein InstanzDB immer benötigt)


Ich hoffe, jetzt ist es ein wenig klarer geworden??? :confused:

Grüsse!
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Das habe ich auch schon probiert!

CALL FB_NUMMER, DB_NUMMER //beide IN-Parameter, Datentyp BLOCK_FB bzw. BLOCK_DB

Das wäre die perfekte Lösung. Leider funktioniert das nicht! :twisted:


Hi,

komischerweise funktioniert:

CALL FB100, DB_NUMMER //Datentyp BLOCK_DB

aber nicht:

CALL FB_NUMMER, DB_NUMMER //Datentyp BLOCK_FB, BLOCK_DB

Schade! :twisted:
Das wäre nämlich genau die perfekte Lösung für mein Problem.

Soweit funktioniert mein SDO-FB mit meiner Bastellösung ja schon. Ich freue mich schon auf die nächsten Probleme... :mad:



In diesem Sinne...

Erst mal vielen Dank an alle! :)
 
Nun, ich muss jetzt mal dumm fragen:

Muss der Sendebaustein warten bis der SDO Baustein fertig ist?

Ist es also quasi zwingend ihn als Unterprogramm aufzurufen?

Du schreibst zumindest daß es sehr wenige Parameter sind die übergeben werden - da drängt sich mir die Frage auf ob du diese "wenigen" Parameter nicht in die Schnittstellen verlagerst und beide Bausteine nacheinander im OB1 z.B. aufrufst. Dann hätte dein Problem mit der FB Nummer zumindest ein ende.

Auch wäre es dann prinzipiell egal wie die FB-Nummer bzw. der der Symbolische Name lautet...

Ein anderer Ansatz wäre (wenn sich das Unterprogramm nicht vermeiden läßt) folgender:

Du setzt an der Stelle wo normalerweise dein SDO gestartet wird ein Bit daß er starten soll und eine Abfrage ob er fertig ist. Wenn nein beendest du den Sender und startest im OB abhängig von dem Anforderungsbit den SDO welcher dir widerum ein Bit liefern muss daß er fertig ist. Dieses wertest du dann im Sender aus, setzt das Startbit zurück (SDO ist jetzt wieder blockiert) und machst mit dem Ergebnis weiter.

Die Bits sowie die Parameter die ausgetauscht werden müssen musst du eben in dem Fall an beiden Schnittstellen ergänzen.

Wie gesagt -> du sagtest es seien nicht viele Parameter daher dieser Vorschlag...
 
Hallo zusammen! ;)

@rs-plc-aa:
Der SDO-Baustein muss auf den Sendebaustein warten. Der Sendebaustein besitzt einen READY-Ausgange (BOOL), welcher signalisiert, dass dieser fertig ist. Der SDO-Baustein hat ebenso diesen READY-Ausgang. So in der Art, wie du das beschrieben hast, soll das ganze auch funktionieren, aber eben als eigenständiger Baustein.
In etwa so:

OB -> Aufruf SDO-FB
-> Aufruf Sende-FB im SDO-FB: wenn Signal vom Sende-FB "READY", dann weiter mit SDO-FB, ansonsten BE
->Sende-FB ist "READY", weiter mit SDO-FB: wenn fertig, dann Signal "READY"


@kiestumpe:
Die Jungs vom Support habe ich bis jetzt noch nicht gefragt. Sollte ich vieleicht auch mal machen. :oops:


@JesperMP:
Danke für diesen Hinweis! Ich habe den Code ausprobiert und ich muss sagen, das funktioniert einwandfrei. Diese Lösung gefällt mir um Längen besser, als meine Pfuschlösung!
Richte bitte ein großes "DANKE" an "L D[AR2,P#0.0]" aus!


Tausend Dank auch an alle anderen!!! :D
 
Zurück
Oben