Cancel
Showing results for 
Search instead for 
Did you mean: 

waituntil / stopuntil ignored

Pioneer
Pioneer

Hey guys,

in my model i have several tracks which calls methods after a MU is leaving.

Depends on which track is calling a method a vehicle is send out of a buffer and will be loaded with matching MUs for the same track.

Now i have 11 tracks which have more or less the same method. Only some variables are different.

Some time my model works fine. But if 2 methods are called the same time the waituntil / stopuntil doesn't work. So only 1 vehicle is send to the loading station and the other method call is totally ignored. So i got the problem, that after some time my tracks run out of vehicles and the simulation stopps.

 

Here is my code of one calling method:

is
	Tabelle : object;
	Station : string;
	weitererWeg : object;
	FTF : object;
do
	
	--waituntil U_belegt = false prio 1;
	stopuntil U_belegt = false prio 1;
	
	Station := "M1";
	weitererWeg := W1;
	Tabelle := "Teile_M1";
	
	-- FTF_Lager nach FTF durchsuchen
	FTF_Lagerbestand.setzeZeiger("verfügbar",1);
	
	if FTF_Lagerbestand.finden({"verfügbar",*}, true) = true then
		
		local y : integer := FTF_Lagerbestand.ZeigerY;
		
		FTF := FTF_Lagerbestand.alsObjekt(1,y);
		
		-- Erzeugungstabelle der Quelle je nach Bedarf anpassen
		Quelle_Teile.Pfad := Tabelle;
		Quelle_Teile.ErzeugungAlsLos := true; 
		
		-- Quellenausgang entsperren
		Quelle_Teile.AusgangGesperrt := false;
		
		FTF.umlagern(H1);
		
	else
		print "kein freies FTF verfügbar!";
	end;

	@.umlagern(weitererWeg);

end;

One try before i had another method where all tracks had the same method only the variables "Tabelle", "Station" and "weitererWeg" are different depends on which track is calling. But that doesn't neither work.

 

Anybody a suggestion how i can solve this problem? The priorities couldn't be changed because every call is important.

 

Thanks in advance

 

Regards

Carsten

8 REPLIES 8

Re: waituntil / stopuntil ignored

Siemens Phenom Siemens Phenom
Siemens Phenom

The model is quite complex. It would be helpful if you could tell us the simulation time at which the problem occurs, and which MUs are involved. In the future you should post a model that is saved in that state.

 

What I can see is that you still use waituntil, for example in the Method 'FTF_Lager_Ausgang'. You need to use stopuntil if you want all Methods to wake up, even if the condition is no longer true when it is the Method's turn.

 

_________________________________________________________________
Did you like the answer? Then click the Thumbs Up button.
Did the answer solve your problem? Then accept the answer as solution.

Re: waituntil / stopuntil ignored

Pioneer
Pioneer

Hi Michael thanks for your reply,

 

in the attached file there is 1 version of my problem.

 

There is the first problem that at ~1:58:00 a vehicle is loaded with MUs (Teil_M9).. then a bit later Track S12 is calling his method for new MUs. But because a vehicle is still be loaded no new vehcile comes out of the buffer. So the ordered MUs for track S12 are still in the source but not loaded. If later track 14 is calling the remaining MUs for track S12 are loaded. So the following order is messed up.

 

Another problem comes at ~ 2:33:32 when vehicles of the tracks S5 and S11 are starting at the same time. Now only 1 order is noted (but there is still the messed up order but in other random runs this problem comes the most) and the other one is lost.

 

----------------------------------------------------------------------------------------

i thought that every method with waituntil or stopuntil is paused until the condition is met? In other methods i have waituntil (e.g. waiting for a free buffer -> E_M1 or the others)

 

So the mainproblem is the Pull-Methods for S1 to S14... with their specific methods called Pull_S1 to Pull_S14

 

hope the informations are helpfull because i'm out of ideas how to solve the problem.

 

Regards

Carsten

Re: waituntil / stopuntil ignored

Siemens Phenom Siemens Phenom
Siemens Phenom

Waituntil and stopuntil both wait until the condition is met, but there is a difference if more than one Method is waking up at the same time. Stopuntil evaluates the condition only once, i. e. if the condition was once met, the Method will continue. Waituntil reevaluates the condition before the woken up Method is about to continue. If the condition is no longer met, the Method stays suspended.

 

Example: Two Methods are waiting for SingleProc.empty. When the MU leaves the SingleProc, the Method with the waituntil/stopuntil statement with the higher priority will be continued first. If they use the same prio, the one that has been suspended longer will continue first. Imagine that the first woken up Method moves an MU onto SingleProc before it ends. If the second Method uses stopuntil, it will be continued too. If it uses waituntil, it will stay suspended, because the condition is no longer true.

_________________________________________________________________
Did you like the answer? Then click the Thumbs Up button.
Did the answer solve your problem? Then accept the answer as solution.

Re: waituntil / stopuntil ignored

Pioneer
Pioneer

Thanks for your good explanation Smiley Happy

 

