JPH0247339A - Trouble check equipment for loom - Google Patents

Abstract

PURPOSE:To provide the title equipment so designed that a memory means to store check and action procedures for each trouble code and a writing means into said memory means are provided, and data are rearranged in the order of frequency in development of troubles and also novel trouble processing contents are inputted, thereby preparing for quickly dealing with troubles. CONSTITUTION:The objective trouble check equipment is so designed that possible troubles for a loom are coded and a memory means to store check and action procedures as data for each trouble code is provided to send the procedures corresponding to loom troubles to loom side. Furthermore, causes or checkpoints for certain troubles are regularly rearranged in the order of frequency in development of such troubles and/or other action procedures for new troubles which have not been inputted as data yet are added, along with providing a writing means to make a memory revision.

Description

[Detailed Description of the Invention] Industrial Application Field The present invention relates to a trouble diagnosis device for looms, and particularly improves the efficiency of troubleshooting (trouble processing) and utilizes in-factory experience for troubleshooting from the next time onwards. This invention relates to a trouble diagnosis device for looms that can be used.

Troubleshooting of prior art looms has traditionally been done by relying on manuals. In other words, trouble codes for the loom were assumed in advance, and procedures for diagnosing and dealing with them were detailed in the manual.

The maintenance engineer was troubleshooting the machine while looking at this manual. In this case, the manual is not distributed to all maintenance workers, but is often kept in the control room, so maintenance workers have to go there and investigate every time a problem occurs, which reduces their work time. There were many losses.

Furthermore, if a microprocessor is used to control the loom, it may be possible to write troubleshooting information into the program in advance and display it on a display on the loom when a problem occurs.

In this way, it becomes possible to check while looking at the display on the loom. However, even when troubleshooting is carried out using this method, ``the experience of actually encountering troubles can be used to update the data for troubleshooting and countermeasure procedures, which can be managed as a factory as a whole and utilized in the future when troubles occur. There is no such device yet.

Problems to be Solved by the Invention As described above, in the conventional trouble diagnosis device, l! Previously, machine troubles had only been coded and diagnostic procedures for each code had been prepared in a manual, so it was necessary to create new diagnostic procedures that sorted the causes and check points for a particular trouble in order of frequency of occurrence, and to It was difficult to add new data that contained solutions to actual problems that had not been entered as new data.

Purpose of the Invention The present invention was made in order to solve the problems of the conventional trouble diagnosis device. It is an object of the present invention to provide a trouble diagnosis device for a loom capable of updating troubleshooting data based on accumulated data.

Means of the Invention Therefore, the present invention provides a loom trouble diagnosis device that responds to inquiries regarding troubles in the loom and transmits diagnosis and countermeasure procedures to the loom side, and a memory that stores the diagnosis and countermeasure procedures for each trouble code as data. and memory writing means for updating the data of the corresponding diagnosis and countermeasure procedure based on implementation of the diagnostic countermeasure procedure for a specific trouble code and re-storing the data in the memory means.

The memory writing means of the present invention enables more efficient diagnosis by periodically sorting the causes and check points of a certain trouble in order of frequency of occurrence, and by adding solutions to actual troubles that have not been input as data. , determine a countermeasure procedure, update the data, and write the updated data into the memory means.

Embodiment 1 Hereinafter, embodiments of the present invention will be described in detail based on the drawings.

FIG. 1 is a block diagram of a trouble diagnosis device showing a first embodiment of the present invention.

The first embodiment shows a case where data for troubleshooting is input into a storage medium such as a memory card. In the memory card 1, diagnostic and countermeasure procedures such as causes and check points are stored as data for each trouble code.

In order to read data for troubleshooting from this memory card l, it is necessary to specify a trouble code corresponding to the trouble.

Each control means 11-1.11-2...11-n of the loom includes a trouble detection means 10-1.10-2...10.
-n is provided, and these trouble detection means 10
-1.10-2・Troubles detected by 10-n are assigned a trouble code depending on the type of trouble.

