JSR - Did not pass as many parameters

[jimdi4 2]

Hello, I had converted a working PLC 5 program to Contrologix. Now every time I tried to put the Contrologix program in RUN mode I get a MAJOR FAULT. (Type 04) Program Fault (can be trapped by a fault routine) (Code 31) JSR or RET did not pass as many paramters as expected. Task MAinTAsk Program MainProgram Routine WARNING_HANDLER Location Rung 0 Heres what rung 0 looks like: SBR Warning_Number The JSR WARNING_HANDLER (as Ron B puts it) is knocking on the SBR door called WARNING_NUMBER. There is a RET at the end of the routine as well. I looked at the PLC 5 program and noticed there are input parameters on all of the JSR's called WARNING_HANDLER; doing a cross reference on WARNING_HANDLER I find that all have input parameters starting with 400 incremeting by one... so one is 400 ,next is 401 etc. The way around this, or should I say the way to eliminate the MAJOR FAULT is to remove the input paramters on the JSR's and delete the SBR and RET in the routine...BUT I am not sure if this is the correct thing to do....ANY suggestions? I also tried to add 400 to the first JSR input parameter and put back the SBR and RET but I get the same result MAJOR FAULT....Is Contrologix not liking the "400" number for the input paramaters that was coded in the PLC 5 code?... I also have a FAULT ROUTINE that is coded the same but the input pararmters start with smaller values such as 1- 100..This does not cause any issue though.... Thanks in advance Edited 6 Aug 2010 by jimdi4

[TConnolly 13]

Are you passing a constant to the subroutine? Double click on the rung number next to your rung to open the mnemonic editor. You should see a line that looks something like this: JSR WARNING_HANDLER 1 400 The JSR instruction requires a parameter that tells the compiler how many input parameters to expect to pass to the subroutine. In this case it expects 1 parameter. If you see JSR WARNING_HANDLER 400 then the compiler is expecting 400 parameters and finding none. Usually when you are passing tags the compiler can infer what you are trying to do but it could be possible that it is having difficulty with the constant.

[jimdi4 2]

Thanks for your reply and tip...Keep in mind I removed the instruction parameters from al the JSRs now... so when I double clciked on the line I saw JSR WARNING_ HANDLER 0 BND. I reinserted the 400 input parameter and downloaded the code - NO MAJOR Fault. - However I deleted the Input parameter tag called Warning_Number from the SBR. When I re-entered the tag Warning_Number and re- downloaded it again, and tried to go to run, i faulted in the same Major fault as before... Can I just run w/o the parameters? The parameters appear to be just markers for the JSR's...In other words they appear to be just numbered values for each JSR thats being used..... The warnigs appear to be FIFL ing correctly...Maybe I'll just use the SBR w/o any parameters... Edited 4 Aug 2010 by jimdi4

[TConnolly 13]

Can you post a copy of the program that is giving you the problems?

[jimdi4 2]

Check your PM

[paulengr 44]

The most common use for a JSR is simply to use it as a "GOSUB"...that is, the parameter passing capability is not used. In other words, it's an organizational tool, not a subroutine call. Logix 5000 programmers seem to be for the most part following this same trend. If they do parameter passing at all, it's the ones that are playing with AOI's (add on instructions). I can think of precisely two reasons to use parameter passing. First is data encapsulation. You could send data from one part of the program to another and "hide" the details. This is the #1 reason that parameter passing and functions are used in procedural computer languages. Second, you can call the same code from several different parts of your program with different parameters to have it do different functions. Sort of like a primitive version of AOI's. This would be useful and could work, except that very, very few PLC programs ever have code which is standardized enough to make this work. Quite often other techniques such as indirect addressing do a better job. Since the parameters were limited to pass-by-value (numbers), you really could not patch much data either. So even if you used it, the subroutine would just end up referencing the same global memory...which completely destroys the whole point of doing it. To make matters worse, there is a very large execution time penalty with JSR's on PLC 5's and SLC's. So the only way this matters is if memory is very critical. In 14 years and various plants and equipment I've only ever seen the JSR function used ONCE with parameters. However, it called a 3 rung ladder and it was called only ONCE from the main program. It was doing a math function and it obviously looked like calling a subroutine would be the right way to do it, IF it was at least called more than once. My advice is to delete the parameter calls if they aren't being used, and rewrite them even if they are. Some quick cross reference checks on the PLC should reveal whether or not they are being used (and you said they aren't). ControlLogix has real program-scoped tag names which allows you to do some real data encapsulation. If you want to go even further, AOI's allow you to encapsulate everything except for UDT's...if they ever make a way to encapsulate UDT's and AOI's into a single file, we will finally have true "routine library" capability.

