Check my thinking please on system selection

[stuman]

Hi, I would like to run this scenario by you guys.

I already have a licence for RSLogix 500, so I am limited to micrologix and SLC 500. I don't want to have to buy and expensive converter card for my laptop, which means that I can really only talk to the plc's via rs-232 or ethernet. I need to be able to make live updates to the program through RSL 500. I also need to be able to view what is going on in the PLC via RSL 500. I am going to use a red lion G3 display as well ( it handles all communication types).

I am putting in a small system to control a water treatment plant, 1 AI card, 1 AO card, 1 DI card, 1 DO card. Given my comments above, am I only really left with the SLC 5/05 processor? I am after the cheapest possible solution, but one with a decent amount of flexibility for possible future expansion.

All help would be appreciated.

Stu

 

[Bob O]

Stuman,

Check the ML1100 and see if it meets your needs...Also, check that you have or can get the correct version of RS500 and RSLinx to communicate with the 1100.

http://www.ab.com/programmablecontrol/plc/micrologix1100/

Hope this helps

 

[GeoffC]

I am after the cheapest possible solution

By restricting yourself simply because you have the programming software makes this hard to achieve. With the small i/o count there are a number of small plcs with free programming software, and RS232 (or USB) programming connections, that would meet your needs.

 

[Ken Moore]

Instead of listing the I/O cards, could you list the amount of I/O by type?

 

[JesperMP]

I say, stay with RSLogix 500 and SLC500. Just to save money on a single project is not enough reason to switch platforms.
If on the other hand, you are looking to possible switch platform generally for all new projects in the future, then by all means do not feel inhibited by what you are using today.

You didnt say how the Redlion HMI connects to the SLC500.
If by DF1 or Ethernet, then you could try to see if it could be switched to DH485. Then you could exchange the SLC5/05 for an SLC5/03 and program via DF1.

 

[MikeGranby]

You didnt say how the Redlion HMI connects to the SLC500. If by DF1 or Ethernet, then you could try to see if it could be switched to DH485. Then you could exchange the SLC5/05 for an SLC5/03 and program via DF1.

We could do any of those -- DF1, Ethernet or DH485. Of the serial options, DH485 is has a high overhead for point-to-point operations, and has a limited Baud rate. I'd thus suggest DF1 over DH485 is most applications. That said, if it's a question of juggling the ports... Another option might be to use the G3's program-thru facility to allow you to connect the AB software via our unit to the PLC, but that would stop the G3<->PLC comms while the PC is online. Probably not what you want.

 

[Dua Anjing]

... Another option might be to use the G3's program-thru facility to allow you to connect the AB software via our unit to the PLC, but that would stop the G3<->PLC comms while the PC is online. Probably not what you want.

Mike, I don't want to hijack this thread but I would like to know a bit more about the "program-thru facility" can it be used with PLC's other than SLC ? My first thought is that it could be very handy on remote installations (pump stations etc) where we have access to to HMI via TCP/IP and could use the "program-thru facility" to use that comms channel to access small PLC that doesn't have ethernet on board or has limited comms options.

 

[MikeGranby]

Essentially, it allows you to use one of the G3's serial ports (or a TCP/IP connection) to take over a serial port that is normally used for PLC communications. If you use a serial port, your PC just talks out of COM1 or whatever and 'thinks' it's connected to the PLC. If you use TCP/IP, the G3 just looks like a serial port server, so you can use a virtual serial port driver to create a COM port that will again map straight through to the port to which the PLC is connected.

The process is protocol agnostic, which means that it can't interleave data requests from the HMI, so the comms stops while it's active. It is also not capable of operating with some protocols that use break states, tight timing or handshake lines to signal special conditions. That said, it works with most PLCs. In fact, it works better with the smaller ones where the protocols tend to be less over-designed...

It's all described in the Sharing Ports section of the Advanced Communications chapter of the Crimson 2.0 manual, which can be found at the link below.

http://www.redlion.net/Support/Downloads/SoftwareLibrary/Crimson2.html

 

[504bloke]

Mike, I don't want to hijack this thread but I would like to know a bit more about the "program-thru facility" can it be used with PLC's other than SLC ?

