Hardware control daemon for rpi2caster
Project description
rpi2casterd
Hardware driver and web API for rpi2caster
This is a machine control daemon for the rpi2caster typesetting and casting software. It is supposed to run on a Raspberry Pi (any model) with an output expander based on two MCP23017 chips to provide 32 additional outputs. These are connected to solenoid valves, which in turn send the pneumatic signals to a Monotype composition caster or tape punch.
The program uses Flask to provide a rudimentary JSON API for caster control.
gpiozero library is used for GPIO control, with RPi.GPIO as a preferable backend.
There are several available MCP23017 control backends:
SMBus (via smbus-cffi or smbus2 package),
WiringPi library.
The daemon also controls several GPIO pins:
ready LED (green) - when lit, the control device and software is ready to use.
working LED (green) and error LED (red), typically a dual-color common cathode LED, indicates the machine state - green when the machine is working, red when the machine is stopping the pump, and orange when the machine is starting.
motor start and motor stop - pulse outputs for start/stop relays, connected with the original AllenWest motor starter (their use is optional, more of a convenience).
air and water - for controlling air solenoid valve (prevents unnecessary air use when the machine is not working) and cooling water valve/pump (ditto with water). Like motor control, this is more of a ‘deluxe’ feature and is not necessary for caster operation.
sensor (photocell, e.g. TCST2103) input for getting the information about the machine cycle phase. When the sensor is going ON, the air is fed into the machine; when the sensor is going OFF, the air is cut off and the control daemon ends the signals sending sequence. This sensor is necessary for caster operation. Punching is timer-driven and no sensor is needed.
mode sense input - when grounded, the interface works in the casting mode; when lifted (pulled up to 3V3), the interface works in the punching mode. This input is typically connected with a 9-pin D-sub connector for the sensor, with a jumper to the ground in the plug.
shutdown and reboot buttons - after one of these is held for 2 seconds, the LED flashes and the shutdown or reboot procedure begins.
emergency stop button - stops the machine as soon as possible and marks the emergency stop as activated; when that happens, the client software has to clear the emergency stop first in order to be able to use the machine.
The program uses Flask to provide a rudimentary JSON API for caster control.
Starting
The interface needs to be started up in order to work. The startup procedure ensures that:
the interface is not busy, not stopping and not starting - has not been claimed by any other client,
air and (for casting only) water and motor is turned on, if the hardware supports this,
(for casting) the machine is actually turning; during this phase, the state LED lights up orange,
after the starting sequence is successfully finished, the state LED lights up green,
the interface will stay busy until released by the stop method.
Machine is started with a request from the client software. See the API section for details.
Stopping
Stopping the interface ensures that:
if the pump is working, it is stopped (see the pump control section); during this phase the state LED lights up red,
air and (for casting) water and motor is turned off, if hardware supports this,
the state LED is turned off, if hardware supports this,
the testing_mode flag is set to False,
the interface is released for the future clients to claim.
Machine is stopped when called by the client software, when the machine has been stalling (waiting for the signal from the cycle sensor for too long), or when emergency stop happens because of button press or client software request.
Pump control
The software turns the pump on (sending NKS 0075 + current 0075 justifying wedge position) or off. Pump switch-off is done whenever the machine stops and the pump is marked as working. This ensures that after re-start, the pump will stay stopped.
During the pump switch-off procedure, an “alarm” LED (red) is lit to prompt the operator to turh the machine’s main shaft a few times. The interface will then send a NJS 0005 + current 0005 justifying wedge position. This way, stopping the pump does not change the wedge position.
Motor control
When starting in the casting mode, the software activates the motor_start GPIO for a fraction of a second. The GPIO can be coupled with a NO SPST relay connected with the original AllenWest electromagnetic starter. Use a relay rated for at least 400V AC if your caster is wired for three-phase power (common in continental Europe). The relay should be connected to the contacts marked “1” and “2” on the motor starter.
Similarly, when stopping in the casting mode, the software activates the motor_stop GPIO. This can be coupled with a NC SPST relay that breaks the current flow through the starter’s coil. The relay should be connected instead of a jumper between one of the live wires and the contact marked as “2”.
Air and water control
The daemon can also control a solenoid valve to enable or disable air flow when the machine is working or stopped. Air control works in all operation modes (casting, punching and testing).
Water control can be used in the casting mode for controlling a pump or solenoid valve for cooling water flow.
Sending signals
Based on the caster’s current operation mode, signals are modified or not:
testing mode ensures that signals 1…14, A…N, 0075, S, 0005, O15 are sent to the machine as they are received
punching mode ensures that a combined signal O+15 is present only when less than 2 signals are received
casting mode ensures that the O15 signal is ommitted
Sending the signals can take place only when the interface has been previously started and claimed as busy; otherwise, InterfaceNotStarted is raised in the casting mode, and the startup is done automatically in the punching and testing modes.
The daemon behaves differently depending on the operation mode:
casting
wait for a machine cycle sensor to turn ON,
activate the valves for specified signals,
wait until the cycle sensor goes OFF,
turn all the valves off,
check the pump state and justifying wedge positions, and update the current state,
return a reply to the request, allowing the client to cast the next combination.
However, a machine sometimes stops during casting (e.g. when the operator sees a lead squirt and has to stop immediately to prevent damage). In case of emergency stop, the machine is stopped immediately and the client software gets an error reply to the send request.
punching
This mode is fully automatic and driven by a configureble timer:
turn the valves on,
wait time_on for punches to go up,
turn the valves off,
wait time_off for punches to come back down,
check the pump state and justifying wedge positions, and update the current state,
return a success reply to the request.
testing
The software just turns off the valves, then turns them on, sending the specified signal combination.
REST API documentation
The API is typically accessed at http://[address]:[port] (typically 23017, as in MCP23017). Several endpoints are available:
/ - status: GET: reads and POST changes the status, which is used mostly for setting the temporary testing_mode flag.
/config - configuration: GET reads and POST changes the configuration
/machine - machine start/stop/state:
GET reads the state, PUT turns the machine on, DELETE turns the machine off, and POST turns it on or off depending on the JSON data in the request ({state: true} for starting, {state: false} for stopping). The reply can either be {success: true, active: [true/false]} if successful, or {success: false, error_code: [EC], error_name: [EN]} if exception was raised. Error codes and names:
0: The machine was abnormally stopped. in case of emergency stop or machine stalling,
3: This interface was started and is already in use. If this is not the case, restart the interface. if the interface has already been claimed as busy,
/motor, /air, /water, /pump, valves - motor, air, water, pump and solenoid valves checking/control. The verbs work as above.
/emergency_stop:
GET gets the current state, PUT (or POST with {state: true} JSON data) activates the emergency stop, DELETE (or POST with {state: false} JSON data) clears the emergency stop state, allowing the machine to start. When emergency stop is activated, the server replies with {success: false, error_code: 0, message: 'The machine was abnormally stopped.'}
/signals:
GET: gets the last signals sent (unless the machine was stopped, which clears the signals), POST or PUT with {signals: [sig1, sig2...], timeout: x} (timeout is optional and overrides the default machine stalling timeout) sends the specified signals, and DELETE turns off the valves. Emergency stop events are tracked and whenever the emergency stop was triggered, the server will reply with an error message.
Possible error replies:
0: The machine was abnormally stopped. in case of emergency stop or machine stalling,
4: Trying to cast or punch with an interface that is not started. (only in casting mode, as punching/testing starts the interface automatically)
Release history Release notifications | RSS feed
Download files
Download the file for your platform. If you're not sure which to choose, learn more about installing packages.
