A method and system for dispensing beer in a smart beer machine with self-learning capabilities.

Abstract

This invention discloses a method and system for quantitative beer dispensing in an intelligent beer machine with self-learning capabilities. The method includes: real-time acquisition of the weight data of the beer glass using a gravity sensor, and selection of the corresponding target weight and initial dispensing time parameters based on the glass type; control of the beer machine's solenoid valve to perform the initial dispensing based on the initial dispensing time parameters, and calculating the actual dispensing weight and dispensing speed based on changes in the weight data after dispensing; dynamically calculating and performing the replenishment dispensing time required for the replenishment stage based on the difference between the actual dispensing weight and the target weight and the dispensing speed; recording the corresponding total dispensing time in a historical parameter database after each complete dispensing process; and dynamically updating the initial dispensing time parameters for the corresponding glass type based on multiple consecutive successful dispensing records in the historical parameter database. Using this invention, precise control and continuous optimization of the dispensing quantity can be achieved, improving the consistency and stability of quantitative beer dispensing.

Description

Technical Field

[0001] This invention belongs to the field of beer machine technology, and in particular to a method and system for dispensing beer in a smart beer machine with self-learning capabilities. Background Technology

[0002] With the popularization of craft beer culture and the upgrading of consumption, smart beer dispensers are gradually entering home and commercial settings. Existing quantitative beer dispensing technologies mostly employ timed control or simple flow metering methods. While timed control is simple to implement, it is affected by factors such as beer type, foam ratio, and pipeline pressure fluctuations, making it difficult to guarantee the correct alcohol content and prone to over-dispensing or under-dispensing. Flow metering, while capable of real-time monitoring of dispensing volume, suffers from bubble interference and beer residue buildup, leading to decreased accuracy over long-term use and higher costs. Furthermore, traditional equipment is mostly open-loop control, lacking adaptability to changes in the operating environment and making it difficult to establish accurate quantitative models for different glass sizes and beer types. When the equipment ages or the pipeline condition changes, the dispensing alcohol content will continuously deviate from the target, impacting the user experience. Summary of the Invention

[0003] The purpose of this invention is to provide a method and system for quantitative beer dispensing in an intelligent beer machine with self-learning capabilities, in order to overcome the shortcomings of the prior art, achieve precise control and continuous optimization of beer dispensing, and improve the consistency and stability of quantitative beer dispensing.

[0004] One embodiment of this application provides a method for dispensing beer quantitatively using an intelligent beer machine with self-learning capabilities, the method comprising: The weight data of the wine glass is collected in real time by a gravity sensor, and the corresponding target weight and initial pouring time parameters are selected according to the glass type. The solenoid valve of the beer machine is controlled to perform the first dispensing based on the initial dispensing time parameter, and the actual dispensing weight and dispensing speed are calculated based on the changes in weight data after dispensing. Based on the difference between the actual output weight and the target weight, and the output speed, the required replenishment time for the replenishment stage is dynamically calculated and the replenishment is performed. After each complete brewing process, determine whether the brewing error is within the preset stable range, and record the corresponding actual total brewing time to the historical parameter database. Based on multiple consecutive successful wine dispensing records in the historical parameter database, the initial dispensing time parameter for the corresponding glass type is dynamically updated, forming a self-learning control closed loop with continuous optimization capabilities.

[0005] Another embodiment of this application provides a self-learning intelligent beer dispensing system for beer machines, the system comprising: The data acquisition module is used to collect the weight data of the wine glass in real time through a gravity sensor, and select and call the corresponding target weight and initial pouring time parameters according to the glass type. The beer dispensing module is used to control the solenoid valve of the beer machine to perform the initial beer dispensing based on the initial beer dispensing time parameter, and to calculate the actual beer weight and dispensing speed based on the change in weight data after the beer dispensing is completed. The wine replenishment module is used to dynamically calculate the required replenishment time for the wine replenishment stage and perform wine replenishment based on the difference between the actual wine weight and the target weight and the wine dispensing speed. The recording module is used to determine whether the current wine-making error is within a preset stable range after each complete wine-making process, and to record the corresponding actual total wine-making time to the historical parameter database. The update module is used to dynamically update the initial dispensing time parameter of the corresponding glass type based on multiple consecutive successful dispensing records in the historical parameter library, forming a self-learning control closed loop with continuous optimization capabilities.

[0006] Another embodiment of this application provides a storage medium storing a computer program, wherein the computer program is configured to execute the method described in any of the preceding claims when running.

[0007] Another embodiment of this application provides an electronic device including a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to perform the method described in any of the preceding claims.

[0008] Compared with existing technologies, the present invention provides a method for quantitative beer dispensing in an intelligent beer machine with self-learning capabilities, which can achieve precise control and continuous optimization of beer dispensing volume, and improve the consistency and stability of quantitative beer dispensing. Attached Figure Description

[0009] Figure 1 A hardware structure block diagram of a computer terminal for a self-learning intelligent beer machine quantitative dispensing method provided in an embodiment of the present invention; Figure 2 A schematic flowchart illustrating a method for dispensing beer in a smart beer machine with self-learning capabilities, provided in an embodiment of the present invention. Figure 3 This is a schematic diagram of a self-learning intelligent beer dispensing system for a beer machine, provided as an embodiment of the present invention. Detailed Implementation

[0010] The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the present invention, and should not be construed as limiting the present invention.

[0011] The present invention first provides a method for dispensing beer in a smart beer machine with self-learning capability. This method can be applied to electronic devices, such as computer terminals, specifically ordinary computers.

[0012] The following detailed explanation uses a computer terminal as an example. Figure 1 This is a hardware structure block diagram of a computer terminal for a self-learning intelligent beer dispenser with quantitative beer dispensing capabilities, provided as an embodiment of the present invention. (See diagram for reference.) Figure 1 As shown, the computer device includes a processor, memory, and network interface connected via a system bus, wherein the memory may include non-volatile storage media and internal memory.

[0013] See Figure 2 The present invention provides a method for dispensing beer in a smart beer machine with self-learning capability, which may include the following steps: S201 collects the weight data of the wine glass in real time through a gravity sensor, and selects and calls the corresponding target weight and initial pouring time parameters according to the glass type. Specifically, the weight signal of the wine glass can be collected in real time using a gravity sensor at a preset sampling frequency of times per second, generating an original weight signal sequence. The core of this step is to continuously collect weight signals using a gravity sensor to obtain the raw weight data of the wine glass, providing a basic data source for subsequent signal processing and glass shape recognition, and ensuring the real-time nature and integrity of the collected data. The specific implementation method is as follows: The gravity sensor is the core component for weight detection in the entire quantitative wine dispensing system. Its working principle involves converting weight signals into electrical signals, and then performing analog-to-digital conversion to obtain digital weight data. During data acquisition, it is crucial to ensure complete contact between the sensor and the supporting platform to avoid external interference affecting acquisition accuracy. The preset sampling frequency setting must balance acquisition accuracy and the processing load of the control module. A frequency that is too low will result in incomplete signal acquisition, failing to capture the weight changes instantaneously when the wine glass is placed; a frequency that is too high will increase data redundancy and processing burden. Based on engineering experience, a sampling frequency of 100Hz is set, meaning 100 sets of weight signals are acquired per second. This frequency can both completely capture dynamic weight changes and control the data volume within a reasonable range.

[0014] Data acquisition is initiated when the beer dispenser is in standby mode and not dispensing beer. The control module sends a data acquisition command to the gravity sensor, which immediately enters continuous acquisition mode, acquiring a set of weight data every 0.01 seconds and simultaneously recording the acquisition timestamp of each set of data (accurate to 0.001 seconds) for subsequent time-dimensional analysis. The acquired raw weight signal includes irrelevant components such as the platform's own weight, environmental vibration interference, and sensor temperature drift. Therefore, the generated raw weight signal sequence is a discrete data sequence containing noise, denoted as m_raw(t), where t is the acquisition timestamp in seconds, and m_raw(t) is the raw weight value at the corresponding moment in grams, retained to three decimal places to ensure data accuracy.

[0015] In the example, after the sensor starts collecting data, the raw weight data collected within 0.01 seconds to 0.5 seconds are as follows: 120.356g, 120.361g, 120.358g, 125.623g, 125.628g, and 125.625g (approximately 120g is the weight of the platform itself, and approximately 125g is the weight after the wine glass is placed). These data are arranged in order of collection timestamp to generate a raw weight signal sequence. The sequence length increases continuously with the collection time until the glass type is identified and the initial parameters are determined. Then, a low-frequency collection (10Hz) is maintained for subsequent wine weight monitoring.

[0016] After the original weight signal sequence is generated, it is synchronously stored in the temporary buffer unit of the control module, and associated with auxiliary information such as the acquisition frequency, sensor working status, and ambient temperature, in order to prepare for subsequent Kalman filtering processing. At the same time, the validity of the acquired signal is monitored in real time. If 10 consecutive sets of data exceed the sensor range (0-500g), the sensor self-test process is triggered to ensure the reliability of the acquired data.

[0017] The original weight signal sequence is processed by Kalman filtering to eliminate measurement noise caused by environmental vibration and temperature drift, and a stable weight data sequence is generated. The core of this step is to denoise the original weight signal using the Kalman filter algorithm, eliminating measurement noise caused by environmental vibrations (such as equipment operation vibrations and personnel contact) and sensor temperature drift, thereby obtaining a stable and accurate weight data sequence. This provides accurate data support for subsequent cup shape recognition. The specific implementation method is as follows: The Kalman filter algorithm is an optimal filtering method based on the state estimation of linear systems. Its core advantage is its ability to process noisy discrete data in real time. Through an iterative "prediction-update" process, it gradually eliminates noise interference and outputs the optimal state estimate, making it very suitable for real-time denoising of gravity sensor weight signals. The core parameters of this algorithm include the process noise covariance Q, the observation noise covariance R, and the initial error covariance P0. The values ​​of these three parameters directly affect the filtering effect and need to be calibrated and set in conjunction with sensor characteristics and environmental interference.

[0018] The process noise covariance Q describes the random noise of the system itself (such as noise from the internal circuitry of the sensor). The smaller the value, the lower the system noise and the more stable the filtering result. Considering the characteristics of the gravity sensor, Q is set to 0.001. The observation noise covariance R describes the noise during the observation process (such as environmental vibration and temperature drift). The smaller the value, the lower the observation noise and the closer the filtering result is to the original observation value. Considering the actual working conditions, R is set to 0.01. The initial error covariance P0 is used to set the estimation error of the initial state. P0 is set to 0.1 to ensure the stability of the filtering in the initial stage of iteration.

[0019] The Kalman filter process consists of two stages: prediction and update. In the prediction stage, the weight estimate and error covariance at the current moment are predicted based on the stable weight value at the previous moment. In the update stage, the predicted value is corrected by combining the original weight signal at the current moment to obtain the optimal stable weight value and the updated error covariance at the current moment. This iterative process is repeated to process each set of data in the original weight signal sequence, and finally a stable weight data sequence m_stable(t) is generated.

