??? 08/08/04 02:30 Read: times |
#75630 - Reliability of BIT flags |
While coding for machine applications, it is common practice to use BIT segments as flags and then use them in program flow branching.
Nothing new with such flags but a recent episode on a gearbox test bed has kind of rattled my confidence on depending "too much" on a single bit for crucial decisions. The application is an aircraft gear box test rig where a hydromotor is used to rev up the gear box from 0 to 7500 rpm in under 12 seconds and hold there for 40 more seconds. The whole operation controlled by my MCU unit lasts under 60 seconds. Thousands of such cycles are done for endurance. The cycle to start, needs a multitude of signals and safety interlocks to be in order, before my MCU unit will acknowledge the START command from the user. All the external safety interlocks are synthesised by the control PLC and given to my MCU unit as a single digital input. Relevant code snippet is below: SCANWAIT: JNB FLG_SCAN, $ ; Wait for 50ms tick from ISR. ... ... WAITLUP: CLR FLG_SYSOK CALL MSG_NOTOK ; VFD message =SYSTEM NOT READY= JNB DIN_SYSOK, EXITSCAN ; DIN_SYSOK will be set by input from PLC. SETB FLG_SYSOK ; System OK to start. ... ... WAIT4START: JNB FLG_SYSOK, EXITSCAN CALL MSG_STRPB ; VFD message =AWAITING START SIG.= JNB FLG_START, EXITSCAN ; Await user start command. STARTSEQ: (code for start cycle ) ... ... EXITSCAN: CLR FLG_SCAN JMP SCANWAIT ; Go await next 50ms ticker from ISR. Despite the above cross checks, it so happened that one start happened even when there was no SYS_OK input from the PLC ( the lube system was down )when the operator pressed the START key by mistake. Fortunatley the other safety features like LUBE_PRESS cut in and aborted the start in about 5 seconds. The issue now is: Even with the lube system down, did the PLC generate a SYS_OK input to MCU unit ? [OR] Did the FLG_SYSOK get Set due to a power line glitch or some such thing ? As part of post analysis, a thorough check on both PLC and my MCU unit have not revealed any abnormalities. Question hence is : How reliable is this dependancy on a single BIT flag for crucial decisions ? Are there any extra precautions that one can take to be more sure ? Thanks Raghu |
Topic | Author | Date |
Reliability of BIT flags | 01/01/70 00:00 | |
RE: Reliability of BIT flags | 01/01/70 00:00 | |
RE: Reliability of BIT flags | 01/01/70 00:00 | |
Triple redundancy? | 01/01/70 00:00 | |
Triple redundancy_Of Course! | 01/01/70 00:00 | |
RE: Triple redundancy? | 01/01/70 00:00 | |
RE: Triple redundancy? | 01/01/70 00:00 | |
RE: Triple redundancy? | 01/01/70 00:00 | |
Single point failure | 01/01/70 00:00 | |
RE: Reliability of BIT flags | 01/01/70 00:00 | |
RE: Reliability of BIT flags | 01/01/70 00:00 | |
RE: Reliability of BIT flags | 01/01/70 00:00 | |
RE: Reliability of BIT flags | 01/01/70 00:00 | |
RE: Reliability of BIT flags | 01/01/70 00:00 | |
RE: Reliability of BIT flags | 01/01/70 00:00 | |
RE: Reliability of BIT flags | 01/01/70 00:00 | |
RE: Reliability of BIT flags | 01/01/70 00:00 | |
RE: Reliability of BIT flags | 01/01/70 00:00 | |
RE: Reliability of BIT flags | 01/01/70 00:00 | |
Correctness of any signal from outside | 01/01/70 00:00 | |
A sane portion of paranoia![]() | 01/01/70 00:00 | |
Thanks - The thread can close | 01/01/70 00:00 |