DB Send

xymoro

Level-1
Beiträge
29
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Hi zusammen

Ich habe Probleme innerhalb einer Funktion (FC93) den DB Send mehr als einmal zu benutzen (s. unbennant.jpg). Der Send FB wird hier wie gewünscht auch öfters aktiviert, aber die CP340 sendet (blinkt) nur einmal.

Rufe ich den DB Send im übergeorneten Programmteil öfters auf (z.B. im FC89), so klappt dies auch mehrmals. (s. unbennant2.jpg).

Im FC89 habe ich einen Receive Baustein. Im FC93 nicht. Liegt es daran?
Müssen Send Blöcke verschiedene DBs im gleichen Unterprogramm haben?
Muss ich einen RESET FB einbauen?

CPU Typ:315-2DP
Software: STEP7 V5.4 + SP4

Gruß
JK
 

Anhänge

  • Unbenannt.JPG
    Unbenannt.JPG
    42,4 KB · Aufrufe: 41
  • Unbenannt2.JPG
    Unbenannt2.JPG
    51,8 KB · Aufrufe: 27
Also drei Dinge mal auf die Schnelle:
1. Ich würde ohnehin immer nur einen Send-Baustein für die CP340 nutzen und das Ganze so aufbauen, das nacheinander die gewünschten Sendeaufträge abgearbeitet werden. Kann durchaus sein, das man mehrere Send-Aufträge absetzen kann, der Baustein regelt das vielleicht intern selbst (wie bei PUT und GET über Ethernet), aber das muss man im Vorfeld abklären, indem man das Handbuch liest.
2. Wenn du schon mehrere Send-Bausteine aufrufst, dann sollte doch jeder seinen eigenen Db haben, das ist genau wie bei den FB der interne Speicher des jeweiligen FB.
3. Die Outs des FB haben ihren Sinn. Dinge wie "Done", sagen einem z.Bsp., dass der Auftrag erfolgreich beendet wurde. Die Timer-Orgie die du da veranstaltest, ist nicht nur unschön, sondern auch extrem schlechter Stil. Nutze die Outputs der Bausteine, um die Kontrolle über den Ablauf zu haben und nicht Timer. Diese sollte man zur direkten Steuerung möglichst meiden, als Timeout oder als Pause zwischen zwei Aufträgen ist das ok, aber ansonsten eher nicht.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hi Ralle,

Danke für die Kommentare. Ich habe mein Programm umgebaut. Dies hat ein bißchen gedauert, daher erst jetzt meine Antwort.

Eine Frage vorab:
Die Timer-Orgie die du da veranstaltest, ist nicht nur unschön, sondern auch extrem schlechter Stil.
Wo finde ich guten Stil? Hast du da eine Empfehlung. Evt. die IEC61131-3?

zu 1. Super Idee. Jetzt brauche ich nicht X Bausteine parametrieren. Und Fehler Bits (Ausgangs des Send bausteins), die bei 20 SEND Bausteinen nervig waren, lassen sich bei einem baustein besser einbauen und vor allem testen...
zu 2. siehe 1.
3. Jetzt auch viel einfacher zu programmieren, da es immer nur einen DONE gibt

--> mehrere Befehle wie bei put get zu senden habe ich nicht gefunden. Aber ich habe einfach eine Variable an den den Baustein verknüpft, der ihm Sagen soll welchen Text er senden soll. Und rufe diesen dann einfach zyklisch auf. Im ersten Zyklus mit Zeile 1 im zweiten mit Zeile 5 usw. (Wie man es dann halt braucht)

Gruß
JK
 
Ja, das mit dem guten oder schlechten Programmierstil ist so eine Sache. Damit kann man seitenlange Diskussionen starten/auslösen, die teilweise in eine Art Glaubenskrieg ausarten. Jeder sieht das ein wenig anders. Es gibt aber ein paar Grundregeln, die sich in der Praxis bewährt haben. Eine davon besagt, dass man Prozesse möglichst mit Rückmeldungen versehen soll und wenn man diese zur Verfügung hat, man diese auch nutzt. In deinem speziellen Fall, gibt der Baustein eine Done-Meldung aus, wenn er seine Arbeit erledigt hat. Statt dieser Done-Meldung, kann man auch einen Timer nehmen, ein paar mal testen, wie lange das Senden dauert und dann den Timer auf die doppelte Zeit stellen. Das ist dann schlechter Stil, weil man niemals sicher sagen kann, dass es immer so klappt. Die Done-Rückmeldung ist sicher, wenn die kommt, ist alles erledigt. Gleiches gilt m.E. nach für Handshake-Signale zwischen Maschinen oder auch Prozessen. Du kannste einem Roboter ein Signal geben, er soll das Teil abholen und dann einen Timer 20 Sekunden warten lassen. anschließend machst du weiter. Das ist übel, denn im schlechtesten Fall kracht es. Besser, der Robbi gibt ein Signal zurück, welches das Teil als abgeholt signalisiert.
 
Zurück
Oben