Micrologix to Red Lion HMI

[calamwill]

i've set the IP address and the subnet mask, left the gateway blank and Pri DNS has come up what should i set that as/what does it mean?

 

[TimWilborne]

For basic communications between the RL and the Micrologix you can leave the gateway and DNS at 0.0.0.0

 

[calamwill]

For basic communications between the RL and the Micrologix you can leave the gateway and DNS at 0.0.0.0

is that both Pri DNS and Sec DNS (i have no idea what either of them are but i'm presuming that's a yes)

 

[TimWilborne]

Yes. Leave them both at 0.0.0.0

 

[calamwill]

Yes. Leave them both at 0.0.0.0

okay i've done that, thank you

another quick question, if i may ... how do i import tags from rslogix 500 to Crimson 3? i can't figure that our either

 

[gbradley]

okay i've done that, thank you

another quick question, if i may ... how do i import tags from rslogix 500 to Crimson 3? i can't figure that our either

Good question.
I don't think you can with 500, but if you can I'd like to know also.

 

[ASF]

Just a quick two minute overview of what the gateway and DNS settings are, so you know why you're leaving them blank -

Your IP address and subnet mask define your "local" network. So if your PLC's IP address is 192.168.0.1 and the subnet mask 255.255.255.0, that means your PLC can communicate directly with any device that has a 192.168.0.xxx address. If your subnet mask was 255.255.0.0, it would be able to communicate with anything that had a 192.168.xxx.xxx address. In 99.9% of applications, your subnet mask will be 255.255.255.0, so as long as the first 3 segments of your IP address are the same, the two devices can communicate directly to one another via regular switches.

However, let's say your PLC at 192.168.0.1 needs to communicate with another PLC at 10.10.10.1. It can't talk directly, so it needs a router, or gateway. When your PLC wants to send a message, it says to itself "hey, this PLC is not on my local network, so I can't talk directly to it. I will address this message to 10.10.10.1, but send it to the gateway". The gateway receives a message and says "yes, I can talk to 10.10.10.1", and sends the message on. The other PLC gets the message and responds the same way - via the gateway. So, long story short - if you need to communicate across different subnets, you will need a router in place, and will need to set the address of that router in the Gateway setting of your PLC.

What about DNS? Well, when you have a large plant with proper IT boffins looking after the network, there will likely be a domain. A domain can be thought of as a web address - e.g. rockwell.com is a domain, yourcompanyname.co.uk is a domain, etc. Everyone has an email address like [email protected] and so on. Now, for some reason, we humans are better at remembering names than numbers, and it makes life much easier for us if we can ask for the computer that's called Bob-Smiths-PC than having to remember that Bob Smith's computer has IP address 192.168.3.57. Not to mention, if (as is quite common) we use a DHCP server to dynamically assign IP addresses, then Bob's computer could have a different IP address today to what it had yesterday. Not helpful. So, there is a DNS server. DNS stands for Domain Name System, and it's purpose in life is to receive requests for Bob-Smiths-PC and reply that today Bob Smith has IP address 192.168.4.173. So if our device needs to communicate with another device by device name, rather than IP address, it needs to know who to ask for an IP address - that someone is the DNS.

Why the primary and secondary DNS you ask (if you are still reading, which you probably aren't as I've realised this is perhaps not the quick two minute primer I promised)? Well, in a large network, as you could probably imagine, this DNS server is fairly important. If for whatever reason the DNS server goes down, then all of a sudden nobody can find anybody else and, well, a lot of people are going to have a Very Bad Day (primarily the IT department, who will receive phone calls from every single person with a network connected device). So, it's standard practice to have a backup DNS server. So, each device goes and asks the primary DNS server for an IP address, and if it can't talk to the primary server, it'll go looking for the secondary instead.

So where does this come into the PLC programming world? Short answer: it doesn't. I've never found an application where it was necessary to set the DNS settings into a PLC (I set them if they're available, but I've never found a situation where it mattered).

So, long story short, in most applications you can leave the gateway blank, and in almost all applications you can leave DNS blank. That's the short answer, but I always like to know why I know things, so if you do too then hopefully that's been of some help

 

[TimWilborne]

Just a quick two minute overview of what the gateway and DNS settings are, so you know why you're leaving them blank -

Your IP address and subnet mask define your "local" network. So if your PLC's IP address is 192.168.0.1 and the subnet mask 255.255.255.0, that means your PLC can communicate directly with any device that has a 192.168.0.xxx address. If your subnet mask was 255.255.0.0, it would be able to communicate with anything that had a 192.168.xxx.xxx address. In 99.9% of applications, your subnet mask will be 255.255.255.0, so as long as the first 3 segments of your IP address are the same, the two devices can communicate directly to one another via regular switches.