These trouble codes are trouble code generation means 9.
-1.9-2...9-n, and is transmitted to the common trouble code receiving means 7 via the trouble code transmitting means 8-1.8-2...8-n.

On the other hand, an inquiry command regarding a troubleshooting procedure is issued from the inquiry means 4, and this inquiry command is transmitted to the retrieval means 3 and the data storage means 5. In response to this inquiry command, data on a diagnostic procedure for the trouble code specified by the trouble code receiving means 7 is read out from the memory card 1 by the card reading means 2 and input to the searching means 3.

Then, the read data indicating the diagnostic handling procedure is stored in the data storage means 5 and then displayed on the display means 6.

Therefore, the maintenance engineer is configured to be able to troubleshoot according to the diagnosis and handling procedure displayed on the display means 6.

Further, FIG. 2 shows the configuration of an apparatus for updating data stored in the memory card 1 that indicates troubleshooting diagnostic handling procedures.

Data to be updated is input from the result input means 13 to the -time storage means 14. On the other hand, the card writing/continuation means 12 reads out data stored in advance from the memory card 1 and stores it in the -time storage means 14. The data read out from the memory card 1 in this way and the updated data input via the result input means 13 are stored in the temporary storage means 1.
It will be stored in 4.

Thereafter, the stored data is rearranged in a predetermined order, for example, in the order of frequency of occurrence, by the rearrangement means 15, and read into the memory card 1 again via the card writing/continuation means I2. Furthermore, when writing new data, it is similarly stored in the memory card 1 via the card writing/sequential output means 12.

FIG. 3 is a flowchart showing the procedure for reading data from the memory card 1 when a trouble occurs.

When a problem occurs, the maintenance engineer inserts the memory card l that stores the diagnostic response procedure as data into this device on the loom where the problem is occurring in order to read out the cause and check points corresponding to the trouble code, and makes an inquiry. An inquiry key built into means 4 is pressed (step 300).

Note that the flowchart shown in FIG. 3 is configured so that a trouble code can be input (step 302) in order to output data at times other than troubleshooting. In this way, when a trouble occurs and the inquiry key is pressed (step 301), or when a trouble code is input (step 302)
), data corresponding to the trouble code is read from the memory card 1 via the card successive output means 2.

The read data is once stored in the data storage means 5 and then displayed on the display means 6 (step 30).
4.305). The maintenance engineer first checks the specified part, and if there is no abnormality in that part, sends inquiry method 4.
When the next data key is pressed to request the next instruction (step 306), the next data is displayed on the display means 6.

In this way, maintenance engineers will carry out troubleshooting interactively (steps 307, 308, 3).
09). Next, when the cause of the trouble is found, the result is fed back to the memory card l by the card writing/continuation means 12 and added.

FIG. 4 is a flowchart showing the procedure for data addition (step 400). First, when adding or sorting data, write all data on the card to the card.
The reading means 12 reads the data from the memory card 1 (step 401) and stores it in the -time storage means 14 (step 402).

Next, a trouble code for which data should be updated is specified (step 403), and the diagnosis and countermeasure procedure for the specified trouble are input as data via the human power means 13 (step 404), and stored in the time storage means 14. do.

In this way, all the data read from the memory card 1 and the data newly input from the result input means 13 are rearranged by the rearrangement means 15 (
Step 405), and write the rearranged data to the memory card 1 (Step 406). When sorting, it is preferable to sort specific trouble codes in order of frequency of occurrence, and to sort the diagnostic measures j@ with high frequency of occurrence in the order in which they are displayed first.

In order to update such data for all maintenance workers, input may be performed each time, and writing to the memory card 1 may be performed periodically. Therefore, it is not necessary to provide a device for writing to the memory card 1 as shown in FIG. 2 for each loom, and only one device is required in the factory.

