I have a question that I wasn’t able to find a relevant answer for after searching and I hope you could help me.
I want to have a signal for when a belt backs up and stops moving. Right now I’m thinking about a decider that checks if two signals are both true, one for if a belt has stopped moving and one for if it is not empty. The second one seems simple, another decider that checks a belt segment in hold mode if anything > 0. For the first part though I’m stumped, not being good with combinators at all. Since a belt segment can’t be both in pulse and hold mode, I would need to wire a second, adjacent segment (the one before the one checking if it is empty) right? I have thought about a selector in random input mode, checking every 1 or 2 seconds (that’s 60 or 120, right?), outputting that to an arithmetic one (a counter) which then checks it against the maximum number it could have in that time to figure out if it is moving, but I’m lost at the how or whether it even is the right thought process.
Any help would be greatly appreciated.
Backed up belt detector help
Re: Backed up belt detector help
Example approach:
- a belt is either backed up or empty for one second, if there are no pulses for one second [condition 1]
- a belt is not empty, if there is at least 1 item on it by reading it in hold mode [condition 2]
- a belt is backed up, if [condition 1] AND [condition 2] are true
So we need as a minimum:
- a counter to count for 1 second (or whatever interval you want)
- read one belt piece in pulse mode
- read another belt piece in hold mode
Now let's build it:
- b1 is the belt piece in pulse mode
- b2 is the belt piece in hold mode
- implement the counter with 1 decider combinator (call it c1) and 1 constant combinator (call it cc) providing a C=-1 signal (we intend to count in negative numbers)
- connect cc to c1 with green wire and connect the input and output of c1 with a green wire as loopback.
- connect b1 with the input of c1 with red wire
- connect b2 with the input of c1 with green wire
- as output in c1 set C=input count. This will make the counter count down into the negatives, since the increment is -1.
this way the pulses are going in with green, and the held items are going in with red. On red, additionally the (negative) counter.
- as condition in c1 set EVERYTHING[red]=0 AND ANY[green]>0.
You now see the reason for the negative counter. It's ignored by the condition > 0, which only triggers for positive numbers. So the counter keeps counting if there are no pulses AND there are items on the belt. Or with other words, it resets if either there are pulses or there are no items on the belt.
And that's it. Connect something to the red wire output of c1 and check C. If C<-60, the belt is stalled, and if C>=-60, the belt is not stalled. 60 is an arbitrary number, it's 60 ticks (1 second).
This is one of the use cases where the improved 2.0 decider combinator really shines.
- a belt is either backed up or empty for one second, if there are no pulses for one second [condition 1]
- a belt is not empty, if there is at least 1 item on it by reading it in hold mode [condition 2]
- a belt is backed up, if [condition 1] AND [condition 2] are true
So we need as a minimum:
- a counter to count for 1 second (or whatever interval you want)
- read one belt piece in pulse mode
- read another belt piece in hold mode
Now let's build it:
- b1 is the belt piece in pulse mode
- b2 is the belt piece in hold mode
- implement the counter with 1 decider combinator (call it c1) and 1 constant combinator (call it cc) providing a C=-1 signal (we intend to count in negative numbers)
- connect cc to c1 with green wire and connect the input and output of c1 with a green wire as loopback.
- connect b1 with the input of c1 with red wire
- connect b2 with the input of c1 with green wire
- as output in c1 set C=input count. This will make the counter count down into the negatives, since the increment is -1.
this way the pulses are going in with green, and the held items are going in with red. On red, additionally the (negative) counter.
- as condition in c1 set EVERYTHING[red]=0 AND ANY[green]>0.
You now see the reason for the negative counter. It's ignored by the condition > 0, which only triggers for positive numbers. So the counter keeps counting if there are no pulses AND there are items on the belt. Or with other words, it resets if either there are pulses or there are no items on the belt.
And that's it. Connect something to the red wire output of c1 and check C. If C<-60, the belt is stalled, and if C>=-60, the belt is not stalled. 60 is an arbitrary number, it's 60 ticks (1 second).
This is one of the use cases where the improved 2.0 decider combinator really shines.
- 11-04-2024, 21-52-23.png (213.11 KiB) Viewed 856 times
- 11-04-2024, 22-06-08.png (133.66 KiB) Viewed 843 times
- Attachments
-
- Aufzeichnung 2024-11-04 215608.mp4
- (752.76 KiB) Downloaded 30 times
Re: Backed up belt detector help
Thank you very much for the detailed answer and the helpful demonstrations! It works as I hoped, irregardless of the nature of the stalling (one lane only for example), and is very compact as well.
I really need to wrap my head around the logic signals I think. I guess the different colour signals is so the condition checking if everything is zero is not contaminated by the existence of items on the hold mode segment? I also assume there is no point performance wise to make it so it checks every x ticks instead of always.
Additionally I was wondering what would be the best way to transfer the signals of multiple such lanes to various parts of the factory. With poles it would get contaminated and radars are similar/not practical I think. Is another decider to first transform the signal to something unique the best way?
Thanks again!
I really need to wrap my head around the logic signals I think. I guess the different colour signals is so the condition checking if everything is zero is not contaminated by the existence of items on the hold mode segment? I also assume there is no point performance wise to make it so it checks every x ticks instead of always.
Additionally I was wondering what would be the best way to transfer the signals of multiple such lanes to various parts of the factory. With poles it would get contaminated and radars are similar/not practical I think. Is another decider to first transform the signal to something unique the best way?
Thanks again!
Re: Backed up belt detector help
Yes, the different wires are used to check for 2 different conditions on different arbitrary input (wildcards) in the same combinator. Otherwise the content read in hold mode could be interpreted as constant pulses by the pulse condition.
The circuit network puts almost zero load to the system, so it makes no sense to think about circuit network performance impact. And using more circuits with the intention to manage load from circuits actually increases load, because there is more circuit instead of less. Using the least possible amount of combinators for some solution is already the best approach performance wise, and we have the minimum amount of combinators here. It's not possible to get the result with less.
About carrying circuit information across the factory: Group factory parts that need circuit connections to keep the connections short. Find paths from pole to pole not used otherwise. This may lead to some kind of wire web - try to keep this simple. But don't try to merge unrelated sources with arbitrary signals just for keeping the amount of wires low, because this could result in unexpected side effects with involved conditions.
Alternatives for using power poles to carry signal wires are constant combinators (just use them as basis, don't configure any signals within) or display panels (just as basis either, don't need to configure anything to display). Or use a belt piece for this and neither activate belt control nor belt reading). It's also often possible to create some kind of daisy chain with the involved buildings, so power pole usage for circuit wires can be minimized.
The circuit network puts almost zero load to the system, so it makes no sense to think about circuit network performance impact. And using more circuits with the intention to manage load from circuits actually increases load, because there is more circuit instead of less. Using the least possible amount of combinators for some solution is already the best approach performance wise, and we have the minimum amount of combinators here. It's not possible to get the result with less.
About carrying circuit information across the factory: Group factory parts that need circuit connections to keep the connections short. Find paths from pole to pole not used otherwise. This may lead to some kind of wire web - try to keep this simple. But don't try to merge unrelated sources with arbitrary signals just for keeping the amount of wires low, because this could result in unexpected side effects with involved conditions.
Alternatives for using power poles to carry signal wires are constant combinators (just use them as basis, don't configure any signals within) or display panels (just as basis either, don't need to configure anything to display). Or use a belt piece for this and neither activate belt control nor belt reading). It's also often possible to create some kind of daisy chain with the involved buildings, so power pole usage for circuit wires can be minimized.
Re: Backed up belt detector help
Thanks. And the inactive constant combinator/display seems elegant enough in congested areas indeed. 
Re: Backed up belt detector help
Thank you SO MUCH! You solved the exact problem I was tackling and explained it! Thank you thank you thank you.