An FTP transmission exception processing method and device, instructor and storage medium

Abstract

This invention discloses an FTP transmission anomaly handling method, apparatus, teach pendant, storage medium, and computer program product. The method includes: generating a corresponding transmission task upon receiving a file transmission request; logically fragmenting the file to be transmitted and storing task status metadata; establishing an FTP transmission session and transmitting the file fragments in parallel through multiple independent channels, while simultaneously monitoring the operating status of each channel in real time; if a working transmission channel malfunctions, switching to a backup channel to continue transmitting the unfinished fragments; temporarily storing all completed fragments in a temporary storage area on a remote server; and performing an overall integrity check after all fragments have been transmitted. Once the check passes, the fragment data is integrated into the final target file. This solution achieves automatic recovery from FTP transmission anomalies and ensures data integrity, effectively improving transmission reliability and overall operational efficiency.

Description

Technical Field

[0001] This invention belongs to the field of industrial robot technology, specifically relating to an FTP transmission anomaly handling method, device, teach pendant, storage medium, and computer program product, and particularly to an FTP anomaly recovery and data saving processing method, device, teach pendant, storage medium, and computer program product based on a six-joint robot teach pendant. Background Technology

[0002] With the widespread application of industrial robots in intelligent manufacturing production lines, the six-joint teach pendant, as a core human-machine interface device for robot trajectory teaching, parameter configuration, and status monitoring, frequently needs to upload data such as teaching trajectory files, equipment configuration parameters, and operation logs to the server for archiving and backup via the FTP protocol. The reliability of FTP data transmission directly affects the data security of the production line and the efficiency of equipment operation and maintenance. Industrial production sites commonly experience complex operating conditions such as network fluctuations, sudden power outages, and momentary server failures, placing extremely high demands on the fault tolerance capability and data integrity assurance of the teach pendant's FTP transmission.

[0003] Currently, FTP transfers on teach pendants mostly adopt a common single-channel direct transfer architecture. Some existing optimization solutions improve transmission reliability to a certain extent by introducing breakpoint resume, file hash verification, or temporary file storage. Some common FTP technology solutions can also realize file restoration or verification overwrite based on temporary files to avoid directly damaging the original file in case of transmission failure.

[0004] However, existing FTP transmission fault tolerance mechanisms cannot adapt to the resource-constrained hardware characteristics of industrial teach pendants and the complex working conditions in industrial environments. They struggle to build an integrated system for anomaly recovery and data integrity assurance, resulting in unreliable automatic recovery from transmission anomalies and a high risk of corrupted data files. This makes it difficult to balance transmission reliability with operational efficiency. Specifically, general FTP fault tolerance solutions typically rely on significant memory caching and computational overhead. Six-joint teach pendants, being embedded devices, have limited memory and computational resources. Complex verification and recovery mechanisms consume substantial system resources, interfering with the teach pendant's primary control functions and hindering direct application. Furthermore, existing solutions often employ a single-link transmission architecture, lacking redundant transmission channels. Transmission is directly interrupted by network or link anomalies, failing to automatically resume transmission and requiring manual restarts by maintenance personnel, leading to extremely high labor costs in mass production deployments. Additionally, existing improvements often optimize transmission recovery or file verification separately, failing to establish a closed-loop mechanism of "redundant transmission - anomaly resumption - integrity verification - atomic commit." Even after transmission interruption, incomplete or corrupted files can still be generated on the server side, failing to fundamentally guarantee the consistency and integrity of remote data.

[0005] The above content is only used to help understand the technical solution of the present invention and does not represent an admission that the above content is prior art. Summary of the Invention

[0006] The purpose of this invention is to provide an FTP transmission anomaly handling method, apparatus, teach pendant, storage medium, and computer program product to solve the problems that existing FTP transmission solutions are difficult to adapt to the hardware characteristics of industrial teach pendants with limited resources and complex industrial field conditions, cannot simultaneously achieve automatic recovery from transmission anomalies and data integrity assurance, and are difficult to balance transmission reliability and operation and maintenance efficiency. This invention effectively adapts to the hardware characteristics of resource-constrained devices and complex industrial field conditions, and can simultaneously achieve automatic recovery from FTP transmission anomalies and data integrity assurance, significantly improving transmission reliability and overall operation and maintenance efficiency.

[0007] This invention provides a method for handling FTP transmission anomalies, comprising: responding to a file transmission request, logically fragmenting the file to be transmitted, generating corresponding transmission tasks, and locally storing task status metadata; establishing an FTP transmission session, transmitting file fragments in parallel through multiple independent transmission channels, while simultaneously monitoring the operating status of each transmission channel in real time; when a transmission anomaly is detected in a working transmission channel, switching to a backup transmission channel to continue transmitting the unfinished file fragments; temporarily storing the transmitted file fragments in a temporary storage area on a remote server; after all file fragments have been transmitted, performing integrity verification on all fragment data in the temporary storage area; if the verification passes, integrating the fragment data in the temporary storage area into a final target file.

[0008] In some implementations, after logically fragmenting the file to be transmitted, at least two identical mirror fragments are generated for each file fragment, and each mirror fragment is assigned to different transmission channels for parallel transmission.

[0009] In some implementations, the multiple independent transmission channels include at least two main transmission channels with different transmission rates and power consumption levels, and the backup transmission channels are isolated from and operate independently of all the main transmission channels.

[0010] In some implementations, the task status metadata is updated in real time according to the transmission progress of file fragments; when the device restarts, the task status metadata stored locally is read, the location of the last successfully transmitted file fragment is located, the FTP transmission session is rebuilt, and fragment transmission is resumed.

[0011] In some implementations, after each file fragment is transmitted, a fragment-level integrity check is performed on the fragment, and the corresponding task status metadata is updated after the check passes.

[0012] In some implementations, temporary files in the temporary storage area are named using a rule that combines a unique task identifier with a timestamp.

[0013] In conjunction with the above method, another aspect of the present invention provides an FTP transmission anomaly handling device, comprising: a task processing unit configured to, in response to a file transmission request, logically fragment the file to be transmitted, generate corresponding transmission tasks, and locally store task status metadata; a transmission control unit configured to establish an FTP transmission session, transmit file fragments in parallel through multiple independent transmission channels, and simultaneously monitor the operating status of each transmission channel in real time; the transmission control unit is further configured to, when a transmission anomaly is detected in a working transmission channel, switch to a backup transmission channel to continue transmitting the unfinished file fragments; a fragment temporary storage unit configured to temporarily store the transmitted file fragments in a temporary storage area on a remote server; and a verification and submission unit configured to, after all file fragments have been transmitted, perform integrity verification on all fragment data in the temporary storage area; the verification and submission unit is further configured to, if the verification passes, integrate the fragment data in the temporary storage area into a formal target file.

[0014] In conjunction with the above-described device, the present invention further provides a teach pendant, comprising: the FTP transmission exception handling device described above.

[0015] In conjunction with the above method, the present invention further provides a storage medium comprising a stored program, wherein, when the program is executed, it controls the device where the storage medium is located to execute the FTP transmission exception handling method described above.

[0016] In conjunction with the above method, the present invention further provides a computer program product comprising a computer program that, when processed and executed, implements the steps of the above-described FTP transmission exception handling method.

[0017] The solution of this invention generates a corresponding transmission task upon receiving a file transfer request, logically segments the file to be transferred and stores task status metadata, establishes an FTP transfer session, and transmits the file segments in parallel through multiple independent channels. Simultaneously, the operating status of each channel is monitored in real time. If a working transmission channel malfunctions, the system switches to a backup channel to continue transmitting the unfinished segments. All completed segments are temporarily stored in a temporary storage area on a remote server. After all segments have been transmitted, an overall integrity check is performed. Once the check passes, the segmented data is integrated into the final target file. This achieves automatic recovery from FTP transfer anomalies and ensures data integrity, effectively improving transmission reliability and overall operational efficiency.

