Question about which version of logix 5000 is appropriate for this situation

[Justin OtherPLC]

I'm converting 3 plc 5's to L72s. The first was converted last year using version 20. I used version 20 for this year's project, and had planned on using it for next year's conversion as well (for consistency); however, the current conversion included replacing one of the unit's VFDs with a powerflex 755 unit (it's a pretty sweet drive). I was told that version 24 integrates the drive with less hassle than the version I'm using, not that it was difficult with version 20.

The question is... is there a tangible benefit to upgrading the current conversion with a newer version of logix? If I do that then I'll likely want to convert last year's version 20 program up to the same version. The idea was to maintain consistency across the three units.

I'm a field guy and currently have versions 13 through 20 installed on my laptop. Based on what happened with version 16 (first scan bit) I like knowing that my coding won't exhibit any quirky behaviour due to unknown bugs. Version 16 bit me in the arse. I set up a routine to be placed in a certain mode whenever the processor is booted up (first scan), but found that the first scan bit kept triggering this mode. Needless to say this caused quite a few headaches. (that's when I found out that Rockwell's solution to this problem was to use one shots in place of the first scan bit... it's a non-fix fix).


Experiencing this firsthand once was enough for me.

 

[TimOB]

I converted 20 L7x processors from v20 to v24 this year. Did not have any issues. But you will want a 64 bit PC and 8GB RAM to run Studio 5000, it's a lot heavier weight than RSLogix 5000 was.

BTW v26 is available, but I have not used it.

 

[Donnchadh]

Hi

I would go to ver 24 as there is some really nice items in it and also it will allow if or when to processor needs to be upgraded or replaced open you up to a wider range

Donnchadh

 

[Ron Beaufort]

Greetings Justin ...

I don't want to hijack your thread, but frankly I'm intrigued by the following statement:

Version 16 bit me in the arse. I set up a routine to be placed in a certain mode whenever the processor is booted up (first scan), but found that the first scan bit kept triggering this mode. Needless to say this caused quite a few headaches. (that's when I found out that Rockwell's solution to this problem was to use one shots in place of the first scan bit) ...

I'm constantly on the lookout for that type of "weirdness" – but I've never even heard of that particular effect before ... can you please point me to some sort of reference on that? ... maybe a Knowledgebase number – or a forum thread – or something along those lines? ...

I did a quick search in the Knowledgebase – but (so far) I haven't come up with any recommendation to use a One Shot instead of the First Scan bit ...

thank you ...

 

[Justin OtherPLC]

Greetings Justin ...

I don't want to hijack your thread, but frankly I'm intrigued by the following statement:



I'm constantly on the lookout for that type of "weirdness" – but I've never even heard of that particular effect before ... can you please point me to some sort of reference on that? ... maybe a Knowledgebase number – or a forum thread – or something along those lines? ...

I did a quick search in the Knowledgebase – but (so far) I haven't come up with any recommendation to use a One Shot instead of the First Scan bit ...

thank you ...

Hi Ron,
I work for various oems in my niche field, and offered to work up a solution to a controls problem at one of their sites. This involved adding some actuators, and creating a simple algorithm to address the issue. I wanted the routine to work in both Auto and manual modes. To ensure the unit's default mode was Auto I wrote this simple rung:

momentary push button (RSView)         Auto-0/Manual-1 Mode
------| |-------------------------------------{OTU}
   |        |
   |        |
    ---| |---
  First Scan Bit

The Auto/Manual bit determined how the rest of the routine functioned. Manual control was enabled via a momentary push button in RSView, and it looked like this:

    momentary push button (RSView)       Auto-0/Manual-1 Mode
---------------| |-------------------------------{OTL}

When the manual button was toggled the routine would enter manual mode, and then very quickly revert back to auto mode. The code was basic, and since I created the tags I knew they weren't being used elsewhere.
I've used First Scan bits extensively in plc 5's and slc 500's, and didn't think anything of using one in this application. When I called the engineer to talk about what I was experiencing he told me that he ran into the same issue - that version 16's first scan bits behaved erratically. He said he spoke with Rockwell and they confirmed it was an issue with version 16. He said that Rockwell suggested replacing first scan bits with one shots.

I took his advice, replaced the first scan with a one shot, and the problem went away. Since then, I've always used one shots in logix 5000 where I would normally use the first scan. Fortunately, I was only 90 minutes from site, so the change was fairly easy. But I travel throughout the states, and into Canada, so there's a chance that a bug like this could be very unpleasant. This is why I'm hesitant of new versions of Logix. Airline tickets can be expensive, and VPN/Remote Desktop/Viewer/Modems aren't always an option.



I realized the code I added the first scan bit to also used one shots. That's when I realized the only first scan bit I ever saw in one of their programs was the one I had inadvertently added. Whoops. All of the new systems I commissioned also used one shots exclusively. I never saw a first scan it in any of the programs.



I wish I could give you a reference to a knowledge base article, or the Rockwell ticket number where this was discussed with the oem's engineer; however, when it occurred, I resolved it as quickly as possible, and moved on to the next issue (a start-up in this case). I took the engineer's advice, and tucked it away.




It sounds like version 24 is pretty good. With the powerflex 755 connected through ethernet, are there any concerns with how I've already set up the basic controls, and should I do anything about the additional drive status feedback I set in the module configuration?

 

[Ron Beaufort]

thank you for your reply ...

in the code than you've posted, you show an XIC referenced to "First Scan Bit" ... is that:

(1) just sample text that you've used for this discussion? ... or ...

(2) a tag that you created yourself and then used in your actual project? ... or ...

(3) the RSLogix built-in First Scan bit - S:FS ? ...

the main thing that is puzzling me (and something that I'd like to learn about) is how a One-Shot performed the desired function that you mentioned ...

in most cases, a ControlLogix/CompactLogix system will automatically write a status of ONE into a One-Shot's bit/box during Pre-Scan ... in most cases, that would prevent the One-Shot from "firing" in a "Go-To-Run" situation ...

once again, I do NOT want to hijack your thread - but this subject is "news-to-me" and I'm always eager to learn new material ...

thank you ...

 

[osmanmom]

found this on manual,but i don't understand

 

[Justin OtherPLC]

thank you for your reply ...

in the code than you've posted, you show an XIC referenced to "First Scan Bit" ... is that:

(1) just sample text that you've used for this discussion? ... or ...

(2) a tag that you created yourself and then used in your actual project? ... or ...

(3) the RSLogix built-in First Scan bit - S:FS ? ...

the main thing that is puzzling me (and something that I'd like to learn about) is how a One-Shot performed the desired function that you mentioned ...

in most cases, a ControlLogix/CompactLogix system will automatically write a status of ONE into a One-Shot's bit/box during Pre-Scan ... in most cases, that would prevent the One-Shot from "firing" in a "Go-To-Run" situation ...

once again, I do NOT want to hijack your thread - but this subject is "news-to-me" and I'm always eager to learn new material ...

thank you ...

Hi Ron,
The first scan bit is the S:FS, sorry for any confusion. An unconditioned (?) one shot will fire during the first scan, but not after that.

     one shot      Reset Timer Done Bit        Reset Timer
------[ONS]---------------[\]---------------------[TON]----
    |        |                                  |         |
    |        |                                  |         |
    ---| |---                                   ---[OTE]---
 Reset Timer Timing                           Boot-up Reset Bit

The oem uses this in units (dating back to the 90s) to reset boot up alarms. The timer will execute once. When its done bit goes true the timer's enable bit will not go true again, i.e. the timer is only enabled one time.

In the older processors they used the the PLC 5 and SLC 500's first scan bit (S:1/15) where the one shots now reside, and flip-flopped between using an xic of the ote, or the xic of the timer timing bit in the OR argument.

 

[Justin OtherPLC]

SFC: Sequential Function Charts are one of the four types of programming routines you can use. Everyone should be familiar with ladder logic, but there's also Structured Text, Function Block, and Sequential Function Charts. I've only seen ladder and function block used. I'm sure there are other uses for function blocks, but the only thing I've ever seen them used for is scaling; they replace the slc SCP (scale with parameters) argument. I snagged an add-on from someone that creates a more traditional SCP in the ladder logic. I mean, sure we can use a cpt statement to do the same thing, but what's the fun in that? hahaha..


I think structured text would be a blast to play with...... but aside from some small programming in VB, C, Python, and C/Pbasic for microcontrollers, I haven't had much experience with that style of coding. For some reason I don't think the various Hello World scripts count for anything . Ladder logic is as natural as breathing.

 

[Ron Beaufort]

An unconditioned (?) one shot will fire during the first scan, but not after that.

personally, I don't think so ...

there's something going on here - maybe behind the scenes - that's not being shown ...

I just ran the following test using a version 16.20 processor - model 1756-L55 - using RSLogix 5000 version 16.03 software ... note that this is the ONLY code in the processor ...

every time that I change the processor from Program mode to Run mode, the S:FS condition goes TRUE - and causes the ADD instruction to increase the value of TEST_S_FS by 1 ...

on the other hand, the unconditional ONS instruction NEVER goes TRUE - and so the value of TEST_ONS does NOT increase ...

this points out what I have always thought/known about trying to use an unconditional ONS instruction to "fire" once at startup ...

NOTE: with the RSLogix500 software systems, an unconditional ONS or an unconditional OSR instruction WILL "fire" once ... after that, something must then "reset" the status bit back to ZERO - or the instruction will never "fire" again ... note that this is DIFFERENT from the operation of the PLC-5 and the ControlLogix/CompactLogix systems ...

.

 

[Justin OtherPLC]

That's fascinating. I wonder if it has to do with what's being executed afterwords (the Add statement, and how that's being handled by the processor). It seems to work beautifully when latching/unlatching bits, and initiating timers.

Last week I a small glitch in someone's code. I perform a message write to the plc that contains two words: 1 - status, 2 - heartbeat timer. On their side they monitor the heartbeat timer with a 10 second watchdog. If the watchdog times out they Fill (FLL) the status word with zeros; however, they inadvertently filled the heartbeat word with zeros by mistake.
The way their logic is set up... there's a NEQ comparing the heartbeat word I send to the mirror heartbeat word (that gets overwritten if the values aren't equal). It also resets the watchdog timer.

I could watch my heartbeat word flicker in their register, but the FLL statement would execute before the NEQ statement, and prevent their watchdog timer from resetting. It was awesome. I changed their mirror heartbeat timer, and on the next scan the timer reset, and the heartbeat/watchdog portion began working properly. I ended up changing the FLL argument so that it set the status word to zeros, and not the heartbeat. That was the problem.

The crazy part was that the FLL was supposed to execute AFTER the Heartbeat check. In the left-right top-down structure you wouldn't think it would happen... but it did.

 

[Justin OtherPLC]

personally, I don't think so ...

there's something going on here - maybe behind the scenes - that's not being shown ...

I just ran the following test using a version 16.20 processor - model 1756-L55 - using RSLogix 5000 version 16.03 software ... note that this is the ONLY code in the processor ...

every time that I change the processor from Program mode to Run mode, the S:FS condition goes TRUE - and causes the ADD instruction to increase the value of TEST_S_FS by 1 ...

on the other hand, the unconditional ONS instruction NEVER goes TRUE - and so the value of TEST_ONS does NOT increase ...

this points out what I have always thought/known about trying to use an unconditional ONS instruction to "fire" once at startup ...

NOTE: with the RSLogix500 software systems, an unconditional ONS or an unconditional OSR instruction WILL "fire" once ... after that, something must then "reset" the status bit back to ZERO - or the instruction will never "fire" again ... note that this is DIFFERENT from the operation of the PLC-5 and the ControlLogix/CompactLogix systems ...

.

Holy ****, you're 100% correct! I deferred to the engineer who wrote the software, told me he'd spoken with Rockwell, and trusted his solution implicitly.

The past few weeks have been insane (clocking over 70hrs a week, hurray!).

I watched the execution of the routines to verify their operation... because you piqued my curiosity, and planted a seed of doubt. They were not executing on their own. I added a 10 millisecond timer to trigger all of my one shots. That took care of the issue; however, I've commissioned this engineer's code across the states, and into Canada. He used the one shots to initiate a boot-up fault reset, and to place the equipment in a certain mode (which, since certain conditions aren't met 99.999% of the time, normally wouldn't be able to execute).

I made the corrections on the two units I upgraded at this site, and the ten-mill trigger's working well.

But... I think I need to contact every site I've commissioned this equipment at to resolve a potentially aggravating situation. There is a risk that mechanical components may engage, but there's a very high probability that nuisance alarms will occur, to add another layer of frustration to someone's already unpleasant day.



Grumble....





...... reaches for a bottle of ibuprofen.....