Internet Protocol: changing IP freely

jimms — Fri, 13 Aug 2010 14:10:36 +1000

Personally, I find the amount of problems you can easily foresee when coming up with a plan inversely correlates with how simply the plan is executed. In short, the jobs that look the simplest on paper turn out to be the ones that give the most headaches.

For instance, installing Hamachi on a string of virtual machines (VMs) was probably a good idea at the time for whoever did it, but when the developers tried to use the same VMs for testing our database sync utility, it took me a while to figure out that Amicus was using the Hamachi connecter settings when populating local and remote sync server records. This is fine if you want to test synchronising to external sites, but when we are just trying to test using our local network, it isn’t ideal.

Another IP-related headache I had recently was the use of an Ethernet thermal printer we had installed at a client’s site. Suddenly, it stopped working (most likely due to the recent use of a USB modem that had been plugged in) and the computer had been assigned a random IP address. Since the range had been changed from that of the Ethernet thermal printer, it stopped working. This wasn’t the first time this kind of thing has happened. At another site, in an effort to fix an internet problem, a technician had come in and reconfigured the site’s router and with it the IP address, as well as the IP addresses of all DHCP-configured machines on the network. Of course, the printer has a static IP and stopped working.

If only we could print directly to MAC addresses, perhaps…

A rolling POS gathers no moss!

jimms — Fri, 04 Jun 2010 11:14:06 +1000

It was a long, but necessary two years as a software testing engineer before I was given a position as head support and implementations officer. I say necessary because there is no better way of learning Amicus POS than using it all day, every day for an extended period of time.

Although Amicus POS is our flagship, it isnâ€™t by far the only software we dabble in. Providing a business solution isnâ€™t just giving someone turnkey POS software, but ensuring every piece of hardware and software is operating as efficiently as possible. For instance, letâ€™s look at all the software/hardware aspects involved if you want to open a service station:

As you can see, Amicus POS isnâ€™t our only concern in this scenario. Everything, down to the third decimal place of a sale, has to be configured to make sure every sale is precise according to regulation, which is no walk in the park. Some service stations have pumps that are decades old, whilst others are brand new. A lot of them communicate slightly differently, which can mean a simple click to change the configuration or can end up ripping the pump apart to change a circuit board inside.

Performance Stress and Load Testing on Integrated Platform

jimms — Tue, 15 Jun 2010 10:39:28 +1000

Due to the nature of a Point of Sale system, certain areas need stress testing (although it is not comparable to the loading of something like a website). Recently, several staff carried out a stress test of a restaurant environment, sending food orders from different tills, which would send the orders our printer spooler called â€˜Strip Printer Queueâ€™, which prints the orders out of the relevant strip printers.

The two main foci of the stress test were:

â€¢ To make sure that orders were being successfully handled by the Strip Printer Queue and being sent to the printers appropriately during a heavy load period.

â€¢ To make sure that in case of disaster during a heavy load period; that the tills will point towards a redundancy database and table service and kitchen printing would continue as normal.

The results were positive. Orders were noted and sent for a period of time where performance of the server was monitored. The main database was then taken offline and Amicus was switched to redundancy mode and the same process was followed. After a satisfactory period, all printed orders were reconciled.

Not cutting the SQL(mus)tard!

jimms — Wed, 23 Jun 2010 12:01:04 +1000

Ever since joining the support team here at Neotechnology full time, thereâ€™s starting to become a certain familiarity with the almost-ironic pain that follows after spending too much time on a problem stemming from job that should take you 10 seconds.

Whilst preparing our new sales laptop, I came across a problem where any copy of Amicus POS I had installed would error on startup, giving the same error as you would if you didnâ€™t have SQL server installed. I checked the installed programs list and all our dependencies - .NET Framework 3.5 SP1, SQL Native Client and the C++ redist were all installed. I tested the connection using the barebones SQL driver â€“ worked fine. Changed the SQL network settings to handle TCP/IP connections - still nothing. Went from a trusted connection to SQL authentication â€“ nada. These usually solved 95% of connection problems in-house.

