Checking comms between PC and PLC

[Akparjay]

Hello, can someone share/explain How to check comms between PC and PLC via TeamViewer? TIA

 

[Ken Roach]

In general, TeamViewer is a remote desktop sort of program that tunnels over the Internet. So you would have the same tools as though you were sitting at the computer screen and keyboard.

I like to start from the bottom and work my way up:

1. Verify that the operating system (often Windows) has a network interface that is plugged in and configured for an IP address on the network I expect the PLC to be on.
2. PING the PLC's IP address
3. If successful, use ARP to find out of the PLC's MAC ID is in the range that I expect for that manufacturer.
4. If successful, use the Windows PowerShell "test-NetConnection" feature to check connectivity to Port 80 (if the controller has a webserver) or Port 502 (if it uses Modbus) or Port 102 (if it's Siemens) or Port 44818 (if it's Rockwell or Omron and uses EtherNet/IP).
5. If successful, use the communications driver package provided by the PLC vendor to "browse the network" and discover devices.

 

[JeffKiper]

What plc? Serial , ethernet, USB?

 

[JeffKiper]

Ken when you use your Ethernet do you put it in bridge mode and use the native ethernet or a secondary ethernet adapter? Like a USB to wifi adapter? I've typically use the native adapter if im using wifi and if i need hardwired I use a USB to Copper adaper. I haven't found a USB to WIFO adapter that is reliable enough for using it with TeamViewer.

 

[Akparjay]

In general, TeamViewer is a remote desktop sort of program that tunnels over the Internet. So you would have the same tools as though you were sitting at the computer screen and keyboard.

I like to start from the bottom and work my way up:

1. Verify that the operating system (often Windows) has a network interface that is plugged in and configured for an IP address on the network I expect the PLC to be on.
2. PING the PLC's IP address
3. If successful, use ARP to find out of the PLC's MAC ID is in the range that I expect for that manufacturer.
4. If successful, use the Windows PowerShell "test-NetConnection" feature to check connectivity to Port 80 (if the controller has a webserver) or Port 502 (if it uses Modbus) or Port 102 (if it's Siemens) or Port 44818 (if it's Rockwell or Omron and uses EtherNet/IP).
5. If successful, use the communications driver package provided by the PLC vendor to "browse the network" and discover devices.

Gotcha. Thank you for the explanation. I have not done this through my program (mechatronics) before.
And now i have to help the tech that will remotely check our machine through TeamViewer. our machine is not online so i had to use a WiFi usb adapter and use hotspot or maybe our guest wifi. Alls i have to do is share my TeamViewer ID and password right? and also IP address?

 

[Akparjay]

What plc? Serial , ethernet, USB?

Allen Bradley compactLogix. theres two Network available but IP address not match. so i have to use a usb dongle or WiFi adapter for the Tech to be able to get in.

 

[JeffKiper]

I totally screwed up my train of thought I was thinking VirtualBox not TeamViewer. My chemo brain kicked in.

 

[Ken Roach]

I use TeamViewer to accomplish remote access to logic controllers regularly, but in two different general ways.

The first method is when the local computer has the software tools and licenses installed on it. The computer has to be connected to the automation network, and also to the Internet. It's almost always done with one hardwired Ethernet adapter (built in or USB dongle) for the automation LAN, and WiFi or mobile data tethering for the Internet connection.

For that setup, the local computer should already be configured to communicate to the controllers, and you just give the person helping you the TeamViewer credentials they need to connect to your computer. Sometimes you have to be right there to authorize/approve their connection. My clients tend to require that, and won't allow unattended connections. The remote user connects, has access to the local computer's desktop and applications and drives and network and tools, and does their work.

The second method is when the local PC just belongs to one of my mechanics or executives or managers and has no automation software on it. The automation software and licenses are on my PC (often in a virtual machine). I have them install the TeamViewer VPN driver as well as the TeamViewer remote access program, and I follow our colleague JesperMP's excellent guide to using the TeamViewer VPN, Windows TCP/IP routing, and Static Route entries in my remote computer.

