error 2Ah and FIFOs RS-LOGIX 500

[DMC]

Hello all,

I am seeing a 2Ah error code in my program.

The equipment is a Micrologix 1500 Series C LRP.
The existing program is in operation and works fine.
The customer wanted to add elapsed runtime meters to the existing Panelview plus
24 hour runtime, 7 day runtime and 30 day runtime must be shown.

I created 3 FIFO subroutines that work great for the elapsed runtime of each pump.

The problem occurs when I bring the new subroutines into the existing program, I get the 2Ah error (An indexed address is out of range) in RS-Logix 500.
I have checked my code numerous times and I cannot see that I am stepping on myself by using an address in two places for example.

The original program works fine, the FIFO .rss file works great, but not when I bring them together. Rockwell has yet to find an issue and this has been going on over a week now.

If anyone would like to help and see what could be causing the fault, I'd appreciate it, and will email the .rss files for review.

Thanks for the help!

DMC

 

[mgvol]

According to RSLogix500 V6.30 online help, indexed addressing is only supported in 5/02, 5/03, 5/04, 5/05 and MicroLogix1000.

 

[DMC]

It says that, but I'm not using indexed addressing directly, although the FIFO FFL and FFU does utilize indexed addressing.

DMC

 

[Operaghost]

The FIFO uses indexed addressing to handle the position parameter. Check these two things:

#1. Make sure the lenth field on the FIFOs do not exceed 128. If it does then RSLogix should catch this and give ytou an error before it ever gets downloaded. But.......

#2. Check to see if your program is writing to the control position or length fields (such as R6:0.POS or R6:0.LEN). If the logic writes a value to these fields the RSLogix syntax check ha sno way to find that.

Maybe if that isn't the issue then save FIFO code separately as a library file and upload it here for folks to take a look at.

It does not sound like an issue of code stepping on each other though. It would appear to be a probelm with the length or position fields on at least one of the FIFOs.

OG

 

[DMC]

Fifo Code

OK I loaded the program into the processor at the pump station (120 miles away) and it did not give me the 2Ah error and ran for about 30 seconds ...... it gave me a 44h error code however.

So it seems as though the 2Ah code is an emulator related problem, but the 44h code is explained as follows:

0044 This non-recoverable run-time error indicates excessive stack depth/JSR calls for event routine.
RSLogix 500 - Copyright Rockwell Software 2000, 2001, 2002

I have 12 JSRs in the program.

DMC

 

[Operaghost]

I think that means you have nested your JSRs too deep. Do you have one subrorutine calling another that is calling another and another?

OG

 

[mellis]

DMC,

The fault code indicates that you have too many JSRs active at the same time. Usually, this would be due to nesting subroutine calls. According to the RSLogix500 help, in normal code you can have eight levels of nesting. However, in the STI and HSC interrupt routines, the limit is three levels of nesting. I expect that the EII is the same (it doesn't specifically say so though).

I'm guessing here, so if I'm wrong you're entitled to a full refund.

If you do not have nested subroutines, there may be an alternate explanation. Your event may be firing so often that the routine can't finish before it's called again. Each call pushes you one level down in the stack.

Are you doing a lot of data manipulation in an EII routine? Normally I'd expect an interrupt routine that takes too long to cause scantime watchdog problems. But if you push to the stack too many times in one scan, you may get this fault instead.

Any of this sound helpful?

Good luck,

Mike Ellis

 

[Operaghost]

Yep, error 2A means the FIFO file (such as N10) is too small. Check the FIFO instructions and their lengths. If the FIFO address on the FFL and FFU reads N10:0 and the length reads 50 then go to the N10 data file and verify there are at least 50 words in the file. As I mentioned earlier, check to see if anyone is writing to that position or length fields (such as R6:0.POS or R6:0.LEN).

OG

 

[DMC]

Found my problem...

Firstly, 44h in a Micrologix is an recoverable error relating to the real time clock.

In a SLC 44h refers to the JSRs etc., so that wasn't an issue.

My RTC write to instructions (MONTH, WEEK, HOUR, MIN, SEC) were being written to by the Panelview in the original Integer locations that existed pre-FIFO.

Once I changed my program the locations that were used for the updating of the RTC were now part of my FIFO for Pump 1. The RTC probably read a 0 for MONTH, or WEEK and faulted a 44h.

Once I fixed these errors, everything ran fine.

Thanks to all for the help.
DMC