Connecting to the database from someone elseâ€™s PC worked fine â€“ proving that the SQL server and permissions on the database were both not the problem, so it was narrowed down to a dependency on the laptop itself. â€œHmmnâ€ I pondered to myself, â€œI have checked all the dependencies. What gives?â€ But all the clues pointed to one of the dependencies - .NET, Native Client, C++ - not playing ball.

â€¢ If .NET was the problem, Amicus would crash on startup, or at the most, on a .NET dialogue
â€¢ Same goes for the C++ redist.
â€¢ If SQL Native Client wasnâ€™t installed, then Amicus couldnâ€™t communicate with the SQL serverâ€¦

I double checked Native Client â€“ it was definitely there under â€˜SQL Native Client 10â€™. â€œHang onâ€ I murmured as I furrowed by brow, â€œSQL Native Client 10 isnâ€™t what Amicus installs â€“ itâ€™s a part of the SQL 2008 Express package.â€ By the looks of it, our Native Client failed during install without a whimper because it gets ran silently because itâ€™s a x86 installer on a x64 machine. All connection testing worked fine because Native Client 10 was on the machine since SQL 2008 was put on it, but it seems like Amicus doesnâ€™t like to play nice with it.

So I hopped onto Microsoft.com and got the x64 SQL Native Client that gets bundled as a part of the SQL 2005 package and Amicus worked fine after that. I made a note of my opus in our internal knowledge base and suggested to the developers to make Amicus work with Native Client 10 to prevent any premature balding in our implementations team.

RS-232 Devices can Turn You into a Serial Killer

jimms — Fri, 20 Aug 2010 15:22:06 +1000

In a world that is gradually becoming nearly exclusively plug and play, POS hardware has yet to catch up. A scarily large majority of affordable hardware I have to deal with is still using RS-232 communication, the antithesis of plug and play.

• First step when setting up a serial device: get the communication settings right. Baud rate, data bits, parity and stop bits. Check the devices manual to get these (the odds of getting the right information in the manual directly correlates with how much you paid for the device). The flow control will be set as ‘None’ unless specified otherwise.
o Changing communications settings is a whole new thing on its own. You can edit the values by right clicking on the port in device manager and viewing its properties. A better way to do it is via a mode statement in the command line. The syntax for that is:
mode com1:9600,n,8,1
Where com1 is the port, 9600 is the baud rate, n is the parity, 8 is the data bits and 1 is the stop bits. Change as need be.

• Next, check if that com port is open. Run mode com1 (if the port you are trying to use is com1) in the command prompt with all programs that you know of that use that port closed. If it is open and available, it will return the communication settings. If the port is in use, then it will say Device COM1 is currently unavailable.
o Common software culprits that hold open com ports (in my experience) are the following: OPOS drivers, any kind of physical device drivers, USB to serial (or vice versa) conversion software, printer drivers (including remote ones that have been mapped back to a com port, run the net use command for more info). Check your msconfig startup tab for anything that runs and claims a port.

• If you’re still having trouble, disabling and enabling the com port in question via device manager has gotten me out of a tight spot. Keep in mind; this might only temporarily stop whatever was claiming the device.

• If you’re finding your device becomes unresponsive after a restart, then you could put the mode statement mentioned earlier into a batch script and put it in the startup folder.

• Hyperterminal is a program (probably not the best, but it will do) that can communicate with serial devices (I use it mostly with scales) that comes with Windows XP. Vista and Windows 7 users will need to yank the executable and .dll files off an XP machine.

• Some serial devices are still made with their own customer cables needed – if you can’t get any from the supplier or manufacturer, then you’re going to have to test out your soldering skills. Usually the manual or manufacturer website should contain a cable guide, with different cables for different POS systems. Since we run Amicus on Windows operating systems, the IBM 9-pin cable configuration works for us.

If you’re still struggling, you should probably stick to parallel and Ethernet solutions. No matter how used you get with serial devices, they will always find a way to throw you a curveball.