However, let's say your PLC at 192.168.0.1 needs to communicate with another PLC at 10.10.10.1. It can't talk directly, so it needs a router, or gateway. When your PLC wants to send a message, it says to itself "hey, this PLC is not on my local network, so I can't talk directly to it. I will address this message to 10.10.10.1, but send it to the gateway". The gateway receives a message and says "yes, I can talk to 10.10.10.1", and sends the message on. The other PLC gets the message and responds the same way - via the gateway. So, long story short - if you need to communicate across different subnets, you will need a router in place, and will need to set the address of that router in the Gateway setting of your PLC.

What about DNS? Well, when you have a large plant with proper IT boffins looking after the network, there will likely be a domain. A domain can be thought of as a web address - e.g. rockwell.com is a domain, yourcompanyname.co.uk is a domain, etc. Everyone has an email address like [email protected] and so on. Now, for some reason, we humans are better at remembering names than numbers, and it makes life much easier for us if we can ask for the computer that's called Bob-Smiths-PC than having to remember that Bob Smith's computer has IP address 192.168.3.57. Not to mention, if (as is quite common) we use a DHCP server to dynamically assign IP addresses, then Bob's computer could have a different IP address today to what it had yesterday. Not helpful. So, there is a DNS server. DNS stands for Domain Name System, and it's purpose in life is to receive requests for Bob-Smiths-PC and reply that today Bob Smith has IP address 192.168.4.173. So if our device needs to communicate with another device by device name, rather than IP address, it needs to know who to ask for an IP address - that someone is the DNS.

Why the primary and secondary DNS you ask (if you are still reading, which you probably aren't as I've realised this is perhaps not the quick two minute primer I promised)? Well, in a large network, as you could probably imagine, this DNS server is fairly important. If for whatever reason the DNS server goes down, then all of a sudden nobody can find anybody else and, well, a lot of people are going to have a Very Bad Day (primarily the IT department, who will receive phone calls from every single person with a network connected device). So, it's standard practice to have a backup DNS server. So, each device goes and asks the primary DNS server for an IP address, and if it can't talk to the primary server, it'll go looking for the secondary instead.

So where does this come into the PLC programming world? Short answer: it doesn't. I've never found an application where it was necessary to set the DNS settings into a PLC (I set them if they're available, but I've never found a situation where it mattered).

So, long story short, in most applications you can leave the gateway blank, and in almost all applications you can leave DNS blank. That's the short answer, but I always like to know why I know things, so if you do too then hopefully that's been of some help

A little more than 2 minutes but excellent job:site:

 

[gbradley]

Just a quick two minute overview of what the gateway and DNS settings are, so you know why you're leaving them blank -

Your IP address and subnet mask define your "local" network. So if your PLC's IP address is 192.168.0.1 and the subnet mask 255.255.255.0, that means your PLC can communicate directly with any device that has a 192.168.0.xxx address. If your subnet mask was 255.255.0.0, it would be able to communicate with anything that had a 192.168.xxx.xxx address. In 99.9% of applications, your subnet mask will be 255.255.255.0, so as long as the first 3 segments of your IP address are the same, the two devices can communicate directly to one another via regular switches.

However, let's say your PLC at 192.168.0.1 needs to communicate with another PLC at 10.10.10.1. It can't talk directly, so it needs a router, or gateway. When your PLC wants to send a message, it says to itself "hey, this PLC is not on my local network, so I can't talk directly to it. I will address this message to 10.10.10.1, but send it to the gateway". The gateway receives a message and says "yes, I can talk to 10.10.10.1", and sends the message on. The other PLC gets the message and responds the same way - via the gateway. So, long story short - if you need to communicate across different subnets, you will need a router in place, and will need to set the address of that router in the Gateway setting of your PLC.

What about DNS? Well, when you have a large plant with proper IT boffins looking after the network, there will likely be a domain. A domain can be thought of as a web address - e.g. rockwell.com is a domain, yourcompanyname.co.uk is a domain, etc. Everyone has an email address like [email protected] and so on. Now, for some reason, we humans are better at remembering names than numbers, and it makes life much easier for us if we can ask for the computer that's called Bob-Smiths-PC than having to remember that Bob Smith's computer has IP address 192.168.3.57. Not to mention, if (as is quite common) we use a DHCP server to dynamically assign IP addresses, then Bob's computer could have a different IP address today to what it had yesterday. Not helpful. So, there is a DNS server. DNS stands for Domain Name System, and it's purpose in life is to receive requests for Bob-Smiths-PC and reply that today Bob Smith has IP address 192.168.4.173. So if our device needs to communicate with another device by device name, rather than IP address, it needs to know who to ask for an IP address - that someone is the DNS.

Why the primary and secondary DNS you ask (if you are still reading, which you probably aren't as I've realised this is perhaps not the quick two minute primer I promised)? Well, in a large network, as you could probably imagine, this DNS server is fairly important. If for whatever reason the DNS server goes down, then all of a sudden nobody can find anybody else and, well, a lot of people are going to have a Very Bad Day (primarily the IT department, who will receive phone calls from every single person with a network connected device). So, it's standard practice to have a backup DNS server. So, each device goes and asks the primary DNS server for an IP address, and if it can't talk to the primary server, it'll go looking for the secondary instead.

