Downtime entity

[Hunter Pratt]

Hello,

I am looking to set up a down time for my model, when thinking of how to do it I can see two ways. One being to have two down time entities, one entity on my ''i'' line and anther on my ''e'' line. if I set up the simulation like this I would like there to be a down time every ten parts, or I could have one downtime entity after the two lines come together and have it go down every twenty parts.

I attached me model without a working downtime entity. I would like to simulate my weld tip being cleaned and we are doing that ever 20 welds parts welded. I have looked for examples with no luck and the manual isn't much help to me either. If anyone could point me in the right direction that would be greatly appreciated.

Thank you,

Hunter

[Harry King]

Hunter,

The use of one DowntimeEntity or two for your model depends on whether each line has a separate welding station or not. If there are two independent welding stations, with no shared equipment, then you should model then separately and have separate downtime activities for each one. If the same welder is used for both lines then it should be modelled as a resource that is seized and released by each line.

The DowntimeEntity can generate maintenance or breakdown events based on either working hours or on calendar hours. It doesn't have the ability to count the number of activities executed unless this quantity can be expressed as an equivalent time. Could you use the total welding time instead of number of welds as your criterion for tip cleaning?

Another way to model the cleaning process would be to use an EntityGate object that would close when tip cleaning is being done. The cleaning process would be modelled by a separate entity and server, with an ExpressionThreshold that would open when 20 welds had been completed.

Harry

[Harry King]

Hunter,

By the way, you should click the "2D" button to re-align your model -- it is a bit skewed right now. Also, close the Property Editor and the Log Viewer so that they don't block the Input Editor and Output Viewer. The Property Editor is only useful for programmers and the Output Viewer is only needed if you get an error message.

Harry

[E.T.]

I was looking for info on downtimes, had the same question, so thanks for the answer :-)

I've seen that the current version of JaamSim has additional features not covered in the current version of the manual, is it right? And I have some doubts, perhaps I got it wrong, let me check it:

If I wanted (say) to clean the tip after some amount of time welding (say the 20*welding_time), should I specify (say) "Welder" in the keyword "IntervalWorkingEntity" and that amount of time in the keyword "Interval", both within the corresponding DowntimeEntity?

BTW, with respect to your recommendation to close the Property Editor and the Log Viewer, I definitely agree... and I'd also appreciate that when a model is saved the layout of tools is preserved, usually I adjust the Input Editor and Output Viewer as large as possible, but when I close the model and reopen it they return to their "default" size and location :-(

Thanks!

[Harry King]

Enrique,

 

I've seen that the current version of JaamSim has additional features not covered in the current version of the manual, is it right?

HK - An updated version of the manual is overdue.

If I wanted (say) to clean the tip after some amount of time welding (say the 20*welding_time), should I specify (say) "Welder" in the keyword "IntervalWorkingEntity" and that amount of time in the keyword "Interval", both within the corresponding DowntimeEntity?

HK - That is correct. Note that only the time the Welder spends in a "working" state is counted towards the next downtime event.

 

BTW, with respect to your recommendation to close the Property Editor and the Log Viewer, I definitely agree... and I'd also appreciate that when a model is saved the layout of tools is preserved, usually I adjust the Input Editor and Output Viewer as large as possible, but when I close the model and reopen it they return to their "default" size and location :-(

HK - We will get around to that feature one of these days.

Harry

[E.T.]

Harry, could you please have a look at this example? I checked that in the "Examples of JaamSim Objects 2016-12" (BTW: great!), "Downtime Example - Server", everything works fine (as expected), but not in my example, and I cannot see the difference.

What puzzles me is that FillerMaintenance occurs much less than expected (even never, depending on the seed): there should be a maintencance cycle (20 min) each 1625 s, but they don't occur.

I duplicated the very same construct (even with the same seeds) in the Sealer where it seems to work fine.

[E.T.]

I'm also trying to fix it, or at least understand it, and in so doing I've found something else which puzzles me a lot, when I was trying to record a detailed states for the units.

I used EntityGates to model blocking, so I assigned state "Blocked" there, but it didn't appear in the units, so I displayed the state of units in the EntityGate. To my surprise it is neither Blocked nor Filling (the previous state) but Capping, Waiting or even Labelling, which are FUTURE states.

I've double-checked everything and I cannot find a reason for this behaviour, might be a bug?

[E.T.]

