Hanging system business processing method and device and storage medium

Abstract

The invention relates to a hanging system service processing method and device and a storage medium, and the method comprises the steps: configuring an asynchronous thread and a cache database; the cache database is used for storing clothes hanger data written by the service main thread after outbound card reading, and the service main thread synchronously triggers issuing of a clothes hanger outbound instruction while writing the clothes hanger data; acquiring a plurality of clothes hanger data from the cache database by using an asynchronous thread, and temporarily storing the clothes hanger data in an asynchronous thread queue; when the number of the clothes hanger data in the asynchronous thread queue exceeds a preset number threshold value or the time from the completion of the last yield calculation task reaches a preset time threshold value, triggering the yield calculation task by using an asynchronous thread, and calculating yield data; and pushing the yield data to the preset terminal board for real-time display by utilizing the asynchronous thread, and through the method and the device, the problem that rapid outbound and real-time data statistics cannot be taken into account in related technologies is solved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of clothing / logistics hanging system, in particular to a hanging system business processing method and device and a storage medium. BACKGROUND

[0002] In the production and operation of the clothing / logistics hanging system, the coordination efficiency of outbound control and yield statistics directly affects the production circulation speed and production data monitoring accuracy, and is one of the core links for stable operation of the hanging system. In related technologies, the full synchronization execution or outbound instruction priority scheme is adopted, which cannot meet the dual needs of fast outbound and real-time data statistics.

[0003] At present, there is no effective solution to the problem that related technologies cannot meet the dual needs of fast outbound and real-time data statistics. SUMMARY

[0004] The embodiments of the present application provide a hanging system business processing method, device and storage medium to at least solve the problem that related technologies cannot meet the dual needs of fast outbound and real-time data statistics.

[0005] In a first aspect, the embodiments of the present application provide a hanging system business processing method, which comprises:

[0006] An asynchronous thread and a cache database are configured; the cache database is used to store hanger data written by a business main thread after reading a card for outbound, and the business main thread synchronously triggers the issuing of the hanger outbound instruction while writing the hanger data;

[0007] The asynchronous thread is used to acquire a plurality of hanger data from the cache database and temporarily store the hanger data in an asynchronous thread queue;

[0008] When the number of hanger data in the asynchronous thread queue exceeds a preset number threshold or the time from the completion of the last yield calculation task reaches a preset time threshold, the asynchronous thread is used to trigger a yield calculation task and calculate yield data;

[0009] The asynchronous thread is used to push the yield data to a preset terminal board for real-time display.

[0010] In some embodiments, when the number of hanger data in the asynchronous thread queue exceeds a preset number threshold or the time from the completion of the last yield calculation task reaches a preset time threshold, the asynchronous thread is used to trigger a yield calculation task and calculate yield data, which comprises:

[0011] When the number of hanger data in the asynchronous thread queue exceeds a preset threshold, or when the time since the last production calculation task was completed reaches a preset time threshold, the asynchronous thread is used to trigger the production calculation task.

[0012] Based on preset historical entry and exit time data, the start time of the production calculation task is determined;

[0013] When the start time arrives, the production calculation task is executed, and the production data is calculated.

[0014] In some embodiments, the historical entry and exit time data includes the entry and exit times of each historical task; determining the start time of the production calculation task based on preset historical entry and exit time data includes:

[0015] Based on the entry and exit times of each historical task, calculate the shortest and longest entry and exit times.

[0016] The start time of the production calculation task is determined based on the shortest and longest entry / exit times.

[0017] In some embodiments, after the production data is pushed to a preset terminal dashboard for display, the method further includes:

[0018] Obtain the production update time and hanger exit time; the production update time is the time when the production data is pushed to the terminal dashboard.

[0019] Based on the production update time and the hanger exit time, the start time of the next production calculation task is adjusted.

[0020] In some embodiments, adjusting the start time of the next production calculation task based on the production update time and the hanger exit time includes:

[0021] If the production update time is earlier than the hanger exit time, calculate a first time difference between the production update time and the hanger exit time;

[0022] The sum of the start time of the current production calculation task and the first time difference shall be used as the start time of the next production calculation task.

[0023] In some embodiments, adjusting the start time of the next production calculation task based on the production update time and the hanger exit time includes:

[0024] If the production update time is later than the hanger exit time, calculate a second time difference between the production update time and the hanger exit time;

[0025] Based on the second time difference, the start time of the next production calculation task is adjusted.

[0026] In some embodiments, adjusting the start time of the next production calculation task based on the second time difference includes:

[0027] When the second time difference is greater than a preset threshold, the difference between the start time of the current production calculation task and the second time difference is taken as the start time of the next production calculation task.

[0028] When the second time difference is less than or equal to a preset threshold, the start time of the current production calculation task is taken as the start time of the next production calculation task.

[0029] In some embodiments, pushing the production data to a preset terminal dashboard for display includes:

[0030] The production data is pushed to a preset terminal dashboard for display via a WebSocket long connection.

[0031] Secondly, embodiments of this application provide a service processing device for a suspended system, the device comprising:

[0032] The configuration module is used to configure asynchronous threads and a cache database; the cache database is used to store the hanger data written by the main business thread after the card is read out of the station, and the main business thread simultaneously triggers the issuance of the hanger out-of-station command while writing the hanger data.