[0018] Other features and advantages of the invention will be set forth in the description which follows, and will be apparent in part from the description, or may be learned by practicing the invention.

[0019] The technical solution of the present invention will be further described in detail below with reference to the accompanying drawings and embodiments. Attached Figure Description

[0020] Figure 1 This is a flowchart illustrating an embodiment of the FTP transmission exception handling method of the present invention;

[0021] Figure 2 This is a schematic diagram of an embodiment of the FTP transmission exception handling device of the present invention;

[0022] Figure 3 This is a flowchart illustrating the FTP anomaly recovery and data saving process based on a six-joint robot teach pendant.

[0023] Referring to the accompanying drawings, the reference numerals in the embodiments of the present invention are as follows:

[0024] 101-Task processing unit; 102-Transmission control unit; 103-Fragmentation temporary storage unit; 104-Verification and submission unit. Detailed Implementation

[0025] To make the objectives, technical solutions, and advantages of this invention clearer, the technical solutions of this invention will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this invention, and not all of them. Based on the embodiments of this invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this invention.

[0026] According to embodiments of the present invention, an FTP transmission exception handling method is provided, such as... Figure 1 The flowchart of an embodiment of the method of the present invention is shown. The FTP transmission exception handling method may include steps S110 to S160.

[0027] In step S110, in response to a file transfer request, the file to be transferred is logically fragmented, a corresponding transfer task is generated, and the task status metadata is stored locally.

[0028] Logical fragmentation refers to splitting a complete file to be transmitted into multiple independent, ordered data fragments according to preset rules. Each fragment has an independent identifier and location information. The fragmentation process only changes the granularity of data transmission, without altering the content and structure of the file itself. Task status metadata refers to a set of information used to describe the attributes and progress of the transmission task. It includes data such as the task's unique identifier, basic file information, total number of fragments, the location of completed fragments, and the task's running status. It is the core basis for achieving traceable and recoverable transmission.

[0029] Traditional FTP transfers are mostly stateless, single-transfer operations. Tasks lack unified identification, and files are not segmented into granular units. Once a transfer is interrupted, it is impossible to track progress or accurately resume the transfer. Retransmitting the entire file wastes a significant amount of time and bandwidth. Splitting files into logical chunks and generating traceable transfer tasks is a prerequisite for enabling breakpoint resumption and anomaly recovery.

[0030] Specifically, when the system receives a file upload request, it first generates a uniquely identified transmission task for this transmission; then it reads the complete information of the file to be transmitted, splits the file into multiple consecutive logical segments according to preset rules, and generates basic information such as segment number, data offset, and data length for each segment; finally, it writes all metadata such as task status and segment information to the local storage medium, and marks the initial state of the task as pending execution.

[0031] In step S120, an FTP transfer session is established, and file fragments are transferred in parallel through multiple independent transfer channels, while the operating status of each transfer channel is monitored in real time.

[0032] Independent transmission channels refer to FTP transmission links where the operating logic and link resources of each other do not interfere with each other. A failure in one channel will not directly affect the normal operation of other channels.

[0033] Single-channel FTP transmission has extremely low fault tolerance; network fluctuations or link interruptions will cause the entire transmission task to stall, requiring manual restart. Furthermore, the transmission efficiency of a single channel is fixed and cannot adapt to different network environments and power consumption requirements. Using multiple independent channels for parallel transmission can improve fault tolerance through redundant links and increase transmission efficiency through parallel distribution. Real-time status monitoring is a prerequisite for automatic failover in case of anomalies.

[0034] Specifically, the system establishes an FTP connection with the remote server based on the task information and completes identity authentication to formally establish a transmission session; then, it activates multiple independent transmission channels and distributes the files to be transmitted in chunks to each channel for parallel transmission; throughout the transmission process, the system continuously collects operating parameters such as the connection status, data transmission rate, and response timeout of each transmission channel to determine in real time whether the channel is in normal working condition.

[0035] In step S130, when a transmission abnormality is detected in the working transmission channel, the system switches to the backup transmission channel to continue transmitting the incomplete file fragments.

[0036] In complex environments such as industrial sites, network fluctuations and temporary link failures are frequent occurrences. Traditional single-channel solutions directly interrupt tasks upon encountering anomalies, requiring manual intervention for restart, resulting in high maintenance costs and low efficiency. Setting up a backup channel and implementing automatic switching can seamlessly take over transmission tasks when the primary link fails, achieving unattended automatic recovery in abnormal scenarios.

[0037] Specifically, when the system determines that the currently operating transmission channel is experiencing abnormal transmission conditions such as connection interruption, continuous timeout, or packet loss rate exceeding a preset threshold, the system automatically terminates the transmission task of the abnormal channel and schedules the remaining untransmitted files of that channel to the backup transmission channel. After the backup channel takes over the fragments, it continues to execute the transmission according to the original fragment order, and the overall transmission task does not need to be paused or restarted.

[0038] In step S140, the file fragments that have been transferred are temporarily stored in the temporary storage area of ​​the remote server.

[0039] Temporary storage area refers to an independent storage path on a remote server specifically used to store intermediate data during transmission. The data in this area will not be used directly as formal business files, but only for temporary storage and verification during the transmission process.

[0040] If the actual business data is written directly during transmission, and an error occurs midway, the server will be left with incomplete files. These incomplete files may overwrite existing files and make it impossible to accurately determine file validity later. Setting up a separate temporary storage area to isolate the intermediate state of transmission can prevent damage to actual business data from abnormal transmission at the source.

[0041] Specifically, after each file fragment is transmitted remotely, it is not directly written to the storage path of the formal business file, but is uniformly stored in an independent temporary storage area pre-defined by the remote server; all intermediate data in the transmission process is stored in this area, completely isolated from the storage path of the formal business file.

[0042] In step S150, after all file fragments have been transferred, the integrity of all fragment data in the temporary storage area is checked.

[0043] In step S160, if the verification passes, the fragmented data in the temporary storage area is integrated into the formal target file.

[0044] Integrity verification is used to compare the transmitted data with the original data using a verification algorithm, verifying whether the data was lost, tampered with, or damaged during transmission. Even if all fragments are transmitted successfully, some fragments may still experience packet loss or corruption, which can lead to file corruption if directly integrated and used. Performing a full integrity verification before the data becomes available verifies the accuracy of the transmission results from the perspective of the entire file, filtering out transmission results with missing or incorrect data.

[0045] Specifically, once the system determines that all file fragments have been successfully transmitted remotely, it reassembles all fragments in the temporary storage area sequentially. Then, it calculates the checksum of the reassembled file using a preset verification algorithm and compares this checksum with the baseline checksum of the source file to determine if the transmitted data is complete and consistent. If the integrity check passes, the system reassembles all fragment data in the temporary storage area into a complete target file, converts this file into a formal business file, and includes it in the formal file storage path. After conversion, the transmission task status is synchronously updated to "completed." If the integrity check fails, the fragment data in the temporary storage area and the local task status metadata are retained, marking the task as a failed check, supporting subsequent automatic retries or manual intervention to prevent data loss.

[0046] Optionally, the operation of integrating fragmented data in the temporary storage area into a formal target file can be achieved through atomic renaming. That is, the recombined complete file is first stored in a temporary path, and after verification, it is renamed to the formal file name in one go. This operation is an atomic operation, which can avoid file corruption during the conversion process.