[0020] In the example, the original weight signal sequence of 125.623g, 125.628g, 125.625g, 125.630g, and 125.626g, after Kalman filtering, yielded stable weight data of 125.625g, 125.626g, 125.625g, 125.627g, and 125.626g, respectively. The fluctuation range of the filtered data was reduced from ±0.007g to ±0.002g, effectively eliminating noise interference from environmental vibrations. For slow weight shifts caused by temperature drift (such as a shift of 0.005g every 10 seconds), the Kalman filter can also gradually correct through iterative updates, ensuring that the stable weight data sequence accurately reflects the actual weight of the wine glass.

[0021] After the stable weight data sequence is generated, its validity needs to be verified. The verification standard is: the absolute value of the difference between 10 consecutive sets of stable weight data is ≤0.003g, that is, the data is in a stable state. If the verification passes, the stable weight data sequence is stored in a temporary storage unit for subsequent cup shape recognition. If the verification fails, the Kalman filter parameters Q and R are adjusted and the filtering process is repeated until the data is stable to ensure the accuracy of subsequent cup shape recognition.

[0022] The weight change characteristics of the stable weight data sequence are analyzed, the peak detection algorithm is used to identify the placement action of the wine glass, and the weight feature template in the preset glass type database is matched based on the stabilized weight value to generate the current glass type recognition result. The core of this step is to identify the placement action of the wine glass by analyzing the changing characteristics of stable weight data, and then determine the glass type through weight matching, providing a basis for subsequent parameter retrieval. The specific implementation method is as follows: The weight change characteristics of a stable weight data sequence are the core basis for identifying the placement of a wine glass. Before the wine glass is placed, the stable weight data sequence remains basically stable (close to the weight of the support platform), and the weight change rate is extremely small. When the wine glass is placed on the support platform, the weight will rise rapidly in a short period of time, forming a significant weight peak, and then tend to stabilize. Therefore, by capturing this "rapid rise-tends to stabilize" change characteristic, the placement of the wine glass can be identified.

[0023] The core function of the peak detection algorithm is to capture the peak point of rapid weight increase and determine the completion of the wine glass placement action. The specific implementation process is as follows: First, calculate the weight change rate Δm / Δt between two adjacent sets of data in the stable weight data sequence (Δm is the weight difference between two adjacent sets of data, and Δt is the acquisition time interval of 0.01s). Set the weight change rate threshold k=5g / s. When the weight change rate of 3 consecutive sets of data is detected to be greater than k, and the weight change rate of subsequent data is less than 0.01g / s, it is determined that a weight peak has been detected, that is, the wine glass placement action is completed. The weight value corresponding to the peak is the initial stable weight after the wine glass is placed.

[0024] In the example, the stable weight data sequence starts from 125.625g. The weight change rates of the three consecutive sets of data are 6.2g / s, 5.8g / s, and 5.5g / s, respectively, all of which are greater than the threshold of 5g / s. The weight change rates of the next two sets of data are 0.008g / s and 0.007g / s, respectively, which are less than 0.01g / s. Therefore, a weight peak is detected, and the stable weight corresponding to the peak is 125.625g. The placement of the wine glass is confirmed to be completed. At this time, the stable weight value is recorded as the core basis for glass shape recognition and is denoted as m_cup.

[0025] The preset glass type database stores weight characteristic templates for different glass types. Its core content is the empty glass weight range (weight characteristic template) for each type of glass. Glass types are categorized into small, medium, and large glasses based on actual serving requirements. The weight characteristic template for each type is obtained through multiple empty glass weighing calibrations to ensure template accuracy, while also allowing for a certain weight fluctuation range to accommodate minor weight differences within the same type of glass. In the example, the preset glass type database's weight characteristic templates are: small glass empty weight 25.30-25.35g (corresponding to a total weight of 125.30-125.35g for the platform + small glass), medium glass empty weight 35.50-35.55g (corresponding to a total weight of 135.50-135.55g), and large glass empty weight 45.70-45.75g (corresponding to a total weight of 145.70-145.75g), where 100g is the fixed weight of the platform.

[0026] The glass type matching process is as follows: Subtract the platform's weight of 100g from the stable total weight m_cup of the glass after placement to obtain the actual weight of the empty glass, m_cup_empty = m_cup - 100g. Then, compare m_cup_empty with the weight feature templates in the preset glass type database. If the actual weight of the empty glass falls within the weight range of a certain glass type, the current glass type is determined to be that type; if it exceeds the weight range of all glass types, it is determined to be an unknown glass type, and a prompt signal is generated to remind staff to replace it with a standard glass type. In the example, m_cup = 125.625g and m_cup_empty = 25.625g, which falls within the small glass weight feature template range of 25.30-25.35g, therefore the current glass type identification result is "small glass".

[0027] After the cup type recognition result is generated, the recognition time, actual weight of the empty cup, weight feature template matching status and other information are recorded synchronously and stored in a temporary storage unit. If the recognition result is an unknown cup type, the subsequent process is paused until the standard cup type is replaced and re-recognized; if the recognition result is a known cup type, the subsequent parameter retrieval process is triggered to ensure the continuity of the entire wine dispensing control process.

[0028] Based on the current glass type recognition result, the target weight and initial pouring time parameters for the corresponding glass type are retrieved from the parameter configuration library, and the target weight value and initial pouring time parameters for the current glass type are generated.

[0029] The core of this step is to accurately retrieve the corresponding core control parameters from the parameter configuration library based on the identified glass type, providing a clear control benchmark for the subsequent initial dispensing operation, and ensuring the accuracy and efficiency of quantitative dispensing. The specific implementation method is as follows: The parameter configuration library is a database that stores the control parameters corresponding to various types of glasses. It corresponds one-to-one with the preset glass database. The core stored content includes the target weight and initial pouring time parameters for each type of glass. These parameters are set by combining the density characteristics of beer, glass capacity and conventional pouring speed, and are obtained through multiple tests and calibrations. At the same time, they can be flexibly adjusted according to the actual alcohol content requirements, and the parameter configuration library is updated synchronously after adjustment.

[0030] The target weight, denoted as m_target and measured in grams, is the core control objective for dispensing beer in a specific glass size. It is set based on the glass capacity and the density of beer (approximately 0.9 g / ml). For example, a small glass with a capacity of 50 ml has a target weight of 50 ml × 0.9 g / ml = 45 g; a medium glass with a capacity of 100 ml has a target weight of 90 g; and a large glass with a capacity of 150 ml has a target weight of 135 g. The target weight is also adjusted by 0.1-0.2 g to account for the weight of beer foam, ensuring that the actual dispensed volume meets the glass capacity requirements.

[0031] The initial pouring time parameter, denoted as t_initial and measured in seconds, is the preset duration for the first pour of wine for the corresponding glass type. It is set based on the target weight and the standard pouring speed (approximately 45g / s). The core principle is to ensure that the initial pour reaches 80%-85% of the target weight, allowing sufficient margin for subsequent top-ups. This avoids over-pouring, which increases the difficulty of top-ups, or under-pouring, which leads to excessively long top-ups and reduced efficiency. For example, for a small glass with a target weight of 45g and a standard pouring speed of 45g / s, the initial pour needs to reach 80% of the target weight (36g). Therefore, the initial pouring time parameter is set to 36g ÷ 45g / s = 0.8s. For a medium glass with a target weight of 90g, the initial pouring time parameter is set to 1.6s. For a large glass with a target weight of 135g, the initial pouring time parameter is set to 2.4s.

[0032] The parameter retrieval process is as follows: The control module reads the current cup type identification result from the temporary storage unit, uses the cup type identifier (such as "small", "medium", "large") as the search keyword, performs a matching search in the parameter configuration library, quickly locates the parameter entry corresponding to the cup type, extracts the target weight and initial pouring time parameters, and simultaneously fine-tunes the initial pouring time parameter according to the current ambient temperature (fine-tuning ±0.05s for every 5℃ change in temperature). This is because ambient temperature affects the viscosity of beer, which in turn affects the pouring speed. When the temperature rises, the beer viscosity decreases, and the pouring speed increases, so the initial pouring time needs to be shortened appropriately; when the temperature drops, it needs to be extended appropriately to ensure the stability of the initial pouring weight.

[0033] In the example, the current cup type is identified as "small cup". The target weight corresponding to the small cup is retrieved from the parameter configuration library as m_target=45.1g (including foam fine-tuning). The initial pouring time parameter is t_initial_base=0.8s. The current ambient temperature is 25℃ (the standard calibration temperature is 20℃). The temperature increases by 5℃, so the initial pouring time parameter is fine-tuned by -0.05s. Finally, the target weight value of the current cup type is generated as m_target=45.1g, and the initial pouring time parameter is t_initial=0.75s.

[0034] After the retrieval is completed, the generated target weight value and initial dispensing time parameter are validated for reasonableness. The validation criteria are: the target weight value must conform to the weight range of the corresponding glass type (small glass 44.9-45.3g, medium glass 89.8-90.2g, large glass 134.7-135.3g), and the initial dispensing time parameter must conform to the time range of the corresponding glass type (small glass 0.7-0.9s, medium glass 1.5-1.7s, large glass 2.3-2.5s). In the example, both parameters meet the validation requirements. After the validation is passed, they are stored in the instruction buffer of the control module and associated with information such as the glass type recognition result and ambient temperature to provide core parameter support for subsequent initial dispensing control, ensuring that the initial dispensing operation can be started accurately.

