Back to all posts
Newsroom
/
Company News

Table of Contents
Heading 2

Three Ways Test Engineers Are Putting RevelTest to Work

Share the post

The hardware’s ready. The campaign’s on the calendar. Then, two weeks out, the requirement changes: a new transducer on the manifold, a new abort limit, one more supply in the loop.

On most test stands, that change is not a quick config edit. It's a request to whoever owns the software, one engineer with a script only they're familiar with, or a specialist with a backlog of support requests. Until it lands, the stand runs the test it was built for and nothing else.

RevelTest is a control platform built to close that gap. Every example below runs on RevelCode, our domain specific language for automating hardware tests. Its syntax is built around the concepts test engineers already think in, sequences, loops, and channels, instead of generic programming primitives. So you don't need a software engineering degree to write it. And because it compiles before it runs, mistakes get caught before they ever reach a test stand. 

Across industries, from rocket engine stands to electric motor dynos to circuit board qualification, we see three use cases come up again and again.

1. Unifying control for electronic and component verification

Testing a circuit board or a battery management system means commanding a heater, a chiller, and the board itself in coordination. Stitching that together with separate vendor tools tends to break the moment firmware changes on the board or a new revision swaps in a different sensor.

RevelTest connects to all of it from one console, so you write one sequence instead of juggling several tools and hoping they stay in sync. Coordinating them means writing an alert that watches the board's temperature and a machine that knows how to abort safely if it fires:

1const MAX_BOARD_TEMP:float = 85.0
2 
2hwout |heater_cmd|:bool = False
3hwout |chiller_cmd|:bool = False
4hwin |board_temp|:float
5 
6alert board_overtemp:
7 severity = Severity.critical
8 arm = True
9 trigger = |board_temp| > MAX_BOARD_TEMP
10 
11machine bms_verify:
12 state ramp:
13 loop:
14 if |alert.board_overtemp.fired|:
15 transition abort
16 sequence:
17 |heater_cmd| = True
18 wait until |board_temp| > 60.0
19 transition ramp
20 
21 state abort:
26 sequence:
27 |heater_cmd| = False
28 |chiller_cmd| = True
29 wait until |board_temp| < 30.0
30 transition ramp

If the board overheats mid-run, the abort state takes over and cools it down on its own, so nobody has to be watching a screen to catch it. Change the firmware, and you rerun the suite the same day. No handoff or waiting on whoever wrote the original script.

2. Automating environmental and soak testing 

A device goes into a thermal chamber, ramps to a target temperature, holds there anywhere from days to months, then runs a functional check before moving to the next range. Done manually, that means someone watching a screen for the length of the test. Step away for lunch, and you can ruin a multi-hour hold before you're back.

RevelTest automates the sequence, so the chamber runs the full ramp, soak, and check cycle unattended. Nobody has to watch a screen for hours. Because it’s just RevelCode, you can keep a different soak routine per device type, temperature ranges and hold times included, and bring a new part online without writing new integration code for it.

A ramp-limited PID holds the setpoint, so the chamber runs the hold unattended.Set soak.target to the next range and the chamber ramps there on its own.

You don't have to be standing at the chamber to catch a failed check or a dead heater. Set the routine running and walk away. You can check in on live telemetry remotely from any browser on the network, whenever you want. Or let the alert flag it the moment something goes wrong, well before the end of a 20-hour run

3. Running certification tests and R&D tests on the same stand

A certification test needs to run exactly the same way every time. Dev testing changes by the day, chasing a new part or a new failure mode. Most teams have one test stand, maybe two. If the automation logic lives behind a software team's build pipeline, switching between them means routing a change through whoever owns that codebase and waiting on a new deployment.

Pull up this morning's certification sequence, tweak it for this afternoon's dev run, and switch back tomorrow, without filing a ticket or waiting on a deploy window. The test stand runs as a machine driven by a target-state channel: flip the channel, and the state logic routes into whichever sequence you asked for.

1sw |test_stand.target_profile|: test_profiles = test_profiles.idle
2hwout |igniter|:bool = False
3sw |profile_complete|:bool = False
4 
5machine test_stand:
6 state idle:
7 loop:
8 if |test_stand.target_profile| == test_profiles.atp:
9 transition next atp_run
10 if |test_stand.target_profile| == test_profiles.dev:
11 transition next dev_run
12 
13 state atp_run:
14 sequence:
15 |igniter| = True
16 wait until |profile_complete|
17 transition idle
18 
19 state dev_run:
20 sequence:
21 |igniter| = True
22 wait 12.0
23 transition idle

Flip test_stand.target_profile to dev, and the stand runs the shorter sequence instead of the ATP one, both defined side by side in the same file. That flexibility is what lets Impulse Space have a 10x faster stand setup, with sequence changes made by the test engineers themselves instead of routed through a software team.

Next steps

Request a demo, or read how Astro Mechanica went from a homegrown control platform to fully operational on Revel in one day.