[0047] This invention, through a comprehensive design encompassing task-based management, multi-channel redundant transmission, automatic failover in case of anomalies, temporary area isolation, and effective integrity verification, simultaneously achieves automatic recovery from transmission anomalies and ensures the integrity of remote data. It solves the problems of traditional FTP transmission requiring manual restarts and incurring high maintenance costs when encountering anomalies, while also avoiding file corruption and poor data consistency caused by transmission interruptions. It can reliably improve the reliability and efficiency of FTP transmission in complex network and device environments. Furthermore, this solution is adaptable to the operating scenarios of embedded industrial control equipment, and the entire process can be streamlined to reduce memory and computing resource consumption, making it suitable for resource-constrained device environments.

[0048] In some implementations, after logically fragmenting the file to be transmitted, at least two identical mirror fragments are generated for each file fragment, and each mirror fragment is assigned to different transmission channels for parallel transmission.

[0049] Mirrored shards refer to replica shards generated based on the original logical shards, which are completely identical to the original shards in terms of data content. Each mirrored shard carries the same metadata as the original shard, such as the shard number, offset, and checksum. If any mirrored shard is successfully transmitted and verified, it can represent the corresponding original shard in the transmission process.

[0050] Relying solely on link-level redundancy through channel switching still presents the problem of retransmission after single-fragment transmission failure or packet loss, which increases transmission latency and system overhead. Generating fragment replicas at the data level allows the same fragment to be transmitted simultaneously on multiple links. As long as one replica succeeds, the fragment transmission is complete, eliminating the need for retransmission. Furthermore, multiple fragment data copies can be retained in abnormal scenarios to prevent data loss due to the loss of a single replica. Specifically, after logically splitting the file to be transmitted, at least two mirror fragments with completely identical data content are created for each original file fragment. All mirror fragments inherit all metadata from the original fragment, including its number, data offset, length, and checksum, ensuring that any successful replica transmission can be correctly identified and reassembled.

[0051] If multiple mirror fragments of the same original fragment are assigned to the same transmission channel, all replicas will fail simultaneously if that channel malfunctions, rendering redundancy ineffective. Distributing replicas to different independent channels leverages the independence of the channels to ensure that at least one replica can be transmitted normally. This creates a synergistic effect between data redundancy and link redundancy, meaning that even if some transmission channels malfunction, mirror fragments on the remaining channels can still complete transmission, maximizing the success rate of fragment transmission in abnormal scenarios. Specifically, the system allocates all mirror fragments corresponding to the same original fragment to different independent transmission channels according to rules such as channel load and channel operating status. Each channel synchronously initiates the transmission operation of its corresponding mirror fragment without interfering with each other. Once the system detects that any mirror fragment transmission is complete and the verification is valid, it determines that the corresponding original fragment transmission was successful.

[0052] Optionally, once the system determines that any mirror fragment corresponding to a given original fragment has been successfully transmitted, it can proactively send a termination command to the remaining channels, interrupting the transmission of other mirror copies of the same fragment, releasing the corresponding bandwidth and channel resources, and avoiding unnecessary resource consumption. Furthermore, differentiated mirror fragment numbers can be configured for files of different importance levels. For example, more mirror copies can be set for core configuration files and critical log files, while fewer copies can be set for ordinary files, ensuring the reliability of critical data while controlling overall resource consumption.

[0053] By generating multiple image fragments and distributing them to different independent channels for parallel transmission, data-level transmission redundancy is further increased on the basis of link-level redundancy. This can effectively reduce the probability of fragment transmission failure in network fluctuation scenarios, reduce the number of retransmissions and transmission latency, and improve data retention capabilities in abnormal scenarios. This further enhances the fault tolerance and overall operating efficiency of FTP transmission, making it more suitable for application scenarios with complex network environments and high data reliability requirements.

[0054] In some implementations, the multiple independent transmission channels include at least two main transmission channels with different transmission rates and power consumption levels, and the backup transmission channels are isolated from and operate independently of all the main transmission channels.

[0055] The primary transmission channel refers to the transmission link that undertakes the main file fragment transmission tasks under normal transmission conditions and is the core carrier channel for FTP data transmission. The backup transmission channel refers to the fallback transmission link that is activated when the primary transmission channel fails. Under normal circumstances, it does not participate in regular transmission and only takes over the remaining transmission tasks when the primary channel fails.

[0056] Setting up only a single main transmission channel results in fixed transmission performance and power consumption, which cannot adapt to diverse operating scenarios: high-speed transmission is needed to improve efficiency when the device is under full load, while low-power transmission is needed to reduce system usage when the device is in low-power mode or resources are scarce. Setting up multiple main transmission channels with different rates and power consumption allows for flexible selection of transmission modes based on real-time scenarios, balancing transmission efficiency and system resource consumption. Specifically, under normal transmission conditions, the system selects the corresponding main transmission channel to undertake the transmission task based on the current device operating status, power consumption strategy, and network bandwidth conditions, or enables multiple main transmission channels to transmit data in parallel; high-speed, high-power main transmission channels are used for the rapid transmission of large files and high-priority tasks, while low-speed, low-power main transmission channels are used for the transmission of small files, low-priority tasks, or when the device is in energy-saving mode.

[0057] The backup transmission channel is completely independent of all main transmission channels in terms of connection links, resource allocation, and operating logic. Under normal transmission conditions, the backup transmission channel is in standby mode and does not carry regular transmission data. When all working main transmission channels are detected to have transmission abnormalities, the system activates the backup transmission channel and switches the unfinished file fragments to the backup channel to continue transmission. The abnormal state of the main channel will not interfere with the transmission of the backup channel, ensuring the reliability of backup transmission in abnormal scenarios.

[0058] Optionally, a dynamic start / stop mechanism for the primary transmission channel can be configured. The system automatically matches the corresponding channel based on the size and priority of the transmission task. When there is no transmission task, the channel enters a low-power standby state, further reducing the normal resource consumption of the device. The backup transmission channel can be configured with an independent network link and server access path. For example, the primary channel can use a wired network, and the backup channel can use a wireless network, which strengthens the channel isolation effect at the physical level and further reduces the probability of fault propagation.

[0059] By combining a differentiated main transmission channel with an isolated backup channel, a flexible balance between transmission efficiency and power consumption is achieved in conventional transmission scenarios, adapting to the resource constraints and operating states of different devices. In abnormal transmission scenarios, the independent reliability of the backup link is ensured, avoiding fault tolerance failure caused by fault propagation. Overall, the scenario adaptability and fault tolerance capability of the multi-channel FTP transmission mechanism are improved.

[0060] In some implementations, the task status metadata is updated in real time according to the transmission progress of file fragments; when the device restarts, the task status metadata stored locally is read, the location of the last successfully transmitted file fragment is located, the FTP transmission session is rebuilt, and fragment transmission is resumed.

[0061] Traditional FTP transfer progress information is only temporarily stored in the device's RAM. If the device experiences a sudden power outage or abnormal restart, all RAM data is erased, resulting in complete loss of the transfer progress. Subsequent transfers must start from the beginning, wasting bandwidth and time resources and failing to guarantee the continuity of the transfer task. Synchronizing the transfer progress in real-time to persistent storage of task status metadata, ensuring the latest transfer status is preserved even in the event of a power outage, is a core prerequisite for resuming transfers after a power outage. Specifically, during file chunk transfer, after each successful chunk transfer, the system synchronously updates the task status metadata in local persistent storage. The update includes the last successfully transferred chunk number, the data offset of the completed transfer, and the current running status of the task. Each update operation is persisted before continuing the transfer of the next chunk, ensuring that progress data is not lost due to sudden power outages.

