Error 55 - "Subroutine ladder data size exceeds limit"

[Flex727]

I occasionally get the compile error 55 - "Subroutine ladder data size exceeds limit. Split subroutine to solve problem". Obviously the subroutine is too large for some reason and it's really no problem to split it up, as suggested, but my question is: what specifically causes the problem? Is it the number of ladder rungs or the total data size of the subroutine (meaning a small number of complex ladder rungs or a large number of simple ladder rungs)?

 

The subroutine that I am currently working on that triggered the error has 130 ladder rungs, including the RET function. That doesn't seem like a lot, but nearly every rung is executing 3 different Data Table functions, which might be data intensive.

 

By the way, I can find nothing in the Help file about this error.

[HigHTech]

I occasionally get the compile error 55 - "Subroutine ladder data size exceeds limit. Split subroutine to solve problem". Obviously the subroutine is too large for some reason and it's really no problem to split it up, as suggested, but my question is: what specifically causes the problem? Is it the number of ladder rungs or the total data size of the subroutine (meaning a small number of complex ladder rungs or a large number of simple ladder rungs)?

 

The subroutine that I am currently working on that triggered the error has 130 ladder rungs, including the RET function. That doesn't seem like a lot, but nearly every rung is executing 3 different Data Table functions, which might be data intensive.

 

By the way, I can find nothing in the Help file about this error.

Hi Flex: do you need all the rungs to run at the same time? I normally break data table subroutines. It will be nice if we can see your subroutine. 

[Flex727]

Yes, they all need to run. Basically, I'm logging events to a data table. The 3 functions are:

 

1) Copy all rows of the data table down one.

2) Copy a single row from a different data table that lists all the events by name into the first row.

3) Write the date & time that I've already converted into a string into the first row of the data table.

 

The 130 rows represents the approx 130 different events that the customer wishes to log.

 

Here is what it looks like:

[HigHTech]

Yes, they all need to run. Basically, I'm logging events to a data table. The 3 functions are:

 

1) Copy all rows of the data table down one.

2) Copy a single row from a different data table that lists all the events by name into the first row.

3) Write the date & time that I've already converted into a string into the first row of the data table.

 

The 130 rows represents the approx 130 different events that the customer wishes to log.

 

Here is what it looks like:

Example1.jpg

I stop using positive transition contacts to call data table commands. I use a direct contact and a reset coil of that contact at the end of the rung. I think you can find a way to make the log a little easier. I don´t understand why you need 1 row for each event. If you want send me your program so I can understand the logic and then try to find together a solution.

[Flex727]

Thanks for your interest, HigHTech. This software is being written exclusively for a specific customer and I would prefer not to send it out without their authorization. I will try to provide more detail though.

 

See attached to see what is inside those function blocks. It's really pretty simple - I want to log the date and time (and event name) to a data table each time one of 130 events occur. For instance, in the ladder rung I attached above, an operator might push a button (binary text switch w/toggle) on screen to disable RSU 1. Pressing that button causes MB 8001 to go high and that positive transition initiates the addition of a line to the data table, as stated above. I see no reason to add complexity by using an additional MB that gets set and reset when the data table entry completes because the data table operations occur within one PLC scan with no problem.

 

My purpose with this thread was to try and understand the source of the compile error, however I am certainly open to learning a more efficient way to create this data table log.

 

Here are the 3 function blocks from the ladder rung above, in order, and a look at the data table structure:

[HigHTech]

Thanks for your interest, HigHTech. This software is being written exclusively for a specific customer and I would prefer not to send it out without their authorization. I will try to provide more detail though.

 

See attached to see what is inside those function blocks. It's really pretty simple - I want to log the date and time (and event name) to a data table each time one of 130 events occur. For instance, in the ladder rung I attached above, an operator might push a button (binary text switch w/toggle) on screen to disable RSU 1. Pressing that button causes MB 8001 to go high and that positive transition initiates the addition of a line to the data table, as stated above. I see no reason to add complexity by using an additional MB that gets set and reset when the data table entry completes because the data table operations occur within one PLC scan with no problem.

 

My purpose with this thread was to try and understand the source of the compile error, however I am certainly open to learning a more efficient way to create this data table log.

 

Here are the 3 function blocks from the ladder rung above, in order, and a look at the data table structure:

Example1a.jpgExample1b.jpgExample1c.jpg

Example2.jpg

I think you can find a way to use only 1 rung to do the log. Using an EVENT FB you can define a vector of the events and then knowing the position of the event you can find the name without repeating 130 times the same rung with a different event contact.

[Flex727]

Yep, that would be great if all the events were in a vector. Assigning or moving all the event MBs into a continuous block is more trouble than it's worth right now, but I'll keep it in mind on future projects.

The primary reason I don't use the Event FB is that it is extremely difficult to troubleshoot and I hate dealing with it. Considering the complexity of the current project I should have reevaluated my general habit in this regard.

 

Thanks again, HigHTech!

 

By the way, I'm still looking for the answer to my original question.

[Joe Tauser]

My hat is off to you;  I've never gotten that error.  I, too, am curious what it takes to choke a subroutine.

 

Joe T.

[Flex727]

I just choked another subroutine. This one had 273 ladder rungs with no Function Blocks at all - just ordinary contacts & coils and a few timers, and none of the rungs were very complex.

 

The reason this subroutine had so many ladder rungs is because I normally have one subroutine just for Inputs (and another for Outputs) where I buffer each Input and add some logic to enable the user to convert the Input from Normally Open to Normally Closed, if needed for the future. This particular project is a beat down as it has 135 Inputs (and almost as many Outputs).

 

This got me worried that I might run out of project memory, but apparently no worries there:

[Flex727]

This project continues to challenge. Not only have I choked several ladder subroutines, but I ran out of transition contacts. I've never done that before with an enhanced vision PLC. It's been a real learning experience as I had to go through the program and determine if I REALLY needed that positive transition contact (e.g. for a button press, etc). Obviously for a button press to navigate to a different screen, a PT contact is absolutely necessary, but to RESET most alarm latches, it's not that important (as long as the SET RUNG follows the RESET rung, not before). I also changed my logging routine to the more sane method suggested above by HigHTech. I had to move well over a hundred MBs to a vector, but it cleaned up my program nicely and the EVENTS TRACK FB works very well for this application.

[HigHTech]

This project continues to challenge. Not only have I choked several ladder subroutines, but I ran out of transition contacts. I've never done that before with an enhanced vision PLC. It's been a real learning experience as I had to go through the program and determine if I REALLY needed that positive transition contact (e.g. for a button press, etc). Obviously for a button press to navigate to a different screen, a PT contact is absolutely necessary, but to RESET most alarm latches, it's not that important (as long as the SET RUNG follows the RESET rung, not before). I also changed my logging routine to the more sane method suggested above by HigHTech. I had to move well over a hundred MBs to a vector, but it cleaned up my program nicely and the EVENTS TRACK FB works very well for this application.

Great job Flex. The more challenging a program the more you learn. 

[Flex727]

Great job Flex. The more challenging a program the more you learn. 

Very true, HigHTech!

 

And thanks again for your help.