[0035] S202, based on the initial dispensing time parameter, control the solenoid valve of the beer machine to perform the initial dispensing, and after the dispensing is completed, calculate the actual dispensing weight and dispensing speed based on the change in weight data; Specifically, a PWM control signal can be generated based on the initial dispensing time parameter to drive the solenoid valve of the beer machine to open and perform the initial dispensing. At the same time, the opening time of the solenoid valve is recorded and a solenoid valve opening timestamp is generated. The core of this step is to convert the initial dispensing time parameter into a control signal that can drive the solenoid valve, accurately initiating the initial dispensing operation and simultaneously recording the opening moment. This provides a time reference for calculating the subsequent dispensing duration, ensuring the timeliness and controllability of the initial dispensing. The specific implementation is as follows: The initial dispensing time parameter, denoted as t_initial and measured in seconds, is the core control parameter retrieved in the previous step. Its value has been fine-tuned based on the glass type and ambient temperature to ensure that the initial dispensing weight reaches 80%-85% of the target weight. In the example, the current glass type is a small glass, and the initial dispensing time parameter t_initial = 0.75s, serving as the duration reference for the initial dispensing. The PWM control signal, or pulse width modulation signal, controls the opening degree and speed of the solenoid valve by adjusting the pulse duty cycle, thereby regulating the dispensing flow rate. This prevents the solenoid valve from opening too quickly, causing splashing and excessive foam, or opening too slowly, resulting in low dispensing efficiency. The core parameters of the PWM control signal include pulse frequency and duty cycle. The pulse frequency is set to 100Hz, meaning 100 pulses are output per second. This frequency ensures the stability of the solenoid valve drive signal, preventing vibration caused by excessively high frequency or inaccurate opening adjustment due to excessively low frequency. The duty cycle is set to 60%, meaning that within one pulse cycle, the high-level time accounts for 60% and the low-level time accounts for 40%. This duty cycle corresponds to 60% opening of the solenoid valve, achieving a smooth and uniform initial dispensing flow rate, suitable for the characteristics of beer dispensing. After the control module reads the initial dispensing time parameter t_initial=0.75s from the instruction buffer, it immediately starts the PWM signal generation module. Based on the preset pulse frequency and duty cycle, it generates a PWM control signal with a duration of 0.75s, and simultaneously amplifies the signal to ensure that the signal strength is sufficient to drive the solenoid valve to open normally. After the PWM control signal is generated, it is synchronously sent to the solenoid valve drive unit of the beer machine. Upon receiving the signal, the drive unit controls the solenoid valve to open smoothly at a preset opening degree. The opening process lasts for 0.05 seconds to avoid water flow impact caused by instantaneous opening, which could lead to beer splashing or pipeline vibration. At the instant the solenoid valve begins to open, the control module activates the high-precision timing module to record the system time at this moment, generating a solenoid valve opening timestamp. The timestamp accuracy is set to 0.001 seconds, accurately capturing the opening moment and providing a precise starting point for calculating the subsequent beer dispensing duration. The timestamp recording format combines Unix timestamps with millisecond-level supplementation. In the example, the system time at the moment the solenoid valve opens is 1699999980.123 seconds, therefore the generated solenoid valve opening timestamp is 1699999980.123 seconds, which is synchronously stored in the temporary storage unit and associated with initial beer dispensing time parameters, PWM signal parameters, and other information to ensure the traceability of time data.After the solenoid valve is fully opened, it enters a stable wine dispensing state. The control module monitors the working current and opening feedback signal of the solenoid valve in real time. If an abnormal current is detected (deviation from the normal range of ±10%) or the opening deviation exceeds 5%, the duty cycle of the PWM control signal is immediately adjusted to correct the opening of the solenoid valve, ensuring the stability of the initial wine dispensing process. At the same time, abnormal information is recorded to provide a basis for subsequent troubleshooting.

[0036] During the period when the solenoid valve is open, a stable weight data sequence is continuously collected. When the weight change rate is detected to be lower than the preset change threshold, the first dispensing is determined to be over, and a first dispensing end timestamp is generated. The core of this step is to continuously monitor the weight change during the initial distillation, determine the timing of the distillation stop based on the rate of weight change, and accurately record the end time to avoid under- or over-distillation, thus ensuring the accuracy of the initial distillation weight. The specific implementation method is as follows: After the solenoid valve opens and performs the initial dispensing, the control module maintains continuous data acquisition from the gravity sensor at a frequency of 100Hz, consistent with the stable weight data acquisition frequency from the previous step, ensuring the continuity and consistency of the weight data. The acquired weight data is simultaneously processed using Kalman filtering (filter parameters are the same as before: Q=0.001, R=0.01, P0=0.1) to eliminate measurement noise caused by equipment vibration and wine splashing during dispensing, generating a real-time stable weight data sequence m_stable(t). This sequence accurately reflects the dynamic changes in the weight of the wine in the glass.

[0037] The weight change rate is the core indicator for determining the end of the initial wine dispensing. It is calculated by dividing the difference between two adjacent sets of stable weight data by the collection time interval, i.e., Δm / Δt, where Δm is the difference between two adjacent sets of stable weight data (unit: g), Δt is the collection time interval (0.01s, corresponding to a 100Hz collection frequency), and the unit of weight change rate is g / s. It can intuitively reflect the rate of increase of wine weight per unit time, i.e., the instantaneous speed of wine dispensing.

[0038] The preset change threshold is set based on the characteristics of beer dispensing and the acquisition accuracy of the gravity sensor. In the later stages of the initial dispensing, the liquid approaches the preset initial dispensing weight, the dispensing rate will decrease slightly, and the foam on the surface of the liquid will gradually stabilize, and the weight change will become extremely slow. Therefore, the preset change threshold k_th = 0.02 g / s is set, which means that when the weight change rate of 3 consecutive sets of stable weight data is less than 0.02 g / s, the initial dispensing is considered to be over. At this time, the liquid and foam in the glass have basically stabilized, and the initial dispensing weight has reached the expected range.

[0039] In the example, during the initial dispensing process, the stable weight data sequence gradually increases from 125.625g (empty glass + platform weight). In the early stage, the weight change rate is maintained at 60-65g / s (corresponding to the dispensing flow rate). As the dispensing process nears its end, the weight change rate gradually decreases. When the three consecutive sets of stable weight data collected are 170.723g, 170.724g, and 170.725g, the calculated weight change rates are 0.01g / s, 0.01g / s, and 0.01g / s, respectively, all of which are lower than the preset change threshold of 0.02g / s. Therefore, it is determined that the initial dispensing process has ended.

[0040] At the instant the initial dispensing is completed, the control module immediately records the system time and generates an initial dispensing completion timestamp. The precision of the timestamp is the same as the start timestamp, both being 0.001s. In this example, the system time at the end is 1699999980.863s, therefore the generated initial dispensing completion timestamp is 1699999980.863s. After the completion timestamp is generated, it is synchronously stored in a temporary storage unit, associated with the start timestamp and the stable weight data sequence. Simultaneously, the control module sends a stop signal to the PWM signal generation module, stopping the output of the PWM control signal and driving the solenoid valve to begin closing. The closing process lasts 0.05s to ensure a smooth closure and prevent liquid leakage.

[0041] The time difference between the solenoid valve opening time stamp and the first dispensing end time stamp is calculated as the first dispensing duration, and the actual dispensing weight is calculated based on the weight change during this time period to generate the first dispensing weight value. The core of this step is to calculate the actual duration of the initial brewing by using two timestamps, and to calculate the actual brewing weight by combining the weight changes. This provides crucial data for subsequent replenishment time calculations and brewing speed fitting, ensuring the accuracy and effectiveness of the data. The specific implementation method is as follows: The initial dispensing duration refers to the actual time from when the solenoid valve is fully opened to when the dispensing is determined to be finished, denoted as t_first, and the unit is seconds. It is calculated by subtracting the solenoid valve opening time from the initial dispensing end timestamp. The calculation formula is t_first = t_end - t_start, where t_end is the initial dispensing end timestamp and t_start is the solenoid valve opening timetamp. The calculation result is rounded to three decimal places to ensure time accuracy and accurately reflect the actual duration of the initial dispensing.

[0042] In the example, the solenoid valve opening timestamp t_start = 1699999980.123s, and the initial dispensing end timestamp t_end = 1699999980.863s. Substituting these values ​​into the formula, we get t_first = 1699999980.863s - 1699999980.123s = 0.740s, meaning the initial dispensing duration is 0.740s. This duration deviates slightly from the initial dispensing time parameter of 0.75s. This deviation is due to the delay in the opening and closing of the solenoid valve and slight fluctuations in the dispensing flow rate. This deviation will be corrected in subsequent refilling stages.

[0043] The core of calculating the actual wine weight is to utilize the weight change before and after the initial pour, that is, the stable weight after the initial pour minus the stable weight of the empty glass before pouring. The calculation formula is m_first = m_end - m_cup, where m_first is the initial pour weight (unit: g), m_end is the stable weight after the initial pour (i.e., the stable weight data at the end of the pouring process), and m_cup is the stable weight of the empty glass before pouring (i.e., the total stable weight after the glass is placed minus the weight of the supporting platform). The calculation result is rounded to two decimal places to ensure weight accuracy.

[0044] In the example, the stable weight after the initial pour is m_end = 170.725g. The total stable weight of the empty glass before pouring (platform + empty glass) is 125.625g. The platform's own weight is 100g. Therefore, the stable weight of the empty glass is m_cup = 125.625g - 100g = 25.625g. Substituting these values ​​into the formula, we get m_first = 170.725g - 125.625g = 45.10g, meaning the initial pour weight is 45.10g. This value is close to the target weight of 45.1g for the smaller glass, indicating a good initial alcohol content with minimal deviation.

[0045] After calculation, the initial pouring duration and initial pouring weight are validated for reasonableness. The validation criteria are: the initial pouring duration should be within ±0.1s of the initial pouring time parameter (0.65s-0.85s in the example), and 0.740s meets the requirements; the initial pouring weight should be within 80%-85% of the target weight to ensure data reasonableness. After successful validation, the initial pouring duration t_first=0.740s and the initial pouring weight m_first=36.10g are stored in a temporary storage unit, linked with two timestamps, weight data sequence, and other information, triggering the subsequent pouring speed calculation process.

[0046] Based on the initial wine weight and the initial wine duration, the least squares method is used to fit the weight change curve, and the weight increment per unit time is calculated as the wine output speed to generate the wine output speed value.

[0047] The core of this step is to fit the weight-time change curve during the initial dispensing process using the least squares method, eliminating random errors and accurately calculating the dispensing rate. This provides the core rate parameter for the dynamic calculation of subsequent replenishment times, ensuring the correct dispensing concentration. The specific implementation method is as follows: Least squares is a curve fitting method based on minimizing the sum of squared errors. Its core advantage is its ability to fit the optimal linear or nonlinear curve from noisy discrete data, reducing the impact of random errors on the calculation results. It is very suitable for fitting weight-time data during the initial dispensing process, thereby accurately extracting the dispensing speed. The core of this fitting is to linearly fit the stable weight data sequence during the initial dispensing process with the corresponding time data. Because the dispensing flow rate is basically stable during the initial dispensing process, and the weight increases approximately linearly with time, the slope of the fitted line is the weight increment per unit time, which is the dispensing speed.

[0048] During the fitting process, the stable weight data sequence and corresponding time data during the initial dispensing are first extracted. The time data is calculated starting from the solenoid valve opening timestamp, and the relative time for each weight data point is calculated as t_rel = t - t_start, where t is the acquisition timestamp for each weight data point, and t_start is the solenoid valve opening timestamp. The unit of relative time is seconds (s), rounded to three decimal places. In the example, five core data sets during the initial dispensing are extracted: relative time 0.100s corresponds to a weight of 131.625g, 0.280s to 139.625g, 0.460s to 147.625g, 0.640s to 155.625g, and 0.740s to 161.725g. These data comprehensively reflect the weight change trend during the initial dispensing process.