Now i replaced all stopuntil with waituntil. For the priority i used z_uniform(3,1,3) for the case that 2 vehicles are calling the same time. So the other vehicle waits like it should. But after the first ordered vehicle is fully loaded, the second wouldn't move out of the buffer... the new table for the source is right setted but i don't understand why the vehicle isn't pulled out?

 

So i get the same problem as before with the messed up order

Re: waituntil / stopuntil ignored

Siemens Phenom Siemens Phenom
Siemens Phenom

I don't see a reason why you would want to use a random priority here. I would advise to use a fixed priority (for example 1), so that you get FIFO order.

I suggested that you replace waituntil with stopuntil, not the other way around.

_________________________________________________________________
Did you like the answer? Then click the Thumbs Up button.
Did the answer solve your problem? Then accept the answer as solution.

Re: waituntil / stopuntil ignored

Pioneer
Pioneer

Thanks for your reply,

 

i'm sorry i misunderstood a bit. I read the german help and now i understand for sure Smiley Happy

 

I solved the problem with the messed up order by changing some settings of my track W1.. and added with "wait" 1 second and now with fix priorities it works that a vehicle is send out of the buffer.

 

But how can i solve the problem with the 2 vehicles, which start at the same time? There my variable "U_belegt" is false and therefore my stopuntil with the priorities wouldn't hit.

i changed the working time of my mantlestations but after some time there will come the situation with 2 vehicle starting at the same time again.

Has anybody an idea?

 

Regards

Carsten

Re: waituntil / stopuntil ignored

Siemens Phenom Siemens Phenom
Siemens Phenom

Hallo Carsten,

 

bei dem Puffer FTF_Lager ist der Ausgang gesperrt. Das verhindert, dass das folgende Fahrzeug auf H1 umgelagert wird.

 

Grüße

Peter

Re: waituntil / stopuntil ignored

Pioneer
Pioneer

Hi Peter,

 

danke für deine Antwort. Aber dass der Pufferausgang gesperrt ist ist Absicht. Durch den umlagern-Befehl klappt das auch so ganz gut.

 

Habe jetzt eine komplett neue Idee das Ganze zu lösen. Ich verwende eine Warteschlange.

Das klappt eigentlich auch ganz gut nur bis zu dem Punkt, an dem wieder 2 Fahrzeuge gleichzeitig ihre Anfrage in die Warteschlange eintragen

 

(siehe angehängte Datei ab ~7:38:00 -> Wege S4 und S10)

 

meine Eintragungsmethode sieht so aus: (wird immer bei Verlassen des Stationsweges aufgerufen)

 

is
	Tabelle : object;
	weitererWeg : object;
do
	
	-- je nachdem welche Station die Methode aufruft unterschiedliche Werte
	-- Station M1
	if ?.Name = "S1" then
		weitererWeg := W1;
		Tabelle := "Teile_M1";
	-- Station M2
	elseif ?.Name = "S2" then
		weitererWeg := W2;
		Tabelle := "Teile_M2";
	-- Station M3	
	elseif ?.Name = "S3" then
		weitererWeg := W3;
		Tabelle := "Teile_M3";
	-- Station M4
	elseif ?.Name = "S4" then
		weitererWeg := W4;
		Tabelle := "Teile_M4";
	-- Station M5
	elseif ?.Name = "S5" then
		weitererWeg := W5;
		Tabelle := "Teile_M5";
	-- Station M6
	elseif ?.Name = "S6" then
		weitererWeg := W6;
		Tabelle := "Teile_M6";
	-- Station M9
	elseif ?.Name = "S9" then
		weitererWeg := W9;
		Tabelle := "Teile_M9";
	-- Station M10
	elseif ?.Name = "S10" then
		weitererWeg := W10;
		Tabelle := "Teile_M10";	
	-- Station M11
	elseif ?.Name = "S11" then
		weitererWeg := W11;
		Tabelle := "Teile_M11";	
	-- Station M12
	elseif ?.Name = "S12" then
		weitererWeg := W12;
		Tabelle := "Teile_M12";	
	-- Station M14
	else
		weitererWeg := W14;
		Tabelle := "Teile_M14";
	end;
			
	Warteschlange.einfügen(Tabelle);
	
	@.umlagern(weitererWeg);
	
end;

das funktioniert soweit auch ganz gut.

Jetzt habe ich in meiner Warteschlange einen Beobachter eingefügt, der bei Dim-Änderung folgende Methode aufruft

 

(Attribut: string; alterWert: any)
is
	y : integer;
	FTF : object;
do
	
	stopuntil U_belegt = false AND H1.belegt = false prio 1;
		
	wait(1);
	
	if Warteschlange.Dim /= 0 then
		
		-- FTF_Lager nach FTF durchsuchen
		FTF_Lagerbestand.setzeZeiger("verfügbar",1);
	
		if FTF_Lagerbestand.finden({"verfügbar",*}, true) = true then
		
			y := FTF_Lagerbestand.ZeigerY;
		
			FTF := FTF_Lagerbestand.alsObjekt(1,y);
		
		-- Erzeugungstabelle der Quelle je nach Bedarf anpassen
			Quelle_Teile.Pfad := Warteschlange.lesen;
			print Warteschlange.lesen;
			
		-- Quellenausgang entsperren
			Quelle_Teile.AusgangGesperrt := false;
		
			FTF.umlagern(H1);
			
		-- Eintrag aus Warteschlange entnehmen
			Warteschlange.entnehmen;
			print "Wert entnommen -> dim ändert sich" + to_str(Ereignisverwalter.Zeit);
			
		else
			print "keine freien Fahrzeuge: Wert erhöhen!" + to_str(Ereignisverwalter.Zeit);
		end;
		
	else
		print "Aufrufversuch!" + to_str(Ereignisverwalter.Zeit);
		
	end;