[0062] Unexpected power outages and forced restarts of industrial equipment are frequent abnormal scenarios. Traditional FTP transfer solutions lack task memory capabilities, requiring manual re-initiation of transfer tasks after a device restart, necessitating the transfer of all data from the beginning. This incurs extremely high labor and time costs in scenarios with mass device deployment. Implementing automatic identification and automatic resumption of transfers after a device restart allows transfer tasks to recover autonomously without intervention, improving transfer efficiency in abnormal scenarios. Specifically, after the device restarts and the system resumes operation, it automatically scans all transfer tasks in the local persistent storage area, filtering out those incomplete and awaiting resumption. The system reads the status metadata of the corresponding task, locates the last successfully transferred file fragment, and sets this location as the starting point for resuming the transfer. Subsequently, the system automatically re-establishes the FTP transfer session with the remote server and continues transferring the remaining file fragments from the breakpoint, eliminating the need to re-transmit successfully transferred fragments.

[0063] Optionally, a threshold for the number of retries to restore transmission can be set. When multiple consecutive automatic restorations fail, the system marks the corresponding task as a failed restoration, stops automatic retries, and retains local task status metadata and fragment cache data for manual intervention to troubleshoot and prevent invalid retries from continuously consuming system resources. Before restoring transmission, the system can re-check the operating status of all transmission channels and prioritize the transmission channel with the best current status to perform the resume task, further improving the stability and efficiency of transmission after restoration.

[0064] By persistently updating task progress in real time and automatically resuming interrupted transmissions after device restart, the abnormal recovery capability of FTP transmission is extended to the scenario of device power failure and restart. This enables the tracking and recovery of the entire lifecycle of transmission tasks, solving the pain points of traditional solutions where progress is lost after power failure and manual retransmission is required. It reduces the cost of manual operation and maintenance, avoids bandwidth and time loss caused by repeated transmissions, and effectively improves the continuity and overall operating efficiency of FTP transmission in complex industrial environments.

[0065] In some implementations, after each file fragment is transmitted, a fragment-level integrity check is performed on the fragment, and the corresponding task status metadata is updated after the check passes.

[0066] Fragment-level integrity verification refers to a consistency verification operation performed independently on a single file fragment. Based on a pre-stored fragment baseline verification value, it compares the fragment data verification value after transmission is completed to verify whether a single fragment has been lost, disordered, or damaged during transmission. It is a more granular means of transmission quality verification.

[0067] If a global integrity check is performed only once after all fragments have been transmitted, it becomes impossible to pinpoint the specific fragment that is erroneous if a data error is detected. This necessitates retransmitting the entire data, wasting significant bandwidth and time. Performing an independent check immediately after each fragment transmission allows for the immediate detection of single-fragment transmission errors, narrowing the fault location granularity from the entire file to a single fragment and preventing errors from accumulating. Specifically, after a single file fragment completes remote transmission, the system immediately retrieves the baseline checksum corresponding to that fragment and simultaneously calculates the actual checksum of the fragment data after transmission. The two sets of checksums are then compared for consistency. If the comparison results match, the fragment transmission is considered valid; otherwise, it is considered a failure. When the fragment-level integrity check passes, the system marks the fragment as successfully transmitted and synchronously updates the task status metadata in local storage, including the last successful fragment index and the offset of completed data. If the check fails, the task progress is not updated, and the retransmission process for the corresponding fragment is triggered.

[0068] Optionally, if fragment-level verification fails, the system can automatically trigger a retransmission operation for that fragment and record the number of consecutive failures for a single fragment. When the number of failures exceeds a preset threshold, it can be determined that the current transmission link is abnormal, and the channel switching process can be automatically triggered, realizing the linkage between fragmentation errors and channel fault tolerance mechanisms. Fragment-level verification can be linked with the mirror fragmentation mechanism. When the mirror fragment verification in a certain channel fails, the system can directly use the mirror fragment that has passed verification in other channels as a valid fragment without initiating additional retransmission, further reducing transmission latency in abnormal scenarios.

[0069] By combining single-segment real-time verification with progress-linked updates, and together with global file-level verification, a two-layer verification system is formed. This system can detect and accurately locate transmission errors in advance, reduce the scope of retransmissions, and reduce resource consumption from invalid transmissions. It can also ensure the accuracy and reliability of task progress data, improve the effectiveness of resuming interrupted transmissions, and strengthen the overall data integrity guarantee capability of FTP transmissions. At the same time, it can improve the processing efficiency in abnormal transmission scenarios.

[0070] In some implementations, temporary files in the temporary storage area are named using a rule that combines a unique task identifier with a timestamp.

[0071] A unique task identifier is a globally unique identifier assigned to each transmission task. The identifiers of different transmission tasks are not repeated and can be accurately matched with all the attributes and progress information of a single transmission task.

[0072] In scenarios where multiple devices and tasks simultaneously transfer files to the same remote server, if temporary files use simple fixed names, sequence numbers, or generic temporary filenames, it is highly likely that temporary files from different tasks will have the same name. This can cause later-written files to overwrite existing temporary files, resulting in data loss and incorrect verification results. Furthermore, irregular naming makes it impossible to quickly associate temporary files with their corresponding transmission tasks, leading to extremely low efficiency in troubleshooting and data tracing. Adopting a naming rule that combines a unique task identifier with a timestamp can naturally avoid name conflicts at the naming level, while also serving as a tool for task tracing and time stamping.

[0073] Specifically, each transmission task generates a globally unique task identifier during the initialization phase, which is unique across the entire system. When a corresponding temporary file is generated in the remote temporary storage area, the system extracts the unique task identifier of the current task, concatenates it with the timestamp information of the temporary file generation time, and combines them to form a complete temporary file name. All temporary files stored in the temporary storage area are named according to this unified rule and correspond one-to-one with different transmission tasks.

[0074] Optionally, automatic lifecycle management can be implemented based on the timestamp information in the temporary file name. The system periodically scans the temporary storage area, and automatically performs a cleanup and deletion operation when the existence time of a temporary file exceeds a preset period, eliminating the need for manual maintenance of the temporary storage area. Quick retrieval of temporary files can be achieved based on a unique task identifier. When performing breakpoint resume, file verification, or task recovery operations, the corresponding temporary file can be quickly located directly through the task identifier, improving the overall efficiency of the transmission process.

[0075] By using a naming rule that combines a unique task identifier with a timestamp for temporary files, the problem of duplicate file names and data confusion in concurrent multi-task transmission scenarios is effectively solved. This ensures the independence and security of intermediate data for each transmission task, while also giving temporary files traceability attributes, thus improving the management efficiency and troubleshooting efficiency of the temporary storage area.

[0076] Figure 3This is a flowchart illustrating the FTP anomaly recovery and data saving process based on a six-joint robot teach pendant. The teach pendant initiates an FTP data transfer task and completes initialization, generating a traceable transfer task and preparing file fragments and metadata. Subsequently, it establishes an FTP session with the remote server and initiates fragment upload. After transmission begins, the teach pendant first generates an FTP-TC buffer area as a transmission control carrier, then allows FTP data to enter the FTP-HLA area with a multi-channel architecture for transmission scheduling. After entering this area, the data first performs a mirror copy of the fragments, then proceeds to two branches based on the link status. When transmission is normal, the mirrored fragments are distributed to devices with different speed and energy consumption attributes. The H / L channels transmit in parallel, balancing efficiency and power consumption to ensure transmission continuity. In case of transmission failure, the backup A channel, isolated from the main channel, is automatically activated to take over the remaining fragment transmission and avoid the impact of main channel failure. After all fragment transmissions are completed, data verification and atomic commit are performed to verify data integrity and complete atomic activation, preventing corrupted files from being stored. After verification, the file will be finalized with a formal filename and format based on timestamps and content attributes, while releasing system resources such as buffers and temporary storage occupied by transmission. Finally, if the teach pendant suddenly loses power and restarts, the locally retained task progress and fragment data can support automatic breakpoint recovery of the transmission task.