[0033] The acquisition module is used to acquire multiple hanger data from the cache database using the asynchronous thread, and temporarily store the hanger data in the asynchronous thread queue;

[0034] The calculation module is used to trigger a production calculation task and calculate production data using the asynchronous thread when the number of hanger data in the asynchronous thread queue exceeds a preset quantity threshold, or when the time since the completion of the last production calculation task reaches a preset time threshold.

[0035] The push module is used to push the production data to a preset terminal dashboard for real-time display using the asynchronous thread.

[0036] Thirdly, embodiments of this application provide a storage medium storing a computer program thereon, which, when executed by a processor, implements the hanging system business processing method as described in the first aspect above.

[0037] Compared to related technologies, the hanging system business processing method, apparatus, and storage medium provided in this application, through the configuration of asynchronous threads and a cache database, solves the problem in related technologies of being unable to simultaneously handle rapid departure and real-time data statistics. The cache database stores hanger data written by the main business thread after card reading at the departure station, and the main business thread simultaneously triggers the issuance of hanger departure instructions while writing the hanger data. Multiple hanger data are retrieved from the cache database using an asynchronous thread, and the hanger data is temporarily stored in an asynchronous thread queue. When the number of hanger data in the asynchronous thread queue exceeds a preset threshold, or when the time since the completion of the last production calculation task reaches a preset time threshold, a production calculation task is triggered using an asynchronous thread, and production data is calculated. The production data is pushed to a preset terminal dashboard for real-time display using an asynchronous thread.

[0038] Details of one or more embodiments of this application are set forth in the following drawings and description to make other features, objects and advantages of this application more readily apparent. Attached Figure Description

[0039] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0040] Figure 1 This is a hardware structure block diagram of a terminal for a suspended system service processing method according to an embodiment of this application;

[0041] Figure 2 This is a flowchart of a hanging system business processing method according to an embodiment of this application;

[0042] Figure 3 This is a schematic diagram of the overall process of the hanging system business processing method according to an embodiment of this application;

[0043] Figure 4 This is a flowchart illustrating the asynchronous thread queue management process according to an embodiment of this application;

[0044] Figure 5 This is a structural block diagram of a hanging system service processing device according to an embodiment of this application. Detailed Implementation

[0045] To make the objectives, technical solutions, and advantages of this application clearer, the application is described and illustrated below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the application. All other embodiments obtained by those skilled in the art based on the embodiments provided in this application without inventive effort are within the scope of protection of this application. Furthermore, it is understood that although the efforts made in such a development process may be complex and lengthy, for those skilled in the art related to the content disclosed in this application, modifications to design, manufacturing, or production based on the technical content disclosed in this application are merely conventional technical means and should not be construed as insufficient disclosure of the content of this application.

[0046] In this application, the reference to "embodiment" means that a specific feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places in the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment that is mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described in this application may be combined with other embodiments without conflict.

[0047] Unless otherwise defined, the technical or scientific terms used in this application shall have the ordinary meaning understood by one of ordinary skill in the art to which this application pertains. The terms “a,” “an,” “an,” “the,” and similar words used in this application do not indicate quantity limitation and may indicate singular or plural. The terms “comprising,” “including,” “having,” and any variations thereof used in this application are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or device that includes a series of steps or modules (units) is not limited to the listed steps or units, but may also include steps or units not listed, or may include other steps or units inherent to these processes, methods, products, or devices. The terms “connected,” “linked,” “coupled,” and similar words used in this application are not limited to physical or mechanical connections, but may include electrical connections, whether direct or indirect. “Multiple” used in this application means two or more. “And / or” describes the relationship between related objects, indicating that three relationships may exist; for example, “A and / or B” can represent: A alone, A and B simultaneously, and B alone. The terms “first,” “second,” “third,” etc., used in this application are merely to distinguish similar objects and do not represent a specific ordering of the objects.

[0048] The method embodiments provided in this example can be executed on a terminal, computer, or similar computing device. Taking running on a terminal as an example,Figure 1 This is a hardware structure block diagram of a terminal for a suspended system service processing method according to an embodiment of this application. Figure 1 As shown, a terminal may include one or more ( Figure 1 Only one is shown in the diagram. A processor 102 (which may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.) and a memory 104 for storing data are also shown. Optionally, the terminal may further include a transmission device 106 for communication functions and an input / output device 108. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the terminal described above. For example, the terminal may also include components that are more... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0049] The memory 104 can be used to store computer programs, such as application software programs and modules, like the computer program corresponding to the hanging system business processing method in this embodiment. The processor 102 executes various functional applications and data processing by running the computer program stored in the memory 104, thus implementing the above-described method. The memory 104 may include high-speed random access memory and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to the terminal via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0050] The transmission device 106 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the terminal's communication provider. In one example, the transmission device 106 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 106 may be a Radio Frequency (RF) module used for wireless communication with the Internet.

[0051] This embodiment provides a business processing method for a suspension system. Figure 2 This is a flowchart of a hanging system service processing method according to an embodiment of this application, such as... Figure 2 As shown, the process includes the following steps:

