KDS Production Item Count Lag

[JoeD]

I just switched our restaurant to KDS screens in our quick service restaurant and was so excited about production item counts and how they could create massive efficiencies for our kitchen. Unfortunately we cannot rely on production item counts to update or be correct on a regular basis. Our workflow is all tickets come in from the register HELD by utilizing course pacing. All orders are then selected by the Expediter KDS  and fired at once (busy times this can mean 10 tickets being fired while 10 tickets are held). We have the setting for only counting fired tickets vs fired and held tickets.

It seems to be a batching issue or a hardware issue where the information on production item counts does not update in a timely manner or updates incorrectly. With an unlimited time frame I think the production items. I find that the most laggy production item counts are the ones which are attributed to the most items. For example, a beef patty is associated with every burger on our menu, 2 beef patties for doubles, 3 for tripples etc. This count is almost always wrong during a busy rush. 

I think our networking is pretty solid... all hardware besides handhelds are hard wired on ethernet with fixed IPs. But open to questions/solutions regarding this aspect of things

I've tried placing all KDS terminals in grid view and limiting the amount of closed orders stored to the minimum. I've also shrunk the time for showing tickets on the "recently fulfilled" option to 20 minutes which I think is our safest bare minimum time to restore tickets that have been mistakenly fulfilled.

There have been some errors due to configuration but I am familiar enough with our setup to identify these issues and resolve them (i.e. item overides the prep station or doesnt have all appropriate production item counts). These errors are easy to identify because they always occur when the same. In other cases, I am sure the direct configuration is not the issue but a lag of some sort. The count EVENTUALLY reaches the correct state but when its 3-15 minutes later this is too late to be of any use.

We are still seeing many errors on an hourly basis which is pushing us towards abandoning the feature all together. What good is a count you cant trust? 

Has anyone experienced this issue? Any potential solutions? 

Thanks,
Joe

[rcmck]

I did not try anything with grid view, but I can test those on Monday. I have a couple other things I want to test as well, I will get back to you. 

[JoeD]

Worth mentioning, I also have trouble emulating the issue outside of real service scenarios (bar also taking a high volume of orders). When i use test mode, or even just fire off a ton of orders at the kitchen POS and (and void them later) everything seems to work and no problematic levels of lag exist.

[rcmck]

That could be helpful, obviously if you are in test mode you must be closed when you are doing those tests and network traffic is very minimal? When you do start to see a lag do the devices themselves seem a little sluggish at all?