[0077] The technical solution of this embodiment generates a corresponding transmission task after receiving a file transmission request, performs logical fragmentation on the file to be transmitted and retains task status metadata, establishes an FTP transmission session and transmits file fragments in parallel through multiple independent channels, monitors the operating status of each channel synchronously, and automatically switches to the backup channel to continue transmitting unfinished fragments when a transmission abnormality occurs in the working channel. All transmitted fragments are temporarily stored in the temporary storage area of ​​the remote server. After all fragments are transmitted, an integrity check is performed. After the check passes, the fragments are integrated into the formal target file. This solution can adapt to the hardware characteristics of resource-constrained devices and complex working conditions in industrial sites, and at the same time realizes automatic recovery from FTP transmission abnormalities and data integrity assurance, effectively improving transmission reliability and overall operation and maintenance efficiency.

[0078] According to embodiments of the present invention, an FTP transmission exception handling apparatus corresponding to the FTP transmission exception handling method is also provided. See also Figure 2 The schematic diagram of an embodiment of the device of the present invention shown below indicates that the FTP transmission exception handling device may include: a task processing unit 101, a transmission control unit 102, a fragmentation temporary storage unit 103, and a verification and submission unit 104.

[0079] The task processing unit 101 is configured to respond to a file transfer request by logically segmenting the file to be transferred, generating a corresponding transfer task, and storing the task status metadata locally.

[0080] Logical fragmentation refers to splitting a complete file to be transmitted into multiple independent, ordered data fragments according to preset rules. Each fragment has an independent identifier and location information. The fragmentation process only changes the granularity of data transmission, without altering the content and structure of the file itself. Task status metadata refers to a set of information used to describe the attributes and progress of the transmission task. It includes data such as the task's unique identifier, basic file information, total number of fragments, the location of completed fragments, and the task's running status. It is the core basis for achieving traceable and recoverable transmission.

[0081] Traditional FTP transfers are mostly stateless, single-transfer operations. Tasks lack unified identification, and files are not segmented into granular units. Once a transfer is interrupted, it is impossible to track progress or accurately resume the transfer. Retransmitting the entire file wastes a significant amount of time and bandwidth. Splitting files into logical chunks and generating traceable transfer tasks is a prerequisite for enabling breakpoint resumption and anomaly recovery.

[0082] Specifically, when the system receives a file upload request, it first generates a uniquely identified transmission task for this transmission; then it reads the complete information of the file to be transmitted, splits the file into multiple consecutive logical segments according to preset rules, and generates basic information such as segment number, data offset, and data length for each segment; finally, it writes all metadata such as task status and segment information to the local storage medium, and marks the initial state of the task as pending execution.

[0083] The transmission control unit 102 is configured to establish an FTP transmission session, transmit file fragments in parallel through multiple independent transmission channels, and monitor the operating status of each transmission channel in real time.

[0084] Independent transmission channels refer to FTP transmission links where the operating logic and link resources of each other do not interfere with each other. A failure in one channel will not directly affect the normal operation of other channels.

[0085] Single-channel FTP transmission has extremely low fault tolerance; network fluctuations or link interruptions will cause the entire transmission task to stall, requiring manual restart. Furthermore, the transmission efficiency of a single channel is fixed and cannot adapt to different network environments and power consumption requirements. Using multiple independent channels for parallel transmission can improve fault tolerance through redundant links and increase transmission efficiency through parallel distribution. Real-time status monitoring is a prerequisite for automatic failover in case of anomalies.

[0086] Specifically, the system establishes an FTP connection with the remote server based on the task information and completes identity authentication to formally establish a transmission session; then, it activates multiple independent transmission channels and distributes the files to be transmitted in chunks to each channel for parallel transmission; throughout the transmission process, the system continuously collects operating parameters such as the connection status, data transmission rate, and response timeout of each transmission channel to determine in real time whether the channel is in normal working condition.

[0087] The transmission control unit 102 is also configured to switch to a backup transmission channel to continue transmitting unfinished file fragments when a transmission anomaly is detected in the transmission channel that is in operation.

[0088] In complex environments such as industrial sites, network fluctuations and temporary link failures are frequent occurrences. Traditional single-channel solutions directly interrupt tasks upon encountering anomalies, requiring manual intervention for restart, resulting in high maintenance costs and low efficiency. Setting up a backup channel and implementing automatic switching can seamlessly take over transmission tasks when the primary link fails, achieving unattended automatic recovery in abnormal scenarios.

[0089] Specifically, when the system determines that the currently operating transmission channel is experiencing abnormal transmission conditions such as connection interruption, continuous timeout, or packet loss rate exceeding a preset threshold, the system automatically terminates the transmission task of the abnormal channel and schedules the remaining untransmitted files of that channel to the backup transmission channel. After the backup channel takes over the fragments, it continues to execute the transmission according to the original fragment order, and the overall transmission task does not need to be paused or restarted.

[0090] The fragmented temporary storage unit 103 is configured to temporarily store fragments of the transmitted file in the temporary storage area of ​​the remote server.

[0091] Temporary storage area refers to an independent storage path on a remote server specifically used to store intermediate data during transmission. The data in this area will not be used directly as formal business files, but only for temporary storage and verification during the transmission process.

[0092] If the actual business data is written directly during transmission, and an error occurs midway, the server will be left with incomplete files. These incomplete files may overwrite existing files and make it impossible to accurately determine file validity later. Setting up a separate temporary storage area to isolate the intermediate state of transmission can prevent damage to actual business data from abnormal transmission at the source.

[0093] Specifically, after each file fragment is transmitted remotely, it is not directly written to the storage path of the formal business file, but is uniformly stored in an independent temporary storage area pre-defined by the remote server; all intermediate data in the transmission process is stored in this area, completely isolated from the storage path of the formal business file.

[0094] The verification submission unit 104 is configured to perform integrity verification on all fragmented data in the temporary storage area after all file fragments have been transferred.

[0095] The verification submission unit 104 is also configured to integrate the fragmented data in the temporary storage area into a formal target file if the verification passes.

[0096] Integrity verification is used to compare the transmitted data with the original data using a verification algorithm, verifying whether the data was lost, tampered with, or damaged during transmission. Even if all fragments are transmitted successfully, some fragments may still experience packet loss or corruption, which can lead to file corruption if directly integrated and used. Performing a full integrity verification before the data becomes available verifies the accuracy of the transmission results from the perspective of the entire file, filtering out transmission results with missing or incorrect data.

[0097] Specifically, once the system determines that all file fragments have been successfully transmitted remotely, it reassembles all fragments in the temporary storage area sequentially. Then, it calculates the checksum of the reassembled file using a preset verification algorithm and compares this checksum with the baseline checksum of the source file to determine if the transmitted data is complete and consistent. If the integrity check passes, the system reassembles all fragment data in the temporary storage area into a complete target file, converts this file into a formal business file, and includes it in the formal file storage path. After conversion, the transmission task status is synchronously updated to "completed." If the integrity check fails, the fragment data in the temporary storage area and the local task status metadata are retained, marking the task as a failed check, supporting subsequent automatic retries or manual intervention to prevent data loss.