[0052] Step S201: Configure asynchronous thread and cache database; the cache database is used to store the hanger data written by the main business thread after the outbound card reading, and the main business thread simultaneously triggers the issuance of hanger outbound command while writing hanger data.

[0053] Specifically, in the initialization phase of the hanging system's business processing flow, the configuration of asynchronous threads and the cache database needs to be completed first. For the configuration of asynchronous threads, a thread pool model can be used to complete the core parameter settings. For example, first configure the number of core threads based on the average frequency of hanger departure in daily production (e.g., configure 6-10 core threads) to ensure the timeliness of data processing in normal scenarios; then set the maximum number of threads and the thread idle timeout based on the maximum data volume during peak production periods (e.g., the maximum number of threads is set to 20 and the timeout is set to 20 seconds). This retains the redundant processing capacity to cope with peak periods, avoids idle threads occupying system resources, and the entire asynchronous thread system is completely decoupled from the main business thread, only realizing data interaction through the cache database. This does not affect the real-time performance of departure instructions issued by the main thread, and can efficiently undertake subsequent data processing tasks, forming a collaborative architecture of "main thread manages instructions, asynchronous thread manages data".

[0054] In terms of the configuration and functional design of the cache database, its core function is to specifically store the hanger data written by the main business thread after the hanger is read out of the station. This data not only includes the unique RFID card number of the hanger, but also covers key business fields such as the current workstation ID, entry timestamp, and associated process information. Simultaneously, while the main business thread is writing hanger data to the cache database, it also triggers the issuance of hanger out-of-station commands, ensuring that the hanging equipment can quickly respond to the out-of-station action without waiting for subsequent data processing. This "parallel data storage and command issuance" design logic fundamentally breaks the blocking of out-of-station response in the traditional serial processing mode, providing architectural support for achieving millisecond-level out-of-station command issuance. For example, high-performance caching components such as Redis can be used, whose supported queue mechanism and high-speed read / write characteristics can perfectly adapt to the high-frequency writing and asynchronous reading requirements of hanger data.

[0055] Step S202: Use an asynchronous thread to retrieve multiple hanger data from the cache database and temporarily store the hanger data in the asynchronous thread queue.

[0056] Specifically, after completing the basic configuration of the asynchronous thread and cache database, the system will start a pre-defined asynchronous thread, which will then retrieve multiple hanger data sets in batches from the cache database. This data includes core fields such as hanger RFID card numbers, corresponding workstation information, and entry / exit timestamps. During data retrieval, the asynchronous thread filters out invalid or duplicate data using pre-defined filtering rules, and then temporarily stores the filtered valid hanger data in an asynchronous thread queue for subsequent processing. This "batch retrieval + queue temporary storage" approach avoids frequent connections between the asynchronous thread and the cache database, effectively reducing database interaction overhead. Simultaneously, the first-in-first-out (FIFO) characteristic of the queue ensures that the processing order of the hanger data aligns with the actual business workflow logic, guaranteeing the orderly execution of subsequent production calculation tasks.

[0057] Step S203: When the number of hanger data in the asynchronous thread queue exceeds a preset quantity threshold, or when the time since the last production calculation task was completed reaches a preset time threshold, the asynchronous thread is used to trigger the production calculation task and calculate the production data.

[0058] Specifically, in the production statistics stage of the hanging system, the system continuously monitors the running status of the asynchronous thread queue and the historical calculation task records. When either of the following conditions is met, namely "the number of hanger data in the asynchronous thread queue exceeds the preset quantity threshold" or "the time since the completion of the last production calculation task reaches the preset time threshold", or both conditions are met, the asynchronous thread will be triggered to start the production calculation task, and then perform statistical calculations on the hanger data in the queue to generate production data.