[0049] The core formula for least squares linear fitting is y = kx + b, where y is the stable weight data (in g), x is the relative time (in s), k is the slope of the fitted line (i.e., the brewing speed, in g / s), and b is the intercept (i.e., the initial weight, in g). This is achieved by minimizing the sum of squared errors Σ(y_i - (kx_i + b)). 2 The optimal values ​​of k and b were calculated. During the fitting process, a fitting error threshold of 0.03g was set, meaning the maximum absolute deviation between the theoretical weight value obtained from the fitting and the actual weight data was ≤0.03g, to ensure fitting accuracy.

[0050] In the example, by performing a least-squares linear fit on the above 5 sets of data, the slope of the fitted line was calculated to be k = 40.54 g / s, the intercept was b = 127.57 g, and the fitting error was 0.02 g, which is below the fitting error threshold, indicating a qualified fit. The slope k = 40.54 g / s represents the dispensing speed, meaning that during the initial dispensing process, an average of 40.54 g of beer was dispensed per second. This value is within the normal dispensing speed range of beer machines (40-45 g / s), meeting the actual operating requirements.

[0051] The dispensing speed is denoted as v_out, in g / s, rounded to two decimal places. In the example, the dispensing speed value v_out = 40.54 g / s. After generation, a validity check is required. The check criteria are: the dispensing speed should be within the normal dispensing speed range (40-45 g / s), and the fitting error should be ≤0.03 g. In the example, both conditions are met, and the check is successful. After successful check, the dispensing speed value is stored in a temporary storage unit, linked to information such as the initial dispensing duration, initial dispensing weight, and fitting curve parameters. This provides a core rate basis for calculating the dispensing time in subsequent replenishment stages, ensuring that the replenishment time accurately matches the actual dispensing speed and achieving the accuracy requirements of quantitative dispensing.

[0052] S203, based on the difference between the actual output weight and the target weight and the output speed, dynamically calculate the required replenishment time for the replenishment stage and perform the replenishment. Specifically, the absolute difference between the initial weight of the wine and the target weight can be calculated to generate a weight deviation value; The core of this step is to quantify the deviation between the initial brew weight and the target weight, clarify the weight gap that needs to be made up during the replenishment stage, and provide a core benchmark for calculating the subsequent replenishment time, ensuring the targeted and accurate nature of the replenishment operation. The specific implementation method is as follows: The initial wine weight is the core parameter calculated in the previous step, denoted as m_first, in grams. Its value has been verified for reasonableness and can accurately reflect the actual weight of the initial wine. This value is the basis for calculating the wine replenishment deviation. In the example, the current glass type is a small glass, and the verified initial wine weight value m_first = 36.10g is within 80%-85% of the target weight value, which meets the expected requirements for the initial wine.

[0053] The target weight value is a quantitative control target generated based on the cup shape recognition result, denoted as m_target, and the unit is g. Its value has been fine-tuned in combination with the cup size, beer density and foam effect to ensure that it is consistent with the actual beer dispensing requirements. In the example, the target weight value m_target for the small cup is 45.1g. This value is used throughout the entire beer replenishment process and serves as the core benchmark for deviation calculation and beer replenishment termination.

[0054] The weight deviation value is the absolute difference between the initial weight of the wine and the target weight, denoted as Δm, with the unit being g. The calculation formula is Δm=|m_target-m_first|. The core purpose of using absolute value calculation is to eliminate the influence of the deviation direction (underweight or overweight), focusing only on the specific value of the deviation, ensuring the objectivity of the deviation data, providing a unified benchmark for subsequent wine replenishment time calculation, and avoiding errors in wine replenishment operations due to confusion of direction.

[0055] In the example, substituting m_target=45.1g and m_first=36.10g into the formula, we can calculate Δm=|45.1g-36.10g|=8.90g, which means the weight deviation is 8.90g. This value indicates that the initial output of wine is 8.90g short, and 8.90g of wine needs to be accurately added during the replenishment stage in order to make the final output weight meet the target requirements.

[0056] After the weight deviation value is generated, it needs to be verified for reasonableness. The verification standard is: the weight deviation value should be less than 20% of the target weight value. If the deviation value exceeds this range, it indicates that there is an anomaly in the initial dispensing (such as abnormal solenoid valve opening or excessive dispensing speed deviation). The replenishment operation needs to be paused, and the anomaly troubleshooting process needs to be triggered (such as checking the working status of the solenoid valve and recalculating the dispensing speed) to avoid blindly replenishing the alcohol, which could lead to a serious over-limit of the final alcohol content. In the example, 20% of the target weight value is 9.02g. 8.90g is less than 9.02g, so the verification is qualified, and the replenishment operation can be started normally. After the verification is passed, the weight deviation value Δm=8.90g is stored in the temporary storage unit, associated with the initial dispensing weight value, target weight value, and other information, triggering the subsequent replenishment dispensing time calculation process.

[0057] Based on the beer dispensing speed and weight deviation, an adaptive control algorithm is used to calculate the supplementary dispensing time, while taking into account the beer foam characteristics and liquid surface fluctuation factors to generate compensation time parameters. The core of this step is to combine the beer dispensing speed and weight deviation, and use an adaptive control algorithm to accurately calculate the time required for replenishment. At the same time, the effects of beer foam and surface fluctuations are taken into account, and the calculation results are corrected to ensure the accuracy of the replenishment time. The specific implementation method is as follows: The output speed value is the core parameter obtained by least squares fitting in the previous step, denoted as v_out, with the unit of g / s. Its value has been verified for reasonableness and can truly reflect the average flow rate of the initial output. In the example, the output speed value v_out = 40.54 g / s after fitting is qualified. This value directly determines the length of the replenishment time. The faster the flow rate, the shorter the required replenishment time, and vice versa.

[0058] Adaptive control algorithms are control algorithms that can dynamically adjust calculation results based on actual operating conditions. Their core advantage is that they do not require a pre-set fixed calculation model. They can adaptively optimize the replenishment time by considering minute fluctuations in the dispensing speed and the magnitude of weight deviations, avoiding replenishment deviations caused by fixed algorithms. This makes them ideally suited to the fluctuating operating conditions of beer dispensers. The core logic of this algorithm is: using the weight deviation value as the target replenishment weight and the dispensing speed value as the base flow rate, calculate the initial replenishment time, and then dynamically adjust it based on real-time operating condition deviations to ensure that the replenishment weight accurately matches the deviation value.

[0059] The formula for calculating the initial replenishment time is t_compensate_base=Δm / v_out, where t_compensate_base is the initial replenishment time in seconds. The calculation result is rounded to three decimal places to ensure time accuracy. In the example, Δm=8.90g and v_out=40.54g / s. Substituting these values ​​into the formula, we get t_compensate_base=8.90g / 40.54g / s≈0.219s, meaning the initial replenishment time is 0.219s.

[0060] The foam characteristics of beer are a crucial factor to consider during top-up. Foam is produced during beer dispensing, and its density is much lower than that of the beer liquid (approximately 0.3 g / ml for foam and 0.9 g / ml for beer liquid). Foam can cause an overestimation of the weight during top-up, leading to insufficient actual weight if not compensated. Therefore, a foam compensation coefficient, k_foam, is needed to correct the top-up dispensing time. The value of k_foam ranges from 0.92 to 0.96, dynamically adjusted according to the ambient temperature. Higher temperatures result in more foam, and a smaller k_foam value is used. In the example, with an ambient temperature of 25℃, k_foam is set to 0.94. The top-up dispensing time after foam compensation is t_compensate_foam = t_compensate_base × k_foam ≈ 0.219s × 0.94 ≈ 0.206s.

[0061] Liquid surface fluctuations can cause slight deviations in weight measurement data. During the refilling process, the wine dripping into the glass creates surface fluctuations, leading to momentary fluctuations in the weight data collected by the gravity sensor. Without compensation, this could result in inaccurate timing of the refill termination. Therefore, a liquid surface fluctuation compensation time Δt_fluctuate needs to be set to correct the refilling time. The compensation time is dynamically adjusted based on the flow rate; the faster the flow, the greater the fluctuation and the longer the compensation time. In the example, the flow rate v_out = 40.54 g / s, and Δt_fluctuate = 0.018 s is set.

[0062] The compensation time parameter, denoted as t_compensate, is the final replenishment time after combining foam compensation and liquid level fluctuation compensation, measured in seconds. The calculation formula is t_compensate = t_compensate_foam + Δt_fluctuate. In the example, substituting the data, we get t_compensate = 0.206s + 0.018s = 0.224s, meaning the generated compensation time parameter is 0.224s. After generation, the compensation time parameter needs to be validated for reasonableness. The validation standard is: the compensation time parameter should be greater than 0s and less than 1.2 times the initial replenishment time. In the example, 0.224s meets the requirements. After successful validation, it is stored in a temporary storage unit, linked to information such as the initial replenishment time, foam compensation coefficient, and liquid level fluctuation compensation time, providing a core time reference for subsequent replenishment operations.

[0063] Based on the compensation time parameter, a wine replenishment control command is generated, and the solenoid valve is controlled to perform a precise wine replenishment operation in pulse width modulation mode, generating a wine replenishment execution command. The core of this step is to convert the compensation time parameter into a wine replenishment control command that can drive the solenoid valve. By using pulse width modulation, the opening degree and opening duration of the solenoid valve are precisely controlled to achieve accurate wine replenishment. At the same time, a wine replenishment execution command is generated to ensure that the wine replenishment operation is traceable. The specific implementation method is as follows: The compensation time parameter t_compensate is the core control benchmark for the wine replenishment operation. After the control module reads the compensation time parameter 0.224s from the temporary storage unit, it immediately starts the wine replenishment control command generation module. Combining the characteristics of the wine replenishment operation, it generates the corresponding wine replenishment control command. The command includes core contents such as the solenoid valve opening mode, opening duration, and opening degree control parameters, ensuring that the solenoid valve can perform the wine replenishment operation according to the preset requirements.

[0064] The pulse width modulation (PWM) control method differs from the initial dispensing in its pulse width modulation parameters during the replenishment stage. The core requirements for replenishment are precision and slowness to avoid excessive foam and splashing. Therefore, the pulse frequency and duty cycle need adjustment. The pulse frequency during replenishment remains at 100Hz to ensure the stability of the solenoid valve drive signal. The duty cycle is adjusted to 40%, a significant reduction from the 60% duty cycle of the initial dispensing. This means that within one pulse cycle, the high-level time accounts for 40%, and the low-level time accounts for 60%. This duty cycle corresponds to a 40% opening of the solenoid valve, enabling a slow and uniform replenishment flow rate, reducing foam generation, and ensuring the replenished alcohol content.

[0065] The control module generates a 0.224s PWM (Pulse Width Modulation) control signal for replenishing the solenoid valve based on the compensation time and pulse width modulation parameters. Simultaneously, the signal is amplified to ensure sufficient strength to drive the solenoid valve to open correctly, preventing insufficient signal strength from causing valve opening deviation. After the PWM control signal is generated, it is simultaneously sent to the solenoid valve drive unit. Upon receiving the signal, the drive unit first checks the current state of the solenoid valve, confirming it is fully closed (it was closed after the initial dispensing). Then, it controls the solenoid valve to open smoothly at 40%, a process that lasts 0.03s, slower than the initial 0.05s, further preventing foaming from water flow impact.