So where does this come into the PLC programming world? Short answer: it doesn't. I've never found an application where it was necessary to set the DNS settings into a PLC (I set them if they're available, but I've never found a situation where it mattered).

So, long story short, in most applications you can leave the gateway blank, and in almost all applications you can leave DNS blank. That's the short answer, but I always like to know why I know things, so if you do too then hopefully that's been of some help

Thank-you, very well said.

 

[calamwill]

Just a quick two minute overview of what the gateway and DNS settings are, so you know why you're leaving them blank -

Your IP address and subnet mask define your "local" network. So if your PLC's IP address is 192.168.0.1 and the subnet mask 255.255.255.0, that means your PLC can communicate directly with any device that has a 192.168.0.xxx address. If your subnet mask was 255.255.0.0, it would be able to communicate with anything that had a 192.168.xxx.xxx address. In 99.9% of applications, your subnet mask will be 255.255.255.0, so as long as the first 3 segments of your IP address are the same, the two devices can communicate directly to one another via regular switches.

However, let's say your PLC at 192.168.0.1 needs to communicate with another PLC at 10.10.10.1. It can't talk directly, so it needs a router, or gateway. When your PLC wants to send a message, it says to itself "hey, this PLC is not on my local network, so I can't talk directly to it. I will address this message to 10.10.10.1, but send it to the gateway". The gateway receives a message and says "yes, I can talk to 10.10.10.1", and sends the message on. The other PLC gets the message and responds the same way - via the gateway. So, long story short - if you need to communicate across different subnets, you will need a router in place, and will need to set the address of that router in the Gateway setting of your PLC.

What about DNS? Well, when you have a large plant with proper IT boffins looking after the network, there will likely be a domain. A domain can be thought of as a web address - e.g. rockwell.com is a domain, yourcompanyname.co.uk is a domain, etc. Everyone has an email address like [email protected] and so on. Now, for some reason, we humans are better at remembering names than numbers, and it makes life much easier for us if we can ask for the computer that's called Bob-Smiths-PC than having to remember that Bob Smith's computer has IP address 192.168.3.57. Not to mention, if (as is quite common) we use a DHCP server to dynamically assign IP addresses, then Bob's computer could have a different IP address today to what it had yesterday. Not helpful. So, there is a DNS server. DNS stands for Domain Name System, and it's purpose in life is to receive requests for Bob-Smiths-PC and reply that today Bob Smith has IP address 192.168.4.173. So if our device needs to communicate with another device by device name, rather than IP address, it needs to know who to ask for an IP address - that someone is the DNS.

Why the primary and secondary DNS you ask (if you are still reading, which you probably aren't as I've realised this is perhaps not the quick two minute primer I promised)? Well, in a large network, as you could probably imagine, this DNS server is fairly important. If for whatever reason the DNS server goes down, then all of a sudden nobody can find anybody else and, well, a lot of people are going to have a Very Bad Day (primarily the IT department, who will receive phone calls from every single person with a network connected device). So, it's standard practice to have a backup DNS server. So, each device goes and asks the primary DNS server for an IP address, and if it can't talk to the primary server, it'll go looking for the secondary instead.

So where does this come into the PLC programming world? Short answer: it doesn't. I've never found an application where it was necessary to set the DNS settings into a PLC (I set them if they're available, but I've never found a situation where it mattered).

So, long story short, in most applications you can leave the gateway blank, and in almost all applications you can leave DNS blank. That's the short answer, but I always like to know why I know things, so if you do too then hopefully that's been of some help

i don't think you understand how incredibly helpful this "two minute overview" actually is for someone, like me, with next to no experience with this stuff. i can't thank you enough for this!

 

[calamwill]

Good question.
I don't think you can with 500, but if you can I'd like to know also.

oh really? damn. thank you for taking the time anyway

 

[calamwill]

Good question.
I don't think you can with 500, but if you can I'd like to know also.

if i can't do it with 500, 5000 should be able to do it, right?
if so, can you programme a micrologix 1400 with rslogix 5000?
if i can do that i can re-write the ladder logic i've made so far in 5000 and do it that way

 

[alan_505]

RSLogix5000 is for CompactLogix/ControlLogix PLC's, you will need to use RSLogix500 to do any programming on the ML1400.

Alan

 

[calamwill]

RSLogix5000 is for CompactLogix/ControlLogix PLC's, you will need to use RSLogix500 to do any programming on the ML1400.

Alan

thank you Alan

is there a way that the data tagging could be done with 500?

 

[gbradley]

thank you Alan

is there a way that the data tagging could be done with 500?

There you go tryin to run when your just learning to walk.
Why don't you create a little "Hello World" program with the equipment that you got?