question

I think it's always done this, so it's compatible with old models - you'd need to add a time zero row with a quantity of zero to get the behaviour you describe. The only reason I can think for preserving this behaviour is if someone wants an initial delay after reset that is different to the row intervals, but that would be better handled as an explicit field so that the behaviour is clear. Showing the interpretation of the table alongside the entered data would also help e.g the first few arrival times.

@steven.hamoen,

While I agree that this can be confusing, I think Jason's explanation is accurate. To help add supporting documentation, I created a small example model in which the table is set up to have a delivery of 1 red item at time 0 and 2 green items at time 10.

As you can see in the demonstration, the entire table is repeated every 10 seconds, and this happens in time 0. So whatever the highest time value in the table is (i.e. 10 seconds) also represents the time that the table will begin to execute again (i.e. 0 seconds).

I guess another way to think of it is that the last row and first row execute simultaneously. In your case, that means the same row is executed infinitely.

repeat arrival table.fsm

@tanner.p My problem is not so much that you need to do it a specific way to get things done, but the problem is that your model crashes and you have no idea why with just standard settings. You can keep this functionality in place but still prevent the source to go into an infinite loop by just making in an extra check in the source code:

else if (v_repeat)
     createevent(holder,0, 0, "Schedulecreatepart",first(node_v_schedule));