Further, if the cause cannot be determined even after checking all the data stored in the memory card 1, the maintenance engineer inquires the manufacturer and takes countermeasures as usual. As a result, if the cause is found, the cause will be added to the memory card l, so that it will be added as new processing content to troubleshooting from the next time onwards.

Furthermore, for problems that cannot be detected automatically, you can also specify a problem code and add items for manual inquiries.

In the embodiment described above, the data for troubleshooting is input into the storage medium, but the case where the data is input into the CPU of each loom can also be realized with a similar configuration.

Embodiment 2 FIG. 5 shows a second embodiment of the present invention, in which a memory 1a is provided in each of the looms L1, L2, . put. Among other constituent parts, the same or equivalent parts as shown in FIGS. 1 and 2 are given the same reference numerals, and detailed explanation thereof will be omitted.

The flowchart for reading and updating data from the memory la is almost the same as the flow shown in FIGS. 3 and 4. In this way, when storing diagnostic handling procedures in the CPU in a loom, a data rewriting device is required for each loom, and data must be updated for each loom.

Embodiment 3 Next, as a third embodiment, a case will be described in which data for troubleshooting is input into the host CPU to which each loom is connected.

FIG. 6 is a block diagram showing the configuration of this third embodiment. In the case of this embodiment, each loom L1, L2...
Ln is provided with a trouble detection means 129 for detecting trouble on the control device 128 and a control state storage means 131 for storing the control state of the control device 128.

Furthermore, trouble code generating means 130 is provided for attaching a trouble code based on the trouble detection result.

When trouble occurs, trouble code and control device 128
The control state is sent to the communication control means 120 via the transmission data creation means 124. Further, a result input means 127 for actually inputting the results of the trouble is provided, and the result input means 127 is used to input the results of the trouble to the communication control means 12 via the transmission data creation means 124.
Data to be updated to 0 is sent.

Further, the received data from the host computer is received by the received data analysis means 121 via the communication control means 120, and after being temporarily stored in the -time storage means 125, it is displayed on the display means 126.

Diagnosis and handling procedures for each trouble code are stored in an external storage means 26 provided on the host side. Trouble codes from the loom are received via communication control means 20 provided on the host side and transmitted to received data analysis means 21. When this trouble code is received, the corresponding data is read from the external storage means 26 and stored in the -time storage means 25. Then, the means 2 infers the cause of the trouble based on the read data and the control state of the loom.
3, and creates a treatment for the trouble as transmission data based on the estimation result, and transmits data creation means 2.
4 and returns to the loom side via the communication control means 20.

Also provided is a sorting means 22 for combining the actual results sent from the loom with the data stored in the external storage means 26 and sorting them according to the frequency of trouble occurrence.

In this way, trouble diagnosis and countermeasure data can be updated between the host side CPtJ and the loom side.

FIG. 7 is a flowchart illustrating the operation when a trouble occurs on the loom CPU side. When a trouble occurs (step 700), the loom side CPU sends the trouble code and the current status of each control device 128 to the host computer (step 701), and the host computer stores the cause and information corresponding to each trouble code from the external storage means 26. Checkpoints, etc. are read out, the cause is inferred based on the status of each control device 128, and a countermeasure for the trouble is sent back to the loom.

The CPU on the loom side temporarily stores the data sent from the host computer in the temporary storage means 125 (steps 702 and 703). Thereafter, the maintenance engineer presses an inquiry key on the inquiry means 132 of the loom to inquire about what to do. Then, the CPU on the loom side displays the first data on the screen (step 704). The maintenance engineer first checks the instructed part, and if there is no abnormality in that part, requests the next instruction by operating the next data key-in (step 705), and the loom side cPU then displays the next data. .

In this way, troubleshooting is carried out interactively for sequential maintenance (steps 706, 707, 70).
8).

Furthermore, even if all the data stored in the external storage means 26 is checked, the cause may not be found.

In that case, maintenance personnel will take countermeasures, such as contacting the manufacturer, as usual.

FIG. 8 is a flowchart on the loom CPU side showing a procedure for newly adding data for diagnosing and dealing with the trouble to the external storage means 26 when the cause of the trouble is found. In the case of adding data (step 800), specify a trouble code. In step 801), the identified cause and its countermeasures are converted into data, and the data is transmitted from the result input means 127 to the host side via the transmission data creation means 124 (step 801). Step 802.803).

FIG. 9 is a flowchart illustrating the operation of the host CPU when trouble is received. When there is an inquiry about a trouble from the loom side (step 900), the received trouble code is analyzed by the received data analysis means 21 (step 901), and data corresponding to the code is read from the external storage means 26 (step 902). , the control state is analyzed, the priority of the cause is estimated by the reasoning means 23 (step 903), a countermeasure is determined, and the data is transmitted to the loom (step 904).

FIG. 10 is a flowchart illustrating the operation of the host CPU when receiving additional data from the i-machine side. When additional data is received (step 1000), all data is read from the external storage means 26 (step 10).
01'), the data is added to additional data and rearranged (step 1002), and the data is stored in the external storage means 26 again.
(Step 1003).

Next, we will take up the case of failure to start the loom as a problem.
The third example will be explained in more detail.

FIG. 11 is a configuration block diagram showing a starting part on the loom side. The sequencer (SQC) 32 operates in response to the manual signal from RUN6031, and the electric delivery means (ELO)
Send a start signal to 33. After the kickback operation is completed, the EL033 issues an enable signal to the electromagnetic pulp control means (SVU) 34.

The sequencers 32, El, 033 and 5VU34 each communicate with the host CPU via the communication interface 35.
It is connected to the.

First, in the configuration shown in FIG. 11, when RUNi031 is pressed, 5QC32 prepares for startup and then outputs enable signal ELO33. After the kick bank operation is completed, the EL033 outputs the 5VU34 signal. The 5VU 34 returns an enable signal to the 5QC 32 after preparing for startup, but it is assumed that the 5QC 32 is performing timeout processing for this period.

Here, it is assumed that a startup failure occurs because the enable signal is not returned from the 5VU 34 within a certain period of time after the 5QC 32 receives the signal from the RUNI 031.

This activation failure is notified from 5QC32 to communication interface 34, and communication interface 35 sends a status launch signal to 5QC32, ELO33 and 5VU3.
4, the current status of each unit is temporarily stored, and sequentially output via the communication line.

It is assumed that the loom is in trouble and cannot be restarted due to the status launch signal. Further, the status indicates the internal state of each unit, and for simplicity, it is assumed that the following exists.

ELO...5TOP, kickback, RUNSVU・
...5TOP, RUN Actually, others, FORWARD, REVER3E,
In addition, each unit has its own status.

Now, in terms of maintenance, since it is known that the 5QC32 has detected a startup failure on the loom, the host computer is inquired about the cause and countermeasures.

FIG. 12 is a flowchart showing the processing on the host side when such a startup failure is inquired from the loom side.

First, in the case of a trouble code for startup failure (step 11)
00), the host CPU reads the ELO status (step 1110), and the status is 5T.
In the case of OP (step 1120), 5QC32 and EL
It instructs to check the cable between it and Oa3 (step 1121).

Furthermore, if the output of 5QC32 is defective, an SQC replacement instruction is issued (step 1122), and if the input of ELOa3 is defective (step 1123), an instruction is issued to replace ELOa3. The order of instructions in steps 1121 to 123 has been rearranged according to priority based on past experience.

Furthermore, if the status is a kickback (step 1130), instructions are given to take measures to prevent kickbanking (step 1130).
Step 1131). In this case, based on past experience, the defective location is registered.

Furthermore, if the status is not RUN (step 1
140), instructs to replace ELOa3 (step 14)
1).

