Shortki Community

General Category => F.A.Q. => Topic started by: shortki on September 07, 2011, 12:54:45 AM

Title: Starting dates
Post by: shortki on September 07, 2011, 12:54:45 AM
A small guide on starting dates in object schedules.

When a process reaches an object, its starting date is set to the maximum date of completion of its predecessors. If an object has no input then the starting date will be equal to the starting date of the whole chart. However, if a chart is embedded in a folder, the starting date for an object without predecessors can be changed arbitrarily. This is the way how the starting date is determined by default.

If one sets the flag "Fixed starting date" for an object, its starting date can be set later than the default starting date for the object. In this case, if dates of predecessors are shifted earlier, the date for the flagged object will still be unchanged, but if the default starting date is shifted later, the current starting date will also change in order to not be earlier. The fixed starting date is denoted on the chart by the diamond.

By setting the parameter "Late start" you can set a fixed delay of execution for the object relative to the default date. Such a date will be shifted in accordance with changes of the default date. The late start is denoted by the special sign "Pause & Play".

Title: Re: Starting dates
Post by: Colin on October 09, 2011, 06:23:45 AM
I've noticed a special case where if an item momentarily had a default start date constraint (by a link from an object that has since been deleted) -- but now no longer has any constraint on it's start date: the item still cannot be set earlier than that date/time.

Can you describe the logic behind the "input starting date with former predecessors can no longer arbitrarily be set".

Also, in "Actual/Real Execution Mode" sometimes the finish date for a process that has iterator inputs uses the {current date/time} and sometimes it uses {start date} + {length-of-last-iteration (or expected time?) i.e. 12 mins 37 secs if that was the actual execution time in the last iteration, even if it's only been 45 seconds of execution time}.

So I'm wondering when current date/time is used for finish date?

Title: Re: Starting dates
Post by: shortki on October 12, 2011, 02:08:11 AM
"Former" items should not have any influence on the current chart, maybe this is "echoes" of that case with a proxy? If an item is in a folder and has no predecessors, its starting date must not have any restrictions.

When an iterator port is activated, the starting date for the item is set to the end date of the item linked by the iterated connection. In the actual schedule, if an item does not have the planned schedule specified, or has no expected time, or the expected time is later than the current one, the current time becomes the item's execution time (which is reasonable for the actual time (at least unless a time machine is invented)). You observed this very effect.
By the way, the program is inaccurate accounting schedule coupling for iterators, it will soon be fixed.

Title: Re: Starting dates
Post by: frankmcleod on June 01, 2012, 11:57:45 AM
I'm afraid I'm struggling with this.
With a form on the desktop containing my diagrams, if I take the folder or the first activity, both with no inputs, whether in planned or actual, P or R you cannot change the start date.

You must drill down to the lowest nested commence activity, with no inputs, then if you request to set start you will get the pin wheel, but it will only let you set the start in the future.

I want to start the project in the past

Can you help

Title: Re: Starting dates
Post by: shortki on June 02, 2012, 02:59:52 AM
Place the resource on the Desktop or inside a folder, and you'll be able to randomly edit its start date until it has an incoming connection or a subdiagram.

Title: Re: Starting dates
Post by: iQuant on May 10, 2013, 10:58:37 PM

Hi Community,

I struggle with the early start dates as well.
Has anyone found out why the process analysis is shifting every process series to the middle or to the end of the project while setting a late start date of the very first process?
How can I overcome this automatic shift? 'Set fix start date' isn't working. When I set this the process series is shifted anyway. (I run the process analysis several time before I set the start date to fixed, maybe this is doesn't work, I don't know. Any experiences?)

Maybe time buffers could fill up the end of a process line, but how can I set time buffer to be extended without process analysis?

Any other hints? Would be very thankful.

Title: Re: Starting dates
Post by: bkonia on November 20, 2015, 08:13:11 AM
I'm confused about starting dates in the context of the Queue of Tasks.

If a starting date is in the future, it seems to me, the object should NOT show up in the Queue of Tasks. However, future start date objects DO show up there. Why?

Furthermore, the documentation describes the Waiting queue as:

These are the tasks, the execution date for which has not yet arrived.

However, tasks with future start dates are NOT automatically added to the Waiting queue, they have to be moved there manually. Why?

To summarize:

1. Why are tasks with future start dates added to the Queue? I'd prefer that a task not show up in the Queue at all until it's POSSIBLE to execute it.

2. If they must be added to the queue, why are they added to the Active queue rather than the Waiting queue. Why does the user have to manually move the task to Waiting? If inShort sees the start date is in the future, shouldn't it be smart enough to automatically place the task in Waiting?

To avoid confusion, I'd prefer option 1 above. I think only executable tasks should be added to the queue. And once a task is in the Queue, it should be up to the user to move it to the correct column within the Queue. However, it makes no sense to me to have a task in the Queue, if it can't possibly be executed. The Waiting queue should be for tasks that the USER has decided must wait for some external event to occur. It should not contain tasks that simply have a future start date, as inShort should keep those out of the queue until the start date arrives.