... and in a modified version (with packing and no blocking), a new puzzle: the entity generator stops (and remains stopped forever) when five units accumulate in front of the first station. (I lowered the intearrival times to make it happen sooner, with uniform(5-10) it occurs after the first maintenance occurrence...

I'm starting to feel that there is something corrupted somewhere ¿? but I'm afraid I cannot see it :-(

I go on trying to understand it, but I stop sending examples. 

[E.T.]

Me again, with some "good" news: the last "poltergeist" disappeared after shut-down and re-start. It is good because it now works as expected (no misterious stoppages) but it is not completely good because it points out that a former, deleted, ExpressionThreshold was provoking strange effects after deletion ¿¿??

And another "good" new: in the new version the original problem with the FillerMaintenance DowntimeEntity has disappeared, perhaps it helps to identify the original problem?

[Harry King]

Enrique,

Deleting an object but forgetting to delete it from the inputs to other objects' keywords could cause problems. Saving and re-loading the model will fix or at least identify any problems of this kind. I'll test this later when I have a bit more time.

Incidentally, a model must be restarted from time zero after a Threshold or DowntimeEntity is added. You cannot just resume a paused model. These objects need to register their users before the model starts.

Harry

[E.T.]

Thanks Harry, although none of the comments apply, the deleted entities were compeltely deleted and the remaining ones reconnected appropriately, and I restart to time zero before every simulation (in fact, sometimes I forgot doing so and observed that occasionally the simulation went on past the end time). Take your time to test the example and uncover some bug... either in my understanding or in the program ;-)

[E.T.]

I've identified (part of) this behaviour: what happens is that the EntityGate keeps linked to the last entity that passed through, so the [FillerBlocked].obj.State gives the state of an entity which is no longer in the EntityGate but in subsequent stations.

The attached modified example shows it more clearly (better with Real Time=1).

Perhaps this behaviour (i.e., to stay linked to the last entity processed) is considered reasonable (I checked that it is the same in other objects, e.g. Servers),

but still there is the problem that the EntityGate never assigns the state Blocked, despite the StateAssignment keyword :-(

El jueves, 25 de agosto de 2016, 13:32:48 (UTC+2), E.T. escribió:

[Harry King]

Enrique,

I've identified (part of) this behaviour: what happens is that the EntityGate keeps linked to the last entity that passed through, so the [FillerBlocked].obj.State gives the state of an entity which is no longer in the EntityGate but in subsequent stations.

HK - It's designed to work that way. The output "obj" is the last object that was received. Therefore, [FillerBlocked].obj.State is the state of this last entity. The state of the EntityGate itself is [FillerBlocked].State.

 

The attached modified example shows it more clearly (better with Real Time=1).

HK - I ran the last model you attached (ExamplePackagingLineWithFailures_Altiok.11.7.cfg), but didn't see anything that seemed odd. Can you give me a specific time and behaviour that seems wrong to you?

Perhaps this behaviour (i.e., to stay linked to the last entity processed) is considered reasonable (I checked that it is the same in other objects, e.g. Servers),

but still there is the problem that the EntityGate never assigns the state Blocked, despite the StateAssignment keyword :-(

HK - The Blocked state is not being assigned to the entities because none are being blocked by your EntityGates. Look at the QueueLengthMaximum output for each EntityGate's Queue -- it is zero. It appears that the logic in your model is restrictive enough that the EntityGates have no effect.

Harry

[E.T.]

First of all, many thanks, Harry, for your time and guidance :-)

I understood that the linked obj behaviour is intentional (and convenient).

The pending odd issue is the following: in the example the Filler maintenance ratio is very low (or even zero, with the current seed, although it should be very similar or identical to the Sealer maintenance ratio, I don't see the difference (or the difference with the  "Examples of JaamSim Objects 2016-12" (BTW: great!), "Downtime Example - Server".

My entities are never *queued* in the EntityGates because only one can be there (by the restrictions of the model), but the EntityGates *do hold* entities, after they are released (see **) from the upstream server, when the downstream queue is full (so whenever they hold an entity they are stopped, for instance the FillerBlocked EntityGate is stopped more than half of the time). The EntityGates are supposed to assign the state "Blocked" to entities, but they never do so.

(**) By the way: is there another way to model that the entity stays in the upstream server while it is blocked by the donwnstream queue? I understood that either it remains in the server (half-porcessed) when the threshold is "immediate", or they are released when it is an "OperatingThreshold" - but in production lines the common case is the one I intended to model with the EntityGate.

Enrique

[E.T.]

UPDATE, FORGET THE FORMER ONE, SORRY

First of all, many thanks, Harry, for your time and guidance :-)

I understood that the linked obj behaviour is intentional (and convenient).

The pending odd issue is the following: in the example the Filler maintenance ratio is very low (or even zero, with the current seed, although it should be very similar or identical to the Sealer maintenance ratio, I don't see the difference (or the difference with the  "Examples of JaamSim Objects 2016-12" (BTW: great!), "Downtime Example - Server".

 

My entities are never *queued* in the EntityGates because only one can be there (by the restrictions of the model), but the EntityGates *do hold* entities ...

CORRECTION: they don't, with the current deterministic times, I've devised a variant that shows that the StateAssignment does work (I see now that when entities cannot go through the EntityGate they get queued, they are not in the EntityGate as if it was a Server).

So this matter is solved.

(**) By the way: is there another way to model that the entity stays in the upstream server while it is blocked by the donwnstream queue? I understood that either it remains in the server (half-porcessed) when the threshold is "immediate", or they are released when it is an "OperatingThreshold" - but in production lines the common case is the one I intended to model with the EntityGate.

This question remains, perhaps it is rather a suggestion to add this Threshold behaviour?

[Harry King]

Enrique,

 

(**) By the way: is there another way to model that the entity stays in the upstream server while it is blocked by the donwnstream queue? I understood that either it remains in the server (half-porcessed) when the threshold is "immediate", or they are released when it is an "OperatingThreshold" - but in production lines the common case is the one I intended to model with the EntityGate.

Instead of using an EntityGate, which requires a Queue, it might be better to use an EntityConveyor with an ExpressionThreshold that closes when the following Queue cannot accept more entities. The same ExpressionThreshold can be used to prevent the Server from accepting another entity. For both objects, the ExpressionThreshold would be entered to the OperatingThreshold keyword.

It might be possible to build this logic into the Server, but it would need to be done very carefully to keep it consistent with the other options. Simulation software can be very prone to feature bloat.

Harry

[E.T.]

True, thanks! For the Server I use the OperationThreshold, and (in my model) for the Conveyor both ImmediateThreshold or ImmediateReleaseThreshold work fine (since by definition the threshold closes due to a release), although the ImmediateThreshold makes more sense for a general situation, where the closing depends on something else.

To my needs, it is now perfect, no need to complicate the Server logic. Love minimalism ;-)

[E.T.]

Harry, finally I managed to find the "mistake"?

Most of the time, the Filler station is Clearing_While_Stopped (or "blocked" by the downstream bottleneck), and this state is not counted as a "working state", so it isn't taken into account for the DurationWorkingEntity.

In my opinion, Clearing_While_Stopped *is* a "working state", don't you agree? 

[E.T.]

(meant "it isn't taken into account for the IntervalWorkingEntity", of course)

[E.T.]

Sorry my messages come in threes :-(

I've "discovered" the WorkingStateList in the Maintenance section (great! and I'm ashamed, it was the FIRST keyword)

But the example still does not work, although now the Filler is working most of the time (82132 s).

It appears that there are several (7) breakdown events (exponential, mean 15 h, max 25000 s), but the Filler station is never in Breakdown state, and there are no repair events.

.cfg attached (and I'll leave it for a while)

[Harry King]

Enrique,

In my opinion, Clearing_While_Stopped *is* a "working state", don't you agree?

The only state that is automatically considered to be Working is the 'Working' state. However, you can make other states such as 'Clearing_While_Stopped' to be taken as Working by adding them to the input for the WorkingStateList keyword under the Maintenance tab.

Harry

[Harry King]

Enrique,

 

But the example still does not work, although now the Filler is working most of the time (82132 s).

It appears that there are several (7) breakdown events (exponential, mean 15 h, max 25000 s), but the Filler station is never in Breakdown state, and there are no repair events.

The logic for breakdowns is fighting with the logic for thresholds. At present, the assumption is that a breakdown cannot start when a threshold is closed. The rationale being that if an external factor is preventing a server from working, then it cannot spontaneously break down. That is, server must be able work just long enough for it something to break.

I need to give this some thought. Your model seems reasonable, but it's not obvious where the breakdown logic should be relaxed to make it work properly. I'll get back to you on this.

Harry

[Harry King]

Enrique,

 

I've "discovered" the WorkingStateList in the Maintenance section (great! and I'm ashamed, it was the FIRST keyword)

Regarding the WorkingStateList keyword, you should enter the two states WITHOUT the braces, i.e.

Working  Clearing_While_Stopped

Your input was read correctly, but this something that might cause problems later for you if we modify the input parser to be more strict.

Harry

[E.T.]

It seems that we have focused the problem, finally.

In my opinion the downtime logic, with its WorkingStateList, should be attended (I liked it very much when I finally understood it ;-),

otherwise it is useless to declare a state such as Clearing_while_Stopped a working state,

although the server is actually working (the entity receives no more than the corresponding service time, 6.5 s in this case),

--- and the reason is quite "hidden".

Moreover, it doesn't seem to be an easy alternative:

if the server is not stopped (but only the downstream conveyor) then the processed entities accumulate ad infinitum in the conveyor.

I look forward to receiving your recommendation to model this case, either after relaxing the logic, or not.

Thanks a lot!

[Harry King]

Enrique,

The logic for breakdowns and maintenance has been modified in release 2016-18 to allow these activities to start while a threshold is closed.

Harry

[E.T.]

Your throughput is impressive, thanks, and very glad to be helpful!

[Harry King]

Enrique,

After some thought about your model and the points you raised, I've decided that there isn't any point in distinguishing between the "Clearing_while_Stopped" state and the normal "Working" state. For this reason, I've removed the "Clearing_while_Stopped" state from release 2016-19.

Thanks for your contribution!

Harry

[E.T.]

Hope I could contribute more, I'm liking JaamSim more and more (even with the few pitfalls that shall be overcome), thanks to you!