LabVIEW
Labview tcp comm with siemens 300 plc
Solved!
Have you in your PLC a TCP communication block that listens on port 102x and automatically sends a 20 byte data message when a client connects? Because that is what your VI as you programmed it expects. While not impossible it is quite uncommon to do it like that. Usually the server (here your PLC TCP communication block) accepts connections and then expects to get some kind of command first to know what it should do (and return).
Here is the PLC side connection
FB65 is set the connection,this is s7300plc ,i did another project use s71200 plc use the same conneciton and it works but for s7300 plc not work
Here's an example that might help: https://forums.ni.com/t5/Example-Program-Drafts/S7-PLC-TCP-IP-Protocol-Reference-Example/ta-p/349219...
There's discussions on how to use it for different PLC.
@carmen9 wrote:
Here's an example that might help: https://forums.ni.com/t5/Example-Program-Drafts/S7-PLC-TCP-IP-Protocol-Reference-Example/ta-p/349219...
There's discussions on how to use it for different PLC.
This is not the same thing that the OP tries to do. This example program talks about implementing the proprietary S7 Ethernet protocol. Siemens has never publically documented this protocol in any way and seems to have no intentions to do so ever. While there are libraries out there like the libnodave or the snap7 library to communicate over this protocol with an S7 PLC controller, support for those libraries is based on voluntary effort by a few developers who are unable to provide support for the entire hardware line and variations of PLCs and they will not work well with newer TIA based projects unless the PLC programmer disables a few features (such as compression) in the datablock configurations in order to make them use the old protocol variant.
Siemens recommendation for communication with other external applications is based on TCP function blocks that are added to the PLC program. You setup a server port and a data area that can be read and written to and external applications then communicate with this function block. The PLC program is then responsible for copying setpoint values from this data area into the correct location in the PLC and copy PLC data block or register values to this data area for the external application to read.
Communicating directly over the S7 protocol gives an external application the possibility to access any DB and register address, and even modify them, which for a production environment is a serious hazard waiting to happen. It's one way why StuxNet could do what it did. But even without bad intend, accessing the internals of a PLC like that is in a production environment one more way to completely shutdown the entire line by a simple stupid programmer mistake. Of course you could say that any operator could do the same by hitting the obligatory emergency buttons everywhere along a production line. But programmer mistakes could also simply make that the line works with a wrong setting for a long time before someone finds out.
By separating the data area that external applications can access from the internal registers of the PLC program, the PLC programmer can verify and sanitize any incoming data and be sure that no external entity is changing anything behind his back, be it by accident or malign intent.
As to why this same program wouldn't work on an S300 PLC while it seemed to work on an S1200 PLC, I can't say. This is definitely not a LabVIEW problem but something that should be taken up with some Siemens support channel. Besides placing the TCP Function Block in the PLC program one also needs to provide certain input signals like the port number and the memory block size to allocate. Further it has an enable signal that needs to be connected to a variable which of course needs to contain the right value too. Maybe the port number configured in the application is reserved or already in use for something else in this PLC. We don't know and can't say!