Also, if the status of ELOa 3 is RUN, 5VU
34 status is read (step 1150), and if the status is 5TOP (step 1160)
, ELO-3VU enable cable check instruction (step 1161), ELO output failure/ELO replacement instruction (
Step 1162), SVU input failure/SVU replacement instruction (Step 1163) is given in the order of priority sorting based on past experience.

Further, if the status is RUN, a 5VU-3QC enable cable check instruction (step 1171),
SVU output failure/SVU replacement instruction (step 1172)
and SQC input failure/SQC replacement instruction (step 11)
73) are similarly instructed in the priority-sorted order.

If the status is not RUN, issue an SVU replacement instruction (step 1180), and) determine whether the trouble has been resolved (step 1190). If the trouble is not resolved, it is a new type of trouble, so a manual check is requested (step 1200), the cause is requested (step 1210), and a new diagnosis and handling procedure for the trouble is added and sorted as data ( step 1220).

Effects of the Invention As described above in detail based on the embodiments, in the present invention, trouble diagnosis of a loom can be performed on the spot by checking one item at a time according to the instructions on the display on the loom, which improves maintenance efficiency. There are advantages.

Furthermore, since the troubleshooting procedure is not fixed as a program, the user can periodically rearrange the data in order of frequency of occurrence or input new troubleshooting details to update the data.

Therefore, the results of solutions to actual troubles can be inputted one after another, allowing the factory to accumulate experience, so that it can quickly respond to future troubles when they occur.

[Brief explanation of the drawing]

FIG. 1 is a block diagram showing the configuration of the reading section of the first embodiment of the present invention, FIG. 2 is a block diagram showing the configuration of the writing section of the first embodiment, and FIG. 3 is the block diagram of the first embodiment. FIG. 4 is a flowchart for explaining memory card writing in the first embodiment, FIG. 5 is a block diagram showing the configuration of the second embodiment of the present invention, FIG. 6 is a block diagram showing the configuration of the third embodiment of the present invention, and FIGS.
9 and 10 are flowcharts illustrating the operation of the CPU on the loom side when a trouble occurs and when data is added according to the third embodiment of the present invention. FIGS. A flowchart for explaining the operation of the CPU, FIG. 11 is a block diagram showing the configuration of the starting section on the loom side according to the third embodiment of the present invention, and FIG. 12 is a flowchart for explaining the startup failure according to the third embodiment of the present invention. 3 is a flowchart illustrating operations on the host side when a trouble occurs. L... Memory card, 2... Card reading means, 3... Searching means, 4... Inquiry means, 5... Data storage means, 6... Display means, 7... Trouble code receiving means, 8... Trouble code transmitting means, 9: Trouble code generating means, 10: Trouble detecting means, 11: Control means, 12: Card writing/sequential output means, 13: Result input means, 14: -time storage means , 15... Sorting means, 20... Communication control means, 21... Received data analysis means, 22... Sorting means, 23... Reasoning means, 24...
Transmission data creation means, 25...-time storage means, 26...
External storage means, 120... Communication control means, 121... Received data analysis means, 125... Time storage means, 124.
- Transmission data creation means, 126... Display means, 127.
-Result input means, 128...control device, 129...trouble detection means, 130...trouble code generation means, 1
31... Control state storage means, 132... Inquiry means. Patent Applicant Tsudakoma Kogyo Co., Ltd. Representative Patent Attorney Kunio Nakagawa Figure 5 Figure 5

Claims (1)

[Claims] Responding to inquiries regarding loom troubles and diagnosing them.
The loom trouble diagnosis device that transmits the troubleshooting procedure to the loom side has a memory means that stores the diagnosis and countermeasure procedure for each trouble code as data, and a memory means that stores the diagnosis and countermeasure procedure for each trouble code as data, and a memory means that stores the diagnosis and countermeasure procedure corresponding to the specific trouble code based on the execution of the diagnosis and countermeasure procedure for the specific trouble code. A trouble diagnosis device for a loom, comprising memory writing means for updating data and re-storing it in the memory means.