I currently installed SambaPOS V5 and have almost everything communicating fine at the moment.
However, I want to install a KDS and was wondering if there is any hardware specific connection instructions about linking SambaPOS to a hardware like the Bematech LS8000?
Most of the instructions available have been about configuring the application itself and none specific about initiating the connection between the software and the hardware.
Just like setting up a printer, which I have done already, is there any specific instruction on how to set the hardware to communicates with POS software apart from just giving an IP address to the KDS address - how does SambaPOS locate the hardware. I intend using two (2) different KDS hardware and need to be specific in setting them up for their different purposes.
Any specific advice in this direction would be highly appreciated.
Those are the hardware the company currently have and we intend adapting them into the SambaPOS system.
The use of a Bump Bar which our kitchen staff are currently used to made this option a very important one as the other recommendation of using a keyboard and stuff just would make life unbearable considering our particular kitchen setup.
I initially intending getting the KDS / Bump Bars from TG3 on Bump Bar for Kitchen display but couldn’t get them and got the Bematech versions instead. Honestly, I had not gone through the entire article before making the purchase assuming that since such tools had been discussed, there should be a solution for their integration into SambaPOS.
I currently use a Micros POS system which uses a similar KDS and Bump Bar system which the kitchen staff are already very familiar with and we would like to use SambaPOS to replicate that setup in conjunction with the Bematech KDS/Bump Bar.
Would there be any difficult adapting them to the system?
If it’s IP based you would probably be able to just use it like a printer and print to it using generic text printer.
Getting feeback into samba is required might be different ball game.
If the bump bards are USB they will just be HID devices like a job specific keyboard and would likely be useable on a samba power display
Did you try plugging the bump bar into a PC and see if it just works as a keyboard? It is very likely it will, just test in notepad. If it works, then you can use with the kitchen display with bump bar tutorial.
Regarding the Bematech LS8000, I looked on their website, it is just an Android device that then runs their own KDS software (which is freeware). So nothing to say you couldn’t integrated that with SambaPOS but will be some work required on your part.
They have no specification as to how to send the data on their website, but they say you can contact them. They mention you need to send data in XML, so SambaPOS can do that but you will need to spend time to integrate it, there will be a bit of learning involved on your part or you can post an ad in the Ads category to have someone do it for you for a charge. But before you post any Ad, you need the full spec of how the data is sent first. It’s a bit strange the company don’t supply this first and that you can’t download their freeware software without emailing them, I think it could be a sales pitch to sell you something else when you contact them as they appear to have other paid solutions.
Honestly unless you have a lot of time to spend on this, you are probably better (cheaper) to just use a SambaPOS based solution, or since the Bematech LS8000 is just an Android device, you could also look at QMX which can connect to SambaPOS and run on Android to give you a kitchen display.
LS8000 KDS which is meant to work with the KB1700 Bump Bar
LS6100 KDS which works with the KB1700 Bump Bar
Initially, the plan was to use the LS6100 along with the KB1700 (which outputs to a notepad as suggested by makrjw). However, the problem with the KDS was that it only outputs to 24" screen whereas we have a 42" screen in the kitchen. A 24" would just be too small - thus my changing to the LS8000 which supports larger screen resolution.
Still thinking of how to proceed…
Markjw, thanks for the heads-up, I also thought somewhat like that when I couldn’t just download their so-called freeware.
Surely you can still connect to the 42" screen? The resolution on a 24" is likely to be the same - 1080p. Did you try it?
If it works in notepad, then you can use with SambaPOS or QMX for a KDS. With QMX, you may be able to use the LS8000 / LS6100 if you can open a web browser on the device. Otherwise you can get a mini PC and install SambaPOS on it, then connect it via HDMI to the 42" screen. Then do the KDS bump bar setup tutorial on SambaPOS, running the KDS on the mini PC and connect the bump bar to it.
Unless you get a good response from Bematech about their KDS freeware, and you are happy doing the required functionality on SambaPOS, I think your best option is either QMX using the existing LS8000 / LS6100, or SambaPOS using a Mini PC. A mini PC should not cost more than $150-200.
Regarding the resolution issue, the LS6100 simply refused to send signal to both of my Dell 27" and 28" monitors and also to my LG 32" monitor. I then brought a 24" Samsung from home and then, bang… the guy came up, working. Bematech support said it won’t work on anything greater than a 24" and I don’t know exactly why - it just refused to.
You just said something I was thinking about raising up as issue that might need to worked on by the SambaPOS community of developers.
My point is this:
Most KDS somewhat have a sort of mini PC that makes their operations possible - at least from the Micros and Bematech ones that we own - they do. You use a mouse and keyboard to generally set them up and they can also open browsers. Essentially I think they run deprecated versions of windows.
Given this scenario and the fact that the major player in the POS software business have stuffs like these that make their customers lives easier, would it be too much stress if the developers in the community look at how to effectively create workarounds that can allow users communicate with these devices. This is important so that we don’t just go throwing away expensive hardware all because we are changing our POS software to SambaPOS. If this can be achieved, I think it would be the decision to switch to SambaPOS a lot easier to make for a lot of people. I think this makes good business sense.
I believe that if slight modifications can be done to the existing SambaPOS that works on normal mini PCs, and it can be adapted to work on these branded KDS machines to be able to communicate effectively with SambaPOS, then we would have achieved a lot in the development of this opensource POS software.
Just thinking out loud while trying to solve this teething problem I am in. The QMX route may be the most likeable one to take at the moment.
Sambapos is not open source. Likely the ability to communicate with those devices exists already but every device is different. Sambapos provides unlimited capability to do almost anything. The main problem is I see people just expect developers to build custom solutuon because it’s easy. Instead we should be looking at the resources available and try making it work then if we hit snags ask the community and we can eventually get features that everyone can benefit from.
I’ll add too that sambapos works with more hardware than any other POS I’ve ever encountered. By design Sambapos is made to work with many hardware solutions and not proprietary tech.
Truth of the matter is that we all want a situation where SambaPOS can be much more easily integrated into existing systems as I believe that most of these hardware just have the brand’s software installed in them and that most of their communication feature are generic in form.
Frankly speaking, there is no physical difference between the Micros and the Bematech hardware I have at the moment. They practically operate the same way. Just like Micros gave us a thermal printer branded "Micros"but it is basically an Epson thermal printer.
What I was trying to say is that most of these hardware are generic to a very large extent and that SambaPOS can capitalize on their generic nature to develop something that can work for a larger number of these KDS hardware.
I bought the hardware even before finishing most of the articles on the forum based on this statement from Bematech’s website:
“Easy Integration With POS Application
Kitchen orders are sent from the Point of Sale to the KDS Manager through xml files. The markup language description is intuitive and simple, allowing applications that currently send orders to kitchen printers to quickly support our Kitchen Display System. The KDS Manager notifies the POS application (file) when orders have been bumped off or recalled. The software can be installed either in the same computer of a Point of Sale application or, if desired, on a different PC.”
Hardware companies are notorious for saying that. It’s just not true most of the time. But that said sambapos can send XML. We need to know what file it’s talking about.
Below is the information the company could offer me regarding how their KDS works:
"It is your POS software that communicates with the hardware. The LS6100 is just a firmware based control unit using windows. Your Samba has to be able to send .xml files in correct format to a shared folder on your POS computer that the LS6100 can pick up and display. It can also use TCPIP communication.
The LS8000 is an android based… using better resolution and more features. It also uses a shared folder drop or can communicate by TCPIP."
Thats one of the important bits, you need to know what format they want, XML might be a common format but you need to know key values etc (like column headers in a table) else the box wont understand what your sending it.
Surely they have documentation for the setup/config and also the code/formatting the box needs sending.
SambaPOS will be able to do this but it/you/we need to know what the box wants in order to setup samba acordingly.
Its like giving you a car, telling you where the fuel cap is but not telling you if its petrol or deisel. (if you knew nothing about cars other than they need either petrol or deisel and it didnt say under the cap LOL)
I was in communication with over this issue of documentation regarding the specifics of the content of the .xml file. A file they sent earlier didn’t contain the documentation but I have been shown where it was in my installation folder.
The issue now is how do I communicate that information to the community. Do I just attached the PDF in question?
I am just starting to use SambaPOS and have not gotten my hands dirty enough to undertake such a task of directing SambaPOS to produce such .xml content.
They have finally sent me the freeware and it contains extra documentation about how the .xml format should be.
Problem now is how to move forward, I just started with SambaPOS and such implementation is obviously beyond me for now and worsened by the time constraint I have at the moment for deployment.