LabVIEW
Good way to connect to Siemens PLC? Alternative to OPC server?
Check this as an example. I clicked Edit > New server connection... and selected my server (Marcom etc.) from the Local machine tree.
Then I created a group ggg. Adding a new item you get something similar to this:
For DB10stati the URL string would be
opc://localhost/Marcom.S7.1/S400.DB10stati
(myAccessPath is a name to be used by Quick Client, it is not relevant for Datasocket)
- last edited on by
Content Cleaner
@Blokk wrote:
@Ola_A wrote:
From National Instruments Sweden I got the tip to use SP7 Toolkit for LabVIEW by DATA AHEAD GmbH
https://www.ni.com/en/support/downloads/tools-network/download.sp7-toolkit-for-labview.html
Looks promizing, but I have not yet looked into it more.
Yes, we also tried this toolkit, did not work with our PLC config. But I guess it is ok for most of the usual PLC systems...
I tried it with a S7-300 and it worked. But it does not allow to change the rack/slot number but instead determines them statically based on the type of PLC you select. So it should work if you use the standard built-in Ethernet port in the CPU but will likely fail if you use an additional communication processor card instead for connection to the PLC.
@Blokk wrote:
edit: as I remember this company or another told us they could come and try to adapt their toolkit for our PLC setup, but they cannot guarantee success, and it will bring in additional cost. Then we moved to Profibus. Actually the automation group boss who deals with PLCs a lot, was very surprised by the feedback that people told us they never seen people using an additional Ethernet card in PLCs, so that is why their toolkit does not work for such config. Our PLC guy said that this is very strange, because he sees our type of configuration (separate Ethernet card) everywhere, at least here at Karlsruhe Inst. of Technology...
The problem about this communication is that there is no official documentation for the ISO on TCP based commmunication protocol that Siemens uses. Sure ISO on TCP is standardized but that is just the outer frame format of the messages, everything inside is Siemens S7 specific. So it is usually possible to get something working with a bit of tinkering and Wireshark protocols from a communication with the Siemens Step7 or TIA portal software, but it is impossible to guarantee upfront that it can be made to work, as you never know what the Siemens developers might have shoehorned into the existing protocol to adapt to new hardware that got released. The Wireshark Siemens S7 dissector is a great help and I even got an idea or two from looking at the source of it but even that one can and does get some protocol elements wrong sometimes.
As to the other issue you mention, it very much depends where you look. For many industrial applications cost is one of the major concerns and extra communication processor interfaces do cost money, so they often use the smallest possible PLC that has enough built in interfaces. Most installations I have seen in the last few years usually use a S7-1500 PLC with two ethernet ports build in, one is for the Profinet communication with other Siemens PLCs and specific Profinet capable devices in the same assembly line and one is for general communication to the management system and also the various LabVIEW based control stations, in the past usually a PXI based Windows machine, but more recently with cRIO based intelligent local controllers. Over this second port we use the ISO on TCP based communication, previously through the AGLink DLL for the Windows based PXI systems, now our own developed VI library for the cRIOs.
If you have bigger PLC controlled systems like for physical science projects, the PLCs are usually larger with many expansion cards and then you can run into the problem that the standard rack and slot for the communication processor won't work. In hindsight it is pretty strange that the ISO on TCP protocol that Siemens employs requires the client to know about intimate details of where the communication processor is installed in a PLC, but that might have been an attempt to provide security through obscurity.
