RSLogix5000 App: Function Blocks Not Excuting

Join Date
Dec 2016
Location
Southeast
Posts
134
Just downloaded an existing app to this Controller and I can see instrument inputs changing in the tag list when I go online, but the clock is not updating. The code uses a "GSV" Function Block to fetch "WallClockTime" and store it in a "DateTime" array. When I manually change one or more of the DateTime array values, I notice that a series of "MOV" Function Blocks, which move each part of the time into individual tags called "PLC_YEAR_NOW", etc. don't change ... meaning - the function blocks aren't executing.

I checked the "Properties" under this "MainTask" and it shows up as type "Continuous". Others have a green clock icon and are defined as "Periodic".

This *was* working, but someone here tried re-loading it, and when it 'failed during the download', he suddenly had to leave for the day because he was 'out of hours' (hourly) ... LOL!

Any ideas?

Also - I see 62 warnings during the download ... mostly "Warning: Rung XX AFI detected", but also a few "Shorted branch detected". Are these just typical minor issues that compilers like to spew out, but which can be ignored (for the most part)?
 
Last edited:
AdrianC:

Thanks! Putting it in Remote Run did it!

proof:

yeah, I could see the call *from* "MainRoutine", so I knew it was being called.

============

I was confused because I could see the I/O inputs updating, so I *thought* I was running. You're not "fully running" until you are in "Remote Run" and you see the green bars to either side, I guess ...
 
Last edited:
You're welcome.

When there's a failure during a download it leaves the PLC in program mode and doesn't ask you to switch back to run mode.
 
"Are these just typical minor issues that compilers like to spew out, but which can be ignored (for the most part)? "

NO !, it is not that the compiler likes to spew these warnings out, the compiler is doing a very good job in issuing warnings that the program has been "compromised".

AFI's : Someone has edited the original program by inserting AFIs in rungs, or branches, to make the following output instructions false, making the original coding redundant.

Shorting Branches : Someone has edited the original program by DEFEATING an instruction that needs to be true to make the rest of the rung work. The instruction(s) that has been "shorted out" may be an interlock or something else that is necessary, that didn't work properly at commissioning, so they just shorted it out, possibly compromising lots of desirable things.

IF
the program is now working as required...


IF all system interlocks perform as designed or to requirements...

IF you can't get the original programmer/commissioning engineer/maintenance engineer or whoever put the AFIs/Shorts in the program to explain why they are even there...

IF (there's probably more I haven't thought of)...

THEN you might want to think about "cleaning" it, by getting rid of rungs or branches that are AFI'd, and removing the branches that are branched out with shorting branches.

Take notice of the big IFs above, I deliberately made them big to emphasise their importance....

only do this clean-up if you are 100% happy with the execution of the code as it is.

At the very least you should inspect each occurrence of AFI and branch short, to determine if required functionality or interlocking has been compromised in the past.

When I was a lead software engineer, I absolutely would not let AFI's and shorted branches exist in the programs, ever, even during development.

Each software/commisioning engineer had his own personal flag-bit, which was always asserted false every scan. He/she could use that bit to make rungs/branches false (using XIC), or to put on a shorting branch (using XIO).

Having a unique named tag for each engineer allowed them to cross-reference their own personal AFI's and shorts to finalise their code, and allowed me to police their use. Every morning I would do a Verify, and if any AFI instructions, or shorted branches were found, I would simply delete them. My software guys quickly learned to use their own flag-bits when they wanted to "mark" a place in the code that needed their attention.

Of course, that was during the development/testing cycle, and all of those pseudo AFI's and shorts would never be left in a final, commissioned job.

Apologies for the shouting above - but this is an area I do feel strongly about. If ever I encounter an AFI or a shorting branch, I just know that it won't be documented, I'd have no idea why they are there, or who put them there, when they were put in etc.
 
daba:

I hear ya! I'm not a PLC programmer, but I *do* write very clean source code on other platforms - which certainly means no compiler warnings and hopefully no cautions, either. When I see them in someone else's work, I tend to just shake my head and look the other way, mostly because like you say - if you're not familiar with the logic and careful doing the cleanup, you *could* potentially introduce a problem. I didn't write this Thermal Oxidizer PLC program, it's fairly large, and since it's very critical to Operations here, sadly, I don't think I'll be "cleaning it up".

But thanks for the reply.
 
Sounds like a "I don't care what you do, just get the thing working now!! Fix it up later!" type of operation.

