The "two customers service queue" acts like a queue with a in-built feature to remove the item at the front of the queue (and any other item in the queue). Items stay in the queue, as long as requests for service are active. To achieve that, instead of storing n values (in this case 2), it stores one value and listens if requests for service are active. By behaving like that, it is also a queue from which items can be deleted, I would say.
I created this circuit for twin train unloading stations. I wanted the trains to be unloaded in sequence, not concurrently. Concurrent unloading often led to a cut stream of resources, when the trains left around the same time.
API
2csq.api.jpg (242.77 KiB) Viewed 2606 times
Requests are made by sending any positive continuous value to the connection points for customers one and/or two (A1, A2).
The information of who has to be serviced at the moment, can be read from the continuous output of the memory cell (OUT) (value 0 -> customer 1, value 1 -> customer 2).
The demo features twin unloading stations and 4 trains with various sized cargo. The signals, which are sent to the circuit to make requests for service are the cargo counts from the train stations. This way, the trains will continue to request service until they are empty. The entities, controlled by the output, are the belts in front of the splitter (rather than the unloading inserters, to ensure a continuous stream of resources).
2csq.demo.jpg (216.14 KiB) Viewed 2556 times
Behavior
The two customers are serviced in the sequence in which their requests arrive. The service for the customer at the front of the queue continues until it withdraws its request for service. Then the other customer is serviced, if it has a request active.
Dual truthtable
(I was not sure how to describe the behavior of this circuit properly with a table. A truthtable would not work as the sequence of requests counts. So I came up with this dual truth table for the state before and after a request change.)
Detailed description, explanation of dual truthtable
Important! Also if there is no active request, the circuit always tells one customer has to be serviced. When built, it is c1 initially. After that it is the customer whos request was active last. (columns 1,2,13,14)
Also, but trivial: The output does not change by itself, if no requests are made (columns 1,2)
If there are no active requests and a new request is made by any customer, that customer is serviced next. (columns 3 to 6)
If a customer is serviced and a new request is made by the other customer, the current service is continued (new request is queued). (columns 7, 8)
If two requests are active and the currently serviced customer withdraws its request, the other customer is serviced. (columns 9, 10)
Also, but trivial: The withdrawal of the request of the currently NOT serviced customer, does not change the output. (columns 11, 12)
Internals
Internals
2csq.parts.jpg (229.23 KiB) Viewed 2606 times
The circuit consists of a binary memory cell (1), the logic to request a change in service for each request/customer (2) and a pulser to change the value in the memory cell (3) (masked to value "1" (3a)).
The logic to request a change to who is serviced for each customer is:
(own request active) && (self currently not serviced) && (other request not active)
Re: Two customers service queue
Posted: Mon Oct 07, 2019 1:31 pm
by Impatient
I changed the description to make it more clear what this design does.
Re: Two customers service queue
Posted: Mon Oct 07, 2019 10:48 pm
by nog
I use the same system you show, but I managed the trick to alternatively unload trains in a way more simple than your solution.
dual_platform_station_1.png (604.7 KiB) Viewed 2503 times
dual_platform_station_2.png (904.81 KiB) Viewed 2503 times
I use the train ID from the station. When a train starts its departure from its station, the signal goes to zero, switch off the output belt from that station and switch on the belt from the other station, thus there is no lost of compression.
The logic is very simple : I use an SR latch as a binary memory cell, when train starts from station A gives a set signal (S), when train starts from station B gives a reset signal (R), belt from station A is active when S=0, belt from station B is active when S=1.
Re: Two customers service queue
Posted: Tue Oct 08, 2019 12:08 am
by Impatient
How does it behave, if a train leaves from station A, thus belts for station B are activated, but there is no train at station B and the next train arrives at station A again?
I tested your design and it works nicely. (One red wire was set up wrong.) I see how smart you set up the S-R. Very nice!
Re: Two customers service queue
Posted: Tue Oct 08, 2019 9:34 am
by nog
Thanks. I don't really remember the "gymnastics" in use when the train flow is not optimal, the design is a few years old now. All I can say now is the design is rock solid and bug free, it was hardly tested and massively used. By the way, you absolutely need no flaws in the belt compression to achieve perfect balanced unloading and synchronized empty wagons, the better is to use input lane balancers.
And sorry for the little wire bug, I extracted the station from a save and cleaned it to make it more readable, but I forgot to put the red wire between the station and the inputs of the combinators (as you can see on the screenshots). I realized it and changed the BP urgently, but too quickly.
