question

It seems you learnt something. The max content of a queue doesn’t exist as a parameter in process flow. It exists only in 3D object logic. In process flow you have take care yourself for a capacity limit by deciding how many items are moved into a queue. This means an On Entry event is too late for such a decision. The activity, that is responsible to move an item into a queue, must check the capacity and the content of a queue. It is a principle of “if this then that”. And on the other hand you learnt, that your question wasn’t asked at the right time. You found out that you must know how to reference items waiting for release in objects. “Thumb up” :-).
Ok, there are tutorials which shows how to use the data of requesting an operator for transport in process flow. Then this is a good start to do them and ask questions which are more related to combine activities rather then asking how to do your job and attach a working model. You find this maybe a bit harsh of me to point this out, but I think that was exactly what you have asked for here.

Back to your original description of this question and “if this then that”. I assume you don’t need to check if the right items are available in the queues anymore. They have been stored already. Then you know the recipe - or in words of FlexSim developers-you know the components list for the combiner. There are two different options to discuss:

1. The combiner counts items from different ports or 2. he counts items from second port only. Both options lead to the same result. You combine an amount of X items. Nobody has said something of different attributes or features of the counted items, because it is totally irrelevant to a combiner. And nobody of FlexSim development tells you that fact. You can read that there is a hidden or involved mechanism to combine items of different attributes through ports, but that is not true. You collect just an amount of items through input ports. The objects at the input ports may hold and release items of a special class to the combiner but the combiner doesn’t care. He just counts items received through input ports. And this leads us to the fact you need at least physical present in your model two input port connections into combiner even if you choose to build a logic upon process flow.

If you are an experienced developer and you know the hidden hooks to notify the combiner that a pulled item entered the combiner through a special parameter of a command by a defined input port even if it doesn’t exists then you don’t need to have input ports present in your model anymore. But that is something for developers and not for users building models. You are better off with a queue near the combiner with input connections into the combiner. A combiner must have at least two input connections.

“ if this then that“: The combiner counts items. One item from input port number one. That is fundamental and you can’t change it. It is always only one item from input port number one. And it is always the first item entering a combiner. This item can change by an property in the On Entry trigger of the combiner the components list and through this mechanism the amount of items to be combined. I hope you still remember the combiner counts only items entering through input ports no more no less. He just counts. And how many, this is defined in the components list.

Your duty is to put the items in the right order into to the queue or queues connected at the input port of the combiner. If you connected the queues RTSPNL, FASCIA, LTSPNL, TKROLLUP to the combiner you can get the involved data by the mechanism of the mentioned tutorial. If you haven’t got such connections and you placed instead a queue in front of the combiner with input connections then you load items from the queues holding the items into an operator and you unload them into this queue in front of the combiner. A load activity can manage only one item at a time. This means you need to repeat load activities as often as you want to load items into the operator. How you repeat this type of activity is up to you. You can hard code this. Place the amount of load activities in a column. Or you repeat one activity by a loop. A loop can be hard coded by a process flow connector and a decide activity or by calling a sub flow through a so called activity.

Then you unload the items in a similar approach as described before.

Here some hints to cope with the data (Input port number, item reference, destination, loading station, and so on). You can assign data to different tokens into labels, then you must keep the tokens together for example by batching activities. Or you assign the data into arrays in a single token into labels.
Arrays are a bit tricky. This is mentioned in the manual. If you copy the data by simple an equal sign then both arrays point to the same address scheme in RAM. What you do to one of them you do it to both of them. If you need to assign only the values of one array to a different array then you have to clone the information.