Small Tablet Proves Easy To Swallow

jimms — Wed, 25 Aug 2010 10:40:28 +1000

I found a Viliv S5 on my desk this morning to play with – our bright new hope in the field of wireless device solutions.

The Viliv is a tablet-style handheld PC basically – not much bigger than a PDA itself. It has a 4.8” touchscreen and a 1.33GHz processer; the idea here, for us, is to phase out the need for a completely different device to be used in a hospitality environment (to start with). This means we can centralise and standardise our software, removing the need to cater for PDA applications (cab files) and web services. This device communicates directly to the Amicus database via its built in wireless adapter.

To cater for its unique resolution, we revamped our full/touch screens (sales, finalising and login). The buttons might prove a bit fiddly on a 4.8” display for the fat-fingered among us, but most of us in the office seemed to navigate around alright, and with a stylus pen it proved very easy to use.

Since a full version of Amicus is running on it, anything is possible. Take sales (even cash; you could look into getting a Bluetooth barcode scanner that could dump its results straight to the device, and strap a wireless receipt printer to your belt. Bang, you have a mobile till), place meal orders or edit stock.

It’s very mobile, light and cradles in your forearm nicely. Not designed to be drop proof though, like some other rugged PDA’s, so make sure people have their strap on tightly whenever it is in their hands.

The manufacturer boasts a 6-hour battery usage life, which is more than enough to get you through a service (really depends on what you’re running on it). I can imagine it might be a bit shorter if you decided to run a redundant SQL server database on the device itself. Charging is done by plugging in a power pack into the side. A USB port also resides there, which was helpful for me being able to plug in a keyboard to install Amicus.

I tested the unit on a template database by running through a few sales, doing some table management and flicking over to a redundant database hosted on the device. I couldn’t notice any notable performance problems. I had some difficulties trying to reach things at the very top of the screen with my finger (not a problem with a stylus). An on screen keyboard is accessible from a button on the side.

Here's a tale for all the resellers - Bust-a-Queue

jimms — Fri, 17 Dec 2010 12:13:39 +1100

If you’re looking expanding the use of Amicus, then this might interest you. We’ve got our hands on a Bixolon SPP-R200 and gave it a whirl. It’s basically a mobile thermal printer that connects to its host via Bluetooth.

Only a small unit that fits comfortably in the palm of your hand, or hang off your belt. The SPP-R200 is used by the Hobart city council to print parking fines after they are issued with a PDA (I discovered this the hard way).

It was quite simple to set up, especially if you’ve had experience with Bluetooth devices before. In the office, I just used a run of the mill laptop with Bluetooth functionality. Switch on the Bluetooth, switch on the device, and pair them up. Admittedly I used Windows 7, which was smart enough to do a lot of it for you, but here’s a Microsoft KB article for using XP (SP2 needed). It will install the Bluetooth driver on a bridging com port (you can tell which one from Device Manager). I then installed a Generic/Text only printer driver on that com port, and used that from within Amicus. Set the width to about 32, choose the strip printer to only print single line per product and you’re right to go. Receipts, suspended sale dockets, payment slips and balance till printouts all look fine.

There was nothing wrong with the printer in terms of performance. The printing was quick and there was an acceptable delay between hitting the ‘Print Invoice’ button and the actual printing itself. I tried restarting the till and sure enough, the device stayed detectable. I fooled around with both the laptop and the printer itself, switching on and off again, changing databases, however as soon as you selected the Windows printer driver it began to print again.

Useful for:
• Queue Busting – You can use these with a mobile till during busy periods in order to process sales faster, since you can issue a tax invoice from here.
• Cut down lane time – Using the suspend sale docket feature within Amicus, you can cut down on the time customers spend in lanes. Ring the sale up on the mobile till, suspend it, and take the docket to the lane. Scan the suspend sale barcode on the docket, process payment.

Use in conjunction with: Viliv S5

Avaliable from: