Automated Weight Recording: Timbang

Being involved in recycling, we receive scrap frequently.  Suppliers bring scrap in the plant aboard their own trucks, the largest of which is a 6 wheeler.  Scrap are usually packaged in bales for ease in stacking inside the vans.  Another advantage of packaging in bales is that it is makes weighing faster on our pallet scale, since more than one bale can be stacked vertically on the scale's platform.  However, not all suppliers neatly organise their scrap in bales.  Weights were recorded by the receiver in a materials receiving report, which was where we write the type of scrap, and its corresponding weight.  We do this until all the contents of the supplier's truck has been weighed.  After finishing the truck's entire contents, this report was brought to the office, where the handwritten report was encoded, weights summed, and payment issued to the supplier per kilo of scrap.

Unloading time depends on how much the supplier brought, so it's variable.  Recording weights was quite fast, since all the receiver needed to do was to write down the correct weight under the proper scrap category.  The real latency occurred at the office.  Since the report was handwritten, it needed to be encoded in a spreadsheet.  If the supplier brought the scrap in bales, only a few weights would be recorded.  The weights would be few, but big in value.  But if the supplier is not organised this way, there would be many weights in the report, since loose scrap cannot be weighed all at once.  Weight records of loose scrap tend to be many, and small in value.  For example, say the total contents of a supplier's truck is 100 kg.  If it's organised in bales of 50 kg. each, then the report will only have 2 weights needed to be encoded.  But if the supplier did not organise the contents, so they're loose, only a few kilos can be weighed at a time, because the mound of scrap would cave.  Let's say each weighing is around 5 kg., that would be 20 weights that need to be encoded.  And that takes time.

Another problem we encountered with the handwritten method is unpredictable handwriting.  We have 3 receivers, who each has his own handwriting quirks the encoder has to decipher.  There were times a four at the report got encoded as a nine.  That situation would not be in favor for us, since we would have to pay the supplier more than what we got.  The opposite can also happen leaving the supplier shortchanged.  One thing is definite though: we want the correct weights to be recorded for us to have a clean, honest transaction.  In this way, we don't lose money, and the supplier would continue supplying.  There were more things that could go wrong in the handwritten method we used before such as misread weighs, encoding keystroke errors, etc., so a better, and faster method was needed.

The solution adopted by the company was to employ an automated, mobile approach in recording weights.  Luckily, the platform scale in service was using First Philippine Scale's FI03, which features an RS232 connection for printing.  This interface provided flexibility in connecting peripherals, such as a mobile phone running Android OS.  The challenge was that additional hardware was required.  An RS232 to USB converter cable was needed to connect the weighing scale to the phone.  However, having the cable alone is not enough.  Since the cable cannot directly connect to the weighing scale, and to the phone, some converters were required, with one being sourced from the US.  When the hardware part was complete, the next challenge was to develop an Android app to read weight data sent by the scale to be used in recording.  It was also realised later on that not all Android phones support USB Host API feature, which enables a phone to communicate with peripherals connected through its micro USB port.

After the challenges were hurdled, the app was deployed to the receivers.  Scrap is still placed on the platform scale, but no writing on paper is involved.  After the connection has been set up, the receiver only has to press a button on the weighing scale, and the weight data is transmitted to the phone, then this is recorded in a CSV file.  When unloading is done, the receiver uploads the file to a cloud storage  where it is retrieved by the purchasing staff.  Since it's a CSV file, it can be opened through a spreadsheet, where payment calculations are made depending on the types of scrap that was brought.  Tedious encoding is eliminated, along with its associated risks.  However, opening the CSV file, and summing weights for different scrap types (e.g. probably by alphabetizing the scrap types, removing duplicates, then using a conditional summing function), recording for inventory (e.g. copy and paste), and finally, printing a report seemed too tedious even when scrap receiving has been automated.

Summing weights, recording for inventory, and printing a report was mechanical task that took the time of our purchaser, which can be used for some other valuable task (i.e. looking for cheap suppliers).  It was in fact too mechanical, that I thought of having the computer do it instead of our purchaser.  Spreadsheets have a feature that can be used to automate tasks.  In this case, the task was to:

1.  Open the CSV file.
2.  Determine the scrap types delivered.
3.  Once unique scrap types have been determined, sum the weights of each scrap type.
4.  Record the scrap receiving in the inventory.
5.  Check the price per kilo of each scrap type received, and calculate payment.
6.  Print a report.

These are now all done by a small program in the spreadsheet.  Now, once the receiver uploads the CSV file of the scraps received, it only takes a press of a button to run the small program that does everything.  Time is conserved, and the purchasing staff is left to do more value added tasks.

Efficiency has its price.  Disregarding the price of the weighing scale, which we already had, we had to purchase a second hand, but high end phone that supports USB Host API, the cable, and adapters.  The cost was around P7000+ to automate the process, bulk of which went to the price of the phone.  It was only later on that a cheaper alternative was suggested in Google Developers Group Hackfair 2015.  Interestingly, a wireless solution is a cheaper approach.  I was able to source an RS232 to bluetooth dongle, which is relatively cheap compared to the price of buying a high end phone.  And after some development, bluetooth communication is now supported by the app.