[0098] Optionally, the operation of integrating fragmented data in the temporary storage area into a formal target file can be achieved through atomic renaming. That is, the recombined complete file is first stored in a temporary path, and after verification, it is renamed to the formal file name in one go. This operation is an atomic operation, which can avoid file corruption during the conversion process.

[0099] This invention, through a comprehensive design encompassing task-based management, multi-channel redundant transmission, automatic failover in case of anomalies, temporary area isolation, and effective integrity verification, simultaneously achieves automatic recovery from transmission anomalies and ensures the integrity of remote data. It solves the problems of traditional FTP transmission requiring manual restarts and incurring high maintenance costs when encountering anomalies, while also avoiding file corruption and poor data consistency caused by transmission interruptions. It can reliably improve the reliability and efficiency of FTP transmission in complex network and device environments. Furthermore, this solution is adaptable to the operating scenarios of embedded industrial control equipment, and the entire process can be streamlined to reduce memory and computing resource consumption, making it suitable for resource-constrained device environments.

[0100] In some implementations, after logically fragmenting the file to be transmitted, at least two identical mirror fragments are generated for each file fragment, and each mirror fragment is assigned to different transmission channels for parallel transmission.

[0101] Mirrored shards refer to replica shards generated based on the original logical shards, which are completely identical to the original shards in terms of data content. Each mirrored shard carries the same metadata as the original shard, such as the shard number, offset, and checksum. If any mirrored shard is successfully transmitted and verified, it can represent the corresponding original shard in the transmission process.

[0102] Relying solely on link-level redundancy through channel switching still presents the problem of retransmission after single-fragment transmission failure or packet loss, which increases transmission latency and system overhead. Generating fragment replicas at the data level allows the same fragment to be transmitted simultaneously on multiple links. As long as one replica succeeds, the fragment transmission is complete, eliminating the need for retransmission. Furthermore, multiple fragment data copies can be retained in abnormal scenarios to prevent data loss due to the loss of a single replica. Specifically, after logically splitting the file to be transmitted, at least two mirror fragments with completely identical data content are created for each original file fragment. All mirror fragments inherit all metadata from the original fragment, including its number, data offset, length, and checksum, ensuring that any successful replica transmission can be correctly identified and reassembled.

[0103] If multiple mirror fragments of the same original fragment are assigned to the same transmission channel, all replicas will fail simultaneously if that channel malfunctions, rendering redundancy ineffective. Distributing replicas to different independent channels leverages the independence of the channels to ensure that at least one replica can be transmitted normally. This creates a synergistic effect between data redundancy and link redundancy, meaning that even if some transmission channels malfunction, mirror fragments on the remaining channels can still complete transmission, maximizing the success rate of fragment transmission in abnormal scenarios. Specifically, the system allocates all mirror fragments corresponding to the same original fragment to different independent transmission channels according to rules such as channel load and channel operating status. Each channel synchronously initiates the transmission operation of its corresponding mirror fragment without interfering with each other. Once the system detects that any mirror fragment transmission is complete and the verification is valid, it determines that the corresponding original fragment transmission was successful.

[0104] Optionally, once the system determines that any mirror fragment corresponding to a given original fragment has been successfully transmitted, it can proactively send a termination command to the remaining channels, interrupting the transmission of other mirror copies of the same fragment, releasing the corresponding bandwidth and channel resources, and avoiding unnecessary resource consumption. Furthermore, differentiated mirror fragment numbers can be configured for files of different importance levels. For example, more mirror copies can be set for core configuration files and critical log files, while fewer copies can be set for ordinary files, ensuring the reliability of critical data while controlling overall resource consumption.

[0105] By generating multiple image fragments and distributing them to different independent channels for parallel transmission, data-level transmission redundancy is further increased on the basis of link-level redundancy. This can effectively reduce the probability of fragment transmission failure in network fluctuation scenarios, reduce the number of retransmissions and transmission latency, and improve data retention capabilities in abnormal scenarios. This further enhances the fault tolerance and overall operating efficiency of FTP transmission, making it more suitable for application scenarios with complex network environments and high data reliability requirements.

[0106] In some implementations, the multiple independent transmission channels include at least two main transmission channels with different transmission rates and power consumption levels, and the backup transmission channels are isolated from and operate independently of all the main transmission channels.

[0107] The primary transmission channel refers to the transmission link that undertakes the main file fragment transmission tasks under normal transmission conditions and is the core carrier channel for FTP data transmission. The backup transmission channel refers to the fallback transmission link that is activated when the primary transmission channel fails. Under normal circumstances, it does not participate in regular transmission and only takes over the remaining transmission tasks when the primary channel fails.

[0108] Setting up only a single main transmission channel results in fixed transmission performance and power consumption, which cannot adapt to diverse operating scenarios: high-speed transmission is needed to improve efficiency when the device is under full load, while low-power transmission is needed to reduce system usage when the device is in low-power mode or resources are scarce. Setting up multiple main transmission channels with different rates and power consumption allows for flexible selection of transmission modes based on real-time scenarios, balancing transmission efficiency and system resource consumption. Specifically, under normal transmission conditions, the system selects the corresponding main transmission channel to undertake the transmission task based on the current device operating status, power consumption strategy, and network bandwidth conditions, or enables multiple main transmission channels to transmit data in parallel; high-speed, high-power main transmission channels are used for the rapid transmission of large files and high-priority tasks, while low-speed, low-power main transmission channels are used for the transmission of small files, low-priority tasks, or when the device is in energy-saving mode.

[0109] The backup transmission channel is completely independent of all main transmission channels in terms of connection links, resource allocation, and operating logic. Under normal transmission conditions, the backup transmission channel is in standby mode and does not carry regular transmission data. When all working main transmission channels are detected to have transmission abnormalities, the system activates the backup transmission channel and switches the unfinished file fragments to the backup channel to continue transmission. The abnormal state of the main channel will not interfere with the transmission of the backup channel, ensuring the reliability of backup transmission in abnormal scenarios.

[0110] Optionally, a dynamic start / stop mechanism for the primary transmission channel can be configured. The system automatically matches the corresponding channel based on the size and priority of the transmission task. When there is no transmission task, the channel enters a low-power standby state, further reducing the normal resource consumption of the device. The backup transmission channel can be configured with an independent network link and server access path. For example, the primary channel can use a wired network, and the backup channel can use a wireless network, which strengthens the channel isolation effect at the physical level and further reduces the probability of fault propagation.

[0111] By combining a differentiated main transmission channel with an isolated backup channel, a flexible balance between transmission efficiency and power consumption is achieved in conventional transmission scenarios, adapting to the resource constraints and operating states of different devices. In abnormal transmission scenarios, the independent reliability of the backup link is ensured, avoiding fault tolerance failure caused by fault propagation. Overall, the scenario adaptability and fault tolerance capability of the multi-channel FTP transmission mechanism are improved.

[0112] In some implementations, the task status metadata is updated in real time according to the transmission progress of file fragments; when the device restarts, the task status metadata stored locally is read, the location of the last successfully transmitted file fragment is located, the FTP transmission session is rebuilt, and fragment transmission is resumed.

[0113] Traditional FTP transfer progress information is only temporarily stored in the device's RAM. If the device experiences a sudden power outage or abnormal restart, all RAM data is erased, resulting in complete loss of the transfer progress. Subsequent transfers must start from the beginning, wasting bandwidth and time resources and failing to guarantee the continuity of the transfer task. Synchronizing the transfer progress in real-time to persistent storage of task status metadata, ensuring the latest transfer status is preserved even in the event of a power outage, is a core prerequisite for resuming transfers after a power outage. Specifically, during file chunk transfer, after each successful chunk transfer, the system synchronously updates the task status metadata in local persistent storage. The update includes the last successfully transferred chunk number, the data offset of the completed transfer, and the current running status of the task. Each update operation is persisted before continuing the transfer of the next chunk, ensuring that progress data is not lost due to sudden power outages.

