5/14/2015 1:46 PM | |
Joined: 1/17/2007 Last visit: 10/21/2024 Posts: 1547 Rating: (537)
|
I am having great difficulty in getting the TSEND_C function work for me in TIA Poortool. I have read the help text / manuals / Mr Bergers books and have set it up I believe correctly but it still doesn't function. I am trying to use a UDP connection to an external PC drirectly from the CPU PN port. At first I configured it as per the help text and left the ADDR field unconnection as it is described as being "optional" in the help text. I then set CONT to true permanently and performed the following. With REQ=0 and CONT=1 we get code 16#7004 which is connection established but no job started - this is as expected. So now I generate a rising edge on REQ. This leads to a sucession of status codes of 16#80B3, followed by 16#7005. You will not be surprised to hear that 16#80B3 not actually listed in the help text. Code 7005 is and that is "data transmission in progress". But how can it be in progress if there is obviously and error? It is lying anyway as I have wiresharked it and there is no data transmitted which I expected as there is an error. So code 7005 is nonsense in this case. So what of code 16#80B3? I found it listed in the help text for the 1200. However the 1200 help text has other codes, that I am getting displayed that are not listed (e.g. 7005), but are listed in the 1500 help text. So can I relay on the 1200 definition for the error code? Anyway I took a chance with the 1200 error code description for 16#80B3 which is explained as "Inconsistant paremeter assignment: Group error for error codes 80A0 to 80A2, 80B4 to 80B9". So this error code is a catch all for lots of other errors codes. So why not just so the underlying error code? Useless. Absolutely useless. So I checked out the excellent books by Mr Berger for S7-1500 / TIA Poortool, and he suggests that when using UDP connections the address details are taken from the ADDR input not the CONNECT input. So I created a DB of the system type TADD_PAR as suggested in the book, filled in the address details and connected it to the TSEND_C block's ADDR input. This seemed to work as the 16#80B3 status code now went away. Sadly only to be replaced by another error code 16#8089 which decodes as "The CONNECT parameter does not point to a data block". This is odd as in my code the CONNECT parameter certainly does point to a datablock. This datablock has the TCON_IP_V4 structure are required by the UDP connection. However I had to create this DB by creating a UDT (my_TCON_IP_V4) for the required structure as the system defined TCON_IP_V4 structure is not present in the picklist when creating a DB (the TADD_PAR type is though - go figure). However I copied the system TCON_IP_V4 structure into my UDT so I know that the structure is correct. But still I get the 16#8089 error code. This software is a total can of worms it really is. I have never, ever used anything this bad before. The development team should be ashamed. Anyway I have included a few pictures of my configuration. If anyone can suggest something to fix it other than giving up and using Allen Bradley, which is my current choice of solution. AttachmentTSEND_C.zip (147 Downloads) |
Programming today is the race between software engineers building bigger and better idiot proof programs, and the universe producing bigger and better idiots. |
|
5/14/2015 1:55 PM | |
Joined: 12/16/2012 Last visit: 10/17/2024 Posts: 654 Rating: (130) |
Hi! I've just read about this 80B3 error code here: |
Follow us on