Hi, all
My CPU314C-2PtP PtP port receive incorrect data.
From hyperterminal I send telegram with the values of 16#0A 16#0B 16#0C 16#0D and I use the function SFB61 "RCV_PTP" to receive this telegram.
In this function I define the start address "DB15.DBB0" where my data will be stored.
But when I am watching bytes DB15.DBB0, DB15.DBB1, DB15.DBB2, DB15.DBB3 in VAT I see just byte DB15.DBB0 filled with some value but not 16#0A.
SFB61 STATUS always is 0 and the NDR bit indicates that data received with no errors.
Where can be the problem?
Thanks in advance
[?]: "RCV_PTP" problem
-
ttsimtic
- Posts: 2
- Joined: Sat Sep 25, 2010 7:09 pm
Re: [?]: "RCV_PTP" problem
Hi,
the usual way ist to define a data end character like 0x0D or a timeout value in the CPU Hardware settings (PTP).
You should imagine the PLC cylce is not syncronous to the datas beeing send from the hyperterminal.
So what I did for a barcode scanner was to let the scanner automatically add 0x0D to every barcode. So the scanner submitts the code like 14518581+CR.
The CPU detects the 0x0D (CR) as end character and takes just then the data from the internal CP into the given DB.
Now the NDR is valid for only one cycle, therefore you need to call SFB61 cylic and detect the NDR.
The DB area should be at least as big for the hole telegram includin 0x0D.
When you make the detection with timeout value the CPU copies the data when the timout between two characters is longer then you defined in the settings.
But this is no secure telegram detection. By manual typing with a hyperterminal you will get this event very often.
In your DB there will always be "strange" data.
So pease keep me informed.
the usual way ist to define a data end character like 0x0D or a timeout value in the CPU Hardware settings (PTP).
You should imagine the PLC cylce is not syncronous to the datas beeing send from the hyperterminal.
So what I did for a barcode scanner was to let the scanner automatically add 0x0D to every barcode. So the scanner submitts the code like 14518581+CR.
The CPU detects the 0x0D (CR) as end character and takes just then the data from the internal CP into the given DB.
Now the NDR is valid for only one cycle, therefore you need to call SFB61 cylic and detect the NDR.
The DB area should be at least as big for the hole telegram includin 0x0D.
When you make the detection with timeout value the CPU copies the data when the timout between two characters is longer then you defined in the settings.
But this is no secure telegram detection. By manual typing with a hyperterminal you will get this event very often.
In your DB there will always be "strange" data.
So pease keep me informed.
-
kelertas
- Posts: 23
- Joined: Tue Jun 12, 2007 8:17 am
- Location: Lithuania
Re: [?]: "RCV_PTP" problem
hello, ttsimatic.
My final destination of this PtP communication should be CPU acting like a modbus master. So the modbus slaves normaly can not add some character to the end of its answer. Thats why I use delay time to detect the end of answer telegram. So I dont know how to get these answer data correctly.
Interesting is that when I shorten Tx and Rx of CPU and with the SFB60 send formed modbus request I get exactly the same request on my SFB61. So the receive function SFB61 works correct.
So how to get correct answer from my modbus slave in this case?
Thanks
My final destination of this PtP communication should be CPU acting like a modbus master. So the modbus slaves normaly can not add some character to the end of its answer. Thats why I use delay time to detect the end of answer telegram. So I dont know how to get these answer data correctly.
Interesting is that when I shorten Tx and Rx of CPU and with the SFB60 send formed modbus request I get exactly the same request on my SFB61. So the receive function SFB61 works correct.
So how to get correct answer from my modbus slave in this case?
Thanks