S7 Block transfers BSEND and BRCV

I have done a quick example if you want.

Nothing fancy cant handle anything other than CHAR but its working in both directions.
 
New try. It was a couple of years since i worked with VB6. I did a save as of the project. I thought everything was included in the project but obviously i was not. Search path to Form1 is in the TestWinSock.vbp file my project was saved in path c:\TestWinSock
 
It works!!!

I actually got it working about midnight last night using your PLC ladders and the help of a VB example from the Microsoft website.
I made the PC the server, which means it listens to the port and waits for the PLC to connect. This is better for my application as it puts the PLC in control and only makes the connection when it needs the data. Apparently 8192 bytes can be transferred in one block. I’m not sure if this is enough but with a bit of programming mores blocks can be transferred and accumulated.

Fantastic, I can now transfer a block of data from my PC to my PLC, I knew it was going to be easy!o_O

Thanks again for all your help.:site:
 
Well, here is an update regarding the Open Comms block transfer using TRCV (FB64) on TCP and Winsock.

Connection is established using TCON (FB65) and then I use the command Winsock1.SendData bytearray() to send the data array to the PLC. The TRCV is in Ad-hoc mode (Len=0) and it puts the received data in DB1 (a byte array).

The transfer success rate is good for small amounts of data, but the failure rate increases to 1 in 10 for block transfers of 8000 bytes. For some reason, half way through the transfer the TRCV flags that it has received the whole block. It part fills the DB1 resets the pointer and if EN_R is true it continues scanning for incoming blocks. Of course the next block is the remaining part of the truncated block which is now dumped at the beginning of DB1 making a big mess!

I am curious about the cause of the transfer split, sometimes it splits at the same place, it’s very odd. At the moment I am discarding blocks that are short in length, but any wise words would be much appreciated.

All the best
 
That's because you have the set the length on the receive block to zero (AD-HOC).

TCP/IP is a streamed based protocol the meaning of that is that there is no length sent with the tcp/ip telegrams. I dont know how Siemens handle this in there so called AD-HOC mode but my guess is that if the stream halts for a period of the time the output the currently received data to the T-Receive block.

There are a couple of other ways to handle this. The easiest way is to always send telegrams with the same length and set the Len parameter to this length.
Another way is to send two telegrams the first with the the length then you use the received length as length parameter until the data telegram is recived then change back and wait for another length telegram
 
Thanks Bratt, wise words indeed đź‘Ľ. It highlights the need to be careful in Ad-hoc mode, if the EN_R is always true (as in your example) then results can be unpredictable.
I have fixed the length and all is well, except if there is a problem during comms, then the block becomes out of sync. The only way I have found to flush the port is to disconnect and reconnect it, is this the best way? I suppose if I use Ad-hoc mode to receive a length telegram, then that would guarantee the port is flushed… thinking out loud here o_O!
 
I think you will be better off using TDISCON than AD-HOC but both will probably work.

For CP cards there is a blocked called AG-CNTRL that can reset the connection but i don't think that works for the integrated interface

Also if you always use a length greater than zero then the maximum length that can be received increases from 8192 to 32767.
 

Similar Topics

A new Forum member named LEOMENA resurrected a decade-old thread about SLC-500 M-Files and 1747-SN RIO Scanner block transfers. In order to keep...
Replies
4
Views
1,715
Hi guy. well im having a hard time figuring out how to make a numeric entry in an already made PV program but i've never worked with scanners and...
Replies
9
Views
2,761
Hi! I have a general question about Block Transfers. If, say, you want to use I/O 10-17 for the transfers, but also for normal I/O communication...
Replies
2
Views
1,815
Hello, all. I am working with a PLC-5/20 and i am trying to set up block transfer instructions for dealing with the transfer of analog data...
Replies
2
Views
1,582
I have several "smart" PLC-5 modules (Analog ins and outs, etc) in a RIO remote rack that I need to communicate with via block transfers. From...
Replies
4
Views
1,883
Back
Top Bottom