Board safety

From RepRap
Revision as of 09:05, 31 July 2016 by PRZ (talk | contribs) (Implementation)
Jump to: navigation, search

Board/Firmware Safety of a FFF printer

An important part of 3D printer safety is handled by its control board and firmware combination.

The purpose of this page is to evaluate the implementation of safeties. Other safeties shall be considered for 3D printers, but they are outside the scope of this page.

Codes used

The following table could be based on the analysis of the software or on tests
Results :

  • 'X' if analysis confirm compliance, 'N' if not, 'NP' if partial (e.g. not all loops)
  • 'WX' if there is a preliminary warning before trigger
  • 'I' indicates that the safety could be implemented but depends from hardware choices, e.g. killing the power supply depends from installation of a relay
  • 'T' if safety physically tested ok, 'F' if physical failed completely 'FP' if failed partially. An absence of warning shall be considered as a partial failure and noted in comments.

Tests and analysis shall be carried on all loops, a partial failure or non compliance shall be explained in notes
If analysis is not possible (closed source software) and test impossible to do, e.g. a watchdog in the processor, test shall be considered failed

  • '-' indicates that it is not applicable
  • a value could follow the result tag (e.g. delay to stop X2000 or T1850)
  • a note reference could follow the result tag (e.g. NP (12))
  • '?' for unknown answer

One table is for a combination of hardware and firmware, so there could be multiple tables for one board/one firmware.

Tests

A test platform shall be built, with switches and temperature controllers. Some tests can be done by simply shorting / opening the heating circuits, but it may be preferable to use an external control loop, say you will heat with another controller to simulate a discrepancy between real heat rate and expected heat rate. All heaters shall be tested.

If there are different control modes (e.g. PID and bang-bang mode for bed heaters), the test shall be carried out for each mode, for each heater this mode can be applied to. If a heater can be parametered for different purposes (say extruder or chamber heater), the test shall be done for each purpose configuration. By convention bed heater will be named H0, Extruder heaters H1...H5, Chamber heater 'HC' if specific.

When other heaters tested as a chamber heater, a 'C' shall be added, say a test on Extruder 2 configured as chamber heater will be noted 'H2C'. One test for chamber configuration may be ok.

So a typical test will be :

  • H0 Bang/Bang, H0 PID, H1...H5 PID, H2C PID, H2C bang-bang.

PID control in all cases may improve safety as it allow better check of heat rate.

Phases

Four phases could be defined for safety handling, as in some phases, incident detection by analysis may not be possible. By example, if you are in ramp-up phase, you may not detect a shorted circuit as it is normal that the power is at its maximum, while max power when stabilised is abnormal. However, you can link the power to the temperature increase/decrease rate which allow detecting other problems.

The phases for heaters are:

A. Printer is idle and heater is supposed to be cold.

B. Heater is supposed to be heating up.

C. Heater is close to target temperature and is supposed to maintain that temperature.

D. Heater is supposed to be cooling down.

Note that safety loops shall be permanently active in all phases. By example a MosFet failure can rise temperature while everything is supposed to be stopped.

Warning

All detected problems or triggers shall rise a warning. Where possible, warning shall be both on the supervising unit and local (typically with a local alarm: buzzer or else).

Where possible (like wrong temperature change rate or unstable temperature), a warning shall systematically be raised for a first level deviation, before triggering either for a higher deviation or after a timeout. As an example, a warning shall be raised 5 to 10°C before the high temperature trigger. This is noted as 'PW' in the table.

A beeper shall handle different sound sequence to distinguish an emergency from a a warning or a preliminary warning (e.g. an intermittent beep for abnormal temperature at start-up and a continuous one for heating fault).

Actions

The different levels of actions are :

  1. Prevent print start
  2. Stop print
  3. Shutdown heat command (if problem is related to heating)
  4. Shutdown whole power (if the heat shutdown have no effect). An output shall always be available to relay the power.

Shutting down heating shall maintain the safety loop, to control this does have an effect.

All power shutdown cause shall record the cause (on a SD card or onboard memory, preferably both)

  • Shutdown heater mean the FET is in non conductive state or SSR/relay signal is down.
  • Kill power means that all heater FET / SSR are no longer electrically supplied (in case of heater FET failure conductive). If workable, it may be better to maintain processor power (5V/3.3V) to maintain alarm and fault signalling to interface. The Buzzer shall be connected on this low power.

Implementation

Board/firmware safety
Firmware/ Revision , Board / revision myfirm - 0.0 - Board - 0.9 -
Phases
A B C D - - Comments - -
1 Thermistor shorted/disconnected
2 Temperature rise too slow, note PW
3 Temperature rise too fast, note PW
4 Too high temperature, note PW
5 Too low temperature, note PW
6 Unstable temperature, note PW
7 Filter thermal sensor noise
8 Reset/boot stop all heating
9 Capability to stop all power (relay command or ATX power supply deactivation)
10 Fault recording on permanent memory
11 Watchdog in the processor (interruption while software is freezing)
12 Watchdog external (tick on a processor pin)
13 Stop button connected on board – precise action
14 Fuse/safety on board on 3.3V (if applicable), note type/current
15 Fuse/safety on board on 5V, note type/current
16 Fuse/safety on board for heating power voltage (12/24V), note type/current
17 Beep output or beeper on board - note type
17 Heater shorted - last test as can be destructive if fuse not working

Watchdog [1] (firmware freeze detection)

Watchdog are delicate to implement [1] in multitasking processus [2] and they could work in one case and not in another case.

To check if they are working in all cases need deep understanding of the firmware and guaranty their proper operation is not easy.
It is advisable that the reviewer justify his position on this particular subject.
In addition, if the watchdog is not physically implemented (say it is an interrupt in the processor and not a pin activation), its action cannot be easily tested.

See also

References

External links


In addition to site licence GFDL1.2, this page is also released under license CC BY-SA 4.0