[0059] Production data is categorized into two types based on business application scenarios. One type is visual data that needs to be pushed to the terminal dashboard in real time for production management personnel to view intuitively. The other type is data used only for statistical archiving in the backend system to support subsequent data analysis. For data that needs to be pushed to the terminal dashboard, the list of fields to be pushed must be clearly defined and obtained in advance based on the terminal display requirements (such as today's total output, rework quantity, standard working hours, etc.). Then, according to the preset field format and statistical rules, the hanger departure information stored in the cache within the specified time range is filtered. Finally, based on the filtered departure information, the statistical calculation of core information fields such as output, efficiency, and rework is completed according to the field requirements to ensure that the data pushed to the terminal dashboard not only meets the display format requirements but also accurately reflects the real-time production status.

[0060] It should be noted that the quantity threshold and time threshold here are not fixed, but will be dynamically adjusted based on the actual business volume of the system. For example, during peak production periods, the quantity threshold can be appropriately increased to reduce the frequency of computing task initiation and reduce resource consumption, while during off-peak production periods, the time threshold can be shortened to avoid data stagnation for a long time, ensuring the real-time nature of production statistics and the rational utilization of system resources.

[0061] Step S204: Use an asynchronous thread to push production data to a preset terminal dashboard for real-time display.

[0062] Specifically, after the production calculation task is completed and accurate production data (including the current incremental production, the cumulative production of the current process, and the efficiency data of related workstations) is generated, the system will call an asynchronous thread to perform a data push operation. This thread will first standardize the production data and then push the processed production data to the preset terminal dashboard through a pre-established WebSocket long connection. This ensures that the terminal dashboard can refresh the displayed content immediately after the data push is completed, allowing production managers to keep track of the production dynamics of each workstation in real time. They can obtain the latest production data without manually refreshing the page, effectively improving the timeliness and convenience of production monitoring.

[0063] Through steps S201 to S204, firstly, by leveraging "asynchronous thread and cache database configuration + decoupling of outbound commands and statistical business," the blocking of outbound responses by data processing in the traditional serial process is completely broken. Combined with the support of high-performance caching components such as Redis, the outbound command response of the overhead system is successfully compressed to the millisecond level, solving the core pain point of outbound latency in traditional solutions. Secondly, by using asynchronous threads to batch retrieve cached data and temporarily store it in a queue after filtering, database interaction overhead is reduced, and the first-in-first-out characteristic of the queue ensures consistency between data processing and business flow logic, laying an ordered data foundation for subsequent calculations. Furthermore, based on the dual threshold dynamics of "quantity + time,"... The mechanism of triggering production calculation can flexibly adapt to production peaks and troughs. During high production, it optimizes resource usage through batch processing, and during low production, it avoids data stagnation through timely triggering, ensuring that the production statistics delay does not exceed the preset limit in real time. Finally, standardized production data is pushed through asynchronous threads, allowing the terminal dashboard to instantly display incremental and cumulative production, workstation efficiency, and other information without manual refresh, greatly improving the convenience of production monitoring. Ultimately, it forms a closed loop of "rapid outbound production - efficient processing - real-time statistics - instant display", which takes into account the multiple requirements of the hanging system for outbound efficiency, data real-time performance, and resource optimization, and significantly improves the overall operational stability and production management accuracy.

[0064] To better understand the specific process of the hanging system's business processing in this embodiment, such as Figure 3 As shown, Figure 3 This is a schematic diagram of the overall process of the hanging system business processing method according to an embodiment of this application.

[0065] Step S301: Start. This marks the official start of the outbound business processing flow for a specific hanger in the hanging system, after which the specific operation and judgment stages will commence.

[0066] Step S302: Exit and read the card. This is the first actual action in the process. By reading the card information corresponding to the hanger, it provides basic data support for subsequent station verification, information acquisition and other steps.

[0067] Step S303: Check if the site is valid. If the result is "No", return an error message and terminate the current process; if the result is "Yes", continue to execute the "Get Card Reader Hanger Information" operation to obtain the binding data and other key information corresponding to the hanger.

[0068] Step S304: Check if there is a next process. If there is a next process, execute the "Get Target Station" operation; if there is no next process, execute the "Get Recycle Bin" operation.

[0069] Step S305: Check if there is a next station. If the result is "no", return an exception message; if the result is "yes", perform the "write to cache database" operation to temporarily store the hanger-related data, and execute the "issue departure command", while triggering the asynchronous task on the right to start execution (the asynchronous thread processing flow is in the dashed box on the right).

[0070] Step S306: Retrieve cached data. In the asynchronous task flow, the "Retrieve cached data" operation is executed to extract the written hanger-related data from the cache database, preparing for subsequent production calculations.

[0071] Step S307: Calculate Production. Based on the acquired cached data, perform the "Calculate Production" operation to complete the production data statistics and calculations corresponding to this business.

[0072] Step S308: Push data and store data in the database. After completing the production calculation, the production output is pushed to the terminal dashboard and displayed. At the same time, the asynchronous task side sequentially performs the operations of storing the cached data (data persistence) and clearing the cached data. After completion, the asynchronous task process ends.

[0073] Figure 4 This is a flowchart illustrating the asynchronous thread queue management process according to an embodiment of this application.

[0074] Step S401: Start. This marks the official start of the asynchronous thread queue management business process, after which the queue element processing will begin.

[0075] Step S402: Retrieve the first element in the queue. Extract the first task element from the queue of asynchronous threads to be processed, providing a target object for subsequent thread processing.

[0076] Step S403: Obtain cache information. Retrieve business data (such as hanger information, site data, etc.) corresponding to the current queue element from the cache to provide data support for subsequent production calculations and other processes.

[0077] Step S404: Obtain station pass-through information. Obtain the station pass-through data (such as workstation parameters, process rules, etc.) corresponding to the current business, and supplement the business logic information required for production calculation.

[0078] Step S405: Calculate the output based on the transparent transmission information and actively push it to the terminal dashboard. After completing the statistical calculation of the output data, the results are pushed to the terminal dashboard in real time to achieve a visual display of the production data.

[0079] Step S406: Other business logic processing. This covers additional business operations corresponding to the current queue element (such as calculations of other data metrics that do not require pushing), ensuring the integrity of the business process.

[0080] Step S407: Remove the current element from the queue. Remove the first element that has been processed from the asynchronous thread queue, completing the entire processing flow for that element.

[0081] Step S408: Determine if there are any elements left in the queue. If there are still unprocessed elements in the queue, the process will jump back to step S402 to continue processing the next queue element; if there are no elements left in the queue, the process will proceed to the subsequent termination stage.

[0082] Step S409: End. This signifies that the processing tasks for all elements in the asynchronous thread queue have been completed.

[0083] In some embodiments, when the number of hanger data in the asynchronous thread queue exceeds a preset threshold, or when the time since the completion of the last production calculation task reaches a preset time threshold, the asynchronous thread triggers a production calculation task and calculates production data, including:

[0084] When the number of hanger data in the asynchronous thread queue exceeds a preset threshold, or when the time since the last production calculation task was completed reaches a preset time threshold, the asynchronous thread is used to trigger the production calculation task.

[0085] Based on preset historical entry and exit time data, determine the start time of the production calculation task;

[0086] When the start time arrives, execute the production calculation task and calculate the production data.

[0087] Specifically, the system first monitors the dynamic data volume of the asynchronous thread queue and the completion time of the previous calculation task in real time. Once either the data volume exceeds a threshold or the time interval reaches a threshold, the system immediately triggers a production calculation task through the asynchronous thread. Next, it determines the start time of the calculation task based on preset historical inbound and outbound time data (covering past records of each hanger's inbound and outbound times). Typically, the shortest and longest inbound and outbound times are extracted from historical data to construct a time interval, and then a suitable start time is selected based on the actual production rhythm. Finally, when the start time arrives, the asynchronous thread executes the production calculation task, performing calculations on the hanger data locked in the queue according to preset rules (such as workstation production statistics, process efficiency calculations, etc.) to generate complete production data. The start time refers to the specific time node at which the asynchronous thread task officially begins executing the production calculation task after it is started.

[0088] The above steps first employ a dual-threshold triggering mechanism based on data volume and time to ensure that asynchronous threads can flexibly initiate production calculation tasks according to business load. During high production periods, data volume thresholds are used for batch processing to reduce task initiation frequency and lower system resource consumption. During low production periods, time thresholds are used to prevent data stagnation and ensure statistical timeliness. Next, the initiation time is determined by combining historical inbound and outbound time data. By extracting the shortest and longest historical inbound and outbound times to construct a reasonable range and matching the actual production rhythm, the initiation point is selected, fundamentally avoiding statistical errors caused by incomplete data generation (such as hangers not having completed their exit). Finally, after the initiation time arrives, the data is locked and production data is generated according to the rules. Ultimately, a balance is achieved in production statistics among "efficiency (batch processing to reduce consumption), real-time performance (time thresholds to control latency), and accuracy (historical data timing mechanism)," effectively solving the problems of resource waste, data lag, or statistical distortion in traditional statistical methods. This provides efficient and reliable data support for subsequent real-time display on terminal dashboards and production management decisions.

[0089] In some embodiments, historical entry and exit time data includes the entry and exit times of each historical task; based on preset historical entry and exit time data, determining the start time of the production calculation task includes:

[0090] Based on the entry and exit times of each historical task, calculate the shortest entry and exit time and the longest entry and exit time.

[0091] The start time for the production calculation task is determined based on the shortest and longest entry / exit times.

[0092] The historical entry and exit time data specifically covers the entry time (i.e., the time when the hanger arrives at the current workstation and completes card reading registration) and exit time (i.e., the time when the hanger receives the exit instruction and leaves the current workstation) of each historical task. The process of determining the start time of the production calculation task based on this preset historical data first extracts the entry and exit times of each task from these historical records. The entry and exit time of a single task is obtained by calculating the time difference between the two. Then, the shortest entry and exit time with the smallest value and the longest entry and exit time with the largest value are selected from all the single durations. Subsequently, a reasonable time interval is constructed with these two time values ​​as boundaries. The start time is selected within the interval based on the actual rhythm of the current production scenario (such as process complexity and equipment operating speed). For example, if the shortest entry and exit time in the historical data is 1 second and the longest is 5 seconds, the median value of 3 seconds in the interval can be set as the initial start time. This can avoid starting too early, which may result in some hanger data not being generated completely, and also prevent starting too late, which may cause statistical delays. This ensures that the production calculation task finds the optimal balance between data integrity and timeliness.

[0093] The above steps, by extracting the duration of a single entry and exit from the station and filtering out the shortest and longest values ​​to construct a time interval, avoid the problem of blindly setting the start time without regard to actual production patterns. Subsequently, by combining factors such as process complexity and equipment speed, the start time is selected within the interval (e.g., using the median value as the initial value). This not only prevents statistical errors caused by starting too early, resulting in hangers not completing their exit and data loss, but also avoids production data lag caused by starting too late, affecting the timeliness of production monitoring. Ultimately, it achieves a precise match between the production start time and the actual business flow rhythm, ensuring the accuracy and real-time nature of production statistics from a time perspective. This lays a crucial foundation for the subsequent efficient execution of calculation tasks by asynchronous threads and the generation of reliable production data.

[0094] In some embodiments, after the production data is pushed to a preset terminal dashboard for display, the method further includes:

[0095] Obtain the production update time and hanger exit time; the production update time is the time when the production data is pushed to the terminal dashboard.

[0096] Based on the production update time and the hanger exit time, the start time of the next production calculation task is adjusted.

[0097] Specifically, after pushing production data to the preset terminal dashboard and completing real-time display, the system further executes a time calibration process: First, it obtains two key time nodes: production update time (i.e., the time when production data is successfully pushed to the terminal dashboard and the page is refreshed) and hanger departure time (i.e., the time when the hanger actually receives and executes the departure command and leaves the current workstation); then, based on the difference between these two times, it dynamically adjusts the start time of the next production calculation task. It should be understood that this "calibration mechanism based on the actual push and departure time difference" does not rely on fixed rules to statically set the start time, but continuously optimizes the timing of subsequent calculations through real-time feedback of time deviations. For example, when the production update time is significantly delayed compared to the hanger departure time and exceeds the preset reasonable range, the next start time is appropriately advanced; otherwise, it is slightly delayed. This ensures that production statistics and display can continuously match the actual production flow rhythm, avoid the accumulation of time deviations caused by factors such as changes in equipment load and fluctuations in business volume, and further improve the real-time performance and accuracy of production data.

[0098] Through the above steps, the system first accurately captures two key time points: production update and actual hanger departure. Using the time difference between these two as a calibration basis, it overcomes the limitation of traditional fixed start-up times being unable to adapt to production fluctuations. Then, based on real-time feedback on time deviations, the system dynamically adjusts the next start-up time. For example, if the delay exceeds the limit, the start-up time is advanced; if it is ahead, the delay is fine-tuned. This proactively adapts to dynamic scenarios such as changes in equipment load and fluctuations in business volume, preventing time deviations from accumulating with the production process. Ultimately, it achieves continuous alignment between production start-up time and the actual production flow rhythm. This prevents both delays in start-up causing a disconnect between production display and actual departure, and premature start-up leading to incomplete data. It further enhances the real-time nature and accuracy of production data from calculation to display, ensuring that the production data presented on the terminal dashboard is always highly matched with the actual progress on-site, providing production managers with more accurate decision-making references.

[0099] In some embodiments, adjusting the start time of the next production calculation task based on the production update time and the hanger exit time includes:

[0100] If the production update time is earlier than the hanger exit time, calculate a first time difference between the production update time and the hanger exit time;

[0101] The sum of the start time of the current production calculation task and the first time difference shall be used as the start time of the next production calculation task.

[0102] Specifically, in scenarios where the production update time is earlier than the hanger departure time, the system first uses its timestamp recording function to accurately calculate the difference between the two, i.e., the first time difference. This difference essentially reflects the time deviation caused by the production calculation task starting too early, resulting in the hangers not actually leaving the station when the data push is completed. Then, the start time of the current production calculation task is added to this first time difference, and the result is the start time of the next production calculation task. For example, if the start time is 3 seconds and the first time difference is 0.5 seconds (i.e., the production update is 0.5 seconds earlier than the hanger departure), the next start time will be adjusted to 3.5 seconds. By adjusting the time difference in this way, the situation of "data push ahead of actual production progress" due to the early start of subsequent calculations can be effectively avoided, ensuring that the production statistics and the actual flow rhythm of the hangers remain synchronized, and further improving the matching degree between the data and on-site production.

[0103] The above steps address scenarios where the production update time precedes the hanger's departure time. By accurately calculating the first time difference between the two, the root cause of the premature calculation start is identified. The next start time is then determined using the adjustment logic of "current start time + first time difference." Essentially, this dynamic calibration, which compensates for the time difference, directly corrects the problem of data push exceeding the actual production schedule caused by the previous premature calculation start. This adjustment method does not rely on fixed rules but is based on targeted optimization of each actual time deviation. It ensures that the start time of the next production calculation task is precisely matched with the actual hanger departure rhythm, avoiding the disconnect between terminal dashboard display and on-site production caused by premature data push. This further enhances the authenticity and timeliness of production data from calculation to display, allowing production managers to accurately reflect the actual flow status of hangers through the terminal dashboard, providing more reliable data support for production scheduling and progress control.

[0104] In some embodiments, adjusting the start time of the next production calculation task based on the production update time and the hanger exit time includes:

[0105] If the production update time is later than the hanger exit time, calculate a second time difference between the production update time and the hanger exit time;

[0106] Based on the second time difference, the start time of the next production calculation task is adjusted.

[0107] Specifically, in scenarios where the production update time is later than the hanger departure time, the system's time recording module will first accurately capture the difference between the two time points, i.e., the second time difference. This difference directly reflects the extent to which the overall time taken for the production calculation task from initiation to completion and push exceeds the actual hanger departure rhythm, causing the data display to lag behind the on-site production progress. Subsequently, based on this second time difference, the next start time will be adjusted accordingly. It should be understood that this adjustment is not a simple uniform shortening of the start time, but rather a judgment of the degree of lag based on the specific value of the second time difference. For example, when the second time difference is small (such as within a preset reasonable range of 200ms), only minor adjustments or even no adjustments may be needed to avoid excessive adjustments causing new time deviations. When the second time difference exceeds a reasonable range, the next start time will be shortened accordingly, thereby ensuring that subsequent production calculations and pushes are more in line with the actual hanger departure rhythm and reducing the impact of data display lag on production monitoring.

[0108] The above steps address scenarios where production updates lag behind hanger departure times. First, a precise calculation of the second time difference clarifies the extent to which production data lags behind actual production progress. Then, a differentiated adjustment strategy is implemented based on the numerical difference of this second time difference. This avoids over-adjustment that could introduce new deviations when the second time difference is small, and also allows for timely shortening of the next start-up time when the difference exceeds a reasonable range. Essentially, through dynamic logic of on-demand calibration, the timing of production calculation startup always aligns with the actual hanger departure rhythm. This adjustment method effectively solves the problem of a single fixed start time failing to adapt to production fluctuations. It proactively corrects data lag caused by unexpected calculation time, ensuring that the production information displayed on the terminal dashboard is highly synchronized with the on-site hanger circulation progress. This further enhances the real-time performance and reliability of production monitoring data, providing crucial support for production managers to promptly grasp the true production status and accurately adjust production scheduling.

[0109] In some embodiments, adjusting the start time of the next production calculation task based on the second time difference includes:

[0110] When the second time difference is greater than a preset threshold, the difference between the start time of the current production calculation task and the second time difference is taken as the start time of the next production calculation task.

[0111] When the second time difference is less than or equal to a preset threshold, the start time of the current production calculation task is taken as the start time of the next production calculation task.

[0112] Specifically, when the second time difference is greater than the preset threshold (which is usually set according to the production requirements for data real-time performance, such as 200ms), it indicates that the lag between the current production data display and the actual output of the hangers exceeds an acceptable range. In this case, the start time of the current production calculation task will be subtracted from this second time difference to advance the start time of the next calculation and make up for the lag. When the second time difference is less than or equal to the preset threshold, it indicates that the data lag is within a reasonable and controllable range and will not have a significant impact on production monitoring. Therefore, there is no need to adjust the start time, and the current start time can be used directly. For example, if the preset threshold is 200ms and the current start time is 3 seconds, when the second time difference is 250ms (greater than the threshold), the next start time will be adjusted to 2.75 seconds. When the second time difference is 150ms (less than the threshold), the next start time will still be 3 seconds.

[0113] This refined adjustment logic of "correcting when exceeding the threshold and maintaining when within the threshold" can effectively solve the problem of significant lag, avoid system instability caused by frequent fine-tuning, and ensure that the output calculation rhythm is accurately matched with the actual production needs.

[0114] In some embodiments, pushing the production data to a preset terminal dashboard for display includes:

[0115] The production data is pushed to a preset terminal dashboard for display via a WebSocket long connection.

[0116] Specifically, during the initialization phase, the system establishes stable WebSocket long connections with various preset terminal dashboards (such as the monitoring screen in the production workshop and the operation terminals of management personnel). Once established, this connection is maintained continuously, eliminating the need to re-establish a connection for each data push as with traditional HTTP requests. Subsequently, after the asynchronous thread completes the calculation and standardization of production data (such as converting it to a format that the terminal can parse and adding data verification identifiers), it directly pushes the data to the corresponding terminal dashboard through the established WebSocket long connection. Once the data arrives at the terminal, the dashboard immediately triggers the front-end refresh logic to display the latest production information (such as real-time production of each workstation, cumulative production, process completion rate, etc.) in an intuitive form such as charts and lists.

[0117] This push method based on WebSocket long connections not only significantly reduces connection establishment overhead and network latency during data transmission, but also ensures that production data is synchronized to the terminal dashboard as soon as it is generated. This avoids the data lag or resource waste that may occur in the traditional timed polling mode, allowing production managers to grasp the dynamics of production progress in real time and accurately.

[0118] Compared with existing technical solutions, this application has the following advantages:

[0119] (1) Efficiency improvement: The outbound response time has been reduced from 2s in the original synchronous mode to 300ms; the outbound command response is freed from the complex business logic of the backend, realizing millisecond-level response and completely solving the risk of outbound timeout.

[0120] (2) Real-time breakthrough: The production statistics delay has been reduced from 3s to 1s (optimal); the dual trigger mechanism ensures that the production statistics delay does not exceed 3 seconds, so that the terminal dashboard data can reflect the production status in almost real time.

[0121] (3) System resource optimization: The dual trigger mechanism intelligently adapts to the system load, improves efficiency by batch processing during high traffic, and ensures real-time delivery during low traffic, thus achieving optimal allocation of computing resources.

[0122] (4) Network load is greatly reduced: The WebSocket-based active push mechanism replaces the timed polling, eliminating more than 99% of invalid network requests and significantly improving server throughput and overall system stability.

[0123] This embodiment also provides a hanging system business processing device, which is used to implement the above embodiments and preferred embodiments, and will not be repeated as described thereon. As used below, the terms "module," "unit," "subunit," etc., can refer to a combination of software and / or hardware that performs a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0124] Figure 5 This is a structural block diagram of the hanging system service processing device according to an embodiment of this application, such as... Figure 5 As shown, the device includes:

[0125] Configuration module 51 is used to configure asynchronous threads and cache database; the cache database is used to store the hanger data written by the main business thread, and the main business thread simultaneously triggers the issuance of hanger outbound instructions while writing hanger data.

[0126] Module 52 is used to retrieve multiple hanger data from the cache database using an asynchronous thread and temporarily store the hanger data in the asynchronous thread queue;

[0127] The calculation module 53 is used to trigger a production calculation task using an asynchronous thread and calculate production data when the number of hanger data in the asynchronous thread queue exceeds a preset quantity threshold, or when the time since the completion of the last production calculation task reaches a preset time threshold.

[0128] The push module 54 is used to push production data to a preset terminal dashboard for real-time display using an asynchronous thread.

[0129] It should be noted that the above modules can be functional modules or program modules, and can be implemented by software or hardware. For modules implemented by hardware, the above modules can reside in the same processor; or the above modules can be located in different processors in any combination. Specific examples in this embodiment can be found in the examples described in the above embodiments and optional implementations, and will not be repeated in this embodiment.

[0130] Furthermore, in conjunction with the hanging system service processing method in the above embodiments, this application embodiment can provide a storage medium for implementation. This storage medium stores a computer program; when executed by a processor, the computer program implements any of the hanging system service processing methods in the above embodiments.

[0131] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties.

[0132] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments described above. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited to these.

[0133] Those skilled in the art should understand that the technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments have been described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0134] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the invention patent. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this patent application should be determined by the appended claims.