[0066] After the solenoid valve is opened, the control module monitors the working current and opening feedback signal of the solenoid valve in real time to ensure that the solenoid valve always operates stably at 40% opening. If an abnormal current is detected (deviation from the normal range ±10%) or the opening deviation exceeds 3%, the duty cycle of the PWM control signal is immediately adjusted to correct the opening of the solenoid valve, ensuring that the replenishment flow rate is stable. At the same time, abnormal information is recorded to provide a basis for subsequent troubleshooting.

[0067] The replenishment execution command is a record of the entire replenishment operation process. It is generated simultaneously with the replenishment control command. The command includes core information such as the replenishment round, compensation time parameters, pulse width modulation parameters, replenishment start timestamp, and current glass type identification result. In the example, the replenishment execution command is explicitly stated as "Replenishment round 1, compensation time 0.224s, PWM frequency 100Hz, duty cycle 40%, start timestamp 1699999980.913s, glass type: small glass." After the replenishment execution command is generated, it is stored in the control module's temporary storage unit, linked to information such as compensation time parameters and dispensing speed, ensuring the traceability of the replenishment operation and triggering the weight monitoring process during subsequent replenishment.

[0068] The system monitors weight changes in real time during the replenishment process. When the real-time weight reaches the target weight, the replenishment operation is immediately terminated, and a replenishment completion signal is generated.

[0069] The core of this step is to monitor the weight change of the glass in real time during the topping-up process, accurately detect when to stop topping up, avoid insufficient or excessive topping up, ensure that the final weight of the wine dispensed meets the target requirements, and generate a topping-up completion signal to mark the end of the topping-up stage. The specific implementation method is as follows: During the replenishment process, the control module maintains continuous data acquisition from the gravity sensor at a frequency of 100Hz, consistent with the acquisition frequency during the initial dispensing and glass shape recognition stages, ensuring the continuity and consistency of weight data. The acquired weight data is simultaneously processed using Kalman filtering with the same filtering parameters as before (process noise covariance Q=0.001, observation noise covariance R=0.01, initial error covariance P0=0.1). This effectively eliminates measurement noise caused by splashing, equipment vibration, and liquid surface fluctuations during replenishment, generating a real-time stable weight data sequence m_compensate(t). This sequence accurately reflects the dynamic changes in the weight of the wine in the glass during replenishment.

[0070] The target weight, denoted as m_threshold and measured in grams, is the core criterion for stopping the replenishment. It is set based on the target weight value and the accuracy of the gravity sensor. Considering the slight deviation in weight detection (±0.05g), directly using the target weight value as the termination criterion might lead to over-replenishment. Therefore, the target weight is set slightly lower than the target weight value. The calculation formula is m_threshold = m_target - 0.05g. In the example, m_target = 45.1g. Substituting this into the formula, we get m_threshold = 45.1g - 0.05g = 45.05g. This means that when the real-time stable weight data reaches or exceeds 45.05g, the replenishment operation is immediately terminated to ensure that the final output weight is close to the target weight value, while avoiding over-replenishment.

[0071] The core logic of weight monitoring is: compare the current stable weight data with the target weight in real time. If the current stable weight data is less than m_threshold, continue to perform the wine replenishment operation and continuously monitor the weight change; if the current stable weight data is greater than or equal to m_threshold, immediately send a wine replenishment termination signal, stop outputting the PWM wine replenishment control signal, drive the solenoid valve to close quickly, and the closing process lasts for 0.03s to ensure smooth closing and avoid wine leakage that could cause weight deviation.

[0072] In the example, during the replenishment process, the real-time stable weight data gradually increased from 161.725g (the weight after the initial dispensing). When the collected stable weight data reached 45.06g (corresponding to a total weight of 170.685g), this value was greater than or equal to the target weight of 45.05g. The control module immediately determined that the replenishment had met the expected requirements, sent a replenishment termination signal, the solenoid valve stopped operating, and the replenishment operation ended. At this time, the replenishment end timestamp was recorded as 1699999981.137s, and the actual replenishment duration was calculated to be 1699999981.137s - 1699999980.913s = 0.224s, which is completely consistent with the compensation time parameter, indicating that the replenishment process was stable.

[0073] The replenishment completion signal is a digital signal that marks the normal end of the replenishment phase. It is generated after the replenishment operation terminates and includes key information such as the replenishment completion timestamp, actual replenishment duration, final stable weight after replenishment, replenishment deviation (the difference between the final weight and the target weight), and preliminary error assessment results. In the example, the replenishment completion signal is explicitly stated as "Replenishment complete, completion timestamp 1699999981.137s, actual replenishment time 0.224s, final weight 45.06g, replenishment deviation 0.04g." After the replenishment completion signal is generated, it is simultaneously sent to the main control unit of the control module, triggering the subsequent dispensing error judgment process. It is also stored in a temporary storage unit, linked to replenishment execution instructions, weight monitoring data, and other information, providing a basis for subsequent dispensing records and self-learning optimization.

[0074] S204 After each complete brewing process, determine whether the brewing error is within the preset stable range and record the corresponding actual total brewing time to the historical parameter database. Specifically, the percentage error between the final weight after replenishment and the target weight can be calculated to generate the error value for this batch of wine. The core of this step is to quantify the deviation between the final weight of the wine after replenishment and the target weight. A relative error percentage is used as the evaluation indicator to eliminate misjudgments caused by differences in glass shape and target weight, generating an accurate error value for this batch of wine. This provides a core quantitative basis for subsequent error assessment. The specific implementation method is as follows: The final weight after replenishment is the total weight of the wine, foam, and empty glass (including the weight of the support platform) after replenishment, denoted as m_final, in grams. This value is derived from the last stable weight data acquisition during the replenishment stage, and Kalman filtering eliminates all noise interference, accurately reflecting the final dispensing state. In the example, the stable total weight acquired after replenishment is 170.685g, the platform weight is 100g, and the empty glass weight is 25.625g. Therefore, the final weight of the wine after replenishment is m_final = 170.685g - 125.625g = 45.06g. This value is the actual weight of the final dispensing and is the core basis for error calculation.

[0075] The target weight value is denoted as m_target, and the unit is g. It is a quantitative control benchmark generated based on the cup shape recognition result. It has been fine-tuned by taking into account the cup size, beer density and foam effect. In the example, the target weight value m_target for the small cup is 45.1g. This value is used throughout the error calculation process and serves as the standard for deviation comparison.

[0076] The dispensing error value in this case is calculated as a relative percentage rather than an absolute error. The core reason is that relative error more objectively reflects the degree of deviation and avoids misjudgment due to different glass types (different target weights). For example, the same absolute deviation of 0.1g will have completely different effects on a small glass (target 45.1g) and a large glass (target 135.3g). Relative error effectively avoids this problem. The formula for calculating the relative percentage error is E_current=|(m_final-m_target) / m_target|×100%, where E_current is the dispensing error value in this case, expressed as a percentage and rounded to two decimal places. The absolute value ensures that the error value is non-negative, reflecting only the magnitude of the deviation and not considering the direction of the deviation (overweight or underweight).

[0077] In the example, substituting m_final=45.06g and m_target=45.1g into the formula, the calculation process is as follows: First, calculate the absolute difference |45.06g-45.1g|=0.04g, then calculate the ratio 0.04g / 45.1g≈0.000887, and finally multiply by 100% to get E_current≈0.09%, meaning the error value for this batch of wine is 0.09%. This value indicates that the final wine weight deviates from the target weight by only 0.09%, resulting in an extremely high alcohol content that meets the expected control requirements.

[0078] After the dispensing error value is generated, its validity needs to be verified. The verification criteria are: the error value should be greater than 0 (ensuring data validity and no collection anomalies) and less than the preset maximum allowable error (1.0%). If the error value is 0 or close to 0, the accuracy of the gravity sensor acquisition needs to be checked to rule out data acquisition anomalies. If the error value is greater than 1.0%, it indicates that the dispensing alcohol content is seriously substandard and should be marked as abnormal data, which will not be included in the subsequent historical record storage. In the example, 0.09% satisfies 0 < 0.09% < 1.0%, and the verification is qualified. The dispensing error value E_current = 0.09% is stored in the temporary storage unit, associated with the final weight, target weight, and other information, triggering the subsequent error evaluation process.

[0079] The error value of this wine production is compared with the upper and lower limits of the preset stable range to determine whether the error is within an acceptable range and generate an error assessment result. The core of this step is to set a scientifically reasonable preset stable range. By quantitatively comparing the relationship between the current wine-producing error value and the range threshold, it is determined whether the current wine-producing effect is acceptable, generating a clear error assessment result. This provides a basis for judgment for subsequent historical record storage. The specific implementation method is as follows: The preset stable range is an acceptable error range set based on the quantitative alcohol content requirements of the beer machine, the acquisition accuracy of the gravity sensor (±0.05g), and engineering practice experience. Its core function is to define whether the current beer dispensing has reached a stable and qualified accuracy standard. The range is expressed as a relative error percentage range, denoted as [E_low, E_high], where E_low is the lower threshold and E_high is the upper threshold. The setting of the upper and lower thresholds must take into account both the accuracy requirements and the rationality of operating condition fluctuations.

[0080] The lower limit threshold E_low is set based on the minimum acquisition accuracy of the gravity sensor. Since the sensor has a small inherent error (±0.05g), it is impossible to achieve absolute zero error. Therefore, E_low is set to 0.05%, which means that when the error value is ≥0.05%, it indicates that the data acquisition is normal and there is no abnormal interference. If the error value is <0.05%, it is necessary to check whether the sensor has acquisition deviation or data falsification to ensure the authenticity of the error data.

[0081] The upper limit threshold E_high is set based on the actual alcohol content requirement of the beer dispenser, combined with industry standards and user experience. E_high is set to 0.2%, which means that when the error value is ≤0.2%, the alcohol content of this dispensing is within a stable and acceptable range, and the dispensing effect is qualified. If the error value is >0.2%, it means that there is an abnormality in this dispensing (such as excessive replenishment deviation, fluctuation in dispensing speed, or excessive foam), and the dispensing effect is unqualified. The cause of the abnormality needs to be investigated, and it will not be included in subsequent historical records and self-learning updates.

[0082] The core logic of error assessment is as follows: when the current wine dispensing error value E_current satisfies E_low ≤ E_current ≤ E_high, the current wine dispensing error is considered to be within an acceptable range, and a "qualified" error assessment result is generated; when E_current < E_low or E_current > E_high, the error is considered to be within an unacceptable range, and a "unqualified" error assessment result is generated. Specifically, when E_current < E_low, it is marked as "data abnormality," and when E_current > E_high, it is marked as "accuracy not up to standard." These two unqualified cases correspond to different exception handling procedures.

