programmable buildings (assembler, furnaces, plants)
Moderator: ickputzdirwech
Re: programmable buildings (assembler, furnaces, plants)
It'd be reaally handy for crafting modules, it also should have the option to turn the assembler off/on.
I also support your idea of inversed filter inserters, it could be useful in various situations
I also support your idea of inversed filter inserters, it could be useful in various situations
Re: programmable buildings (assembler, furnaces, plants)
Why not just make a logistic assembler with build in Requester, Active Provider and Passive Provider chests. Make it 4x3 to accomodate for the storage space used.
Would make an logistic system requirement for programmable assemblers, but that's the only thing that makes sense imo.
Items left over from recipe switches would always be dumped in the active provider chest. Left over requested items will be left in the requester chest for the next recipe change.
It would be so much more convenient, since you don't have to set up an assembly machine, chests and inserters every time. You just tell the machine to produce until a certain amount in your logistic system is reached.
Hell, this would be super nice to have even if it can't switch recipes.
Would make an logistic system requirement for programmable assemblers, but that's the only thing that makes sense imo.
Items left over from recipe switches would always be dumped in the active provider chest. Left over requested items will be left in the requester chest for the next recipe change.
It would be so much more convenient, since you don't have to set up an assembly machine, chests and inserters every time. You just tell the machine to produce until a certain amount in your logistic system is reached.
Hell, this would be super nice to have even if it can't switch recipes.
- Gertibrumm
- Fast Inserter
- Posts: 162
- Joined: Fri Jun 03, 2016 6:54 pm
- Contact:
Re: programmable buildings (assembler, furnaces, plants)
You can turn off the power with a power switch. That damn thing must be god for something I assume .SoRaC wrote:It'd be reaally handy for crafting modules, it also should have the option to turn the assembler off/on.
I also support your idea of inversed filter inserters, it could be useful in various situations
Inversed filter inserters would not be necessary for circuit-assemblers.
By the way you can mimic the behaviour of a inversed filter by using a filter inserter and hooking up a negative signal from a constant combinator.
Please no mandatory logistic system requirement. I am just figuring out how to use the circuit-assembler early on and I really never want to ever bother about bots.. but that of course is personal preference. But maybe the circuit-assmbler shouldn't be combinator-mandatory either, rather free to choose what system you prefer to use?Xeanoa wrote:Why not just make a logistic assembler with build in Requester, Active Provider and Passive Provider chests. Make it 4x3 to accomodate for the storage space used.
Would make an logistic system requirement for programmable assemblers, but that's the only thing that makes sense imo.
Items left over from recipe switches would always be dumped in the active provider chest. Left over requested items will be left in the requester chest for the next recipe change.
It would be so much more convenient, since you don't have to set up an assembly machine, chests and inserters every time. You just tell the machine to produce until a certain amount in your logistic system is reached.
Hell, this would be super nice to have even if it can't switch recipes.
Re: programmable buildings (assembler, furnaces, plants)
Well, technically you don't need it. But you'd be limited to taking items out from the provider chest tile, if you need to use an inserter.Gertibrumm wrote:Please no mandatory logistic system requirement. I am just figuring out how to use the circuit-assembler early on and I really never want to ever bother about bots.. but that of course is personal preference. But maybe the circuit-assmbler shouldn't be combinator-mandatory either, rather free to choose what system you prefer to use?
Re: programmable buildings (assembler, furnaces, plants)
Which would be extremely annoying.Xeanoa wrote:Well, technically you don't need it. But you'd be limited to taking items out from the provider chest tile, if you need to use an inserter.
Last edited by Yoyobuae on Tue Dec 20, 2016 6:19 pm, edited 1 time in total.
Re: programmable buildings (assembler, furnaces, plants)
That's why it's a logistic assembly machine.Yoyobuae wrote:Which would be extremely annoying.Xeanoa wrote:Well, technically you don't need it. But you'd be limited to taking items out from the provider chest tile, if you need to use an inserter.
Re: programmable buildings (assembler, furnaces, plants)
Which would also be annoying (to me at least).Xeanoa wrote:That's why it's a logistic assembly machine.Yoyobuae wrote:Which would be extremely annoying.Xeanoa wrote:Well, technically you don't need it. But you'd be limited to taking items out from the provider chest tile, if you need to use an inserter.
Re: programmable buildings (assembler, furnaces, plants)
I'll basically copy&paste what I've written in the Assembling machines and signals Thread (since I don't know if everyone interested in the topic looks over there):
[...]
But if you always have to wait for residual items to be completely removed before you can start crafting the new recipe one is actually delaying things artificially and increasing the overhead, decreasing overall crafting throughput considerably if you always have to wait for the slow inserters to output everything.
I mean as I see it... the Assembler could already start working on the new recipe after moving the unusable items to the residual item output buffer and once the actually required resources are inside the assembler. The residual items can still be removed from the buffer in the background at the same time.
So I thought about how it could work similar to how CPU pipelining works, just with a 3-stage assembly pipeline instead or so:
In each step the Assembler would do following:
This way one can make it so that there is always a limited "internal cache" for resource items... and as long as one is switching between the same 2-3 simple recipes or something there would never be residual items to be removed because they fit into the cache. But if you switch between more complex recipes or a lot of simple recipes then the cache will overflow and the oldest (least used) resources will be moved to the residual item output for pickup. And the assembler will only stall if you don't remove the residuals fast enough filling up the residual item output.
That would increase the overall throughput for simple recipes because the penalty of switching the recipe is largely mitigated.
I came up with that because with all the suggestions of "taking out residuals" almost nobody ever thought about how inefficient the throughput gets if the assembler always stalls waiting for removal of items. It becomes way too ugly that the machine spends more time waiting for item removal/insertion than it actually does pure crafting... It becomes so inefficient that it is not worth going for in comparison to dedicating machines to specific recipes.
So my above suggestion of pipelining the input/crafting/output is might actually be necessary to increase the efficiency of the entire "Set recipes"/"Smart Assembly" concept.
I continued to made a rough mockup of how I think that it might actually "work" with being able to switch the recipe at any given point without any performance loss within a certain "window":
Basically this is how it would work:
The amount of Cache/Buffer Slots is up for debate of course, but I'd say the 6 slot variant is a solid foundation to work with.
So how I see it, it would be possible to store the resources for up to 6 "single-resource" recipes in the cache and switch between those 6 recipes before it would become necessary to dump something into the residual item output buffer. That in turn increases the uptime of the assembler significantly. Maybe a stall doesn't even happen at all because you get a lot of time to remove the residuals.
That in turn makes it possible to use it even with belts that may have huge delays in item delivery/export, though maybe still not as effective as bots would be of course.
[...]
- Items that cannot be used for the current recipe are moved to an internal residual item buffer
- Output (Filter) Inserters can take items from that residual items buffer
- Input Inserters can only input resource items from the current recipe.
But if you always have to wait for residual items to be completely removed before you can start crafting the new recipe one is actually delaying things artificially and increasing the overhead, decreasing overall crafting throughput considerably if you always have to wait for the slow inserters to output everything.
I mean as I see it... the Assembler could already start working on the new recipe after moving the unusable items to the residual item output buffer and once the actually required resources are inside the assembler. The residual items can still be removed from the buffer in the background at the same time.
So I thought about how it could work similar to how CPU pipelining works, just with a 3-stage assembly pipeline instead or so:
In each step the Assembler would do following:
- Recipe Resource Fetch: Look at current Recipe signal and allow input inserters to prefetch necessary resource items (if they are not already inside the buffer)
- Recipe Crafting Execute: Start Crafting the recipe once all required resources are inside
- Items & Residuals Output: Output finished items. Output mismatching residuals if new recipe signal mismatches old recipe. (Basically your Write Back for those who are into CPUs)
This way one can make it so that there is always a limited "internal cache" for resource items... and as long as one is switching between the same 2-3 simple recipes or something there would never be residual items to be removed because they fit into the cache. But if you switch between more complex recipes or a lot of simple recipes then the cache will overflow and the oldest (least used) resources will be moved to the residual item output for pickup. And the assembler will only stall if you don't remove the residuals fast enough filling up the residual item output.
That would increase the overall throughput for simple recipes because the penalty of switching the recipe is largely mitigated.
I came up with that because with all the suggestions of "taking out residuals" almost nobody ever thought about how inefficient the throughput gets if the assembler always stalls waiting for removal of items. It becomes way too ugly that the machine spends more time waiting for item removal/insertion than it actually does pure crafting... It becomes so inefficient that it is not worth going for in comparison to dedicating machines to specific recipes.
So my above suggestion of pipelining the input/crafting/output is might actually be necessary to increase the efficiency of the entire "Set recipes"/"Smart Assembly" concept.
I continued to made a rough mockup of how I think that it might actually "work" with being able to switch the recipe at any given point without any performance loss within a certain "window":
Basically this is how it would work:
- So basically you set the recipe by signal, which then tells which items are "allowed" to be input into the internal Resource Cache.
- Once all required resource items are inside the Resource cache the recipe starts crafting.
- Finished items are moved to the Finished Item Output buffer. An Inserter can pick the stuff up from here.
- If Recipe Switch happens then the requirements of the new recipe are compared with what is already inside the cache.
- If it turns out that the resources for the new recipe don't fully fit into the cache (= "Cache Overflow", since there may still be other mismatching items) then it proceeds to dump one mismatching resource item after another to the residual Item Output buffer until there is enough space. It could begin by dumping the "oldest" resource that hasn't been used recently to the youngest.
- From the Residual Output buffer the inserters can grab the items that aren't needed anymore.
- Output buffer for finished items is full.
- Cache is empty because you didn't deliver enough resources to the assembler.
- Output buffer for residuals is full while a recipe switch requires dumping additional residuals since the Resource Cache is also full.
The amount of Cache/Buffer Slots is up for debate of course, but I'd say the 6 slot variant is a solid foundation to work with.
So how I see it, it would be possible to store the resources for up to 6 "single-resource" recipes in the cache and switch between those 6 recipes before it would become necessary to dump something into the residual item output buffer. That in turn increases the uptime of the assembler significantly. Maybe a stall doesn't even happen at all because you get a lot of time to remove the residuals.
That in turn makes it possible to use it even with belts that may have huge delays in item delivery/export, though maybe still not as effective as bots would be of course.
Re: programmable buildings (assembler, furnaces, plants)
Or while we are at make the direction freely settable. N, S, W, E signals to set direction or R = 0, 90, 180, 270.golfmiketango wrote:I think a more interesting and amusing solution to this would be to implement the ability of an inserter to reverse direction based on criteria from the circuit network -- in other words, to rotate itself 180 degrees on demand. This would also allow certain things to be done with trains that are not currently possible.
-
- Inserter
- Posts: 33
- Joined: Mon Mar 12, 2018 8:51 pm
- Contact:
Assembling machine circuit network compatibility
TL;DR
Let the assembling machines allow their recopies to be adjusted, based off of circuit network input.What ?
Assembling machines can be attached to the circuit network which could allow the circuit network to change the recipe of the assembling machine depending on the input.Why ?
The circuit network can be used to easily adjust an outpost to create a variety of resources upon demand, or to have an assembling machine switch to a different crafting material once the previously crafted material has been backed up. If iron gears are backed up, then the outpost can switch to iron rods until they themselves are backed up or have run out of raw materials.-wat3rstone
Re: Assembling machine circuit network compatibility
This has already been suggested two years ago in the following thread:
viewtopic.php?f=6&t=32697 programmable buildings (assembler, furnaces, plants)
EDIT: Meanwhile, the threads have been merged. Therefore, my above link now points to the current thread.
viewtopic.php?f=6&t=32697 programmable buildings (assembler, furnaces, plants)
EDIT: Meanwhile, the threads have been merged. Therefore, my above link now points to the current thread.
Last edited by Tekky on Sun Feb 10, 2019 1:13 pm, edited 1 time in total.
Re: programmable buildings (assembler, furnaces, plants)
[Koub] Merged into older topic with same suggestion
Koub - Please consider English is not my native language.
-
- Manual Inserter
- Posts: 1
- Joined: Sun Jul 22, 2018 5:00 pm
- Contact:
Ability to attach wires to assemblers/chemical plants.
TL;DR
Is there a way to add wires to assemblers and chemical plants to select a recipe?What ?
I'm building a cell-based factory, so I have a lot of assemblers in one location building the same thing. It would be a lot easier to plant a blueprint with a constant combinator attached to all the assemblers with a "select recipe" control so I can set the blueprint on all the assemblers at once. Copy/pasting recipes is ok if you've only got a few assemblers to set up, but if you've got a couple dozen (or more) all crafting the same thing it gets monotonous. Especially if you're putting down a lot of these cells.Re: programmable buildings (assembler, furnaces, plants)
[Koub] Merged into older thread with same suggestion.
Note : There are actually dozens threads asking for virtually every building of the game to be connectable to circuit network, in order to be read or controlled.
Note : There are actually dozens threads asking for virtually every building of the game to be connectable to circuit network, in order to be read or controlled.
Koub - Please consider English is not my native language.