AG_RECV und Pointer(SCL)

[ditj_vitja]

Zuviel Werbung?
-> Hier kostenlos registrieren

hmm das gibts doch nicht dass ich das einfach nicht verstehe...


ich habe nun leider doch wieder Probleme mit der Ausführung mit der ich das versucht habe umzusetzen..
nun steh ich quasi wieder am Anfang..

Ist es denn überhaupt möglich, wenn ich im DB1 ab Addresse 0 eine int Variable reinmache, und der sps immer eine dreistellige Integerzahl schicke, dass diese Intergerzahl immer auch in der angelegten Variablen von DB1 landet?
Ich bekomms beim besten Willen nicht hin...

Gruß

 

[Thomas_v2.1]

ich habe nun leider doch wieder Probleme mit der Ausführung mit der ich das versucht habe umzusetzen..
nun steh ich quasi wieder am Anfang..

Ist es denn überhaupt möglich, wenn ich im DB1 ab Addresse 0 eine int Variable reinmache, und der sps immer eine dreistellige Integerzahl schicke, dass diese Intergerzahl immer auch in der angelegten Variablen von DB1 landet?
Ich bekomms beim besten Willen nicht hin...

Doch klar geht das. Aber der AG_RECV nimmt keinen Any-Pointer vom Typ INT, das solltest du aber dann am Status-Ausgang des Bausteins erkennen können.
Ich würde die Daten immer in eine Struktur packen, und diese Struktur dann symbolisch an den Baustein schreiben. Dann ist der Datentyp des Any-Pointers immer BYTE und man bekommt keine Probleme.

Zum AG_RECV gehört aber immer ein korrespondierender AG_SEND auf der Gegenseite. Wie sieht dort denn der Aufruf auf? Vielleicht liegt der Fehler ja auf der Seite.

 

[BiBi]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,

Dein Sender schickt Dir den Wert "102" in drei Bytes. Das deutet daraufhin, dass diese Zahl BCD kodiert übergeben wird. Das hast Du auch festgestellt, nachdem Du den Empfangsbuffer vergrößert hast. Der Sender muss den Wert "102" nach INT konvertieren, damit er in einem WORT untergebracht werden kann.

 

[ditj_vitja]

Ich schicke über ein Javatool den Integerwert an die SPS und da kann ja nichts falsch laufen, immer dreistellig...

jetzt hab ichs mal mit:

VAR
rein : ARRAY[1..3] OF BYTE;
END_VAR

AG_RECV(ID := 1 // IN: INT
,LADDR := w#16#0100 // IN: WORD
,RECV := rein // IN: ANY
,NDR := recv_done // OUT: BOOL
,ERROR := recv_error// OUT: BOOL
,STATUS := recv_status // OUT: WORD
,LEN := recv_len // OUT: INT
); // VOID

