static objects as SingleProc have a obstacle boundary to prevent worker to cross.
I could not find similar for workers, so they move 'through' each other.
I use the workers with AGV type graphics, so it would be nice if they would could pass side by side as the cross each other.
Solved! Go to Solution.
workers don´t have an obstacle area around them. In case that it is critical for your AGVs not to cross each other a better way to model them might be to use transporters driving on tracks. This way you can implement controls that prevent your AGVs from crashing into each other.
sorry to reply on this again.
I recently showed a model in my company and the visiting people (management, politicians, press, etc...) asked why SGVs collide with workers (.. move through).
In this factory model the worker need to be free to move in the possible area (limited by barred areas objects in 3D). Transporters on rails are not acceptable as not reflecting the real world.
I suggest to program this into PlantSim as real good option for the 3D shows, ... but also 2D.
Good evening gentlemen,
sorry to mingle into your conversation, yet this topis is of a pivotal interest to me (I also need forklifts to move in the area freely, i.e. not acording to a given matrix define by roads and I also tried to use Workers with an appearance of forklifts to facilitate this - also with the issue that workers/forklifts collied with other moving objects or go through them).
Is my understanding correct that Plant Simulation calculates the trajectory for each worker before he sets off so that any object which enters and blocks the trajectory after the worker has set off and is now on his way, will not be taken into consideration, i.e. the worker will "ignore" it and go through that object without recalculating its trajectory?
If this mechanism is correct, I guess I have seen a parial solution to this issue at the previous User conference. As far as I remember it was base on periodical re-evaluating of xPos and yPos of each moving object, so that those who got too close to each other (Euclidean distance probably...) will be "somehow" stopped (moved to a dummy workplace created in their current position) to wait for the other adjiacent Worker to pass by (and then continue).
I reckon this solution must be extremely demanding for comupting power and the simulation run must be slow, right?
Isn't there any other solution? Or is it a topic to be tackled within the further development?
I was racking my brains with theoretical suggestions of alternative solutions but I haven't got to far. My questions:
- is there any command through which the user can get the coordinates of the worker (before it sets of?)
- would it be possible to combine a free movement of the worker with Footpaths (restriction in let's say tiny areas)?
- any other ideas?
Thank you very much,
ok, thank you for your reply, anyway.
My intention here was also to try to draw more attention to this problem and to find out, wheter it is maybe already being under development for further versions of Plant Simulation...
I have noticed there is the tool "WorkerSankeyDiagram" as a standard Plant Simulation element . This can draw (in 3D scene) Sankey Diagram accordingly to the actual trajectories of all surveilled workers. I.e. this tool somehow collects data regarding the points where the direction of further movement of each worker is about tu change.
Now, I wonder how this is done and if there is any way how to trigger a (user) method whenever the WorkerSankeyDiagram is allerted that the direction of further movement of the respective worker is about to change.
I am afraid to enable this one would get into the internal code of the tool WorkerSankeyDiagram, correct? I have also noticed that in the help file the chapter "Method of the WorkerSankeyDiagram" leads to section "Method of the Chart" and, true, there is a certain similarity between the dialogue of this tool and dialogue of a chart element. Yet, the command "putValuesIntoTable" does not work with WorkerSankeyDiagram as the help file promises...
I would be greatful if I get any useful hints how to procede further...
The potential worker paths are calculated in beforehand to make the resulting performance bearable. Calculating these paths on demand would virtually halt your simulation (maybe with the exception of a really small simulation with a small couple of potential paths). This however also means that there is not that moment anyone could tap into. The sankey diagram (in the beginning, it could only monitor freely moving workers, now it can do more than that) is not actively informed about every trajectory change. The data collection works a bit different here (I would need to go into far too many details - suffice it to say you cannot simply tap into this procedure).
But is there a particular application you need this for? Maybe there is a solution to that case...
just a rough idea...
You could take the same approach as modern videogames do and make a dense network of nodes with even spacing in between (a square grid). You'd have to set the distance to neighbouring nodes to e.g. 1 or 1.4 depending on whether you move horizontally/vertically/diagonally. Then use a pathfinding algorithm such as a* to find a path and keep the path somewhere in a table.
When an AGV arrives at a node you could put a claim on the neighbouring positions, making those unavailable for other AGVs. Then when they would collide, you would know and could start recalculating the route with the claimed nodes being unavailable, avoiding the collision.
Since you're only recalculating the route when a collision is immanent and a* is fairly efficient, this should not be that computationally expensive - depending on the size of the grid.