TIA Daten von einem Server/TCP mit TIA auslesen

[Marcel89]

Zuviel Werbung?
-> Hier kostenlos registrieren

schon gemacht. hatte ja keine wirkung

 

[Pipboy]

Wird der TRCV in jedem Zyklus aufgerufen?

 

[volker]

Zuviel Werbung?
-> Hier kostenlos registrieren

schreib mal eine globale variable an den done des trcv
und diese var als &NICHT an den REQ.
und lass adhoc mal auf true.
mit dem bit done kopiere die empfangene länge (du hast das ein wenig anders gemacht, was aber auch funktionieren sollte).
mit der flanke req nulle male unmittelbar vorher das empfangsarray. dann kann man besser sehen was im empfangsarray landet.
bei der kleinen menge (die du im vorigen post gesagt hast) kommt mir dein empfangsarray komisch vor

 

[volker]

kleiner anhang
also so ungefähr. (bild unten) (das ist nur so aus dem bauch raus geschrieben )

in der konfiguration wie ich das nutze verwende ich tsend_c und trcv (ohne c, mit der gleichen id wie tsend_c)

 

[Oberchefe]

Die wichtigste Frage wäre, welche Daten zur Übertragung angewählt sind. Bei angewähltem Videosignal hat dies alleine schon zwischen 1024 und 2048 Bytes. Das wird dann sehr wahrscheinlich auf mehrere TCP Pakete verteilt und muss dann nach dem Empfangen wieder zusammengesetzt werden.
Reduzieren auf das Nötigste, Datenlänge berechnen, dann sehen wir weiter.

 

[meatec]

Zuviel Werbung?
-> Hier kostenlos registrieren

Aha... das lese ich da aber nicht so raus. Ich lese da eher, dass unbedingt auch noch RCVD_LEN ausgewertet werden muss, um das empfangene Telegramm in einem zweiten Puffer zusammenzusetzen oder die Lage im Empfangspuffer festzustellen. Woher soll TRCV die Frame-Länge wissen? Von Sendepausen zwischen Frames?

Ja, ich werte die RCVD_LEN aus. (Es geht gar nicht anders, zumindest bei großen Telegrammen, da habe ich dann mehrere NDR habe
bis die erwartete Länge empfangen wurde)
Ich habe 2 Puffer, im 1. liegen die mit jedem NDR empfangenen Daten, im 2. Puffer speichere ich die mit jedem NDR fortlaufend, aneinanderhängend ab.
Mit jedem NDR speichere ich die bisher empfangene Länge ab, damit ich weiß an welche Stelle ich im 2. Puffer die neuen (weiteren) Daten schreiben muss und kopiere die Daten in den 2. Puffer.
Ungefähr so:

#STATE_RECEIVE:
#statRcvdLenTotal := #statRcvdLenTotal + #statRcvdLen;

#tmpRetValMoveBlkVariant := MOVE_BLK_VARIANT(SRC := #statDataBufferRcv.buffer,
COUNT := #statRcvdLen,
SRC_INDEX := #CONST_DINT_0,
DEST_INDEX := UDINT_TO_DINT(#statRcvdLenTotal - #statRcvdLen),
DEST => "MESSAGE_BUFFER".buffer);