Years ago I worked in the Defense Industry where every line of code was scrutinized. No such thing here in the Big Pharma commercial world. We *do* write Functional Specs, and we *do* write Test Procedures and execute them, but nobody's reviewing anybody's code to see if it meets any kind of standard.

And I would bet that it's the same way at most places.
 
AFI's and shorted rungs can be nice when multiple people out in the field, if they are used with caution. But first, the program needs to be cleaned up so that there are no AFI's or shorted rungs. The AFI's could be replaced with a XIC ORIG_AFI where ORIG_AFI is false, and shorted rungs are replaced with XIC ORIG_Short where ORIG_Short is set true, or some other scheme.

Then, if a night man were to add a short or AFI, and forget to tell you about it, you are much more likely to find it, due to the warnings they generate, induce you to investigate why the changes were made, and see that the problems fixed correctly. If the code is not clean to start with, then additional AFIs and shorts add to the cruft, and keep you from noticing new warnings. If it turns out the 'temporary fix' to be something that is not going to get fixed (in a reasonable amount of time), the code should be changed to get rid of the AFIs and shorts.

I'd use AFI and shorts for development and testing, but only if I was the only person doing the development and testing. And they are all removed in short order.

As an end user, I review a lot of code. While some code is absolutely brilliant. Most only provides the minimal functions needed to run (but does not provide diagnostic information when there are equipment failures). Unfortunately, since most review is done because there is a problem in the field that needs to be diagnosed or circumvented, it is much more likely that the problem is in crappy code. There is a lot of code that was (and will be) written by developers whose goal was to get a system up and running, but not much more than that.
 
Many things chap my a$$ when troubleshooting other people's code...afi's, short circuit branches and a hundred unused tags in the tag database. Add to that program scope tags for no reason and a thousand minor errors due to careless divide by zero math.
 
Originally posted by robertmee:

...and a hundred unused tags in the tag database. Add to that program scope tags for no reason ...

Remove "unused" from the first sentence fragment above and you will find why I disagree with the second sentence fragment above.

While I generally agree with daba's post above I think the necessity and utility of the point is tied pretty strongly to machinery lifecycle. In addition there is a very strong dependence on documentation in order for the unique marking of modifications to be useful.

A program should not make a lifecycle transition with any type of jumper or block in place. If a jumper or block is put in during development segment the program should not leave development with that jumper or block in place. If the jumper/block is still in place the program is still in development. The exception would be transitioning into decommissioning, where it doesn't matter anyway.

Furthermore, given the frailty of the human memory, uniquely identifying a jumper/block (or even uniquely identifying the INSTALLER of the jumper/block) doesn't have much usefulness unless the reason for the jumper/block is recorded somewhere other that the installer's neural pathways. Otherwise the reason for the modification will be lost in pretty short order. This is most important with larger projects with longer development cycles but is really valid for any project.

Keith
 
Furthermore, given the frailty of the human memory, uniquely identifying a jumper/block (or even uniquely identifying the INSTALLER of the jumper/block) doesn't have much usefulness unless the reason for the jumper/block is recorded somewhere other that the installer's neural pathways. Otherwise the reason for the modification will be lost in pretty short order. This is most important with larger projects with longer development cycles but is really valid for any project.

Keith

I just liked to "kick a$$" - that's why each programmer/commissioning engineer had his own "bit" to use as AFI and shorts. At least I could kick the right person's a$$, even if he couldn't remember why they were in the program, but it was still his responsibility to remove them, and if it meant him back-tracking to work out why they were there, then so be it.
 

Similar Topics

Hi guys, Just viewed an app a guy developed which allows you to develop all your Logix5000 code offline and import to .acd. Nice interface which...
Replies
5
Views
2,485
Hello everyone, I have an RSLogix5000 project which is running live in the factory but I need to make some changes to the logic. I want to test...
Replies
0
Views
1,097
Good Morning Everyone, I'm looking to use the GSV instruction to get I/O fault codes for my project so I know if there's a comms issue in my E/IP...
Replies
5
Views
810
The machine is running production. When trying to go online with the laptop the whole machine looses communication and faults out. Drives, HMI...
Replies
13
Views
1,867
Hello, is it possible to create a data block, something like shared datablock in Siemens STEP 7, in the RS Logix5000 PLC project? I would like...
Replies
3
Views
1,049
Back
Top Bottom