Claims

1. A business processing method for a suspension system, characterized in that, include: Configure asynchronous threads and a cache database; the cache database is used to store the hanger data written by the main business thread after the outbound card is read, and the main business thread simultaneously triggers the issuance of the hanger outbound command while writing the hanger data; The asynchronous thread retrieves multiple hanger data from the cache database and temporarily stores the hanger data in the asynchronous thread queue. When the number of hanger data in the asynchronous thread queue exceeds a preset threshold, or when the time since the last production calculation task was completed reaches a preset time threshold, the asynchronous thread is used to trigger a production calculation task and calculate the production data. The asynchronous thread is used to push the production data to a preset terminal dashboard for real-time display.

2. The business processing method for the suspension system according to claim 1, characterized in that, When the number of hanger data in the asynchronous thread queue exceeds a preset threshold, or when the time since the last production calculation task was completed reaches a preset time threshold, the asynchronous thread triggers a production calculation task and calculates production data, including: When the number of hanger data in the asynchronous thread queue exceeds a preset threshold, or when the time since the last production calculation task was completed reaches a preset time threshold, the asynchronous thread is used to trigger the production calculation task. Based on preset historical entry and exit time data, the start time of the production calculation task is determined; When the start time arrives, the production calculation task is executed, and the production data is calculated.

