PG/PC Interface for Ethernet, Step 7

[orense]

Hello,

We have been using Ethernet for our plcs for quite some time now. The set up of the interface in Simatic Manager, is set up in PG/PC interface.

However, several times I have noticed that I can find the Ethernet devices in the "accessible nodes" window. Devices such as panels, CP cards, CPUs etc. But when I try to monitor blocks or hardware configurations, then I can not get connected. So, several times I would have to change the PG/PC interface from ISO ind. Ethernet, to TCP/IP... It seems like it depends what I am connected to. If it is through a CPU, through a switch or a CP card.

If I can't get connected then I change the PG/PC interface in either directions, and it will work.

Point is that I would like to know what the difference is between ISO and TCP/IP set up in the PG/PC interface. I know it has something to do with IP versus MAC addresses, but I would like to understand it better... Does the program editor use it differently than accessible nodes?

Anyone?


Brg
Andreas

 

[jmsmoreira]

Don't know the answer but I always use the TCP/IP and it works well for CPU, HMIs...

 

[JesperMP]

There is no reson to use ISO mode, unless for old CP cards that only support ISO mode.

 

[joseph_e2]

I would like to add that I rarely have "accessible nodes" show up when using Ethernet, even when directly connected to the CPU. I can usually connect after opening the project, though. If I'm trying to connect without a project, I almost always have to use a PC adapter.

 

[JesperMP]

Why do you connect without a project ???
Ethernet and TCP/IP is very easy and reliable to my experience.

 

[joseph_e2]

I agree that it's *usually* the best way to connect. Sometimes our IT department's network software bloatware will mess things up, but it usually works great for us when we're connecting to a machine that actually has Ethernet.

We have machines from several builders who didn't include fully matching program archives. I work for a huge, high inertia corporation and the bunch that buys the machines isn't the same bunch that has to support them, so we support folks are all too often left to fend for ourselves. I've found that uploading to an empty project and copying all the program blocks and symbol table over from the archive is the only repeatable way to reconcile a non-matching hardware configuration.

With the latest batch of machines, I'm going to try to refuse to support them until we get matching archives, but I'm not really holding my breath for it to happen that way. I did upload them so I could send the builder exactly what's in the machines in case it makes it easier for them to reconcile. I expect I'll have to go through the comparison results by hand later on, though.

 

[JesperMP]

I think that it is extremely desperate to try and troubleshoot the PLC program for a machine without the source code. Without symbols and comments it can be hopeless. And if the machine is still in waranty - dont touch the program at all.

 

[joseph_e2]

Agreed, that would normally be my approach, but I'm not generally given the option. As I said, those who buy and pay for the machines have little or no interest in the day to day support of them, and those responsible for the day to day support have absolutely NO say in what gets bought and at what point the machine is accepted.

 

[rylandlloyd]

Andreas,

I have seem similar problems when he number of PG connections in the CPU hardware setup are insufficient for the number of devices that are connecting to it (HMI & DCS usually occupy the PG connections), try increasing the number of concurrent connections.

Hope it helps

Ryland