[0083] In the example, the current dispensing error value E_current = 0.09%, and the preset stable range is [0.05%, 0.2%], where 0.05% ≤ 0.09% ≤ 0.2%. This fully meets the judgment criteria, so the generated error assessment result is "qualified," with the supplementary explanation "error is within the stable range, dispensing alcohol content meets the standard." If the current error value is 0.25%, an assessment result of "unqualified - accuracy not up to standard" is generated, pausing the subsequent historical record process and triggering anomaly investigation (such as checking whether there are deviations in the calculation of replenishment time and the fitting of dispensing speed); if the error value is 0.03%, an assessment result of "unqualified - data anomaly" is generated, triggering the gravity sensor self-check process.

[0084] After the error assessment result is generated, the judgment basis (this error value, the upper and lower limits of the preset stable interval, the comparison result), assessment time and other information are recorded synchronously and stored in the temporary storage unit. If the assessment result is "qualified", the subsequent actual total wine production time calculation process is triggered; if it is "unqualified", the current wine production record process is terminated, and only the abnormal information is saved to provide a basis for subsequent maintenance and troubleshooting.

[0085] When the error assessment result is qualified, the duration of the initial wine pouring and the supplementary wine pouring time are added together to calculate the actual total wine pouring time and generate the total wine pouring time value. The core of this step is to calculate the total time of the entire brewing process, assuming the brewing effect is satisfactory. This involves integrating the time data from the initial brewing and replenishment to generate the actual total brewing time value. This value serves as the core basis for subsequent self-learning updates to the initial brewing time parameters, ensuring the accuracy of self-learning optimization. The specific implementation method is as follows: The calculation of the actual total dispensing time is based on the premise that the error assessment result is "qualified". If the assessment result is "unqualified", there is no need to calculate the total dispensing time, because the dispensing process data that is unqualified cannot be used for self-learning optimization, and calculating the total dispensing time is meaningless. When the control module receives the "qualified" error assessment result, it immediately retrieves the two core parameters, the initial dispensing duration and the supplementary dispensing time, from the temporary storage unit and performs an cumulative calculation.

[0086] The initial dispensing time is denoted as t_first, in seconds. It is the actual duration of the initial dispensing calculated in the previous step, i.e., the difference between the solenoid valve opening time and the initial dispensing end time. After a reasonableness check, it accurately reflects the actual time consumed for the initial dispensing. In the example, t_first = 0.740s. The supplementary dispensing time is denoted as t_compensate, in seconds. It is the actual time consumed during the supplementary dispensing stage, i.e., the difference between the supplementary dispensing start time and the supplementary dispensing end time. It is consistent with the compensation time parameter. In the example, t_compensate = 0.224s.

[0087] The actual total brewing time is denoted as t_total, in seconds. The formula is t_total = t_first + t_compensate. The core logic of this formula is that the complete brewing process consists of two stages: the initial brewing and the replenishment. The total time is the sum of the times taken in the two stages. The calculation result is rounded to three decimal places to ensure time accuracy and to accurately reflect the overall brewing time.

[0088] In the example, substituting t_first=0.740s and t_compensate=0.224s into the formula, we can calculate t_total=0.740s+0.224s=0.964s, which means the total dispensing time is 0.964s. This value indicates that the total time for dispensing beer from the initial dispensing to the replenishment is 0.964s, which is reasonable and meets the dispensing efficiency requirements of the beer machine.

[0089] After the total dispensing time is generated, it needs to be validated for reasonableness. The validation criteria are: the total dispensing time should be greater than the initial dispensing duration and less than 1.05 times the sum of the initial dispensing duration and the supplementary dispensing time (minor time fluctuations are allowed, such as solenoid valve switching delays). It should also be within the reasonable range for the corresponding glass type (small glass 0.9-1.1s, medium glass 1.8-2.2s, large glass 2.7-3.3s). In the example, 0.964s is greater than 0.740s and less than 0.964s × 1.05 ≈ 1.012s, and is within the reasonable range for the small glass's total dispensing time, thus passing the validation. After successful validation, the total dispensing time value t_total = 0.964s is stored in a temporary storage unit, associated with the initial dispensing duration, supplementary dispensing time, and other information, triggering the subsequent historical dispensing record packaging process.

[0090] The current glass type recognition result, total dispensing time value, ambient temperature parameter and error assessment result are packaged into a complete dispensing record and stored in the historical parameter database to generate historical data records.

[0091] The core of this step is to integrate all the key parameters of this successful brewing process, package them into a complete brewing record, and store it in a historical parameter database. This provides basic data support for subsequent self-learning based on historical data and updating of the initial brewing time parameters, and achieves key data retention for the self-learning control closed loop. The specific implementation method is as follows: The core parameters of the package include four items, each with a clear function and indispensable, collectively forming a complete wine dispensing record. This ensures that the correlation between working conditions and dispensing parameters can be comprehensively analyzed during subsequent self-learning: The current glass type recognition result is used to distinguish historical data of different glass types, avoiding confusion between different glass type data. In the example, the current glass type recognition result is "small glass"; the total dispensing time value is the core basis for updating the initial dispensing time parameter during subsequent self-learning, reflecting the actual total time spent on this qualified dispensing; the ambient temperature parameter is used to analyze the impact of temperature on dispensing time and alcohol content. During subsequent self-learning, the temperature fine-tuning strategy of the initial dispensing time can be optimized based on the dispensing time corresponding to different temperatures. In the example, the current ambient temperature parameter is 25℃ (retaining one decimal place, the accuracy meets the requirements); the error evaluation result is used to mark the validity of this dispensing record, ensuring that only qualified records can be used for self-learning. In the example, the error evaluation result is "qualified", and the dispensing error value of 0.09% is attached to facilitate subsequent analysis of the accuracy fluctuation pattern.

[0092] In addition to the four core parameters mentioned above, to improve the traceability and usability of the records, two auxiliary parameters need to be added during packaging: the timestamp of the wine production record (accurate to 0.001s, 1699999981.167s in the example) and the initial wine production time parameter for this production (0.75s in the example). The auxiliary parameters do not participate in subsequent self-learning calculations, but can be used for fault tracing and operational review.

[0093] The complete wine dispensing record is packaged in a standardized format, integrating the following sequence: "glass type identification result - total dispensing time - ambient temperature - error assessment result - error value - generation timestamp - initial dispensing time." This ensures a consistent format, facilitating subsequent data retrieval, extraction, and analysis from the historical parameter database, and preventing data from being accessed incorrectly due to format inconsistencies. In the example, this complete wine dispensing record is: "glass type: small glass; total dispensing time: 0.964s; ambient temperature: 25.0℃; error assessment result: qualified; dispensing error value: 0.09%; generation timestamp: 1699999981.167s; initial dispensing time: 0.75s."

[0094] The historical parameter database is a database specifically designed to store all qualified wine dispensing records. Its core feature is that it stores wine dispensing records by glass type. Different glass types have their dispensing records stored in corresponding data partitions, making it easy to retrieve historical data by glass type later. At the same time, the database supports data updates and queries, and can retain the most recent 100 qualified wine dispensing records. Once this number is exceeded, the oldest record is automatically deleted to ensure that the database storage capacity is reasonable and to avoid data redundancy.

[0095] The specific process of recording and storing is as follows: The control module writes the complete wine production record after packaging into the corresponding partition of the historical parameter database according to the glass type. A dual verification mechanism is adopted during the writing process. After the first writing is completed, the record is immediately read from the database and compared with the original packaged data in the temporary storage unit to ensure that all parameters are consistent and there are no writing errors. If the comparison is inconsistent, the writing operation is immediately re-executed until the comparison is successful, so as to avoid data loss or errors caused by writing interference or database abnormalities.

[0096] After the writing process is complete, a historical data record is generated. This record is a complete entry stored in the database, containing all packaging parameters and the database storage address. Simultaneously, the control module generates a "historical record successfully stored" feedback signal, marking that this dispensing record has been successfully saved and can be used for subsequent self-learning processes. Once the historical data record is generated, all processes for this complete dispensing cycle are finished. The beer machine awaits the next glass placement to begin the next dispensing cycle. The stored historical data record will become the core basis for dynamically updating the initial dispensing time parameters for the corresponding glass type and achieving self-learning optimization, driving a continuous increase in the dispensing alcohol content.

[0097] S205, based on multiple consecutive successful wine dispensing records in the historical parameter library, dynamically update the initial wine dispensing time parameter of the corresponding glass type to form a self-learning control closed loop with continuous optimization capabilities.

[0098] Specifically, the system can periodically extract the most recent preset number of successful wine dispensing records for a specified glass type from the historical parameter database, filter out the records with qualified error evaluation results, and generate a valid historical dataset. The core of this step is to accurately extract effective data that can be used for self-learning optimization from the historical parameter database, remove unqualified records, ensure the validity and representativeness of the dataset, and provide high-quality data support for subsequent parameter prediction. The specific implementation method is as follows: The periodic extraction cycle is set by combining the beer dispensing frequency and the stability of the operating conditions. The core principle is to ensure that the data can reflect changes in the operating conditions in a timely manner, while avoiding excessive extraction that would overload the control module. Based on the beer machine's normal dispensing frequency (10-20 times per hour), the extraction cycle is set to automatically trigger a data extraction operation after every 8 complete dispensing processes. If the number of qualified records in the 8 dispensing processes is less than the preset number, the extraction will be postponed until the number of qualified records meets the requirements.

[0099] The specified cup type refers to the cup type for which parameters need to be updated. The historical parameter database is stored in partitions according to cup type. When retrieving data, the target cup type (such as small, medium, or large) must be specified first, and then the data must be extracted from the corresponding partition to avoid data confusion between different cup types and ensure the relevance of parameter updates. In the example, the specified cup type is small, and data is only extracted from the small cup partition of the database.

[0100] The preset number of times needs to balance data representativeness and computational efficiency. Too few times will lead to excessive randomness in the data and will not be able to reflect the wine-making pattern under real working conditions. Too many times will increase the data processing burden and may include outdated working condition data. Based on engineering practice experience, the preset number of times is set to 6 times, that is, extracting the 6 most recent successful wine-making records of the specified glass type. This number of times can cover minor fluctuations in working conditions and can quickly adapt to changes in working conditions.

[0101] The selection criteria for successful wine production records are those with an error assessment result of "qualified". During the selection process, the error assessment result of each record must be checked one by one. Records marked as "unqualified - inaccuracy" or "unqualified - data abnormality" are removed. Only qualified records with errors within the preset stable range [0.05%, 0.2%] are retained. If there are fewer than 6 qualified records in the most recent 6 records, the earlier records are extracted until 6 qualified records are selected.