3. The business processing method for the suspension system according to claim 2, characterized in that, The historical entry and exit time data includes the entry and exit times of each historical task; The process of determining the start time of the production calculation task based on preset historical entry and exit time data includes: Based on the entry and exit times of each historical task, calculate the shortest and longest entry and exit times. The start time of the production calculation task is determined based on the shortest and longest entry / exit times.

4. The business processing method for the suspension system according to claim 1, characterized in that, After pushing the production data to a preset terminal dashboard for display, the process also includes: Obtain the production update time and hanger exit time; the production update time is the time when the production data is pushed to the terminal dashboard. Based on the production update time and the hanger exit time, the start time of the next production calculation task is adjusted.

5. The business processing method for the suspension system according to claim 4, characterized in that, The adjustment of the start time for the next production calculation task based on the production update time and the hanger exit time includes: If the production update time is earlier than the hanger exit time, calculate a first time difference between the production update time and the hanger exit time; The sum of the start time of the current production calculation task and the first time difference shall be used as the start time of the next production calculation task.

6. The business processing method for the suspension system according to claim 4, characterized in that, The adjustment of the start time for the next production calculation task based on the production update time and the hanger exit time includes: If the production update time is later than the hanger exit time, calculate a second time difference between the production update time and the hanger exit time; Based on the second time difference, the start time of the next production calculation task is adjusted.

