[phpBB Debug] PHP Warning: in file [ROOT]/viewtopic.php on line 2075: compact(): Undefined variable $warn_allowed [phpBB Debug] PHP Warning: in file [ROOT]/viewtopic.php on line 2182: Undefined variable $warn_allowed [phpBB Debug] PHP Warning: in file [ROOT]/viewtopic.php on line 2075: compact(): Undefined variable $warn_allowed [phpBB Debug] PHP Warning: in file [ROOT]/viewtopic.php on line 2182: Undefined variable $warn_allowed [phpBB Debug] PHP Warning: in file [ROOT]/viewtopic.php on line 2075: compact(): Undefined variable $warn_allowed [phpBB Debug] PHP Warning: in file [ROOT]/viewtopic.php on line 2182: Undefined variable $warn_allowed [phpBB Debug] PHP Warning: in file [ROOT]/viewtopic.php on line 2075: compact(): Undefined variable $warn_allowed [phpBB Debug] PHP Warning: in file [ROOT]/viewtopic.php on line 2182: Undefined variable $warn_allowed [phpBB Debug] PHP Warning: in file [ROOT]/viewtopic.php on line 2075: compact(): Undefined variable $warn_allowed [phpBB Debug] PHP Warning: in file [ROOT]/viewtopic.php on line 2182: Undefined variable $warn_allowed [phpBB Debug] PHP Warning: in file [ROOT]/viewtopic.php on line 2075: compact(): Undefined variable $warn_allowed [phpBB Debug] PHP Warning: in file [ROOT]/viewtopic.php on line 2182: Undefined variable $warn_allowed [phpBB Debug] PHP Warning: in file [ROOT]/viewtopic.php on line 2075: compact(): Undefined variable $warn_allowed [phpBB Debug] PHP Warning: in file [ROOT]/viewtopic.php on line 2182: Undefined variable $warn_allowed [phpBB Debug] PHP Warning: in file [ROOT]/viewtopic.php on line 2075: compact(): Undefined variable $warn_allowed [phpBB Debug] PHP Warning: in file [ROOT]/viewtopic.php on line 2182: Undefined variable $warn_allowed [phpBB Debug] PHP Warning: in file [ROOT]/viewtopic.php on line 2075: compact(): Undefined variable $warn_allowed [phpBB Debug] PHP Warning: in file [ROOT]/viewtopic.php on line 2182: Undefined variable $warn_allowed [phpBB Debug] PHP Warning: in file [ROOT]/viewtopic.php on line 2075: compact(): Undefined variable $warn_allowed [phpBB Debug] PHP Warning: in file [ROOT]/viewtopic.php on line 2182: Undefined variable $warn_allowed [phpBB Debug] PHP Warning: in file [ROOT]/viewtopic.php on line 2075: compact(): Undefined variable $warn_allowed [phpBB Debug] PHP Warning: in file [ROOT]/viewtopic.php on line 2182: Undefined variable $warn_allowed [phpBB Debug] PHP Warning: in file [ROOT]/viewtopic.php on line 2075: compact(): Undefined variable $warn_allowed [phpBB Debug] PHP Warning: in file [ROOT]/viewtopic.php on line 2182: Undefined variable $warn_allowed [phpBB Debug] PHP Warning: in file [ROOT]/viewtopic.php on line 2075: compact(): Undefined variable $warn_allowed [phpBB Debug] PHP Warning: in file [ROOT]/viewtopic.php on line 2182: Undefined variable $warn_allowed [phpBB Debug] PHP Warning: in file [ROOT]/viewtopic.php on line 2075: compact(): Undefined variable $warn_allowed [phpBB Debug] PHP Warning: in file [ROOT]/viewtopic.php on line 2182: Undefined variable $warn_allowed [phpBB Debug] PHP Warning: in file [ROOT]/viewtopic.php on line 2075: compact(): Undefined variable $warn_allowed [phpBB Debug] PHP Warning: in file [ROOT]/viewtopic.php on line 2182: Undefined variable $warn_allowed [phpBB Debug] PHP Warning: in file [ROOT]/viewtopic.php on line 2075: compact(): Undefined variable $warn_allowed [phpBB Debug] PHP Warning: in file [ROOT]/viewtopic.php on line 2182: Undefined variable $warn_allowed [phpBB Debug] PHP Warning: in file [ROOT]/viewtopic.php on line 2075: compact(): Undefined variable $warn_allowed [phpBB Debug] PHP Warning: in file [ROOT]/viewtopic.php on line 2182: Undefined variable $warn_allowed [phpBB Debug] PHP Warning: in file [ROOT]/viewtopic.php on line 2075: compact(): Undefined variable $warn_allowed [phpBB Debug] PHP Warning: in file [ROOT]/viewtopic.php on line 2182: Undefined variable $warn_allowed [phpBB Debug] PHP Warning: in file [ROOT]/viewtopic.php on line 2075: compact(): Undefined variable $warn_allowed [phpBB Debug] PHP Warning: in file [ROOT]/viewtopic.php on line 2182: Undefined variable $warn_allowed [phpBB Debug] PHP Warning: in file [ROOT]/viewtopic.php on line 2075: compact(): Undefined variable $warn_allowed [phpBB Debug] PHP Warning: in file [ROOT]/viewtopic.php on line 2182: Undefined variable $warn_allowed [phpBB Debug] PHP Warning: in file [ROOT]/includes/functions.php on line 4218: Cannot modify header information - headers already sent by (output started at [ROOT]/includes/functions.php:3103) [phpBB Debug] PHP Warning: in file [ROOT]/includes/functions.php on line 4218: Cannot modify header information - headers already sent by (output started at [ROOT]/includes/functions.php:3103) [phpBB Debug] PHP Warning: in file [ROOT]/includes/functions.php on line 4218: Cannot modify header information - headers already sent by (output started at [ROOT]/includes/functions.php:3103) [phpBB Debug] PHP Warning: in file [ROOT]/includes/functions.php on line 4218: Cannot modify header information - headers already sent by (output started at [ROOT]/includes/functions.php:3103) Train- balancing multiple bays/stations - Factorio Forums
This board is to show, discuss and archive useful combinator- and logic-creations.
Smart triggering, counters and sensors, useful circuitry, switching as an art , computers.
Please provide if possible always a blueprint of your creation.
This is if you have 2 or more parallel loaders at an ore deposit, smelter etc. I made this so the trains will pick the fullest bay, instead of the empty one on the shortest route and viceversa at an unloader. It ensures all bays stay used equally and simultaneously.
How it works. This setup is placed at each bay and interconnected with the other bays via wire. Its connected to the loader chests to receive this bays contents, and to the signal at the bay entrance to block trains individually. At each bay the chest contents are summed and compared against whatever signal is shared by the other bays, and block this bay if another bay has more items. The contents of itself get transmitted to the other bays in turn. Its only 3 combinators which is cool.
The catch is that the signal is read back out, which will determine a bay is occupied or not. If a bay is occupied, the next best bay is opened up. There is always a bay open, unless theres a train in every.
How to setup: Connect the chest with your chests via red wire. Connect the pole with the other bays pole via green wire. Open the top right combinator (which is [0]*green=crate). Change crate to any unique item different at each bay, doesnt matter which. Viola.
i will try the same with unloading bays tomorrow
Edit: That was easy, just changed the "greater than" to "less than" ,and then it works for unloading bays.
Edit: And if you put 1 item (any item) into every bays dummy chest, unloaders will perform better. Just 1 random item. This is made so the bay still outputs a value when its empty. Make sure its 1 in every, not 2 not 3. I think i will change this to a static constant combinator instead. Initially i put the chest to make it more userfriendly, it doesnt serve another purpose. (connect chest with chest.. easy to remember)
I like it! And combinators are just magic sometimes. The feedback from the signal is kinda weird i dont really understand it ,but it works loool.
Last edited by aober93 on Sat Apr 15, 2017 7:14 pm, edited 1 time in total.
If you put the manipulators on both sides of the train, then instead of four stations, two will suffice. Well, for two stations, combinators will no longer be needed. Although you can object - what if the amount of cargo is so much that two stations can not cope with loading? My experience of the game shows that you usually have to load on a little but in different places, and unload a lot in one place. ie the problem is completely the opposite of what you presented
Guu wrote:My experience of the game shows that you usually have to load on a little but in different places, and unload a lot in one place. ie the problem is completely the opposite of what you presented
What do you mean by opposite? The opposite of balancing is unbalancing
And even if you continue to think in the same vein, then firstly to improve the speed of unloading (loading) of the station or group of stations, you need to remove the discrepancy between the number of manipulators and the throughput of the conveyors that serve them. And when the mechanisms no longer cope then connect the logic
MadZuri's design only works fairly well for loading, with belt balancers feeding the stations.
Unloading stations is a completely different problem, you can either have unbalanced belts, chest or trains, if you try to use a chest to belt circuit solution, it's only possible to create the perfect upstream if you use creative mode or something similar to simulate, because a live environment is always a little bit off and it requires a perfect environment to unload evenly.
Not sure if the problem existed before 0.13, but that is how long I've been working on creating a solid unloading station that doesn't create a problem with unbalanced chests or trains.
Unbalanced trains: Let the train leave when some of the wagons is empty, this mostly work fine without any deadlocks, as long as you don't wait until the train is empty.
Unbalanced chest: This is broken as the unbalancing will transfer to the belt when the chest unbalancing gets bad enough.
Unbalanced belt: My current design create four compressed blue belts, so I simply only have smelters that need less than that, so the belt have more input than is drained.
What you do with the information I gave you is up to you.
Miravlix wrote:MadZuri's design only works fairly well for loading, with belt balancers feeding the stations.
Unloading stations is a completely different problem, you can either have unbalanced belts, chest or trains, if you try to use a chest to belt circuit solution, it's only possible to create the perfect upstream if you use creative mode or something similar to simulate, because a live environment is always a little bit off and it requires a perfect environment to unload evenly.
Not sure if the problem existed before 0.13, but that is how long I've been working on creating a solid unloading station that doesn't create a problem with unbalanced chests or trains.
Unbalanced trains: Let the train leave when some of the wagons is empty, this mostly work fine without any deadlocks, as long as you don't wait until the train is empty.
Unbalanced chest: This is broken as the unbalancing will transfer to the belt when the chest unbalancing gets bad enough.
Unbalanced belt: My current design create four compressed blue belts, so I simply only have smelters that need less than that, so the belt have more input than is drained.
Using Zuri's balanced loading at every mine balanced unloading is ridiculously simple.
2017-03-23-07-12-08-9703356.jpg (102.34 KiB) Viewed 18605 times
The above example unloads 1 fully compressed or 2 uncompressed belts using every chest equally. More than 2 belts will require a belt balancer.
It will work as long as all trains entering unloading station are equally loaded and have the same length.
Dude you are missing the topic, youre showing a belt to chest balancer. This topic is a train balancer, trains going into multiple bays, picking the optimal bay. Similar to deactivating train stations.
I wonder why you all talk about belt balancers and loaders. Was my explanation this bad that the topic has failed?
BTW I have figured out the solution from the video i meantioned that i will share. Its a simple flipflop, it alternates between 2 bays only. So every other train goes into a different bay. Its pretty solid but only works on 2 bays and doesnt detect a defunct bay. It opens up the other bay when 1 is occupied, and frees up the same bay when the other is still occupied, or in other words it doesnt flip flop in that case. Pretty solid.
Guu wrote:I meant that you're trying to solve a problem that does not exist
Thats just wrong. A train always picks the shortest path, and this makes 1 bay always tend to get 100% service while the farthest away one will get the least service, and trains are not aware of the status of the train station. And thus you have a scenario to solve.
Theres another recent topic here viewtopic.php?f=5&t=43953 with similar talk. This is a different scenario but the balancing there is done by simply deactivating bays below a certain threshold, which is kinda ok when having tens or hundreds of identical bays. Either can work in combination with mine or none. Its situational but anything works really.
There is also the feature coming in 0.15 to deactivate stations entirely, which might give new possibilities to that. Nobody knows, but deactivating the entrance is kinda the same effect i think. But you can keep telling this is a feature to a nonexistant problem..
Youre not constructive by just saying "i solve a nonexistant problem", while at the same time imply you have a "cheaper, better.." solution. So either there is a solution then there is also a problem, or neither. But talking both is bullshitting. If your intend is to brag that you know something better we dont ,but wont tell what, then get out. Perhaps you evaluate the possibility that your playstyle is different or you dont understand yet how trains work.
Anyway i dare you to show your solution to that problem being more effective than mine.
aober93 wrote:Dude you are missing the topic, youre showing a belt to chest balancer. This topic is a train balancer, trains going into multiple bays, picking the optimal bay. Similar to deactivating train stations.
I wonder why you all talk about belt balancers and loaders. Was my explanation this bad that the topic has failed?
BTW I have figured out the solution from the video i meantioned that i will share. Its a simple flipflop, it alternates between 2 bays only. So every other train goes into a different bay. Its pretty solid but only works on 2 bays and doesnt detect a defunct bay. It opens up the other bay when 1 is occupied, and frees up the same bay when the other is still occupied, or in other words it doesnt flip flop in that case. Pretty solid.
bayalternate.jpg
My bad, I got confused since I use the same terms to describe different things.
To me a loading bay is something loading a single entity (wagon, car) while what you call loading bay here is a track to me.
A flipflop wont account for trains having different loads and you might end up with different amounts between tracks.
What I'd do is compare buffered amount from track1 with track2 and set the entrance signal of the bigger one red (that way if they are equal both are green).
Ah right, perhaps i should rename to station, but i thought that may describe the whole outpost. You know like 5 bays or single stations named "Iron 1" make up a big station.
That flip flop seems to be ok if nothing else is in place, and you have high performance robot loading. Because the requester chests are served equally, and the chests tend to be filled fast enough they hit their cap often. In which case you barely need that flip flop but who cares it works. The performance of a mining outpost will change over time, so it has its place eventually. And its not that each outpost has a carefully planned and calculated bay to miner to robotcount ratio. So install that, and worry less. But it can still barely be called universal.
A simple decider has its place. But as a counterexample, take a 5 bay high performance robot unloader. The robots drain the nearest bay out, while the farther bays get less drain the farther away they are. However that decider only opens the nearest bay because its emptiest. A train in it will never catch up with the drain, so it stays emptiest , until the other bays are emptied. But by then the trains have already waited, and the high performance is busted. And the trains coming late will unload the fastest they can, which in turn makes the arrival and departure time more prevalent and is dominating idle time. Then its better to have nothing in place at all.
Each has its place. But i like mine because its so universal. It always works. Train picks the fullest/emptiest station but doesnt block the other. It works in a local outpost with any number bays, it works across all outposts in the game. (If i wire up the whole map), it works at unloaders be it robot or belt. High or low performer etc. Especially at mining outposts which go from high to low performer in their lifetime it works like a charm imo.
Bots are impossible to balance unless you design perfectly symmetrical builds like this design by MadZuri.
Even for just one row of 6 chests bots will constantly prefer picking from the closest chest draining only those so mostly only 1 or 2 of my stations inserters are even capable of unloading, severely dropping throughput.
That's why I always use chains like wagon > 12 steel chest > belt(s) > strategically placed provider feed by 4 sides from stack inserter to feed into logistic network, but mostly I run the belts through balancers right into the factory.
For my centralized Megabase I use 2 tracks for iron and 2 tracks for copper ore unloading. They are easily able to unload more ore than is needed for 2 rockets/min. I didn't even need to get close to the maximum throughput they could have.
2017-01-01-17-07-02-6286496.jpg (684.89 KiB) Viewed 18532 times
The major downside to this belt madness is high entity update times dropping from 60ups down to 25 under full load. I expect it to become playable with improved belt mechanics in 0.15, but it will always use up more ups than bot setups.