[jimdi4 2]

Thanks Paul, Removing the input parameters DID NOT appear to hurt any thing and I no longer get the major fault. Ok thats a great explanation on how JSR's operate but I'm still at a loss on why the major fault? i was just wondering why I was getting this fault in the first place??? Since I also have a fault routine that is basically coded the same (This was converted from a PLC 5 program that someone else did) and is functioning fine w/o any major faults.... (See original post at beginning of thread)

[paulengr 44]

PLC-5 has the ability to pass parameters. Logix 5000 doesn't. So if you run the automated conversion program, this is yet another area where you have to "fix" the code to get it to run. By the way, even though most PLC programmers don't use the parameters, there is a little "gotcha" built into Logix 5. Normally when you use the "point-click" interface in Logix for any version and any instruction, it pops up little question marks wherever you have to fill in something. The JSR in Logix 5 always shows up with at least TWO question marks. The first one is the ladder to call. The second is for OPTIONAL parameters. But it looks like the first parameter is not so optional and if you don't know any better, you end up putting one in. If you use the TEXT interface, then it's JSR x y ? ? ? ? ? where x is the ladder number to call, y is the number of parameters (0 is a valid answer), and then you add in as many parameters as needed. The point-click stuff is so completely incorrect here that I always just type in JSR's as standard practice. Then again, I learned how to program AB PLC's on AI which was DOS based.

[OkiePC 14]

Logix 5000 does allow passing parameters, but it defaults to not even showing them when you type JSR. If you drag and drop the instruction from the palette, it will show the fields for one parameter. Most likely the original problem was caused by a mismatch in the number of parameters, or the data type. Perhaps the conversion utility changed a SINT to a DINT on one end of the JSR/SBR pair?

[jimdi4 2]

Now thats interesting...but the input parameter is just a number constant like "400" ...there are allot of JSR's starting with input parameter going up to 300... the previous programmer used quite a few... I believe the input parameter was not used as a parameter pass so to speak but just to number the amount of JSR's used...1- 300 for Faults 400-450 for warnings... **Paralleled them across each output that produced a fault or warning tag and then wrote to a waring and fault handler for the date and time of the fault or warning stack...up to 10... The code for the Waring and fault is very similar code, (See above**) however, the fault stack does not fault and I am still using the input parameters on the fault JSR's without a problem.... Here's something from the Program Control Instructions Clogix book Do not use a JSR instruction to call (execute) the main routine. • You can put a JSR instruction in the main routine or any other routine. • If you use a JSR instruction to call the main routine and then put a RET instruction in the main routine, a major fault occurs (type 4, code 31). I do have a JSR in the main but its calling the Warning w/o a RET. The JSR instruction jumps execution to a different routine. The SBR and RET instructions are optional instructions that exchange data with the JSR instruction. As stated earlier to get around the major fault; remove the input paramters on the JSR's and delete the SBR and RET in the routine or leave the input parameters (just found this out today) and just simply remove the SBR and RET in the called routine, since the END does the same as RET anyway and the SBR is now considered Optional....This kept the processor from faulting any further. Ok that was the solution to the problem but I still don't understand what is meant by A Major Fault Will Occur If Fault Type Fault Code JSR instruction has fewer input parameters than SBR instruction 4 31 Edited 6 Aug 2010 by jimdi4

[paulengr 44]

The number of parameters (and their data type) if used, must match exactly in both the JSR and the corresponding SBR instructions. If not, then the processor does not know what to do with either the "extra" or "missing" parameters.

[OkiePC 14]

In the program that causes the fault, how exactly were the JSR and SBR/RET instructions set up? Since you were passing a constant, I believe that Logix5000 would consider that value to be a DINT, but I may be wrong, and I have no idea what the conversion utility would do to the data type for a constant from a PLC-5 program. Perhaps it treated it as a SINT. Logix5000 will not do any type conversion on the parameter, it is considered the same as a copy. You will not get an error if you pass too many parameters, the extra ones will be ignored. You will get an error if the JSR is passing too few parameters, and probably get an error if you are passing a 16 bit SINT to an SBR which expects a 32 bit DINT. I would look closely at the number and data types of parameters in the JSR, SBR and RET instructions.