7. The business processing method for a suspension system according to claim 6, characterized in that, The adjustment of the start time of the next production calculation task based on the second time difference includes: When the second time difference is greater than a preset threshold, the difference between the start time of the current production calculation task and the second time difference is taken as the start time of the next production calculation task. When the second time difference is less than or equal to a preset threshold, the start time of the current production calculation task is taken as the start time of the next production calculation task.

8. The business processing method for a suspension system according to claim 1, characterized in that, The step of pushing the production data to a preset terminal dashboard for display includes: The production data is pushed to a preset terminal dashboard for display via a WebSocket long connection.

9. A business processing device for a suspended system, characterized in that, The device includes: The configuration module is used to configure asynchronous threads and a cache database; the cache database is used to store the hanger data written by the main business thread after the card is read out of the station, and the main business thread simultaneously triggers the issuance of the hanger out-of-station command while writing the hanger data. The acquisition module is used to acquire multiple hanger data from the cache database using the asynchronous thread, and temporarily store the hanger data in the asynchronous thread queue; The calculation module is used to trigger a production calculation task and calculate production data using the asynchronous thread when the number of hanger data in the asynchronous thread queue exceeds a preset quantity threshold, or when the time since the completion of the last production calculation task reaches a preset time threshold. The push module is used to push the production data to a preset terminal dashboard for real-time display using the asynchronous thread.

10. A storage medium, characterized in that, The storage medium stores a computer program, wherein the computer program is configured to execute the hanging system business processing method according to any one of claims 1 to 8 when it is run.

Images