How To Connect To A Siemens Plc

[Lourdes Horace]

Getmore value from your IT investment

By consolidating and enhancing Opcenter connectivity, Opcenter Connect reduces project effort and risk. It also enables end-to-end message processing and diagnosis. Opcenter Connect integrates Opcenter systems with enterprise resource planning (ERP) systems, manufacturing systems with cloud intelligence systems, Opcenter systems with manufacturing shop floor devices or tools, and much more.

Choose from numerous deployment options

Opcenter Connect is compatible with almost all solutions, including distributed solutions. Its components are scalable and support a high-availability architecture.

Eliminate manual process errors

Opcenter Connect provides up-to-date information gathered through tightly connected business, manufacturing, quality and shop floor systems. As a result, you gain control over cumbersome, error-prone manual processes.

I have a problem connecting my laptop with TIA Portal to a S7-1200 PLC through an ethernet network. I have had no issues for a long time except now I have moved the PLC to a different point in the network which I can no longer connect too. Nothing has changed on my laptop side.

If you work from new it is more easy, but if you have existing infrastructure the options become less. Unhappily you have to be specific on what you have and what you have to choose. Protocol converters also is available or add-ons. One such example I can think of is a Profibus card meant for AllenBradley PLCs for example.

also info what kind of Siemens HW you want implement, will be fine. In my opinion (also my long time experience) I'm always try avoid OPC due timeouts (but yes, can be configuration/HW problem), but your case is simply must (WinCC/Scada). In my opinion in case of Exchange data between both PLCs, info about HW cfg is needed, simply if you want Exchange not so much data (maybe about 250 Bytes) and are very needed to control important things on both sides, better can be create serial or TCP user communication, maybe Modbus also, all depends on HW you have now. You'll have quickly responses, also you can everytime change all what you need. Only one important thing is, that you must be ready program both sides, Siemens and AB. Till this time I'm using serial/TCP communication with perfect satisfaction. In case that you can't change both sides, probably only OPC is your case. Your task looks complex to think for other ideas, but you must think about all possibilities.

So if I have two CPUs from different brands which both support Profibus, I can connect them with Profibus? Is that correct? So there is no need for OPC connection when there is Profibus or Profinet to connect one PLC tp another PLC/HMI?

I only tested with 1 integer in a global data block. I made the int count 1 up every second and reset to 0 at 1000. This was monitorable in Ignition. I also tried to write to the integer from Ignition which worked.

Are you sure your processor is not a newer ET200SP? The ET200S is a S7-300, the ET200SP is a S7-1500. You can use the standard Ignition driver for both, but the 1500 requires a different configuration.

Not as far as my experience goes. The 1510SP and 1512SP cpu's have the same connection mechanism and settings as all other 15xx cpu's. So Put/Get access has to enabled, security disabled and there is no access to symbolic adresses, optimized datablocks or legacy timers.

Although I can see the PLC on the network when I search for it through the start search I cant go online and I get the message Connection Failed - The Selected Online target could not be reached (0130: 000002).

My standard setup is to connect to the PLC and a HMI through an unmanaged ethernet switch. I have tried connecting the programming PC directly to the PLC but with the same outcome. I am confident the ethernet switch is OK as the KP300 HMI is able to connect with no problems.

For this purpose, I created a folder c:\automation, and when things get strange, I migrate the project to that folder, and test again. If things suddenly work, I delete the original project from the one-drive folder.

MyID support receives hundreds of tickets every day. Mainly the tickets are caused by issues not related to the functionality of the service. Sometimes on-boarding processes may take some few days causing issues during the first login. Sometimes the issue caused by the wrongly configured client or poor internet connection. Please read following chapters to identify the root cause of the issue.

Below you can find the information about possible issues with different login methods and the tips to resolve them. In case of issues you can always create a support ticket. To speed up the ticket resolution please provide information regarding:

With this method you can authenticate using your windows credentials. It is offered when you access Siemens-applications from the internet or using non-Windows devices. Sometimes MyID combines email login with other login methods to reach the required authentication strength.

The method is especially useful when you authenticate from mobile devices. Once configured on your device it does not require additional inputs. The method requires the certificate installation on your device prior to be used.

PingID helps you confirm your identity via a mobile device when accessing critical applications. Before using it for the first time, you must activate PingID on your device. You can use multiple devices with PingID. Please note that your account password expires 30 days after onboarding and must be reset before activation is possible.

MyID supports authentication of some Siemens affiliates using their login systems. This option appears on the login screens only in case MyID could not identity the user to come from the Siemens intranet. After selecting the affiliate company, the user is forwarded to the login service of the affiliate. If you work for the MyID supported affiliate company, please contact the local IT support in case of login issues.

This option allows registered and federated Siemens ID users to login. This can be used to provide authentication to Siemens external partners without full on-boarding. In case of issues with this login method approach the application support contact. Siemens ID does not have the user support process. Please consult Siemens ID FAQ for further information.

We first developed the project in Labview 2012, and now when it is time for a review and bug fix we realize that our code base is now LV2015. Means we need to upgrade also the NI OPC server and NI DSC Runtime. Since we did not pay for any SSP it means we have to pay for the whole OPC + DSC runtime again. For each client system.

The URL string depends on the OPC server. The trick is to read the item as a variant, then get the OPC Quality as a variant attribute. At last you need to convert the variant to the proper data type; a memory block would be converted to a LabVIEW cluster.

I've done this in one application, I've set up Modbus Master in my LV application and there was Modbus communication enabled on PLC side. I'm not sure about PLC side technical details (someone else programmed it), but I think it's not rocket science One possible caveat: Modbus communication with PLC can be slow, so be sure to benchmark your application before jumping into full-scale developement.

A collegue use Proibus in a project and said he had to program the data send/received in quite a low level. Was it maybe Modbus he was actually sending? I just googled and saw Profibus more as a cabling standard. I will look up the link and learn if Modvus can help us.

And you are definately right, for the current program release I will go for the "save as LV2012" option. Or try to only deploy the shared library with the OPC-server in LV2012, seems rest of the code can be LV2015.

pincpanter, tried your example with NI OPC server, but did not know how to construct a proper opc-URL. In NI-OPC-QC (quick client) one example variable looks like. Tried to use these data with your url structure (and with backslash and dots instead of slash). Can you explain how do this?

1) There is of course OPC, but that requires an OPC Server somewhere either from Siemens or a 3rd party, that knows how to connect to the PLC properly. And accessing OPC from within LabVIEW can either be done with Datasocket, if your requirements are not very demanding and you can live with creating your datasocket URLs correctly, control binding which also uses datasocket internally, or the LabVIEW DSC system which allows a lot more control over how the OPC items are accessed.

3) There are various 3rd party libraries that access the ISO on TCP protocol that all Siemens S7 PLC with Ethernet interface support. Most of them are either DLLs, ActiveX components or .Net assemblies and require some work to interface, but it's definitely possible. One of them I used in the past is the Accon-AGLink software from Deltalogic. Works like a charm.

Another is a native LabVIEW library from Data Ahead called SP7 Toolkit and you can buy it from the NI 3rd Party Addons here. For the price you can't really do much wrong and for accessing Datablock and IO items it works well. The nice thing about this library is that it is pure LabVIEW code, so it will work on any LabVIEW platform that has a network connection, including the cRIO controllers from NI. With DLLs, ActiveX and .Net based libraries you are usually restricted to Windows only systems, although the Accon AGLink library does support Linux too, but my attempts to get that library to work on a x86 based NI Linux Realtime cRIO where pretty discouraging and the fact that it would anyhow not work on the cheaper ARM based cRIOs was the final knockout for this solution.

3a8082e126