The usual problems are that the PLCs aren't configured with the proper Default Gateway set to the local LAN address of the laptop, or the automation network coincidentally has an IP subnet identical to the one I have to connect to internally to borrow licenses. I resolve the Default Gateway issue by installing RSLinx Classic Lite on the local user's computer so I can make those changes to the PLCs and devices. I resolve the local/remote LAN conflict by doing a License Borrow then disconnecting from my corporate LAN.

If all that sounds clear as mud, take a deep breath and a step back, and read our colleague's frequently-reproduced TeamViewer VPN + PLC configuration guide:

PLCS.net File Manager

How to download program from TiaPortal to PLC via Teamviewer VPN - 119827 - Industry Support Siemens

https://www.myomron.com/modules/KB/file_d.php?id=743

 

[JesperMP]

How to check comms between PC and PLC via TeamViewer?

Exactly what are you trying to achieve ?
It could be as simple as pinging the PLC from the PC via the remote desktop.
But without knowing what you want to achieve in what context it is hard to say.

 

[mad4x4]

What you trying to do ? Write Code & Download?
Where is the PLC Development Software? On our Laptop, or on the Machine you are Connecting to?

 

[Akparjay]

I use TeamViewer to accomplish remote access to logic controllers regularly, but in two different general ways.

The first method is when the local computer has the software tools and licenses installed on it. The computer has to be connected to the automation network, and also to the Internet. It's almost always done with one hardwired Ethernet adapter (built in or USB dongle) for the automation LAN, and WiFi or mobile data tethering for the Internet connection.

For that setup, the local computer should already be configured to communicate to the controllers, and you just give the person helping you the TeamViewer credentials they need to connect to your computer. Sometimes you have to be right there to authorize/approve their connection. My clients tend to require that, and won't allow unattended connections. The remote user connects, has access to the local computer's desktop and applications and drives and network and tools, and does their work.

The second method is when the local PC just belongs to one of my mechanics or executives or managers and has no automation software on it. The automation software and licenses are on my PC (often in a virtual machine). I have them install the TeamViewer VPN driver as well as the TeamViewer remote access program, and I follow our colleague JesperMP's excellent guide to using the TeamViewer VPN, Windows TCP/IP routing, and Static Route entries in my remote computer.

The usual problems are that the PLCs aren't configured with the proper Default Gateway set to the local LAN address of the laptop, or the automation network coincidentally has an IP subnet identical to the one I have to connect to internally to borrow licenses. I resolve the Default Gateway issue by installing RSLinx Classic Lite on the local user's computer so I can make those changes to the PLCs and devices. I resolve the local/remote LAN conflict by doing a License Borrow then disconnecting from my corporate LAN.

If all that sounds clear as mud, take a deep breath and a step back, and read our colleague's frequently-reproduced TeamViewer VPN + PLC configuration guide:

PLCS.net File Manager

How to download program from TiaPortal to PLC via Teamviewer VPN - 119827 - Industry Support Siemens

https://www.myomron.com/modules/KB/file_d.php?id=743

wow! make very much sense to me, All's i need now is Experience. They got the tech in in our machine remotely earlier today but i was not able to see since I work 2nd shift. Unfortunately, the machine still down the guy was saying that all comms wise are look good, but notice some 24vdc issue.
I check everything and didnt fine any lost 24v. but one 24vdc safety relay was suspicious, there's a line that only cary 11vdc but the rest are 24vdc when i check the terminal connection from the safety relay.
Im sorry if im off topic now, just dealing with this issue we have and try to get some help and also, to understand more on plc remotely check. Thanks again sir!

 

[Akparjay]

I use TeamViewer to accomplish remote access to logic controllers regularly, but in two different general ways.

The first method is when the local computer has the software tools and licenses installed on it. The computer has to be connected to the automation network, and also to the Internet. It's almost always done with one hardwired Ethernet adapter (built in or USB dongle) for the automation LAN, and WiFi or mobile data tethering for the Internet connection.

