You are not registered yet. Please click here to register!


 
 
plc storereviewsdownloads
This board is for PLC Related Q&A ONLY. Please DON'T use it for advertising, etc.
 
Try our online PLC Simulator- FREE.  Click here now to try it.

---------->>>>>Get FREE PLC Programming Tips

New Here? Please read this important info!!!


Go Back   PLCS.net - Interactive Q & A > PLCS.net - Interactive Q & A > LIVE PLC Questions And Answers

PLC training tools sale

Reply
 
Thread Tools Display Modes
Old January 6th, 2017, 04:19 PM   #1
SoftwareJanitor
Member
United States

SoftwareJanitor is offline
 
Join Date: Dec 2016
Location: Southeast
Posts: 93
RSLogix5000 App: Function Blocks Not Excuting

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 by SoftwareJanitor; January 6th, 2017 at 04:25 PM.
  Reply With Quote
Old January 6th, 2017, 04:21 PM   #2
AdrianC
Member
United States

AdrianC is offline
 
Join Date: Jan 2017
Location: Ohio
Posts: 5
PLC is in program mode?
  Reply With Quote
Old January 6th, 2017, 04:26 PM   #3
proof
Member
United States

proof is offline
 
Join Date: Jan 2014
Location: Illinois
Posts: 110
Make sure the routine is called if it is not main routine in the task.
  Reply With Quote
Old January 6th, 2017, 04:28 PM   #4
SoftwareJanitor
Member
United States

SoftwareJanitor is offline
 
Join Date: Dec 2016
Location: Southeast
Posts: 93
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 by SoftwareJanitor; January 6th, 2017 at 04:33 PM.
  Reply With Quote
Old January 6th, 2017, 05:03 PM   #5
AdrianC
Member
United States

AdrianC is offline
 
Join Date: Jan 2017
Location: Ohio
Posts: 5
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.
  Reply With Quote
Old January 6th, 2017, 08:48 PM   #6
daba
Lifetime Supporting Member + Moderator
United Kingdom

daba is offline
 
daba's Avatar
 
Join Date: Jul 2004
Location: uk
Posts: 3,745
"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.
__________________
___________________________
ControlLogix & SLC Training
a-b train ltd.
abtrain@tiscali.co.uk
www.abtrain.co.uk
tel: 07506 73 9999
nil illegitimi carborundem


  Reply With Quote
Old January 7th, 2017, 02:51 PM   #7
Colt Hero
Member
United States

Colt Hero is offline
 
Join Date: Apr 2015
Location: USA
Posts: 9
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.
  Reply With Quote
Old January 7th, 2017, 03:12 PM   #8
bernie_carlton
Lifetime Supporting Member + Moderator
United States

bernie_carlton is offline
 
bernie_carlton's Avatar
 
Join Date: Apr 2002
Location: Yakima, Washington
Posts: 6,076
Sounds like a "I don't care what you do, just get the thing working now!! Fix it up later!" type of operation.
__________________
Controlling outputs is the PLC's way of getting its inputs to change.

www.thePLCguy.com
  Reply With Quote
Old January 9th, 2017, 03:58 PM   #9
SoftwareJanitor
Member
United States

SoftwareJanitor is offline
 
Join Date: Dec 2016
Location: Southeast
Posts: 93
Quote:
Originally Posted by bernie_carlton View Post
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.
  Reply With Quote
Old January 9th, 2017, 05:17 PM   #10
proof
Member
United States

proof is offline
 
Join Date: Jan 2014
Location: Illinois
Posts: 110
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.
  Reply With Quote
Old January 9th, 2017, 10:26 PM   #11
robertmee
Member
United States

robertmee is offline
 
robertmee's Avatar
 
Join Date: Feb 2008
Location: NC
Posts: 1,415
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.
  Reply With Quote
Old January 11th, 2017, 12:53 PM   #12
kamenges
Member
United States

kamenges is offline
 
kamenges's Avatar
 
Join Date: Nov 2002
Location: Brillion, WI
Posts: 3,604
Quote:
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
  Reply With Quote
Old January 11th, 2017, 01:44 PM   #13
daba
Lifetime Supporting Member + Moderator
United Kingdom

daba is offline
 
daba's Avatar
 
Join Date: Jul 2004
Location: uk
Posts: 3,745
Quote:
Originally Posted by kamenges View Post
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.
__________________
___________________________
ControlLogix & SLC Training
a-b train ltd.
abtrain@tiscali.co.uk
www.abtrain.co.uk
tel: 07506 73 9999
nil illegitimi carborundem


  Reply With Quote
Old January 11th, 2017, 03:03 PM   #14
kamenges
Member
United States

kamenges is offline
 
kamenges's Avatar
 
Join Date: Nov 2002
Location: Brillion, WI
Posts: 3,604
Quote:
Originally posted by daba:

I just liked to "kick a$$" ...
You're a baaaad man!!
  Reply With Quote
Reply
Jump to Live PLC Question and Answer Forum

Bookmarks


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump

Similar Topics
Thread Thread Starter Forum Replies Last Post
Multithreaded C++ into function blocks - PLCOpen EinarM LIVE PLC Questions And Answers 18 March 28th, 2016 06:37 AM
Migrating VB6 IDEA app to VB.Net Extrasoft LIVE PLC Questions And Answers 5 November 4th, 2007 06:13 AM
siemens step 5 function blocks stevelawson LIVE PLC Questions And Answers 38 February 20th, 2007 01:26 AM
Function Blocks BENNY LIVE PLC Questions And Answers 2 July 27th, 2004 09:03 AM
Siemens step 5 function blocks stevelawson LIVE PLC Questions And Answers 1 February 13th, 2004 07:43 AM


All times are GMT -5. The time now is 11:44 AM.


.