Tuesday
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?
Solved! Go to Solution.
Tuesday
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?
Tuesday
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).
Tuesday
@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?
Tuesday
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?
Tuesday
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]'
Tuesday
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.
Tuesday - last edited Tuesday
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.
Tuesday
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
Tuesday - last edited Tuesday
@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