Troubleshooting JSR with parameters

Hi all. I have a Control Logix system controlling our coal conveying system. Each conveyor and piece of equipment has a separate routing in the program,however, the conveyor/machine status and alarming is combined into 3 separate status routines. They are using JSR's with parameters to jump out of a conveyor routine, check for faults and give status updates to the HMI, then jump back into the conveyor routine and finish the scan. After studying the logic, I understand how it works, and why they wrote it (I wouldn't do it), but I'm wondering how to troubleshoot it. While in a status routine, every bit and timer is constantly changing states and values. If I'm trying to see what or why a particular conveyor is shutting down or alarming, how is the best way to view it alone.

This is a bad practice for the very reasons you are discovering. Subroutines with passing parameters have their place but, this is not one of them.

There is no neat way to troubleshoot one conveyor's logic. If you want to troubleshoot just one conveyor, you could replicate the JSR'd routine with all new tags and change the JSR for that one conveyor to use your newly replicated routine and new tags instead of the original one. As long as you have only one conveyor using this new routine, you can monitor the new routine and expect to be monitoring logic for one conveyor only.

Depending on the version of CLX you could convert the routine to a AOI (Add On Instruction), you will then be able to view the status of each call.

chadhoot78 said:

Hi all. I have a Control Logix system controlling our coal conveying system. Each conveyor and piece of equipment has a separate routing in the program,however, the conveyor/machine status and alarming is combined into 3 separate status routines. They are using JSR's with parameters to jump out of a conveyor routine, check for faults and give status updates to the HMI,(1) then jump back into the conveyor routine and finish the scan. After studying the logic, I understand how it works, and why they wrote it (I wouldn't do it), but I'm wondering how to troubleshoot it.(2) While in a status routine, every bit and timer is constantly changing states and values. If I'm trying to see what or why a particular conveyor is shutting down or alarming (3), how is the best way to view it alone.

Click to expand...

(1) - The subroutine is checking for faults and reporting them to the HMI - why do you need to look in the code?
If the information provided to the HMI by the PLC code is not enough, then the PLC code is incomplete and badly written.

(2) - You shouldn't have to troubleshoot "function code" - once written, tested, and accepted as a function, then its internal workings are largely irrelevant.

(3) - I said before, the function-code should be telling you this information, without having to dive into it to watch bits going on and off.

Summary - the use of subroutines as Function-Code is perfectly acceptable, provided that it they give out enough information so that you don't have to look at it. If you do have to look at code, because it doesn't tell you why a motor or valve has alarmed, then it isn't doing a very good job. Perhaps it needs additional functionality, such as multiple alarms per device, or an error code, to give to the HMI.

Why do i want to look at the code you ask? How about BECAUSE I WANT TO! If you aren't going to reply to legit question somebody asks with an intellgent answer then stay off the forum. It's a waste of my time to read it. Nobody said sh!t about troubleshooting the "logic"! Most people watch logic in real time to find problems in the process faster

chadhoot78 said:

Why do i want to look at the code you ask? How about BECAUSE I WANT TO! If you aren't going to reply to legit question somebody asks with an intellgent answer then stay off the forum. It's a waste of my time to read it. Nobody said sh!t about troubleshooting the "logic"! Most people watch logic in real time to find problems in the process faster

Click to expand...

After a rant like that, do you really expect anyone to waste their time giving you any help? I didn't agree with everything in daba's post either, but it certainly didn't warrant that kind of response.

kolyur said:

After a rant like that, do you really expect anyone to waste their time giving you any help? I didn't agree with everything in daba's post either, but it certainly didn't warrant that kind of response.

Click to expand...

+1
nicely put - I find that being polite usually gets me better results and usually in a shorter time frame. Plus I am happy to go back to them and ask again for support

I agree. Daba's post was just giving some good general information about that style of code and some general reminders and thoughts.

Great post from daba IMHO.

Daba's advice is good, but actually, MattReardon's is the best.

Take some time, simulate everything (in emulator or run it on a spare rack and CPU), and convert all of the parameterized subroutines to AOI's.

With an AOI, you can actually view each instance individually if you must for troubleshooting, without the interactions of having the logic try to process twenty different instances. They are also NON-EDITABLE at runtime, which is a good thing (even for parameterized Subroutines). It sucks to 'fix' a problem related to one call, only to have it crash the other 5, or 10, or 100.

I had a whole panel board line where they were doing the same thing with subroutines and moving data into common fault words. I learned a few things:

1. Limit switches, speeds,analog stuff-it was always somewhere in the program as a constant. If by chance i had trouble, i would one shot the info into a temporary register.

2. Although it may came across wrong-Daba has a point that i would have to convince others at times- if the gears been functionally tested and checked, use the HMI alarms to troubleshoot the problem- at times, it's much less confusing.

daba said:

You shouldn't have to troubleshoot "function code" - once written, tested, and accepted as a function, then its internal workings are largely irrelevant.

Click to expand...

This statement is the only issue I had with daba's post. In my experience, there's not much that's exempt from troubleshooting. It is often difficult to test a portion of code for all possible combinations of inputs or arguments. And if the person troubleshooting is not the person who originally wrote and commissioned it, he has no idea how (in)comprehensive that testing might have been.

kolyur said:

This statement is the only issue I had with daba's post. In my experience, there's not much that's exempt from troubleshooting. It is often difficult to test a portion of code for all possible combinations of inputs or arguments. And if the person troubleshooting is not the person who originally wrote and commissioned it, he has no idea how (in)comprehensive that testing might have been.

Click to expand...

And OTOH, I fully support that statement. Any bit of code that is usable enough to become a parameterized subroutine (or better, AOI) should be viewed as a canned function.

It should be rigorously simulated, and tested, in a stand alone format before being code-locked, and should not require any internal modifications for 'Special Cases'. Once code-locked and released into the wild, any editing on the logic can be disastrous.

Canned logic, either PSR or AOI, should NOT be overly complex. Most of my AOI's total under 25 rungs. More complex ones I'll usually look at seriously to see if they should be AOI's; not all code is candidate to become a user-defined function.

The way I deal with them is essentially the same as I deal with built in functions - A good example might be AB's Sequencer functions... They are handy, and 95% of the time they can be used to simplify code. Then again, that last 5% of the time, you need to roll up your sleeves, and roll your own, not try to 'adapt' or 'fudge' the existent instructions into trying to do something they aren't designed for.

IMHO, of course.

rdrast said:

And OTOH, I fully support that statement. Any bit of code that is usable enough to become a parameterized subroutine (or better, AOI) should be viewed as a canned function.

It should be rigorously simulated, and tested,

Click to expand...

I agree, and would only add fully documented as well. PSR and AOI can be used improperly, but for a standard bit of tested code, As long as it is known what it is doing, how should be of little consequence.

As long as the IO and the machine functions are known, often a PC is not needed. Especially on Small machines, and those with an HMI

MattReardon said:

Depending on the version of CLX you could convert the routine to a AOI (Add On Instruction), you will then be able to view the status of each call.

Click to expand...

we have a system designed in India that calls the same subroutine with parameter more than 70 times, so I converted that subrutine to a AOI and my problems disappeared.