[0114] Unexpected power outages and forced restarts of industrial equipment are frequent abnormal scenarios. Traditional FTP transfer solutions lack task memory capabilities, requiring manual re-initiation of transfer tasks after a device restart, necessitating the transfer of all data from the beginning. This incurs extremely high labor and time costs in scenarios with mass device deployment. Implementing automatic identification and automatic resumption of transfers after a device restart allows transfer tasks to recover autonomously without intervention, improving transfer efficiency in abnormal scenarios. Specifically, after the device restarts and the system resumes operation, it automatically scans all transfer tasks in the local persistent storage area, filtering out those incomplete and awaiting resumption. The system reads the status metadata of the corresponding task, locates the last successfully transferred file fragment, and sets this location as the starting point for resuming the transfer. Subsequently, the system automatically re-establishes the FTP transfer session with the remote server and continues transferring the remaining file fragments from the breakpoint, eliminating the need to re-transmit successfully transferred fragments.

[0115] Optionally, a threshold for the number of retries to restore transmission can be set. When multiple consecutive automatic restorations fail, the system marks the corresponding task as a failed restoration, stops automatic retries, and retains local task status metadata and fragment cache data for manual intervention to troubleshoot and prevent invalid retries from continuously consuming system resources. Before restoring transmission, the system can re-check the operating status of all transmission channels and prioritize the transmission channel with the best current status to perform the resume task, further improving the stability and efficiency of transmission after restoration.

[0116] By persistently updating task progress in real time and automatically resuming interrupted transmissions after device restart, the abnormal recovery capability of FTP transmission is extended to the scenario of device power failure and restart. This enables the tracking and recovery of the entire lifecycle of transmission tasks, solving the pain points of traditional solutions where progress is lost after power failure and manual retransmission is required. It reduces the cost of manual operation and maintenance, avoids bandwidth and time loss caused by repeated transmissions, and effectively improves the continuity and overall operating efficiency of FTP transmission in complex industrial environments.

[0117] In some implementations, after each file fragment is transmitted, a fragment-level integrity check is performed on the fragment, and the corresponding task status metadata is updated after the check passes.

[0118] Fragment-level integrity verification refers to a consistency verification operation performed independently on a single file fragment. Based on a pre-stored fragment baseline verification value, it compares the fragment data verification value after transmission is completed to verify whether a single fragment has been lost, disordered, or damaged during transmission. It is a more granular means of transmission quality verification.

[0119] If a global integrity check is performed only once after all fragments have been transmitted, it becomes impossible to pinpoint the specific fragment that is erroneous if a data error is detected. This necessitates retransmitting the entire data, wasting significant bandwidth and time. Performing an independent check immediately after each fragment transmission allows for the immediate detection of single-fragment transmission errors, narrowing the fault location granularity from the entire file to a single fragment and preventing errors from accumulating. Specifically, after a single file fragment completes remote transmission, the system immediately retrieves the baseline checksum corresponding to that fragment and simultaneously calculates the actual checksum of the fragment data after transmission. The two sets of checksums are then compared for consistency. If the comparison results match, the fragment transmission is considered valid; otherwise, it is considered a failure. When the fragment-level integrity check passes, the system marks the fragment as successfully transmitted and synchronously updates the task status metadata in local storage, including the last successful fragment index and the offset of completed data. If the check fails, the task progress is not updated, and the retransmission process for the corresponding fragment is triggered.

[0120] Optionally, if fragment-level verification fails, the system can automatically trigger a retransmission operation for that fragment and record the number of consecutive failures for a single fragment. When the number of failures exceeds a preset threshold, it can be determined that the current transmission link is abnormal, and the channel switching process can be automatically triggered, realizing the linkage between fragmentation errors and channel fault tolerance mechanisms. Fragment-level verification can be linked with the mirror fragmentation mechanism. When the mirror fragment verification in a certain channel fails, the system can directly use the mirror fragment that has passed verification in other channels as a valid fragment without initiating additional retransmission, further reducing transmission latency in abnormal scenarios.

[0121] By combining single-segment real-time verification with progress-linked updates, and together with global file-level verification, a two-layer verification system is formed. This system can detect and accurately locate transmission errors in advance, reduce the scope of retransmissions, and reduce resource consumption from invalid transmissions. It can also ensure the accuracy and reliability of task progress data, improve the effectiveness of resuming interrupted transmissions, and strengthen the overall data integrity guarantee capability of FTP transmissions. At the same time, it can improve the processing efficiency in abnormal transmission scenarios.

[0122] In some implementations, temporary files in the temporary storage area are named using a rule that combines a unique task identifier with a timestamp.

[0123] A unique task identifier is a globally unique identifier assigned to each transmission task. The identifiers of different transmission tasks are not repeated and can be accurately matched with all the attributes and progress information of a single transmission task.

[0124] In scenarios where multiple devices and tasks simultaneously transfer files to the same remote server, if temporary files use simple fixed names, sequence numbers, or generic temporary filenames, it is highly likely that temporary files from different tasks will have the same name. This can cause later-written files to overwrite existing temporary files, resulting in data loss and incorrect verification results. Furthermore, irregular naming makes it impossible to quickly associate temporary files with their corresponding transmission tasks, leading to extremely low efficiency in troubleshooting and data tracing. Adopting a naming rule that combines a unique task identifier with a timestamp can naturally avoid name conflicts at the naming level, while also serving as a tool for task tracing and time stamping.

[0125] Specifically, each transmission task generates a globally unique task identifier during the initialization phase, which is unique across the entire system. When a corresponding temporary file is generated in the remote temporary storage area, the system extracts the unique task identifier of the current task, concatenates it with the timestamp information of the temporary file generation time, and combines them to form a complete temporary file name. All temporary files stored in the temporary storage area are named according to this unified rule and correspond one-to-one with different transmission tasks.

[0126] Optionally, automatic lifecycle management can be implemented based on the timestamp information in the temporary file name. The system periodically scans the temporary storage area, and automatically performs a cleanup and deletion operation when the existence time of a temporary file exceeds a preset period, eliminating the need for manual maintenance of the temporary storage area. Quick retrieval of temporary files can be achieved based on a unique task identifier. When performing breakpoint resume, file verification, or task recovery operations, the corresponding temporary file can be quickly located directly through the task identifier, improving the overall efficiency of the transmission process.

[0127] By using a naming rule that combines a unique task identifier with a timestamp for temporary files, the problem of duplicate file names and data confusion in concurrent multi-task transmission scenarios is effectively solved. This ensures the independence and security of intermediate data for each transmission task, while also giving temporary files traceability attributes, thus improving the management efficiency and troubleshooting efficiency of the temporary storage area.

[0128] Since the processing and functions implemented by the device in this embodiment are basically the same as the embodiments, principles and examples of the aforementioned methods, any details not covered in the description of this embodiment can be found in the relevant descriptions in the aforementioned embodiments, and will not be repeated here.