[jimdi4 2]

The input parameters were stricky some number constant not even a tag name like everyone is thinking....The constant(s) don't even show in the tag database, so perhaps they are being ignored....during conversion The SBR's input parameters though reference a tag name (DINT) in both instances of the Warning_Handler routine as well as the Fault_Handler routine... Warning Handler SBR references the tag Warning_Number (DINT) and Fault_Handler SBR references tag Minor_Fault_Number The RET has no input parameters...Now keep in mind the Fault_Handler routine doesn't cause the fault....Yet its exactly coded (I think) the same exact way... Edited 6 Aug 2010 by jimdi4

[paulengr 44]

It creates a bunch of arrays of DINT's with names like "I", "O", "N_7", etc. It puts comments in for instructions like MSG and any references to the S (status) registers since those pretty much don't easily translate at all. Most conversions I've seen done fix up these little spots. The IO references point to the generic image tables (I, O). If you do the right thing, you need to go through your new/old IO and point the I, O references to their appropriate reference points. In addition, you have to be very cognizant of and watch out for logic hazards. In a ControlLogix PLC (and unlike any of AB's other PLC's), an IO tag can change value DURING program scan because the IO scanner operates independently of the program scanner. So if the program reads an input in more than one place in the program, it is very important to take a look at what would happen if the value of the input is different in both places. 99% of the time this is OK. It's the 1% that you have to watch out for. An even better approach is not to use the translator at all but to recode the whole program in Logix 5000 to take advantage of the better tools for program organization. However, most programmers take the quick way out and simply put in a "translate" routine that does array copies from the actual Logix 5000 data tables (Local...) into the I and O image tables, and leave the rest of the code pretty much intact, warts and all. This solves two problems. First, there is no need to go through the whole program line-by-line looking for IO references. Second, it eliminates the logic hazard problem. But it introduces an even bigger problem: maintenance hours. Every time you go to troubleshoot a routine, you have to search through the program and the data copying to figure out where the "real" IO is actually at. It is easy enough to do but has to be done on almost EVERY troubleshooting call. This adds lots of time (and money) to equipment maintenance, something which is much more expensive than the time spent fixing this problem up front when the program is offline. Don't get me wrong here...yes, there are some very creative ways to label things to make the job easier, but it should not be that way in the first place. As Mike says, do it right the first time. I've inherited several programs like this. After dealing with programs that have been translated and looking at what you get for an output, I'm convinced that the translator doesn't save any time at all. The amount of debugging on a "new" program seems to be just about as much as on the translated program, and there are many opportunities to do some "cleanup" in the process. After 5 years or so, most programs have at least 10-20% unused/bypassed sections and lots of "don't use that anymore" stuff unless they are really, really simple. Best approach is to simply rewrite the whole program. I know that it sounds like you are saving debugging time, but you aren't. Actual experience seems to be that the IO checkout and startup times are identical with new vs. "translated" programs. The translated programs also turn into much longer downtimes down the road because they are tougher to troubleshoot.

[jimdi4 2]

<Resolution> I was able to get rid of the major fault...I had a JSR in the Main program also referencing the other JSR called program. (Warning_Handler)...Now this is strange but seem to have fixed it...I deleted the JSR in the Main program....Added the Input pararmeters back to all the original JSR's and then downloaded the program. NO Major fault anymore. Ok , so I put back the JSR I deleted from the Main program , then added an input parameter to it , and downloaded, and CPU went back to RUN mode w/o any major fault....Go Figure!!! Jim Edited 12 Aug 2010 by jimdi4

[ratcliffe_ic 2]

Just done the exact same thing myself, whilst checking through a CLX program was looking at JSR's in the main program and noticed one was missing, stuck it in thinking I'd forgotten about it - processor faulted same fault as you. On careful inspection the subroutine was called elsewhere passing two parameters. If your converted program had the JSR in the main program, PLC5's must have been able to handle the fact you called it without parameters where as the CLX is not so forgiving and requires the parameters are present. Edited 13 Aug 2010 by ratcliffe_ic