I was trying to search a way to have one-way footpaths, like in many factories, for objects of the workerclass. I know there is an equivalent one-way track for transporters, but this class does not fulfill the requirements of my project.
I tried adding a workplace to the end and beginning of a footpath to at least have an entrance and exit control. The workers however just jump over these workplaces, making it impossible for the controls of the workplace to work.
I am not even sure if it is possible to simulate a one way footpath even if an entrance or exit control can be obtained because the pathfinding algorithm has to take this into account in some way...
Is there any a way to implement this one way footpath functionality?
Thank you in advance,
Solved! Go to Solution.
One way to model your scenario is using 'Transporter' and 'One way track'. Transporter(Change the icon) will act a worker.
Do you mean modelling the footpaths as tracks and using the transporter class instead of the worker class (changing the icon as a worker)? It's not the visual aspect that is important in my case.
The worker class is needed because the model heavily relies on the workerpool, workstations and especially the services. These elements are not available in the transporter class, if I'm correct.
Thank you for your reply.
that's what he means, and in your case you would have to implement your own TransporterPool and TransporterImporter logics/controls to replace the worker-objects.
We have also tried finding workarounds for one-way footpaths and so far I have not found any "good" ones:
Hi Alex, thank you for your informative response!
It seems that we may have to remodel all logistics. We want to avoid this because the model is already very complex and changing from "workers" to "transporters" will be very tricky.
If I am correct, Plant Simulation uses the Dijkstra algorithm to calculate the paths for transport. Maybe if there is a way to influence this algorithm, we could "scrap" one direction of taking a footpath for this algorithm to select? It would also be nice to influence this algorithm because we are simulating the logistics of the line supply of a large factory. You can imagine that transporters do not always take the shortest path in real life, it would be nice to make the path a bit longer on purpose. But there might be other ways to take this into account (make transporters slower, ...). The reason why all this is important in our model, is because we want to see what "streets" are occupied the most using a Sankey-diagram for example.
Thank you once again!
The thing is, you have way more options to influence the transporters than the workers; so we also prefer to use transporters that only "look like workers". Regarding your problem, the transporter+track approach allows using the RouteWeightingAttr to dynamically change the routes that transporters will take, e.g. based on current traffic, instead of changing the physical tracklengths; also the oneway-issue can be easily resolved.
As far as I know, there are no comparable options for the worker/footpath simulation available, but I understand that you don't want to re-build your model with transporters. So I guess your best option will be to look at the GoTo-syntax and manually route the workers "workplace-by-workplace" to their destination, potentially with some additional workplaces that are only used for routing. But that may also turn out as a lot of work, I'm afraid
Yes, exactly what I was thinking, both options will probably be a road full of trouble.
Let me elaborate a little bit more about how the current model works:
The reason we chose for workers is because we developed an order system. The production line, which consumes MUs, places orders in this system (a table) and checks if this order can be fulfilled (in the correct Stores where MUs are held). When MUs enter Stores, for example, it is checked if this MU can be used to fulfill these orders. There are many Stores, intermediate Stores, ... (complex system). These "orders", as we call them, are executed by doing the following actions (simplified explanation):
- set the MU destination attribute and the Store where the MU is moving from its MU target to the destination of the order
- set the broker of the Store where the MU is moving from to the broker of a specific transportation team (there are multiple teams, every MU has a specific team according to the MU name). A team consists of a broker, workerpool, shiftcalendar and analysis tools.
- move the MU using MU.move, which assigns a worker of the assigned team (with the correct services) to get the MU and deliver it to its destination.
I hope this explanation is clear enough, it is hard to give a brief overview of the complex systems. If it is not clear, please don't hesitate to ask a question.
This system works very well for what we are trying to simulate, because we can easily change what transportation teams deliver what MUs to the line (with the correct services, ...). The model therefore relies on the workerpools, services and brokers. And as far as I personally know, it is not possible to use the transporters to do these steps (is this true?).
I fear we will have to keep looking for an alternative one-way footpath option or use your proposal.
If we find an alternative, we will certainly post this solution here.
Thank you once more for the information!
Well, depending on your layout and whether the transport-worker-teams have only 1 store where they pick up from (and no other team must pick up from that store), it might be enough to use the TransferStation for loading parts to transporters and there setting "Always stop" = true, and thus have each team wait on the track at its pickup store, then once there are parts for your orders, they can be loaded, do the transport and then you can send them back to that station. The TransferStation's destination sensor must be set to "Activate only if destination".
If it's more complex, you would have to do something like in the attached example model. There I have defined
In this example, each MU-name requires a transport-service with a matching name and thus there are 3 MU-types and 3 transporter-pools. So I guess this control now does the same as the broker/workerpool in your case.
It's quite "stupid/simplistic", but I guess it can give you some ideas on how to proceed, if you are going to switch to transporters.
Thank you for the example model, it can certainly be a good starting point if we convert our model to using transporters. We were not sure how to model workerpool functionalities and emulate the services of workers for the transporters and this model certainly demonstrates a way to do this! We will try to implement our ordering system in your model.
So we will probably decide to convert the model, because the transporters indeed offer more fucntionalities in terms of carrying parts, routing, etc.
Thank you for all the help, it helped us a great deal!