SLC 5/05 Upgrade

[the_msp]

Looking into maybe upgrading a SLC 5/05.

13 Slot rack. 12/13 populated.

DeviceNet to a panelview. That's going in the bin, replaced by Ignition Edge.

PowerFlex 700 and 525.

I believe there is a 500->5000 program converter, although you don't then get the benefit of tags and end up with weird tag names.

Onsite in Feb to pull the program and see how convoluted it is.

Not to start an AB bashing thread, but the site doesn't care what's put in. Is modern AB CLX, e.g. L8x decent? Seen a few threads that suggest they don't build 'em like they used to.

If I change to another brand and rewrite the program from scratch, I'd be leaning towards AD Productivity P2000 with Yaskawa drives on E/IP.

 

[robertmee]

I dont mind Rockwell other than their pricing structure. I definitely wouldn't use the SLC/PLC5 conversion to CLX. Defeats the purpose of organizing and tag structure, and using UDTs which especially work well with Ignition.

 

[the_msp]

What are lead times like, have they settled or still like 9 months?

 

[OkiePC]

My biggest complaint about Productivity Series is that array indices and bit numbers start with 1 instead of 0. That caused me a handful of errors tying bit of word numbers to Ignition alarm tags. I have no idea why they did that. I had a list of other complaints, mostly minor.

The P2K hardware isn't super reliable either in my limited experience. I only have 4 of them in the field and all of them have suffered more than a handful of I/O card failures. I have decided that the Click or Click Plus is hardier hardware. I probably have 100 Clicks in the field and only the worst lightning storms have taken any of them out.

I doubt I'd replace a fully populated 10 slot SLC with a Click though. I have replaced one SLC rack with the newer 5069 platform and really liked it. You might be able to buy better and get it faster, but you can't pay more.

If PSuite would switch (or provide an option) to zero based bit and array addressing, I might give them another chance. I could add I/O protection and still be less expensive than anything A/B.

 

[kamenges]

Originally posted by OkiePC:

My biggest complaint about Productivity Series is that array indices and bit numbers start with 1 instead of 0.

I wonder what Marketing whiz went on vacation to Tahiti for that one.

Marketing Whiz: "I don't understand the whole 'bit 0' thing. Lets start counting at 1 instead"

Development Programmer: "You want to do WHAT?!?!"

Marketing Whiz: "Yea, Yea, everyone will LOVE it!"

There are some days I wonder.
Keith

 

[robertmee]

I wonder what Marketing whiz went on vacation to Tahiti for that one.

Marketing Whiz: "I don't understand the whole 'bit 0' thing. Lets start counting at 1 instead"

Development Programmer: "You want to do WHAT?!?!"

Marketing Whiz: "Yea, Yea, everyone will LOVE it!"

There are some days I wonder.
Keith

The old TI/Siemens 500/505 was not only 1 to 16, but reverse MSB/LSB. An integer value of 1 was bit 16.

 

[kamenges]

Originally posted by robertmee:

An integer value of 1 was bit 16.

Did it actually store bits in bytes in that order or did it just refer to bits in a different order than others? Said another way, if a TI505 series plc sent a byte with a value of 1 to another non-TI plc, would it show up as 128?

I have swapped my share of bytes and words to get numbers to come up right but never bits.

Back to the OP. I have had pretty solid luck with the L8X so far. But we haven't been using them real long. When you say "not built like they used to be" do you mean L8X relative to L7X or do you mean CLX relative to SLC5? I haven't seen any specific indication that the L8X is less durable than the L7X. I don't think we have enough time in yet to know if the longest lived CLX will outlive the longest lived SLC5. I do know we have quite a few L55 plcs out there that are still plugging along. But that is all anecdotal. I don't have hard data on this stuff.

If you have the time and can absorb the expense I would definitely rewrite the plc program from scratch. I have never used the conversion tool on a SLC to CLX conversion but I have touched the result after the fact on a couple of occasions. It isn't the easiest thing to work with. To make it relatively usable I think you would need to go in after the fact and make sure stuff is commented as well as is needed to make the result readable.

Keith

 

[ASF]

I've put in a lot of L8 processors in the last few years and have no complaints at all so far. I agree with robertmee that I'd rewrite the program from scratch, especially if you've got Ignition sitting voer the top - proper use of UDT's/AOI's makes Logix/Ignition integration gloriously easy.

 

[the_msp]

I've put in a lot of L8 processors in the last few years and have no complaints at all so far. I agree with robertmee that I'd rewrite the program from scratch, especially if you've got Ignition sitting voer the top - proper use of UDT's/AOI's makes Logix/Ignition integration gloriously easy.

Well, isn't there like an 86-page PDF manual stating the quirks between L7x and L8x?