[0102] In the example, the most recent 8 wine dispensing records are extracted from the small glass section of the historical parameter database. After filtering, 6 qualified records are obtained. Each record contains core information such as the glass type recognition result, total dispensing time, ambient temperature parameter, error assessment result, and the error value of this dispensing. These 6 qualified records are integrated to generate a valid historical dataset. The specific information of the dataset is as follows: Record 1 (total dispensing time 0.964s, ambient temperature 25.0℃, error 0.09%), Record 2 (0.958s, 24.8℃, 0.10%), Record 3 (0.972s, 25.2℃, 0.08%), Record 4 (0.966s, 25.1℃, 0.11%), Record 5 (0.956s, 24.9℃, 0.09%), Record 6 (0.968s, 25.0℃, 0.10%).

[0103] After a valid historical dataset is generated, it needs to be verified for completeness. The verification criteria are: the number of qualified records in the dataset is equal to the preset number of times (6), and the core parameters of each record (total brewing time, ambient temperature, and error value) are not missing or abnormal. The dataset in the example meets the verification requirements. After the verification is passed, it is stored in the temporary processing unit to trigger the subsequent time distribution feature analysis process.

[0104] Statistical analysis was performed on the total wine production time values ​​in the valid historical dataset. After removing outliers, the time mean and standard deviation were calculated to generate time distribution characteristics. The core of this step is to quantitatively analyze the total brewing time in the valid historical dataset, remove random outliers, and use the mean and standard deviation to reflect the central tendency and volatility of the brewing time, generating time distribution characteristics. This provides a quantitative basis for subsequent initial brewing time prediction. The specific implementation method is as follows: The total brewing time is the core analytical parameter in the valid historical dataset, denoted as t_total(i) (i=1,2,...,6, where i is the record number), and the unit is seconds. This parameter directly reflects the actual total time consumed for each qualified brewing and is the core link between the initial brewing time and the operating conditions. In the example, the total brewing times for the 6 records are 0.964s, 0.958s, 0.972s, 0.966s, 0.956s, and 0.968s, respectively.

[0105] The purpose of outlier removal is to eliminate random biases in the data (such as instantaneous voltage fluctuations or abnormal dispensing times caused by brief jamming of the solenoid valve) and to avoid outliers affecting the accuracy of statistical analysis results. In this study, the 3σ principle is used for outlier removal. The core logic of the 3σ principle is: if the total dispensing time of a certain data exceeds the range of ±3 times the mean of the total dispensing time of the valid historical dataset, then the data is determined to be an outlier and removed.

[0106] First, calculate the initial mean of the total brewing time of the valid historical dataset, μ_initial. The calculation formula is μ_initial=(Σt_total(i)) / n (n=6, which is the preset number of times). In the example, by substituting the data, we can get μ_initial=(0.964+0.958+0.972+0.966+0.956+0.968) / 6≈0.964s.

[0107] Then, the initial standard deviation σ_initial is calculated. The standard deviation reflects the degree of data fluctuation, and the formula is σ_initial=√[Σ(t_total(i)-μ_initial)). 2 [ / (n-1)], Substituting the data in the example, we can calculate σ_initial≈0.0057s, 3σ_initial≈0.0171s, so the outlier judgment range is μ_initial±3σ_initial≈0.964s±0.0171s, that is, 0.9469s-0.9811s.

[0108] The total dispensing time of each of the six records was checked one by one. All of them were within the range of 0.9469s-0.9811s and there were no outliers, so no one needed to remove them. If the total dispensing time of a record was 0.930s, which was outside the judgment range, it was judged as an outlier and removed. An earlier qualified record was then added from the historical database to ensure that the dataset still contained six valid records.

[0109] After outlier removal, the final time mean μ and standard deviation σ are calculated using the same formulas as the initial mean and standard deviation. In this example, there are no outliers, therefore μ≈0.964s and σ≈0.0057s. The time mean μ reflects the average total pouring time for the specified glass type under current conditions and is the basis for predicting the initial pouring time. The standard deviation σ reflects the degree of fluctuation in the total pouring time; the smaller σ is, the more stable the pouring time and the more stable the operating conditions. In this example, σ≈0.0057s, with minimal fluctuation, indicating that the current small glass pouring conditions are stable.

[0110] The time distribution feature integrates the time mean μ, standard deviation σ, and data fluctuation trend. Its core components include the time mean, standard deviation, fluctuation range (μ±σ), and data distribution trend (e.g., stabilizing or slightly fluctuating). In the example, the generated time distribution feature is: "The average total historical brewing time for a small glass is μ≈0.964s, the standard deviation σ≈0.0057s, the fluctuation range is 0.9583s-0.9697s, and the data is generally stable with no significant fluctuations." After the time distribution feature is generated, it is stored in a temporary processing unit, linked to the valid historical dataset, and triggers the subsequent initial brewing time prediction process.

[0111] Based on the time distribution characteristics, the exponential weighted moving average algorithm is used to predict the optimal initial brewing time for the next brewing, while also considering the impact of seasonal temperature changes on beer flow rate, and generating optimized initial brewing time parameters. The core of this step is to use an exponentially weighted moving average algorithm to predict the trend of the total brewing time, obtain the optimal initial brewing time, and then adjust it based on seasonal temperature changes to generate optimized initial brewing time parameters. This ensures that the parameters are suitable for the current operating conditions and seasonal temperature, thereby improving the alcohol content. The specific implementation method is as follows: The Exponentially Weighted Moving Average (EWMA) algorithm is an optimization algorithm for time series forecasting. Its core advantage is that it assigns higher weights to recent data and lower weights to older data, enabling it to quickly adapt to subtle changes in operating conditions. This avoids the problem of slow response of traditional arithmetic average algorithms to recent changes in operating conditions, making it very suitable for the dynamic prediction of beer dispensing time in beer machines. The core formula of this algorithm is y_t=α×x_t+(1-α)×y_{t-1}, where y_t is the current predicted value (optimal initial dispensing time), α is the smoothing coefficient, x_t is the current time mean μ, and y_{t-1} is the initial dispensing time parameter of the previous prediction.

[0112] The smoothing coefficient α ranges from 0 to 1. The larger α is, the higher the weight of recent data, and the more sensitive the predicted value is to recent changes in operating conditions. The smaller α is, the more stable the predicted value is, but the slower the response speed. Considering the stability of the beer machine's operating conditions (small fluctuations), α is set to 0.65. This value can ensure the responsiveness of the predicted value to recent changes in operating conditions, while avoiding excessive fluctuations in the predicted value, thus ensuring parameter stability.

[0113] The previously predicted initial pouring time parameter y_{t-1} is the initial pouring time parameter for the specified glass type in the current parameter configuration library. In the example, the current initial pouring time parameter y_{t-1} for the small glass is 0.75s, and the time mean μ≈0.964s. Substituting into the exponential weighted moving average algorithm formula, the optimal predicted initial pouring time value is calculated as y_t=0.65×0.964s+(1-0.65)×0.75s≈0.6266s+0.2625s≈0.8891s.

[0114] The initial brewing time accounts for 80%-85% of the total brewing time, so the predicted value needs to be proportionally corrected. The correction formula is t_initial_predict=y_t×k_ratio, where k_ratio is the proportionality coefficient. Combining the average total brewing time of 0.964s in the example and the proportion of the initial brewing time, we set k_ratio=0.82. Substituting into the calculation, we get t_initial_predict≈0.8891s×0.82≈0.729s, which means that the optimal predicted value of the initial brewing time without considering seasonal temperature changes is 0.729s.

[0115] Seasonal temperature changes affect beer viscosity, which in turn affects the pouring rate. Higher temperatures decrease beer viscosity, increasing the pouring rate and shortening the initial pouring time; conversely, lower temperatures increase viscosity, slowing the pouring rate and lengthening the initial pouring time. Therefore, a seasonal temperature correction factor, k_temp, needs to be set to adjust the predicted values. This correction factor is calculated based on the difference between the current season's average temperature and the standard calibration temperature (20℃). The formula is k_temp = 1 + (T_season - 20) × 0.002, where T_season is the current season's average temperature in °C, and 0.002 is the temperature influence coefficient, meaning that for every 1℃ deviation from the standard temperature, the correction factor is adjusted by 0.002.

[0116] In the example, the current season is summer, and the average temperature T_season = 25℃. Substituting into the formula, we get k_temp = 1 + (25 - 20) × 0.002 = 1.01, which means the seasonal temperature correction factor is 1.01. The corrected initial brewing time parameter is t_initial_optimize = t_initial_predict × k_temp ≈ 0.729s × 1.01 ≈ 0.736s, which means the generated optimized initial brewing time parameter is 0.736s. We retain three decimal places to ensure accuracy.

[0117] After the optimized initial dispensing time parameter is generated, it needs to be validated for reasonableness. The validation criteria are: the parameter value should be within the reasonable range of the initial dispensing time for the corresponding glass type (0.7-0.9s for small glasses), and the absolute value of the difference between the parameter and the previous parameter should be ≤0.05s (to avoid abnormal dispensing caused by parameter mutation). In the example, 0.736s meets the requirements. After the validation is qualified, it is stored in the temporary processing unit to trigger the subsequent parameter update process.

[0118] The optimized initial brewing time parameter is updated to the corresponding glass type record in the parameter configuration library, and the system is triggered to recalibrate, completing the self-learning parameter update cycle.

[0119] The core of this step is to write the optimized initial brewing time parameters into the parameter configuration library, replacing the original parameters, and then recalibrate the system to ensure that the parameters are adapted to the equipment status, completing a self-learning update cycle to achieve continuous optimization of the brewed alcohol content. The specific implementation method is as follows: The parameter configuration library stores the corresponding control parameters according to the glass type. Each glass type corresponds to one parameter record, which includes core content such as target weight and initial pouring time. When updating, it is necessary to first locate the parameter record of the specified glass type (small glass in the example), and then replace the original parameter with the optimized initial pouring time parameter to ensure the relevance of the update and avoid affecting the parameter settings of other glass types.

[0120] The update process employs a dual verification mechanism to ensure the accuracy and completeness of parameter writing. First, the control module packages the optimized initial dispensing time parameter (0.736s) from the temporary processing unit according to a preset format and sends it to the corresponding storage address in the parameter configuration library, overwriting the original initial dispensing time parameter for the small glass (originally 0.75s). After the first write is completed, the updated parameter is immediately read from this storage address and compared with the optimized parameter in the temporary processing unit. If the absolute value of the difference between the two is ≤0.001s, the update is confirmed to be successful. If the comparison is inconsistent, the write operation is immediately re-executed until the comparison is successful, avoiding parameter errors caused by write interference or database anomalies.

[0121] After the parameters are successfully updated, the control module automatically triggers the system recalibration process. The core purpose of the calibration is to ensure that the optimized initial alcohol output time parameters are compatible with the actual state of the equipment (accuracy of gravity sensor, opening degree of solenoid valve, pipeline resistance), so as to avoid the decrease in alcohol output caused by the mismatch between parameters and equipment state. The calibration process does not require manual intervention and is completed automatically by the control module.

