Compact I/O vs Point I/O

ASF

Lifetime Supporting Member
Join Date
Jun 2012
Location
Australia
Posts
3,907
Hi all,

I've got an application coming up with a Compact GuardLogix and safety I/O. Seeing as my only option for safety I/O is 1734 point I/O, I'm going to have to have two racks in the MCC - the local 1768/1769 rack, and the 1734 rack. The safety I/O will have to be on the 1734 rack, and the standard I/O could be on either. Just due to my typical drawing and numbering style, having two I/O racks in the same cabinet is a bit of a pain - I mean, it's a real First World Problem, but it got me wondering, is there any reason I shouldn't have ALL my I/O on the 1734 rack? Just have the power supply, ethernet and CPU on the 1768 chassis, and then do both safety and non-safety I/O on the 1734 chassis?

Costwise, it's much the same whether I buy four 1734 8 channel cards or one 1769 32 channel card.

I don't have a massive amount of standard I/O; probably in the ballpark of 50 in and 30 out. Maybe a couple of analog inputs.

There's nothing that's speed critical (well, there is one thing, but its on ethernet anyway).

Safety I/O will have to be on the 1734 chassis anyway, so the concern of "what happens if you lose the link" is moot. Sure, we can't set off a siren or a flashing light, but everything's going to have come to a grinding halt, and there's a HMI to explain the problem.

So I guess, are there any other quirks, differences, or considerations when choosing between 1734 and 1769 I/O that I should think about before making this decision? Will I need any extra power distribution modules etc to power that many 1734 cards?

Appreciate any insight or thoughts :)
 
Thanks patrick, yes I had a read through that one yesterday and I'm confident that the amount of I/O I've got won't be a problem (side note: how did that project end up going?)

I'm more thinking about functionality I may gain/lose by using all point I/O, for example, I know that with in-chassis ControlLogix I/O there is quite a lot of information you can gather about each I/O point. Obviously this is CompactLogix vs Point, not ControlLogix vs Point, and I can't see any main benefits to that extra information - but I'm just curious to hear if anyone's got any tips like "you don't get this functionality with Point I/O" or "you can't do that with Point I/O" etc, so that I can consider that as well and see if it's relevant to my situation.

By the absence of replies I guess there aren't a lot of strong opinions either way, which is almost an answer in itself ;)
 
ASF said:
...By the absence of replies I guess there aren't a lot of strong opinions either way, which is almost an answer in itself...

I would tend to err on the side of no replies meaning a general level of uncertainty here, more so than indifference.

I'm off home to bed now so I'll just leave you hanging...:sleep:

I might post something tomorrow, if I find the time?

G.
 
Have never had a problem with point I/O. I've got a job coming up that will have Point I/O in the main panel instead of the compactlogix I/O (processor is a L43 at the minimum) just as you described. The customer feels he'll have more flexibility when it comes to future changes.
 
That would be terrific, thanks George :)

Thanks also jstolaruk, good to hear I'm not the only one on this path!
 
Just a quick bump, in case George has had his sleep and his morning coffee and has anything more to add ;)

(or anyone else, for that matter!)
 
Point I/O is really good. I used to be against remote stuff like that. We had a point I/O rack catch fire a couple weeks ago. Nothing malfunctioned, but operators sprayed water into a cord grip on the panel. So I had to scope out what was damaged and get it ordered. I ordered 10 cards, 2 power supplies, and 10 backplates. It was much cheaper than I thought it would be.
 
I have used Point I/O on a couple of projects with good success. The only thing I dont like about it is the module density. With only 4-6 I/O per module, you have to wire up 4 cards to get the I/O of a standard 16 I/O card.

The other thing I don't like about it is the wiring of the module. There isn't a Interface Module for them like the 1769 modules have. So you have to wire to the module itself which can get messy depending on the module.

Another module to look into that I just recently used on a project is the 1794 Flex I/O modules. You can get them in up to 32 DI's. They have a base similar to the IFM's and are a little easier to wire. Connected up to a Ethernet module they are pretty easy to set up. No BTR or BTW commands needed. Might be another way to go.
 
If you are doing any analog....Point I/O usually has better resolution.....never worse....even compared to Flex I/O.
That is why I went Point I/O.
 
Bullzi - yes, module density is a little low, but you can get 8 channel cards in both digital and analog, which isn't so bad (possibly excluding analog output, I've not checked). And when you look at it, two 1734-IB8's are 11mm narrower than a 1769-IB16 and four 1734-IB8's are 5mm narrower than a 1769-IB32. Plus, they're slightly cheaper. Sure, I have to spend a bit more time defining modules, but it's hardly a deal breaker :)

We never use the interface modules either - we wire everything directly to the card; spare or external inputs are wired to terminals. It's been a while since I was on the tools, but when I was I could fit off both ends of a 1769-IB32 in under 25 minutes, and that's with pins both ends and wire numbers at the terminal strip :)

I did think about flex I/O, but the main point here is that I have to have a point I/O rack regardless for the safety I/O, so the choice is between 1769 and 1734.

Thanks for all the input, definitely a few things I hadn't thought of. I think at this stage I'm happy to do all my I/O on the point chassis :)
 
Safety I/O will have to be on the 1734 chassis anyway, so the concern of "what happens if you lose the link" is moot. Sure, we can't set off a siren or a flashing light, but everything's going to have come to a grinding halt, and there's a HMI to explain the problem.

You can configure fault states on 1734 modules; on discrete outputs, for example, you can maintain the most recent state, de-energize the output, or energize an output. You can even set a fault state on analog outputs.

Navigate to page 111: http://literature.rockwellautomation.com/idc/groups/literature/documents/um/1734-um001_-en-p.pdf
 
Last edited:

Similar Topics

Is it possible to run a AB controller without the Local/Point IO attached by making small modifications to a project? I would like to test...
Replies
3
Views
1,279
Dear All, I am using 1769 L32 Processor. I need decimal points or floating point application in my mathematical instructions. I am not able to...
Replies
3
Views
4,700
gents, I am trying to configure communication with EMERSON PK300 controller through port A1 using generic ethernet communication module . I could...
Replies
0
Views
28
My PLC is currently running the program and the process is still live. One of my 1769-if16C cards values are all frozen but the card is not...
Replies
1
Views
88
I've blown the Output Transistor on the Output Card of a Compact Logix 1769-L24ER-QBFC1B It says J378. Does anyone know the replacement part...
Replies
3
Views
169
Back
Top Bottom