LaserCutterUsageCounter

From RevSpace
Jump to navigation Jump to search
Project LaserCutterCounter
Status Stalled
Contact bertrik
Last Update 2016-02-14


Status

I haven't worked on this project for some time, I still think it's a good idea and there is some initial code. However I consider it low-priority for now.

Sebastius actually built something like this already, making this thing obsolete.

Context

This project is about a usage counter for the laser cutter at revspace.

Currently, the original purchase cost of the laser cutter is recouped by asking E2,50 per 15 minutes of usage. People have to keep track of time themselves, it is not very fine-grained and this cost-model does not take into account how intensive the laser cutter is actually used.


A laser cutter usage counter can improve this situation as follows:

  • keep track of usage time per cutting session, for example show the time since power-up on a display
  • count usage in smaller units of time (e.g. 1 minute instead of 15 minutes)
  • account for the actual usage per time unit, for example count usage in proportion to laser power (the assumption is that using lower power produces less wear on the laser tube, which means longer life).


Additional features could be:

  • directly calculate a price instead of just showing time
  • keep track of various other interesting usage counters (a bit like SMART does for disks), for example:
    • on-time (this session)
    • on-time (lifetime total)
    • minutes of laser on-time (this session)
    • minutes of laser on-time (lifetime total)
    • effective minutes of laser on-time (time x power) (this session)
    • effective minutes of laser on-time (time x power) (lifetime total)
    • number of times the laser cutter was powered up
  • publish the usage counters, e.g. on our mosquitto topic over the revspace wireless NRF network
  • a configuration interface to set parameters (e.g. price/minute)

Design

The laser cutter usage counter functionally consists of the following parts:

  • electrical front-end to measure whether the laser tube is on, and at what power it is operating
  • user interface
    • display to show the current session time (among other things)
    • button to reset the current session
  • an arduino that controls all of this, which also implements:
    • a clock to keep track of time (arduino internal clock)
    • non-volatile memory to store usage counters (arduino internal EEPROM)

Electrical front-end

The laser cutter has three wires we can interface with:

  • GND
  • 5V, this could possibly also be the power source for the usage counter
  • PWM, the laser tube intensity signal

A low-pass filter is needed to average the PWM-signal before measuring it. The LAOS-board in our laser cutter probably runs at a PWM frequency of 20 kHz (the default).

Proposed low-pass filter: 1 ms RC-time (this is 20 times the PWM period) Proposed sample rate: every 100 ms / 10 Hz

User interface

To display the usage counters, a Nokia 5110 display (84x48 pixels, or 6 lines of 14 characters) is used.

Example: use a nokia 5110 display and alternate between these screens:

   SESSION

PowerOn   999m
LaserOn   999m
LaserEff  999m

    TOTAL     
              
PowerOn  9999h
LaserOn  9999h
LaserEff 9999h
Reboots  65535

The button is a push button. Pressing it causes the session counters to be reset back to zero. The lifetime counters are never reset.

Arduino

An arduino nano or mini pro is likely sufficient.

The internal timer is used as a time base, probably accurate within 100 ppm.

The internal EEPROM is used for storage of the counters. By using a smart wear-leveling mechanism, the lifetime of the EEPROM can be stretched to several 100 thousands of operating hours, which should be sufficient (longer than the laser tube lifetime).

Wear-leveling algorithm

The wear-leveling algorithm works by storing the data to be persisted in a different location every time. For example, if we have 16 bytes to store, we can define 64 slots in the arduino 1kB EEPROM. Each slot contains a sequence number and a checksum.

When reading, we read all slots and select the slot which has the highest sequence number and a valid checksum. The checksum makes it likely that a half-written slot can be detected (e.g. when a power-down/crash occurred during writing). An invalid slot can be skipped this way, and we automatically fall back the slot before it. When writing, we simply write to the next slot than the one we read from, using a higher sequence number.

Assuming a write frequency of once per minute, it takes about 64 * 100,000 writes before the EEPROM reaches its official limit, this amounts to about 100,000 hours.

One counter slot could consist of:

  • 32 bits: minutes of on-time, how long the machine has been on
    • 22 bits for the lifetime total, this field also acts as the sequence counter because it always increases
    • 10 bits for the current session
  • 32 bits: minutes of laser-on time, how long the laser has been powered up, regardless of the laser power
    • 22 bits for the lifetime total
    • 10 bits for the current session
  • 32 bits: effective minutes of laser-on time, time x laser power percentage
    • 22 bits for the lifetime total
    • 10 bits for the current session
  • 16 bits: total number of times the laser cutter was powered up
  • 16 bits: checksum

Total bytes per slot: 128 bits, or 16 bytes.

A 16-byte slot is nice, because we can fit 60 of those in the EEPROM (1 hour worth of logging) and still have 64 bytes left (e.g. to store settings).

Counter times are counted in minutes. Life-time counters are 22 bits, so they can fit a maximum of about 70k hours. Session counters are 10 bits, so they can fit a maximum of about 17 hours. The power-up counter is 16 bits, so it can log a maximum of 65k times power-up.

If using a 16-bit CRC for the checksum, the best choice to protect our 112 bytes of data is the one with polynomial 0x9eb2, according to this great page on CRCs. It can reliably detect up to 6 flipped bits.

Implementation

Block diagram:

LaserCutterUsageCounter.svg

Solid blocks: software Dashed blocks: hardware

Software development is on github.