I was referring to the new hardware in general, compared to SLC maybe rather than PLC5. 5069 cards, off the top of my head, were very prone to noise etc?

If I do go AD, I might use some form of other IO on E/IP.

Haven't used the P2K yet, done several projects with P1K (mapped to Ignition), and no complaints - so far.

 

[robertmee]

Did it actually store bits in bytes in that order or did it just refer to bits in a different order than others? Said another way, if a TI505 series plc sent a byte with a value of 1 to another non-TI plc, would it show up as 128?

I have swapped my share of bytes and words to get numbers to come up right but never bits.

Back to the OP. I have had pretty solid luck with the L8X so far. But we haven't been using them real long. When you say "not built like they used to be" do you mean L8X relative to L7X or do you mean CLX relative to SLC5? I haven't seen any specific indication that the L8X is less durable than the L7X. I don't think we have enough time in yet to know if the longest lived CLX will outlive the longest lived SLC5. I do know we have quite a few L55 plcs out there that are still plugging along. But that is all anecdotal. I don't have hard data on this stuff.

If you have the time and can absorb the expense I would definitely rewrite the plc program from scratch. I have never used the conversion tool on a SLC to CLX conversion but I have touched the result after the fact on a couple of occasions. It isn't the easiest thing to work with. To make it relatively usable I think you would need to go in after the fact and make sure stuff is commented as well as is needed to make the result readable.

Keith

When reading or writing a TI integer to AB integer the entire iNT value is the same....32767 = 32767. But if you examine the bits between TI and AB, bit 1 to 16 in TI are bits 15 to 0 in AB. So if in your TI program you have V100.1 set for an alarm, and read V100 in AB, the 15th bit is set, MyINT.15.

If you examine the value of 4 in an INT in TI as binary, it's 1100000000000000. I always heard it had something to do with the Motorola processor used at the time.

 

[ASF]

Well, isn't there like an 86-page PDF manual stating the quirks between L7x and L8x?

I was referring to the new hardware in general, compared to SLC maybe rather than PLC5. 5069 cards, off the top of my head, were very prone to noise etc?

If I do go AD, I might use some form of other IO on E/IP.

Haven't used the P2K yet, done several projects with P1K (mapped to Ignition), and no complaints - so far.

I've seen a few posts about problems with 5069 cards, but I've used a lot of them and never myself experienced an issue, so I can't comment.

Yes, there are some significant differences between the L7 and L8 processors (same as between the 5370 and 5380 Compact Logix), and as far as I'm concerned, they're all changes for the better. There are many neat things about the L8 series that I wish were backward compatible with the L7 series - there's a few things I'd like to be able to roll into my standard AOI's but can't because they would only work on an L8 (or 5380) processor, and I'm still working with a lot of 5370 processors.

From a hardware perspective, it's hard to say just how reliable they are, because I wouldn't consider it "reliable" until it's been running without issue for at least 10 years, and I've only been working with the L8's for 5-6. That said, I haven't experienced any failures or undesirable behaviour in that time, so, so far so good. My personal perception is that the 5580 and 5380 hardware is built somewhat more robustly than the 5570 and 5370 equivalents, but I'm basing that entirely on how they feel to pick up and install in a control panel, not a "tear down and see how well it's been assembled" thing, so again, that's more anecdotal than anything.

 

[dummy_bit]

The 500>5000 conversion tool sucks as a maintenance standpoint. All the SLC data tables are turned into individual tags which becomes confusing to the average maintenance person just using it to troubleshoot. If its a small enough program, I just convert it from scratch. Although we have had SLC > CLX programs come in from OEMs....

 

[joseph_e2]

I've seen programs converted from 500 to 5000....and when I upgraded from PLC5, I transcribed it by hand after going through and eliminating obsolete code. It was a fairly extensive system and took a few days to convert but ended up way more streamlined than before. For something that's going to be running for years and years it makes sense to invest a couple of days up front.

 

[the_msp]

Has anyone got any direct experience with Phoenix Contact AxioLine Remote IO. Either Ethernet/IP or ModbusTCP.

https://www.phoenixcontact.com/en-g...-systems#ex-content-transclusion-snippet--682

I use a stack of PT terminals, distribution, relays. Call me a push over, but I like push in.

 

[padees]

Has anyone got any direct experience with Phoenix Contact AxioLine Remote IO. Either Ethernet/IP or ModbusTCP.

https://www.phoenixcontact.com/en-g...-systems#ex-content-transclusion-snippet--682

I use a stack of PT terminals, distribution, relays. Call me a push over, but I like push in.

No direct experience with what you ask, but I have had a number of issues with Phoenix lately. It seems like they don't care on what they provide to customers. Quality has been really bad on what I usually use, but that doesn't mean you will have the same issues.