[0129] The technical solution of this invention addresses the needs of FTP file transfer by first generating a dedicated transfer task and completing the logical splitting of the file, synchronously storing task status metadata for progress tracking, and then distributing file fragments in parallel through multiple independent transfer channels after establishing an FTP session. The operation status of the channels is monitored throughout the process, and the backup channel is automatically switched to continue the transfer when the main working channel malfunctions. The fragmented data during the transfer process is uniformly and temporarily stored in a remote temporary storage area. After the full fragment transfer is completed, integrity verification is performed, and the target file is officially generated after the verification is passed. This solution can adapt to the hardware constraints of resource-limited devices and the complex environment of industrial sites, taking into account both the automatic recovery capability of transmission anomalies and the data integrity guarantee capability, significantly improving the transmission stability and operation and maintenance efficiency.

[0130] According to an embodiment of the present invention, a teach pendant corresponding to an FTP transfer error handling device is also provided. This teach pendant may include the FTP transfer error handling device described above.

[0131] Since the processing and functions implemented by the teach pendant in this embodiment are basically the same as the embodiments, principles and examples of the aforementioned devices, any details not covered in the description of this embodiment can be found in the relevant descriptions in the aforementioned embodiments, and will not be repeated here.

[0132] The technical solution of this invention generates an independent transmission task when responding to a file transmission request. The file to be transmitted is split into multiple logical fragments and the task status metadata is persistently stored. After establishing an FTP transmission link, the fragment data is transmitted in parallel through multiple independent channels. The operating status of each transmission channel is monitored in real time. When a working channel fails, a backup channel is automatically switched to complete the transmission of the remaining fragments. The transmitted fragment data is uniformly stored in the temporary storage area of ​​a remote server. After all fragments have been transmitted, an overall integrity check is performed. After the check passes, the files are formally integrated. This solution can adapt to the complex working conditions of industrial sites and the hardware conditions of resource-constrained equipment, and simultaneously achieves the goals of automatic recovery from transmission failures and data integrity and reliability, effectively improving transmission reliability and operation and maintenance efficiency.

[0133] According to an embodiment of the present invention, a storage medium corresponding to the FTP transmission exception handling method is also provided. The storage medium includes a stored program, wherein the program controls the device where the storage medium is located to execute the FTP transmission exception handling method described above when it is running.

[0134] Since the processing and functions implemented by the storage medium in this embodiment are basically the same as the embodiments, principles and examples of the aforementioned methods, any details not covered in this embodiment can be found in the relevant descriptions in the aforementioned embodiments, and will not be repeated here.

[0135] The technical solution of this invention, after initiating an FTP file transfer request, generates a corresponding transfer task, performs logical fragmentation on the file to be transferred and retains task status metadata, establishes an FTP transfer session with the remote end, distributes fragmented data in parallel through multiple independent transfer channels, monitors the channel operation status throughout the process, automatically switches to a backup channel to continue the transfer when a working channel experiences a transfer failure, and temporarily stores the fragments that have been transferred to a remote temporary storage area. After the full fragment transfer is completed, a full data integrity check is performed, and after the check passes, the data is integrated to generate the formal target file. This solution can adapt to the hardware constraints of resource-limited devices and complex working conditions in industrial sites, while also achieving automatic recovery from transmission anomalies and ensuring data integrity, significantly improving transmission stability and operation and maintenance management efficiency.

[0136] According to an embodiment of the present invention, a computer program product corresponding to the FTP transmission exception handling method is also provided. The computer program product includes a computer program that, when processed and executed, implements the steps of the above-described FTP transmission exception handling method.

[0137] Since the processing and functions implemented by the computer program product in this embodiment are basically corresponding to the embodiments, principles and examples of the aforementioned methods, any details not covered in the description of this embodiment can be found in the relevant descriptions in the aforementioned embodiments, and will not be repeated here.

[0138] The technical solution of this invention generates a traceable transmission task upon receiving an FTP file transfer request. The file to be transferred is logically fragmented, and task status metadata is stored. After establishing an FTP transmission session, file fragments are transmitted in parallel through multiple independent channels. The operating status of each channel is monitored in real time. If a working channel malfunctions, a backup channel is automatically switched to continue transmitting unfinished fragments. Completed fragments are temporarily stored in a temporary storage area on a remote server. After all fragments have been transmitted, an integrity check is performed on the entire dataset. Once the check passes, the fragmented data is integrated into a formal target file. This solution is adaptable to complex working conditions in industrial settings and the hardware characteristics of resource-constrained equipment. It also enables automatic recovery from transmission anomalies and reliable data integrity assurance, effectively improving the reliability of the transmission process and the overall efficiency of operation and maintenance.

[0139] In summary, it is readily understood by those skilled in the art that, without conflict, the aforementioned advantageous methods can be freely combined and superimposed.

[0140] The above description is merely an embodiment of the present invention and is not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of the claims of the present invention.

Claims

1. A method for handling FTP transmission anomalies, characterized in that, include: In response to a file transfer request, the file to be transferred is logically segmented, a corresponding transfer task is generated, and the task status metadata is stored locally. Establish an FTP transfer session and transfer file fragments in parallel through multiple independent transfer channels, while monitoring the operating status of each transfer channel in real time; When a transmission anomaly is detected in a working transmission channel, the system switches to a backup transmission channel to continue transmitting the incomplete file fragments. The transmitted file segments are temporarily stored in the temporary storage area of ​​the remote server; After all file fragments have been transferred, the integrity of all fragment data in the temporary storage area is verified. If the verification passes, the fragmented data in the temporary storage area will be integrated into the final target file.

2. The FTP transmission exception handling method according to claim 1, characterized in that, The method further includes: after logically segmenting the file to be transmitted, generating at least two identical mirror segments for each file segment, and allocating each mirror segment to different transmission channels for parallel transmission.

3. The FTP transmission anomaly handling method according to claim 1 or 2, characterized in that, The multiple independent transmission channels include at least two main transmission channels with different transmission rates and power consumption levels, and the backup transmission channels are isolated from all the main transmission channels and operate independently.

4. The FTP transmission exception handling method according to claim 1, characterized in that, The method further includes: updating the task status metadata in real time according to the transmission progress of file segments; when the device restarts, reading the locally stored task status metadata, locating the last successfully transmitted file segment, reconstructing the FTP transmission session, and resuming segment transmission.

5. The FTP transmission exception handling method according to claim 1 or 4, characterized in that, After each file fragment is transmitted, a fragment-level integrity check is performed on that fragment. Once the check passes, the corresponding task status metadata is updated.

6. The FTP transmission exception handling method according to claim 1, characterized in that, The temporary files in the temporary storage area are named using a combination of a unique task identifier and a timestamp.

7. An FTP transmission exception handling device, characterized in that, include: The task processing unit is configured to respond to a file transfer request by logically segmenting the file to be transferred, generating a corresponding transfer task, and storing the task status metadata locally. The transmission control unit is configured to establish FTP transmission sessions, transmit file fragments in parallel through multiple independent transmission channels, and monitor the operating status of each transmission channel in real time. The transmission control unit is also configured to switch to a backup transmission channel to continue transmitting the incomplete file fragments when a transmission anomaly is detected in the transmission channel that is in operation. The fragmented temporary storage unit is configured to temporarily store fragments of the transmitted file in the temporary storage area of ​​the remote server. The verification submission unit is configured to perform integrity verification on all fragment data in the temporary storage area after all file fragments have been transferred. The verification submission unit is also configured to integrate the fragmented data in the temporary storage area into a formal target file if the verification passes.

8. A teach pendant, characterized in that, include: The FTP transfer exception handling device as described in claim 7.

9. A storage medium, characterized in that, The storage medium includes a stored program, wherein, when the program is executed, it controls the device where the storage medium is located to perform the FTP transmission exception handling method as described in any one of claims 1 to 6.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the steps of the FTP transfer exception handling method as described in any one of claims 1 to 6.

Images