|
|
|
I am trying to develop (on c#) a Point of Sale program(deployed on machine 1), with integrated kitchen display system(deployed on machine 2). I pretty much have an idea how to develop the individual programs, however, I haven't tried integrating thee machines (to function as one) before.
Here's a brief overview of the system im trying to do:
Machine 1 : Point of Sale
function - Enter customer orders(do basic POS functions), then PUSH the list of order from the POS to the kitchen display system.
Machine 2 : Kitchen Display System
function - Basically what it needs to do is to receive the list of orders pushed by the POS, then queues whenever several tickets were sent at the same time. The KDS bumps a ticket when the order was already prepared. The list queue then moves...and so on.
Machine 3 : Queue System
function - when the KDS (kitchen display system) bumps the ticket, the ticket number then displays on the screen. (e.g. serving: 21)
I'm suppose to implement this using one server running on windows XP or later, and three thin clients. Another option for me is to run this using terminal services(server 2003). Each thin client is equipped with a touch screen display.
I am hoping for your inputs. Thank you very much!!
|
|
|
|
|
What exactly is your question?
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Hi Richard,
Im trying to figure out how am I suppose to implement this project using three different machines. (e.g. when pos pushes the order, the list will appear on the kds monitor) I've never tried integrating 2 or more computers to function as one before.
|
|
|
|
|
Your question is very broad. But one idea is that you can have the POS machine put the order into a database table, and then the KDS machines query the table to see what new orders there are.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
I would prefer to have the data transferred realtime (upon input), rather than the KDS sending frequent queries to the database. Im thinking about socket programming(which I dont have any idea about). Is it applicable for my project?
|
|
|
|
|
Yes, it would be appropriate if you want to transmit the data in real time.
You'll need to look for a good winsock library that can take care of the communication for you if you don't know winsock programming. Search for "Winsock library".
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Thank you Richard. I would have to research on winsock library. It'll be a kick start for me. thanks again! - Carlos
|
|
|
|
|
And what happens if you can't connect? You can't transmit the data then. Plus, does it really have to be real time? Would a one minute delay really cause that much of a problem?
|
|
|
|
|
hello Pete,
The program i'm trying to make is supposedly for a quick service restaurant. More like a fastfood (e.g. Mcdonalds). It would be much better if I can get the data passed on to the KDS terminal immediately after being entered on the POS. If the KDS terminal cannot connect to the server, the operation will halt. 
|
|
|
|
|
Then have the KDS terminal poll at a faster interval (e.g. 5 seconds). The architecture you are proposing currently is far too fragile.
|
|
|
|
|
What you're proposing will not work. Sure, you can send the order, but what if the second machine is down or the network is down at the time?? Your design is not fault tolerant at all, not to mention unscalable.
Once the order is sent, your POS machine no longer has any record of it once the other machines come back up. So what happened to the order and how are you going to get it back??
The POS machine should put the order in a submitted orders table in a database. The RDS machine would then have to pickup the orders from that table WHEN IT CAN, not when the POS sends it.
|
|
|
|
|
Pete O'Hanlon wrote: And what happens if you can't connect? You can't transmit the data then
Then the servers start manually carrying the tickets to the kitchen.
Pete O'Hanlon wrote: Would a one minute delay really cause that much of a problem?
That is pretty long for a high volume restaurant. Assuming single floor layout a server can deliver it to the kitchen in less time than that.
|
|
|
|
|
Member 8605543 wrote: I would prefer to have the data transferred realtime (upon input), rather than
the KDS sending frequent queries to the database.
Incorrect.
Polling is exactly what you want in that situation.
Casinos tend to be the single largest single location multi-business type POS deployments. You could implement a polling system where all of the resturants in the casino used the same system and still easily handle the load using a single database.
Any other resturant would have far less traffic than that.
|
|
|
|
|
What happens if, during the KDS operation you realise it needs some more POS, do you send it back to the POS? You are REALLY going to have to look at your workflow carefully.
Personally I'd go with the polling a table solution, it being the simplest and probably the most robust.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Hi Mycroft,
Upon submission of data by the POS to the KDS, it cannot send back to POS. Just like those being used in fastfood chains, when you've already paid for your meal, you cannot make any changes, not unless you make a new transaction. Polling a table is another option. Is this what you mean: POS enters data to database, then the KDS queries the database for new entries every specified interval? isnt this cpu intensive? thanks! - Carlos
|
|
|
|
|
Member 8605543 wrote: when you've already paid for your meal,
Even more of a reason to put this stuff in the database without going to the RDS machine. Once you take customer money, losing their order is very unacceptable.
Member 8605543 wrote: isnt this cpu intensive?
You're making a small database query every 10 seconds, so no, it's not.
|
|
|
|
|
Thanks Dave! Ill do a research on how to poll a database every specified intervals. what would be an acceptable interval rate for this kind of application(fastfood)? 3 seconds?
I got your point. Indeed I would have to put it in a database so when the network is down, or KDS is unavailable, It can still fetch data as soon as it goes back.
|
|
|
|
|
I would have thought that 10 seconds would be fast enough.
|
|
|
|
|
Member 8605543 wrote: Just like those being used in fastfood chains, when you've already paid for your
meal, you cannot make any changes, not unless you make a new transaction
Not sure about fast food itself but in other types of restaurants you can adjust orders on the POS.
Member 8605543 wrote: isnt this cpu intensive?
Not as long as you put a small delay in it. Small is like a second.
|
|
|
|
|
I'm going to disagree with almost everyone else and say that you want to do this with sockets, albeit with the central server storing information in a database for audit/recovery reasons. That's because polling is almost always an inferior solution (you're transferring, at best, the same data, and generally the same data plus a large number of empty poll requests, while having a slower response time), and not necessary in this case.
The data recovery scenarios are:
- POS down: everything has to be manual anyway, in either case
- Server down: ditto
- KDS down: this is the one you have to worry about
The server should be in primary control of the data. The POS and KDS software should both keep a socket open to it, assuming you're running on hardware that can do that (unless you have 1000 tills you should be fine; if not, you might need to use a different approach, i.e. fire-and-forget web service calls for POS->server).
When you make an order, the POS should send messages to the server: make an order, order paid for, order modified (if applicable), and allow the front desk staff to post notes to a particular order. When an order is ready (I guess this is when it's made for a fast food place) the server should, as well as writing to its local data store (which it should do with every order status update for tracking purposes), also push a message to the KDS to add an item to its queue. When the kitchen finishes with an order they should be able to select the order on the KDS and that will cause a status update message to go back to the server, which the server will then forward to the appropriate till (if you want the information there).
If the kitchen rejects an order (for example if they're out of some ingredient), that should also be sent back to the till that sent it.
Data recovery: if the server goes down, you're fairly screwed, so make sure it has a UPS and safe shutdown mechanics. If the server loses connection with the KDS, or the KDS goes down and needs rebooting, it needs a special request it can send to the server to get the full list of things which should be on its queue (i.e. all orders which were 'in progress' the last time the server knew about it).
|
|
|
|
|
BobJanova wrote: I'm going to disagree with almost everyone else and say that you want to do this
with sockets, albeit with the central server storing information in a database
for audit/recovery reasons. That's because polling is almost always an inferior
solution (you're transferring, at best, the same data, and generally the same
data plus a large number of empty poll requests, while having a slower response
time), and not necessary in this case.
However polling almost always is a sufficient design.
And it is more than sufficient in this case because the traffic is very low.
Thus there is no point in making the design more complex.
|
|
|
|
|
Polling isn't really any less complex than persistent sockets, you still have to link the same components together and send the same messages. Generally it's more complex because you also have to worry about how to send data the other way, and how to detect a dropped connection. The exception is if there is an existing HTTP service that does what you want, so the socket solution is duplicating existing code, but that's clearly not the case here.
|
|
|
|
|
BobJanova wrote: Polling isn't really any less complex than persistent sockets,
Your solution requires clients, servers and a database.
Mine requires clients and a database.
Thus it is less complex.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