IF (#statRcvdLenTotal = #statRcvLenExpected) THEN // Erwartete Länge komplett empfangen
// FC aufrufen um Daten auszuwerten
"handleReceivedMessage"(messageBuffer := "MESSAGE_BUFFER",
rcvdLen := #statRcvdLenTotal);
FOR #i := 0 TO (#tmpReceiveBufferSize - 1) BY 1 DO
#statDataBufferRcv.buffer[#i] := 0;
END_FOR;
#statLenDetected := false;
#statRcvdLenTotal := 0;
#statStateRcvValue := #STATE_CONNECTED;
ELSE // wait for more data to rcv
FOR #i := 0 TO (#tmpReceiveBufferSize - 1) BY 1 DO
#statDataBufferRcv.buffer[#i] := 0;
END_FOR;
#statStateRcvValue := #STATE_CONNECTED;
END_IF;

#STATE_CONNECTED:
#done := false;
#ndr := false;
#rcvdLen := #CONST_UINT_0;
#instTrcv.EN_R := true; // always true
IF (#instTrcv.NDR = TRUE) //New Data Received
THEN
#statRcvdLen := #instTrcv.RCVD_LEN; // empfangene Länge speichern
#statStateRcvValue := #STATE_RECEIVE;

// TRCV
#instTrcv(ID := #statConnID,
ADHOC := 1,
LEN := 0,
DATA := #statDataBufferRcv.buffer);

Vielleicht passt es für den ein oder anderen als Anregung.

VG Markus

 

[meatec]

Den Code nur lesbarer:

#STATE_RECEIVE:

#statRcvdLenTotal := #statRcvdLenTotal + #statRcvdLen;



 #tmpRetValMoveBlkVariant := MOVE_BLK_VARIANT(SRC := #statDataBufferRcv.buffer,
                                                                     COUNT := #statRcvdLen,
                                                                     SRC_INDEX := #CONST_DINT_0,
                                                                     DEST_INDEX := UDINT_TO_DINT(#statRcvdLenTotal - #statRcvdLen),
                                                                     DEST => "MESSAGE_BUFFER".buffer);




 IF (#statRcvdLenTotal = #statRcvLenExpected) THEN // Erwartete Länge komplett empfangen
                            // FC aufrufen um Daten auszuwerten
                            "handleReceivedMessage"(messageBuffer := "MESSAGE_BUFFER",
                                                    rcvdLen := #statRcvdLenTotal);
                            FOR #i := 0 TO (#tmpReceiveBufferSize - 1) BY 1 DO
                                #statDataBufferRcv.buffer[#i] := 0;
                            END_FOR;
                            #statLenDetected := false;                           
                            #statRcvdLenTotal := 0;
                            #statStateRcvValue := #STATE_CONNECTED;
                        ELSE // wait for more data to rcv
                            FOR #i := 0 TO (#tmpReceiveBufferSize - 1) BY 1 DO
                                #statDataBufferRcv.buffer[#i] := 0;
                            END_FOR;
                            #statStateRcvValue := #STATE_CONNECTED;
                        END_IF;


#STATE_CONNECTED:                   
                #done := false;
                #ndr := false;             
                #rcvdLen := #CONST_UINT_0;
                #instTrcv.EN_R := true;  // always true             
 IF (#instTrcv.NDR = TRUE) //New Data Received
                THEN
                    #statRcvdLen := #instTrcv.RCVD_LEN; // empfangene Länge speichern
                    #statStateRcvValue := #STATE_RECEIVE;


 // TRCV
    #instTrcv(ID := #statConnID,
              ADHOC := 1,
              LEN := 0,
              DATA := #statDataBufferRcv.buffer);

 

[Marcel89]

Habe es hinbekommen nachdem der Hersteller mir den Hinweis gegeben hat, dass die Sensorik intel-orientiert mit little-endian arbeitet
und man dadurch die Daten drehen muss.
Habe dann abgefragt, wann die Präambel richtig in meinem Buffer steht und konnte somit die Daten auslesen und aufbereiten.

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Habe es hinbekommen nachdem der Hersteller mir den Hinweis gegeben hat, dass die Sensorik intel-orientiert mit little-endian arbeitet
und man dadurch die Daten drehen muss.

Hmm, was hat die Endianness mit den sich verschiebenden Daten zu tun??

Bei mir ändern sich die Daten/Zeichen aber sekündlich. In der SPS steht auch nie in einem Datenword immer der selbe Kram.

Habe dann abgefragt, wann die Präambel richtig in meinem Buffer steht und konnte somit die Daten auslesen und aufbereiten.

Wartest du nun, bis irgendwann ein Datenframe (zufällig) an der richtigen Stelle im Empfangspuffer liegt?

 

[Marcel89]

Theoretisch ja, da das aber sehr schnell ist und für meine Anwendung mehr als ausreichend ist. Also kein Problem. Klappt sehr gut