Bei dem ersten Integerwert den die sps bekommt packt er die Werte in das rein array[16#31, 16#30, 16#32] das ist ja auch voll ok denn das steht ja für die Zahl 102, wenn ich nun im nächsten Schritt nochmal was schicke, dann bekommt die SPS [16#30, 16#33, 16#0D] und das ist doch wieder blödsinn.. man ich kapier das Prinzip wohl so garnicht..
oder muss ich nach jedem erfolgreichen einlesen das array erst wieder leeren? wenn ja wie? einfach mit 16#00 füllen?

Gruß und danke für die Geduld mit mir

 

[BiBi]

Hallo,

wie schon vermutet empfängst Du KEINE Integerzahl, sondern drei Bytes mit ASCII (vermutlich - ich hab grad keine ASCII Tabelle zur Hand) Zeichen 1=HEX31=ASC49, 0=HEX30=ASC48, 2=HEX32=ASC50.
Das muss der Sender in eine INT Zahl konvertieren und Du kanst mit einem WORT die INT Zahl 102 empfangen.

 

[Paule]

Zuviel Werbung?
-> Hier kostenlos registrieren

oder muss ich nach jedem erfolgreichen einlesen das array erst wieder leeren? wenn ja wie? einfach mit 16#00 füllen?

Nein, musst du nicht.
Aber du musst dein Empfangsfach so groß machen das das gesendet Packet platz hat.
Was für ein Format und vor allem wie viel sendet denn dein Javatool (Byte, Long, Charact) ?
Für mich schaut das aus als ob das Tool mit dem senden noch nicht fertig ist und 0D vielleicht die Endekennung ist.

 

[BiBi]

Hallo,

ich bin mir ziemlich sicher, dass das Übertragungsprotokoll ASCII ist.
Und 0D ist die Endekennung (ein Teil von "CR" - Line Feed und Return).
Der Empgangspuffer muss auf jeden Fall vergrößert werden, damit diese Zeichen ebenfall empfangen werden können. Die Zeichen vor "0D" sind die ASCII Werte für 0 und 3.

 

[ditj_vitja]

sauber.. danke an alle...

ich habe im javatool mit println(int) gearbeitet... dieses ln am ende hat mir das Genick gebrochen ohne funzt perfekt..

vielen Dank nochmal an alle, wenn noch was sein sollte weiß ich jawo ich gute Hilfe erwarten kann


Gruß
Viktor

 

[Larry Laffer]

Zuviel Werbung?
-> Hier kostenlos registrieren

... es tut mir leid ... ich kann es mir nicht verkneifen ...
Das Ergebnis hättest du auch schon 25 Beiträge vorher erzielt haben können. Naja ...

 

[ditj_vitja]

ja das ist mir klar.. nur kann ich mir nicht erklären warum das mit dem array Puffer was du mir vorgeschlagen hast aufeinmal funktioniert... vorher hatte ich beim übertragen des Programms auf die cpu immer ein fehler und die sfleuchte ging an.. und aufmal funktioniert das.. und ich hab keine Ahnung warum..
naja nun gehts ja

 

[Larry Laffer]

... das kann ich dir auch nicht sagen ... möglicherweise hast du den I-DB deines FB nicht mit übertragen ... das könnte so etwas bewirken - das ist aber aus der Ferne auch immer schlecht zu sagen ...

Gruß
Larry

 

[BiBi]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich hoffe Du weisst nun warums funktioniert.

 

[PN/DP]

Hallo Viktor,

ich kann es mir auch nicht verkneifen, Dir noch ein paar Hinweise zu geben.

Bevor Du hochtrabend mit Java und Pointern 'rummachst, solltest Du Dich erstmal
grundlegend mit Datentypen und Zahlenformaten beschäftigen. Dann hättest Du gewußt,
daß es beim INT-Format NICHT möglich ist, daß die Einerstelle beim Übertragen
verschwindet. Das kann nur sein, wenn jede Dezimalziffer in einem eigenen Byte
übertragen wird. Das ist aber kein INT-Format - es ist also klar, daß der Sender
gar nicht im INT-Format sendet. Und dann reicht es natürlich nicht, nur 2 Byte
auszuwerten, wenn der Sender 3 oder mehr Byte sendet!
Dann hättest Du auch nicht geschrieben, daß Dein AG_RECV eine 10 empfängt, wenn
er tatsächlich die Zeichenfolge '10' (W#16#3130) empfängt.

ob du es glaubst oder nicht aber ich bekomme anstatt der 102 wirklich nur die 10..

Wenn Du meinen Beitrag #18 nochmal liest, dann wirst Du sehen, daß ich Dir genau
vorausgesagt habe, was bei Dir nicht stimmt.

Im übrigen hätte Dir auch auffallen können, daß Dein AG_RECV zweimal 2 verschiedene
Zeichen empfängt und in DB1.DBW0 einträgt: abwechselnd W#16#3130 und W#16#320D

und aufmal funktioniert das.. und ich hab keine Ahnung warum..
naja nun gehts ja

Bist Du SICHER?!
Es darf bei einem SPS-Programm niemals sein, daß man irgendwas programmiert,
ohne zu verstehen, wie es funktioniert. Dann hat man nach langem Rumprobieren
wahrscheinlich Code, der zufällig ein scheinbar richtiges Ergebnis liefert.

Was Du auf jeden Fall nochmal penibel checken solltest:

• In welchem Format sendet die nun von Dir benutzte Java-Funktion?
  Tatsächlich binäres INT oder ASCII-Einzelziffern mit/ohne CR?
• Ist am AG_RECV ein Empfangspuffer angegeben, der groß genug ist?
• Meldet der AG_RECV am Bausteinausgang LEN genau die Anzahl empfangener Zeichen,
  wie die Java-Funktion sendet? Wichtig: wird LEN immer ausgewertet und korrekt
  verarbeitet? Der AG_RECV-Bausteinausgang LEN ist nicht nur zum Schmuck da.
• Wenn der Sender nicht INT sendet (sondern z.B. ASCII): konvertierst Du die
  empfangenen Zeichen dann auch korrekt in INT? (das passiert nicht automatisch!)

Harald

 

[Larry Laffer]

... ich denke auch, dass die verwendete Funktion (auch ohne sichtbare Typkonvertierung) tatsächlich einen String versendet. Wollte man etwas anderes haben, so müßte man m.E. den zu verwendenden Zahlenwert als ASCII-Wert im Format CHAR (oder wie immer das in JAVA heißt) versenden.

Gruß
Larry