[0122] The system recalibration process includes: gravity sensor calibration, which involves collecting the weight of the platform and the weight of an empty cup to calibrate the weight acquisition accuracy; solenoid valve opening calibration, which adjusts the duty cycle of the PWM control signal based on the optimized initial dispensing time parameters to ensure the solenoid valve opening matches the parameters; and dispensing speed calibration, which simulates a dispensing process, collects the dispensing speed, and verifies the rationality of the parameters. During calibration, if any abnormal equipment status is detected (such as excessive sensor accuracy deviation or abnormal solenoid valve opening), a calibration anomaly signal is immediately generated, prompting personnel to perform equipment maintenance; if no calibration anomalies are detected, a calibration pass signal is generated, confirming that the parameters are compatible with the equipment status.

[0123] After successful calibration, the self-learning parameter update process is complete. The control module generates a "self-learning parameter update successful" feedback signal, records the update time, parameter values ​​before and after the update, calibration results, and other information, and stores them in the self-learning record partition of the historical parameter library for easy traceability and maintenance. At this point, the initial dispensing time parameter for the small glass in the parameter configuration library has been updated to 0.736s. The next time the small glass dispenses wine, the system will call this optimized parameter to perform the initial dispensing operation, and then, through the accumulation of subsequent dispensing records, enter the next round of self-learning parameter update cycle.

[0124] This cyclical update mode can continuously adapt to changes in operating conditions (such as reduced barrel volume, changes in pipeline resistance, and seasonal temperature fluctuations), gradually optimize the initial dispensing time parameters, continuously increase the dispensing alcohol content, and ultimately form a self-learning control closed loop with continuous optimization capabilities, achieving long-term stability of quantitative dispensing alcohol content without manual intervention.

[0125] Another embodiment of the present invention provides a self-learning intelligent beer dispensing system for beer machines, see [link to relevant documentation]. Figure 3 The system may include: The data acquisition module 301 is used to acquire the weight data of the wine glass in real time through the gravity sensor, and select and call the corresponding target weight and initial dispensing time parameters according to the glass type. The beer dispensing module 302 is used to control the solenoid valve of the beer machine to perform the initial beer dispensing based on the initial beer dispensing time parameter, and to calculate the actual beer dispensing weight and dispensing speed based on the change in weight data after the beer dispensing is completed. The wine replenishment module 303 is used to dynamically calculate the required replenishment time for the wine replenishment stage and perform wine replenishment based on the difference between the actual wine weight and the target weight and the wine dispensing speed. The recording module 304 is used to determine whether the current wine-making error is within a preset stable range after each complete wine-making process, and to record the corresponding actual total wine-making time to the historical parameter database. The update module 305 is used to dynamically update the initial dispensing time parameter of the corresponding glass type based on multiple consecutive successful dispensing records in the historical parameter library, forming a self-learning control closed loop with continuous optimization capabilities.

[0126] This invention also provides a storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above method embodiments when running.

[0127] This invention also provides an electronic device, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to perform the steps in any of the above method embodiments.

[0128] Specifically, the aforementioned electronic device may further include a transmission device and an input / output device, wherein the transmission device is connected to the aforementioned processor, and the input / output device is connected to the aforementioned processor.

[0129] The above description, based on the embodiments shown in the figures, details the structure, features, and effects of the present invention. The above description is only a preferred embodiment of the present invention, but the present invention is not limited to the scope of implementation shown in the figures. Any changes made in accordance with the concept of the present invention, or equivalent embodiments modified to have equivalent changes, that do not exceed the spirit covered by the specification and figures, should be within the protection scope of the present invention.

Claims

1. A method for dispensing beer from an intelligent beer machine with self-learning capability, characterized in that, The method includes: The weight data of the wine glass is collected in real time by a gravity sensor, and the corresponding target weight and initial pouring time parameters are selected according to the glass type. The solenoid valve of the beer machine is controlled to perform the first dispensing based on the initial dispensing time parameter, and the actual dispensing weight and dispensing speed are calculated based on the changes in weight data after dispensing. Based on the difference between the actual output weight and the target weight, and the output speed, the required replenishment time for the replenishment stage is dynamically calculated and the replenishment is performed. After each complete brewing process, determine whether the brewing error is within the preset stable range, and record the corresponding actual total brewing time to the historical parameter database. Based on multiple consecutive successful wine dispensing records in the historical parameter database, the initial dispensing time parameter for the corresponding glass type is dynamically updated, forming a self-learning control closed loop with continuous optimization capabilities.

2. The method according to claim 1, characterized in that, The process of collecting real-time weight data of the wine glass using a gravity sensor and selecting the corresponding target weight and initial pouring time parameters based on the glass type includes: The weight signal of the wine glass is collected in real time by a gravity sensor at a preset sampling frequency of times per second, and the original weight signal sequence is generated. The original weight signal sequence is processed by Kalman filtering to eliminate measurement noise caused by environmental vibration and temperature drift, and a stable weight data sequence is generated. The weight change characteristics of a stable weight data sequence are analyzed, the placement action of the wine glass is identified by a peak detection algorithm, and the weight feature template in the preset glass type database is matched with the stabilized weight value to generate the current glass type identification result. Based on the current glass type recognition result, the target weight and initial pouring time parameters for the corresponding glass type are retrieved from the parameter configuration library, and the target weight value and initial pouring time parameters for the current glass type are generated.

3. The method according to claim 2, characterized in that, The process of controlling the solenoid valve of the beer machine to perform the initial dispensing based on the initial dispensing time parameter, and calculating the actual dispensing weight and dispensing speed based on changes in weight data after dispensing, includes: A PWM control signal is generated based on the initial dispensing time parameter to drive the solenoid valve of the beer machine to open and perform the first dispensing. At the same time, the opening time of the solenoid valve is recorded and a solenoid valve opening timestamp is generated. During the period when the solenoid valve is open, a stable weight data sequence is continuously collected. When the weight change rate is detected to be lower than the preset change threshold, the first dispensing is determined to be over, and a first dispensing end timestamp is generated. The time difference between the solenoid valve opening time stamp and the first dispensing end time stamp is calculated as the first dispensing duration, and the actual dispensing weight is calculated based on the weight change during this time period to generate the first dispensing weight value. Based on the initial wine weight and the initial wine duration, the least squares method is used to fit the weight change curve, and the weight increment per unit time is calculated as the wine output speed to generate the wine output speed value.

4. The method according to claim 3, characterized in that, The step of dynamically calculating and executing the replenishment time required for the replenishment stage based on the difference between the actual and target weight of the wine and the wine-producing speed includes: Calculate the absolute difference between the initial wine weight and the target weight to generate a weight deviation value; Based on the beer dispensing speed and weight deviation, an adaptive control algorithm is used to calculate the supplementary dispensing time, while taking into account the beer foam characteristics and liquid surface fluctuation factors to generate compensation time parameters. Based on the compensation time parameter, a wine replenishment control command is generated, and the solenoid valve is controlled to perform a precise wine replenishment operation in pulse width modulation mode, generating a wine replenishment execution command. The system monitors weight changes in real time during the replenishment process. When the real-time weight reaches the target weight, the replenishment operation is immediately terminated, and a replenishment completion signal is generated.

5. The method according to claim 4, characterized in that, After each complete dispensing process, it is determined whether the dispensing error is within a preset stable range, and the corresponding actual total dispensing time is recorded in the historical parameter database, including: Calculate the percentage error between the final weight after replenishment and the target weight to generate the error value for this batch of wine. The error value of this wine production is compared with the upper and lower limits of the preset stable range to determine whether the error is within an acceptable range and generate an error assessment result. When the error assessment result is qualified, the duration of the initial wine pouring and the supplementary wine pouring time are added together to calculate the actual total wine pouring time and generate the total wine pouring time value. The current glass type recognition result, total dispensing time value, ambient temperature parameter and error assessment result are packaged into a complete dispensing record and stored in the historical parameter database to generate historical data records.

6. The method according to claim 5, characterized in that, The method of dynamically updating the initial dispensing time parameter for the corresponding glass type based on multiple consecutive successful dispensing records in the historical parameter database, forming a self-learning control closed loop with continuous optimization capabilities, includes: Periodically extract the most recent preset number of successful wine dispensing records for a specified glass type from the historical parameter database, filter out the records with qualified error evaluation results, and generate a valid historical dataset; Statistical analysis was performed on the total wine production time values ​​in the valid historical dataset. After removing outliers, the time mean and standard deviation were calculated to generate time distribution characteristics. Based on the time distribution characteristics, the exponential weighted moving average algorithm is used to predict the optimal initial brewing time for the next brewing, while also considering the impact of seasonal temperature changes on beer flow rate, and generating optimized initial brewing time parameters. The optimized initial brewing time parameter is updated to the corresponding glass type record in the parameter configuration library, and the system is triggered to recalibrate, completing the self-learning parameter update cycle.

7. A self-learning intelligent beer dispensing system for beer machines, characterized in that, The system includes: The data acquisition module is used to collect the weight data of the wine glass in real time through a gravity sensor, and select and call the corresponding target weight and initial pouring time parameters according to the glass type. The beer dispensing module is used to control the solenoid valve of the beer machine to perform the initial beer dispensing based on the initial beer dispensing time parameter, and to calculate the actual beer weight and dispensing speed based on the change in weight data after the beer dispensing is completed. The wine replenishment module is used to dynamically calculate the required replenishment time for the wine replenishment stage and perform wine replenishment based on the difference between the actual wine weight and the target weight and the wine dispensing speed. The recording module is used to determine whether the current wine-making error is within a preset stable range after each complete wine-making process, and to record the corresponding actual total wine-making time to the historical parameter database. The update module is used to dynamically update the initial dispensing time parameter of the corresponding glass type based on multiple consecutive successful dispensing records in the historical parameter library, forming a self-learning control closed loop with continuous optimization capabilities.

8. The system according to claim 7, characterized in that, The acquisition module is specifically used for: The weight signal of the wine glass is collected in real time by a gravity sensor at a preset sampling frequency of times per second, and the original weight signal sequence is generated. The original weight signal sequence is processed by Kalman filtering to eliminate measurement noise caused by environmental vibration and temperature drift, and a stable weight data sequence is generated. The weight change characteristics of a stable weight data sequence are analyzed, the placement action of the wine glass is identified by a peak detection algorithm, and the weight feature template in the preset glass type database is matched with the stabilized weight value to generate the current glass type identification result. Based on the current glass type recognition result, the target weight and initial pouring time parameters for the corresponding glass type are retrieved from the parameter configuration library, and the target weight value and initial pouring time parameters for the current glass type are generated.

9. A storage medium, characterized in that, The storage medium stores a computer program, wherein the computer program is configured to execute the method of any one of claims 1-6 when it is run.

10. An electronic device comprising a memory and a processor, characterized in that, The memory stores a computer program, and the processor is configured to run the computer program to perform the method of any one of claims 1-6.

Images