It doesnt work with the Siemens S7-200

Shame as i love redlion and they can do most things

 

[MikeGranby]

It doesnt work with the Siemens S7-200

See my comment about over-designed protocols!

 

[504bloke]

Hi, I would like to run this scenario by you guys.

I already have a licence for RSLogix 500, so I am limited to micrologix and SLC 500. I don't want to have to buy and expensive converter card for my laptop, which means that I can really only talk to the plc's via rs-232 or ethernet. I need to be able to make live updates to the program through RSL 500. I also need to be able to view what is going on in the PLC via RSL 500. I am going to use a red lion G3 display as well ( it handles all communication types).

I am putting in a small system to control a water treatment plant, 1 AI card, 1 AO card, 1 DI card, 1 DO card. Given my comments above, am I only really left with the SLC 5/05 processor? I am after the cheapest possible solution, but one with a decent amount of flexibility for possible future expansion.

All help would be appreciated.

Stu

All joking aside, i know you said you wanted to stick with SLC or ML BUT if you did want to change then i could recommend the Siemens S7-200 range combined with a G3 on 485 connection, you can talk to both the G3 and S7 no problems at all (Except for Pass Through!). And regarding software i dont know about your part of the world but over here if you get on a freebie intro S7 200/logo course then siemens give the software away at the end of the day.

If you want to stick with ML or SLC then i'd go with the SLC and talk DF1 over 485 as Mike suggested.

How many Analogue and Digital IO are you talking of ?

 

[Dua Anjing]

Thanks Mike. You guys (Red Lion) are scary ! I wish I could get this kind of support response from other vendors.

 

[kolyur]

I'm a big fan of the G3 series but my experience with the port-sharing capability has not been positive. I've tried it on a few occasions and the problem is that it is s-l-o-w, much slower than connecting direct. As it was explained to me by tech support, the port-sharing is based on TCP, so if you're trying to access one serial port through another, the data actually has to be converted twice. (Jeremy explained it much better than I can.) Supposedly it is faster if you access the shared serial port using Ethernet and a utility that lets you create a virtual com port over TCP... I haven't tried this.

I am putting in a small system to control a water treatment plant, 1 AI card, 1 AO card, 1 DI card, 1 DO card.

I would second the recommendation for the ML1100. Ethernet comms between the ML1100/SLC505 and the G3 are solid. My only concern is that you can't add more than four expansion modules to the 1100 so you'd be maxed out already. You could consider using a ML1200 or 1500 with a 1761-NET-ENI module to give you Ethernet connectivity. I'd stay away from the 5/05... based on your I/O requirements I think it's overkill and it will cost more than any Micrologix. Ethernet is a good option because all you'd need is an el cheapo hub/switch and you can program both the PLC and G3 from the same connection.

 

[stuman]

I did not think it was possible to do live updates to the PLC program when using the ML series of PLC's. Please correct me if I cam wrong. I have also read recently (cannot find the post) that certain ethernet devices, maybe the 1761-net-eni module, cannot handle communicating to an ethernet enabled PanelView for example. Something about it has 14 communication lines, 2 for inbound, 2 for outbound and the rest is as needed. When hooking it up to a PanelView, the PV needed say 12 direct lines, which meant it would not work. It was something along those lines, please don't flame me for getting it wrong.

The IO is 4 AO, 4 AI, 4 Realy DO, 2 DO, 2 DI. But if the system works better than the current USB based controller, it would go to AI 24, AO 4, Relay DO 40, DO 4 DI 4. That is my main reason at this point intime, leaning towards the 5/05.

Thanks for the help thus far.
Stu

 

[kolyur]

I did not think it was possible to do live updates to the PLC program when using the ML series of PLC's.

You are correct for the most part; I missed that requirement in your original post. However, the ML1100 does support online editing although I have found it to be somewhat buggy when connecting over Ethernet.

I have also read recently (cannot find the post) that certain ethernet devices, maybe the 1761-net-eni module, cannot handle communicating to an ethernet enabled PanelView for example.

I have never had a problem getting a NET-ENI to communicate with a Panelview (standard, not PV+). I'm not sure what you mean about the number of communication lines.