Skip not yet produced variants in delivery table when day changes

[bugger]

Hey there,

first of all: I read several threads about delivery tables but I didn't find a solution for me.

Is there a way to cut the production and begin with the next entry (of the next day) when the day changes?

To clarify this issue here a little example:

Time	MU	 Number
0.0000	A	500
0.0000	B	500
0.0000	C	500
0.0000	D	5000
1.0000	A	500
1.0000	B	500
1.0000	C	500
1.0000	D	2000
2.0000	A	500
2.0000	B	500
2.0000	C	500
2.0000	D	5000

Let's say we have beginning of day 1. Production of 5000 pieces D is not finished, yet. Normal behaviour of delivery table: finish production of D before beginning with A again.

Now I want to interrupt production of D and start with A at exactly 1.0000

How is that possible? 

[NickPeeters]

Hello Bugger,

I guess you refer to the blocking behavior in the source. Because you're still working on product D, product A cannot be sent out yet.

You could split up the products over different sources, so you'll always have products waiting at the start?

[MarcusA]

You could also try setting an observer that checks the time, and when the day changes you somehow restart the production? The problem there is that it might drain unwanted processing power, as it will "check the time" regularly.

Or perhaps it could  be solved with a method that triggers once every day? If that sounds interesting, check the helpguide for 'methCall' (renamed 'executeIn' in PlantSim 14.2).

[bugger]

@MarcusA : That's something I thought of: Running a method every new day that is checking the delivery time of the actual produced MU, comparing it with the simTime, skip to first MU of this new day.

But how can I adress the column of the actual MU and the first column of the next day?

[Nomden]

Why not seperate the product classes in several buffers (Exit>>MU-attribute). Then use a FlowControl object to take the MUs from these buffers in order of your priority (Entry strategy>>Start at sucessor 1).

Would this work?

[MarcusA]

If you only have four different items, as in the provided example, I think that the easiest solution would be to combine the timer with @NickPeeters suggestion of separate sources.

For a more general solution you could change the MU selection in the source to constant, and then change it with a method. However, in that case you'll most likely need to also use a counter/observer to change the produced type after X number of products.

Finding the current row would be easier if you only have the different types in your list once then you can find the row of the searched part:

var Row: integer
Row := DataTable.Find(<Path>.MU) --Or if they have different names: 'DataTable.Find("MUName")'
-- You can then access the number produced column with 'DataTable[2,Row]'

[IgorKunjavskij]

Hello,

attached is an example implementation using the generator object triggering a method that changes your MU selection after one day. Other than that the exit control of the source is used here to check whether the current number of MUs exceeds the number of MUs of this type to be produced defined in a table. Here the source stops producing MUs once all parts necessary are produced within a day, although alternative implementations are also possible here.

[bugger]

first of all thank all of you guys coping with my question!

I forgot an important information: I have the standard license, so I cannot use a generator or Flowcontrol

My Delivery table normally looks way more complex. I just reduced it to make it easier to understand

Example:

0.0000	F_ZV_DF	997
0.0000	B_ZV_DF	997
0.0000	H_ZV_DF	4000
0.0000	F_TZ_DF	878
0.0000	B_TZ_DF	878
0.0000	H_TZ_DF	2250
1.0000	H_TZ_DF	2250
1.0000	F_ZV_DF	997
1.0000	B_ZV_DF	997
1.0000	H_ZV_DF	4000
1.0000	F_TZ_DF	878
1.0000	B_TZ_DF	878
2.0000	F_ZV_B	443
2.0000	B_ZV_B	443
2.0000	H_ZV_B	2667
2.0000	F_TZ_B	2473
2.0000	B_TZ_B	2473
2.0000	H_TZ_B	1500
3.0000	H_TZ_B	300
3.0000	H_ZV_B	2000
3.0000	H_ZV_B	4000
3.0000	H_ZV_D	4000
4.0000	H_ZV_D	4324
4.0000	F_ZV_D	2568
4.0000	B_ZV_D	2568
4.0000	F_TZ_D	135
4.0000	B_TZ_D	135
4.0000	H_TZ_D	270
5.0000	H_TZ_D	270
5.0000	H_ZV_D	4324
5.0000	F_ZV_D	2568
5.0000	B_ZV_D	2568
5.0000	F_TZ_D	135
5.0000	B_TZ_D	135

It also can be that more than one row has to be skipped ( e.g. on the first day it was only possible to produce until H_ZV_DF 4000 and then it should start next day with H_TZ_DF 2250)

Here is the background information for the reason why I have this behaviour:

I want to find the best amount of workpiece carriers. I have a lot of Experiments with different amount of carriers which have an impact on the possible daily output. That's why I have the situation where the model is not capable of producing the amount given in the table in the appropriate day.

[MarcusA · Accepted solution]

This might not be the flashiest solution, but it should at least get the job done: First, create a backupTable and make sure that it is formatted the same as the DeliveryTable. Fill it with your data. 

Then create (or add to an already existing) init-mtehod the following lines:

DeliveryTable.deleteContents
DeliveryTable:= BackupData.copy

Unless I'm completely misremembering this should overwrit the contents of the DeliveryTable with your backup data.

The create a method that you can call on every new day (E.g. NewDayMethod(<CurrentTime>)).

param SimTime : time --Parameter recieved from calling method

for var Row := 1 to DataTable.YDim --Go through whole table
if DataTable[1,Row] < SimTime --Reduce number of MU if they are created before SimTime
DataTable[3,Row] := 0
else
exitloop 2 --When all rows are reduced, exit the method
end
next

 This sets the number to produce to zero for all lines that have a creation date before the SimTime. (And that's why we have the backup, otherwise you'd have to refill it manually every time).

If this doesn't work, then I'll blame my cold for reducing my ability to think properly 

[bugger]

@MarcusA  I like this!

There are 2 errors: 

exitloop 2

 has to be changed into 1

DeliveryTable:= BackupData.copy

error: left and right sides of the assignment are incompatible. But they both are the same (I copied the original to get the backup)

I could not figure out the second error, yet