For that setup, the local computer should already be configured to communicate to the controllers, and you just give the person helping you the TeamViewer credentials they need to connect to your computer. Sometimes you have to be right there to authorize/approve their connection. My clients tend to require that, and won't allow unattended connections. The remote user connects, has access to the local computer's desktop and applications and drives and network and tools, and does their work.

The second method is when the local PC just belongs to one of my mechanics or executives or managers and has no automation software on it. The automation software and licenses are on my PC (often in a virtual machine). I have them install the TeamViewer VPN driver as well as the TeamViewer remote access program, and I follow our colleague JesperMP's excellent guide to using the TeamViewer VPN, Windows TCP/IP routing, and Static Route entries in my remote computer.

The usual problems are that the PLCs aren't configured with the proper Default Gateway set to the local LAN address of the laptop, or the automation network coincidentally has an IP subnet identical to the one I have to connect to internally to borrow licenses. I resolve the Default Gateway issue by installing RSLinx Classic Lite on the local user's computer so I can make those changes to the PLCs and devices. I resolve the local/remote LAN conflict by doing a License Borrow then disconnecting from my corporate LAN.

If all that sounds clear as mud, take a deep breath and a step back, and read our colleague's frequently-reproduced TeamViewer VPN + PLC configuration guide:

PLCS.net File Manager

How to download program from TiaPortal to PLC via Teamviewer VPN - 119827 - Industry Support Siemens

https://www.myomron.com/modules/KB/file_d.php?id=743

Also Thank you for the links that you share.

 

[Ken Roach]

>there's a line that only cary 11vdc but the rest are 24vdc when i check the terminal connection from the safety relay.

What exactly is the purpose of the signal you are measuring, and what kind of meter are you using to measure it ?

Many safety relays provide one or more pulsed voltage source terminals. Those voltage sources are meant to specifically run through contacts (like buttons and switches) and into a safety relay input terminal. The purpose is to be able to tell the difference between two different channels (they pulse at different times/rates) and to tell the difference between a continuous normally-closed circuit or a short to +24V DC.

Most ordinary multimeters average out signals to the extent that a pulsed 24V signal might average out to only 11 volts. It's a head-scratcher when you first encounter it in the field, and I'm going to guess 80% of us learned about how those work the hard way.

 

[hardaysknight]

Most ordinary multimeters average out signals to the extent that a pulsed 24V signal might average out to only 11 volts. It's a head-scratcher when you first encounter it in the field, and I'm going to guess 80% of us learned about how those work the hard way.

Dang Ken, you just gave me an epiphany and a flashback at the same time

 

[Akparjay]

>there's a line that only cary 11vdc but the rest are 24vdc when i check the terminal connection from the safety relay.

What exactly is the purpose of the signal you are measuring, and what kind of meter are you using to measure it ?

Many safety relays provide one or more pulsed voltage source terminals. Those voltage sources are meant to specifically run through contacts (like buttons and switches) and into a safety relay input terminal. The purpose is to be able to tell the difference between two different channels (they pulse at different times/rates) and to tell the difference between a continuous normally-closed circuit or a short to +24V DC.

Most ordinary multimeters average out signals to the extent that a pulsed 24V signal might average out to only 11 volts. It's a head-scratcher when you first encounter it in the field, and I'm going to guess 80% of us learned about how those work the hard way.

I was just trying to make sure i have all the 24vdc on all 24V channels as per the tech advised yesterday that i have to check it. I used my fluke t6-600.

So, last night i was troubleshooting everything. It was looking good as it should no faults on safety relays, no lost 24vdc anywhere, alarm has been acknowledged. But OIT still stuck im looking at the Input/output screen none of them are lit(the ones that should be lit when in idle.). its like not communicating to the plc?
So i told my boss to get a third party tech to come in and check in this morning.
And there it is, the 3rd party tech found the issue on the plc was not seeing the end cap. I'm not really sure what's that mean? (Again, i never learn this on my Mechatronics program before.)

I just dont get it why the Software tech guy didnt found this at the beginning. and we have to call for 3rd party just to get the issue fixed.