Vibration Monitoring Tablet App (InCBM) for Food and Beverage Plants

How the brief came about

The challenge in this case was to see the vibration status of every motor, pump and blower on one screen. This food and beverage factory had already installed 3 vibration measurement boxes, but the measured values sat separately in each box. The on-site team therefore wanted to see which machine was starting to behave abnormally and to look back at trends, so they could plan repairs before a machine suffered serious damage.

The sensors and measurement boxes are equipment supplied by the client. Our work is the software that reads values from that equipment, stores them in a database and displays them on tablets the on-site team can carry around.

Requirements and constraints

The system had to work with the measuring equipment the factory already had and had to display on tablets. The main requirements and constraints were as follows.

• Read 76 Tags from 3 measurement boxes. Each measuring point has a Velocity value (mm/s) and an impact wave value (g).
• Support another 5 machines that send values through a Gateway, with Velocity split into X, Y and Z axes plus an impact wave value.
• The back end and database run on a server inside the factory.
• The measurement box has no API for receiving thresholds from outside, so thresholds that users set in the app are not sent back to the box.
• The system can retrieve the list of Events (alert events) from the measurement box, but cannot retrieve the analysis text (Analysis) because no API supports it.

Why this work did not require new sensors

New sensors were not needed because the sensors and 3 measurement boxes were already installed at the factory, and the brief was to read values from those boxes and bring them together on one screen. The main work was therefore combining values, not taking new measurements. The system requirements specified InCBM as the base of the app.

The app only displays information and raises alerts. The maintenance team decides which machines to inspect or repair. The system works in the following sequence.

1. 1

   Sensors measure vibration on the machine

   Measuring points are on the blowers, water pumps, rotary unit and conveying screw (Screw Feed), motors and bucket conveyor (Bucket). Each point gives a Velocity value and an impact wave value.

2. 2

   Reading values from the measurement boxes and Gateway

   A server inside the factory reads 76 Tags from 3 measurement boxes and reads values from another 5 machines sent through a Gateway.

3. 3

   Storing the values and comparing them with thresholds

   The Python FastAPI back end stores values in a PostgreSQL database, then compares them with each sensor's thresholds to assign a Normal, Watch or Critical status.

4. 4

   Displaying on the tablet app

   The first screen is a factory layout divided into zones, and a zone's frame changes colour when a machine raises an alert. Tapping a zone shows the machine list, photos of the actual machines with their sensor mounting points, and trend graphs whose history can be viewed by day, month or year.

5. 5

   Setting thresholds and acknowledging alerts

   Users can set Watch ranges separately for each sensor and enter their own alert messages. The history screen shows the time, machine and sensor involved. Once a user presses Acknowledge, the item disappears from the main screen.

Deliverables

Our delivery covers the complete software work, from reading values from the equipment through to the tablet app. This work does not include the sensors or measurement boxes.

• Data Pipeline (a data transfer system) that reads 76 Tags from 3 measurement boxes and stores them in a database on a server inside the factory
• Connecting the dashboard to the measurement boxes, including showing the measurement boxes' Event list in the app
• Reading values from 5 machines sent through a Gateway, with thresholds that can be set separately for Velocity on the X, Y and Z axes and for the impact wave value
• InCBM app on tablets: factory layout, status colours, machine photos with sensor mounting points, trend graphs, a threshold-setting screen and alert history
• A note field on the main screen for recording the latest maintenance cycle or repair so that other users can see it
• Installing the app on 2 of the factory's tablets, and the user manual

Steps and scope extension

During the project, the scope was extended to bring another 5 machines that send values through a Gateway into the same app. These machines have Velocity values on 3 separate axes, so a threshold-setting screen had to be added to support the values on each axis. The work sequence was as follows.

1. July 2025: project started, reading values from 3 measurement boxes
2. During the project: added 5 machines that send values through a Gateway
3. September 2026: installed the app on 2 of the factory's tablets, delivered the manual and notified the client that the work was complete
4. Current: the client's acceptance of the work is in progress

Confirmed results so far

The results confirmed so far are the installation and the delivery of documents. We installed the vibration monitoring app on 2 of the factory's tablets, delivered the user manual and notified the client that the work was complete in September 2026. After that, we revised the manual according to the client's comments.

The installed app reads 76 Tags from 3 measurement boxes, plus values from another 5 machines through a Gateway. This work has no figures yet measuring maintenance results, because the client's acceptance of the work is in progress, so we report only what documents confirm.

What we learned

This work offers 3 principles for connecting software to existing measuring equipment.

• Check the existing equipment's data channels, both outgoing and incoming, before designing functions. In this work, the measurement box could output values but had no API for receiving thresholds and no API for sending analysis text, so thresholds sit in the app and the app shows the Event list instead.
• Equipment and data supplied by the customer are conditions of the work plan. In this work, the sensors and data from the customer arrived later than planned, so these items and the dates they must be received should be stated in the plan from day one.
• Alerts need someone to acknowledge them and a history. The acknowledge button, history screen and repair note field let the team know which alerts someone has already taken up and which machines have recently been attended to.

How this approach can apply to your factory

If your factory already has a vibration monitoring system, you can use the same approach as this case: read values from the existing equipment, store them on a server inside the factory, then show the status on tablets. What needs adapting is how the data is read, when your equipment is another brand or outputs data through a different channel.

• Check how the existing measuring equipment can output data, and whether it can receive thresholds or commands back
• Prepare the complete factory layout, machine list and photos of the actual machines with sensor positions from the outset, because they are the main content of the screens
• Tablets must connect over Wi-Fi to the same network as the factory server, and the display should be tested on every tablet model that will actually be used
• Agree clearly who acknowledges alerts and who records repairs in the app