Created Date: April 27,2018

Created by: Jaycen

My project is a stacker for our products. It will stack pre-bundled batches of product into X rows by Y columns. To help with troubleshooting, I 've put indicators onto the screen to show the stack as it's being built. To turn the indicators on, I'm using some simple logic to put values into memory and turning on internal bits tied to the indicators on the HMI.

This process will generate 72 runs of logic. Am I better off turning this into a subroutine to keep scan time down, or am I being overly concerned about relatively low overhead on the Do-More?

Created Date: April 27,2018

Created by: franji1

If you are just doing simple contacts or relational contacts and simple OUTs or SET/RST (no STRING manipulation), 72 rungs are nothing.

However, you might want to stick them in their own PROGRAM code-block called GenStackInd and RUN it from $Main just to keep those 72 rungs out of $Main.

If you are doing heavy lifting, like doing STRINGs, you are better off just inserting YIELD instructions inside your GenStackInd PROGRAM code-block after every 3, 4, 6, 8, 9, or 12 rungs (whatever is a logical grouping of your 72 rungs). This will cause the GenStackInd to execute just a few rungs every scan up to the next YIELD, then automatically on the next scan start where it left off. So if you insert a YIELD every 3 rungs, it will take the PLC 24 (72 / 3) scans to execute ALL the rungs. So you end up spreading that processing across 24 scans so your scan times are faster. This is NOT NECESSARY if you are doing simple ladder logic. I just know that STRINGs can take some time.

Note: do NOT use YIELD inside $Main. YIELD should definitely be used inside a DIFFERENT code-block that can execute portion of the rungs round-robin (YIELD to YIELD) across multiple PLC scans.

Created Date: May 11,2018

Created by: Jaycen

If I don't want to avoid writing a lot of extra code, yes. I'm building a matrix on the screen, as these product bundles are stacked next to and then on top of each other. In order cut down the number of lines of code, I'm using the edge trigger to capture the counter value/state for a column on each row to display that new bundle, and then re-using the counter to continue counting columns for that row. Once the stack is fully built and moves down the conveyor, I reset it on the screen by resetting all the values to 0 again.

It seemed like the most efficient way to do the logic, but I'm still new to this and open to a better method if anyone has one.

Created Date: May 11,2018

Created by: Jaycen

If you post your code, someone here may be able to see a solution for you.

Attached are screenshots of what I'm doing. These stacks are NEVER more than 6 wide x 6 high. I have an interface on the HMI for the operator to define the stack, which dictates the preset for the counters. The counters are buried in another section of the code.

So, I capture the current row in one variable, and the current column in another. Using that, I edge trigger to capture that specific location in a third. I use that third to turn on a bit that's tied to a graphic on the HMI. The counter bits are reset as each row is completed, and I reset all the bits when a stack is complete and moved down the conveyor system. Since the matrix has the potential to be 6 x 6, that's 36 rungs, and each of those rungs turns on the bit tied to the graphic on the HMI, so that's another 36 rungs for a total of 72.

My original concern was "Gee that's a lot of rungs for a simple operation " and "maybe that's impacting scan time ", but mostly I'm interested in finding a more efficient way to do it.