Jump to content

Error 55 - "Subroutine ladder data size exceeds limit"


Recommended Posts

  • MVP 2023

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.

Link to comment
Share on other sites

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. 

Link to comment
Share on other sites

  • MVP 2023

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:

post-408-0-62796200-1471898252_thumb.jpg

Link to comment
Share on other sites

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:

attachicon.gifExample1.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.

Link to comment
Share on other sites

  • MVP 2023

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:

post-408-0-48174500-1471901723_thumb.jpgpost-408-0-04742200-1471901733_thumb.jpgpost-408-0-97008200-1471901742_thumb.jpg

post-408-0-28345400-1471901769_thumb.jpg

Link to comment
Share on other sites

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:

attachicon.gifExample1a.jpgattachicon.gifExample1b.jpgattachicon.gifExample1c.jpg

attachicon.gifExample2.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.

Link to comment
Share on other sites

  • MVP 2023

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.

  • Upvote 1
Link to comment
Share on other sites

  • MVP 2023

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:

post-408-0-62495800-1472004628_thumb.jpg

Link to comment
Share on other sites

  • MVP 2023

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.

  • Upvote 1
Link to comment
Share on other sites

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. 

Link to comment
Share on other sites

  • 7 years later...
  • MVP 2023

The compile error tells you exactly what to do. Cut half the ladder rungs from the subroutine and place them in a newly created subroutine then call that subroutine immediately after the original one.

I see that the problem exists with the Main Routine. I don't have version 9.9 installed yet so I can't look at your program, but if your Main Routine is too big then you have serious problems with your programming style. Subroutines exist to break up your code into manageable chunks, typically separated by function. The Main Routine should only have configuration function blocks, as needed, and the called subroutines. You shouldn't be putting your entire program into the Main Routine.

Link to comment
Share on other sites

  • MVP 2023

Also, all the warning messages regarding changing a bit and then reading the value in the same net indicates to me that you are overcrowding your ladder nets. Keep your nets as short and simple as possible. Break them up into smaller chunks whenever possible. The only thing you have to be mindful of is that coils cannot be duplicated (except for Set & Reset coils) and must have assignment in one ladder net only.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

This site uses cookies. By clicking I accept, you agree to their use.