BD...
So... the only thing that is different is that you have added a new pattern... and the process screws up ONLY with the new pattern... Is that so?
If so, then yes... your problem must lie in the new pattern data file.
If I understand you correctly, you are relying solely on timers to determine when to resume running the belt... I would never do that. That is what I would call "a minimalist design". You are "hoping" that the sweeper performs as it should and then you "assume" that it has, and then you restart the belt.
Not good.
There is another name for that type of control... it is called "Supply-Side Programming". That is in contrast to "Demand-Side Programming".
Many inexperienced programmers try to design code in a manner that replicates the activity of a purely mechanical device. That would be a device in which all of the activities in the process are mechanically linked together through cogs, shuttles, ...whatever. You feed a piece of raw material into the machine and, as it moves through each of several steps, the material is chewed up until it is finally spit out... hopefully in the form that you were expecting.
If the machine consists of 6 steps and there happens to be a part jammed in Step-5... then this process will continue feeding material until Step-5 is totally jammed, Step-4 is totally jammed, Step-3, Step-2 and Step-1 until you simply can't feed any more material in... or the machine stalls out on its' own.
That is called a "Supply-Side" design... as in... Ready or not, here it comes! See what you can do with it! (Oh, and Good Luck!)
The better way to design this kind of material handling process is by employing the "Demand-Side" strategy.
The "Demand-Side" strategy is based on the idea that material is not passed to a subsequent step unless that step is "calling" for material. That means, each step monitors itself and does not "call" for more material unless it is ready and waiting for that material.
The "Demand-Side" strategy precludes the use of a timer as the PRIMARY motivator for any subsequent activity. Certainly timers are allowed... but only in terms of monitoring the duration of a particular activity (for Fault Detection), or for delaying a subsequent action that has been "approved" by the POSITIVE indications associated with the previous activity.
For example, if your sweeper has positively performed the required activity (as indicated by the appropriately indicated/selected sensors), then you might use a timer to introduce a slight delay before restarting the Feed-Belt. The key-point being that the sweeper-cycle was verified as being completed as expected!
Yes... this requires more sensors and more programming... however... the cost is recovered very quickly in reduced down-time. Depending on your process, a sensor can be purchased and incorporated into the program for the cost of only a few minutes of down-time! It's kind of a "DUH?" sorta thing!
You can definitely use Pattern Files in a Sequencer with the "Demand-Side" strategy... it's just a matter of properly designing the code (trigger) for stepping from one step to the next.
I would not include timer values in the Pattern File. I would, however, specify which sensors to use when determining sweeper activity. If that means using a half-dozen cylinder stroke-sensors (not the best way), or a half-dozen sweeper detectors (better), then so be it! It WILL pay off, In Spades! I guarantee it!
If you don't get my point, tell me what you don't understand about what I said.
In my experience, I've come upon many palletizers that were marginal at best. The primary reason for that was that they were based on Timers instead of "positive indications"!
Do yourself a HUGE favor... blow off the timer-based control; go to positive indications! It's more than worth it!