end;

Jetzt ist es der Fall, dass die Methode gleich 2 mal gleichzeitig aufgerufen wird und somit nur die Anfrage für Station 10 bearbeitet wird.

 

Das mit dem 2 Mal aufrufen kann ich noch verstehen aber müsste dennoch nicht nur der erste Wert entnommen werden und dann müsste die Methode warten bis der Eintrag gelöscht wurde, was wiederrum eine Dimänderung mit sich bringt, um den nächsten Eintrag, der jetzt auf 1. Position ist aufzurufen?

 

Finde kein richtiges Beispiel zu einer Warteschlange bzw. einem Beobachter, daher kann auch meine Methode falsch angewendet sein.

 

Danke schonmal für eine Antwort

 

Gruß Carsten

 

#-------------- english ----------------------------------------------------

Now i use another way to handle the problem with 2 method-calling at the same time. I use a queue.

Therefore i write with every vehicle leaving of a track an order in this list. See following code.

is
	Tabelle : object;
	weitererWeg : object;
do
	
	-- je nachdem welche Station die Methode aufruft unterschiedliche Werte
	-- Station M1
	if ?.Name = "S1" then
		weitererWeg := W1;
		Tabelle := "Teile_M1";
	-- Station M2
	elseif ?.Name = "S2" then
		weitererWeg := W2;
		Tabelle := "Teile_M2";
	-- Station M3	
	elseif ?.Name = "S3" then
		weitererWeg := W3;
		Tabelle := "Teile_M3";
	-- Station M4
	elseif ?.Name = "S4" then
		weitererWeg := W4;
		Tabelle := "Teile_M4";
	-- Station M5
	elseif ?.Name = "S5" then
		weitererWeg := W5;
		Tabelle := "Teile_M5";
	-- Station M6
	elseif ?.Name = "S6" then
		weitererWeg := W6;
		Tabelle := "Teile_M6";
	-- Station M9
	elseif ?.Name = "S9" then
		weitererWeg := W9;
		Tabelle := "Teile_M9";
	-- Station M10
	elseif ?.Name = "S10" then
		weitererWeg := W10;
		Tabelle := "Teile_M10";	
	-- Station M11
	elseif ?.Name = "S11" then
		weitererWeg := W11;
		Tabelle := "Teile_M11";	
	-- Station M12
	elseif ?.Name = "S12" then
		weitererWeg := W12;
		Tabelle := "Teile_M12";	
	-- Station M14
	else
		weitererWeg := W14;
		Tabelle := "Teile_M14";
	end;
			
	Warteschlange.einfügen(Tabelle);
	
	@.umlagern(weitererWeg);
	
end;

then i set an observer at the queue which is activated if a dim-change is happening.. like a new list-entry or an list-exit.

(Attribut: string; alterWert: any)
is
	y : integer;
	FTF : object;
do
	
	stopuntil U_belegt = false AND H1.belegt = false prio 1;
		
	wait(1);
	
	if Warteschlange.Dim /= 0 then
		
		-- FTF_Lager nach FTF durchsuchen
		FTF_Lagerbestand.setzeZeiger("verfügbar",1);
	
		if FTF_Lagerbestand.finden({"verfügbar",*}, true) = true then
		
			y := FTF_Lagerbestand.ZeigerY;
		
			FTF := FTF_Lagerbestand.alsObjekt(1,y);
		
		-- Erzeugungstabelle der Quelle je nach Bedarf anpassen
			Quelle_Teile.Pfad := Warteschlange.lesen;
			print Warteschlange.lesen;
			
		-- Quellenausgang entsperren
			Quelle_Teile.AusgangGesperrt := false;
		
			FTF.umlagern(H1);
			
		-- Eintrag aus Warteschlange entnehmen
			Warteschlange.entnehmen;
			print "Wert entnommen -> dim ändert sich" + to_str(Ereignisverwalter.Zeit);
			
		else
			print "keine freien Fahrzeuge: Wert erhöhen!" + to_str(Ereignisverwalter.Zeit);
		end;
		
	else
		print "Aufrufversuch!" + to_str(Ereignisverwalter.Zeit);
		
	end;

end;

But now i have the problem, that when 2 vehicles are calling at the same time again both list-entries are read and only the last one is served.

I haven't found an example with a queue or an observer which could help me by my problem. So i think i used a wrong observer.

 

Can anybody help me with a solution or a tipp?

 

For the problem please see my model at ~7:38:00 where 2 vehicles start at the same time (S4 and S10)

 

Thanks in advance

 

Regards Carsten