I discovered a strange behaviour in 14.2 different to 14.1:
My model has an AssemblyStation which first has to delete the content on the transporter and then put another MU on it.
In 14.1 this worked perfectly fine with following EntranceControl (setProctime is a method that sets the ProcTime dependant on the variant of MU):
if @.empty @.move else @.cont.delete ?.setProctime end
The problem now is, that this method does not even start. Before I get following error:
After I click Yes or No the entrance control method starts. But this is obviously too late.
I checked the box "before actions" in controls and unchecked the box "automatic processing".
Opening the same model in 14.1 works perfectly fine.
Is this a bug or do I have to consider another thing?
Solved! Go to Solution.
it's not a bug but message
informing you, that no Mu could be loaded
onto the transporter due to not enough capacity.
One reason could be , that the part on the transporter
is still on the transporter.
Try and see what happens, if you switch to the
assembly mode "delete Mus"
As you have aready noticed,
v14.1 and v14.2 behave differently in this case- for what ever reason.
I guess in v14.2 the assembly station does not assemble before -
but checks the required capacity to load /assemble the parts.
In any case if you want to continue in v14.2 you have to modify
the assembly mode to "delete MUs".
Ok thanks for your replies.
I changed it to Delete MUs but then multiple MUs get deleted from th conveyor during the proctime. It should only be 1.
Changing capacity of the Transporter is working.
However, i don't understand why this has been changed.
From what I can tell it only deletes the one MU that is already loaded onto the container when it enters the assembly station. However, the container doesn't seem to exit the station afterwards.
Try and replace the code for the AP_190 entrance control with this one:
if @.empty = False
so my special case is solved: I increased capacity of the conveyor.
But physically this is not true. At this point everything seems ok with this workaround. I hope that it won't cause something in th further process.
@MarcusA : I did exactly the same thing but didn't find anything in the changelog.