Designed & Made in the USA Since 1983
The MobileCollect EVO API turns your software into the only interface your operators need. Set up transmitters, configure what data comes back, read gage identity and calibration status, and trigger measurements on demand, all from your own application. No separate setup utility, and no gap between what your software expects and what the shop floor is actually running. Enabling GageSync and TriggerSync takes one brief step at the transmitter, done once per gage. Everything after that is under software control.
The API started as a way to eliminate the MobileCollect Xpress and MobileCollect Extended setup step. With the addition of GageSync and TriggerSync on Base firmware 6.30, it now does considerably more: it communicates in both directions with the gage itself.
Any software can now pair MobileCollect transmitters to EVO Bases, assign channels, and set output formats programmatically. You retain full control of the user experience and of how MobileCollect systems get deployed. Your operators never see a configuration dialog they did not design.
Send far more than a measurement. Unique Module ID, base ID, module label, units, channel, battery voltage, signal strength, send attempts, event number, and gap time between readings are all available, configurable per channel or globally, with no user input required. Every device sends exactly the fields your software is parsing.
GageSync opens a bi-directional channel to the gage. Your software can query the gage rather than just receive from it: serial number, model number, gage code, last calibration date, next calibration date. You can also send commands to it, including a remote zero. When you have hundreds of gages on the floor, the difference between reading gage identity from software and reading it off a sticker is the difference between a traceable process and a paperwork exercise.
TriggerSync lets your software ask for the reading instead of waiting for an operator button press. Request a reading on demand and it arrives at the next transmitter check-in. TIR Mode runs a continuous read cycle for Total Indicator Runout and returns the reading count, minimum, maximum, and range as a single result, so runout work does not require the operator to watch a dial and write down two numbers.
For GageSync enabled gages, attach the gage serial number, model number, and calibration dates to the measurement stream itself, either once on request or with every single reading. Calibration status stops being a periodic audit activity and becomes an attribute of the data. Your software can refuse a reading from an out-of-calibration gage at the moment of collection rather than discovering the problem during a records review.
GageSync and TriggerSync Smart Battery Management lets the transmitter manage its own power. Rather than holding one fixed check-in interval, the Mini Mobile Module EVO modulates its check-in rate against gage activity: faster while the gage is in use, so command latency stays low while the operator is working, and slower as the gage goes idle, so current draw drops when nothing is happening. A transmitter spends its energy where responsiveness actually matters instead of paying a fixed polling cost around the clock. Three schemes are available, targeting 9 months, 1.5 years, and 2+ years of battery life.
When your software needs deterministic latency instead, take direct control and set a fixed check-in interval anywhere from 500 milliseconds to 60 seconds. Either way the decision belongs to your application, not to a fixed factory setting.
When your software detects an inconsistency in incoming data, it can reconfigure the MobileCollect system on the fly. Query the current state of any channel, compare it to what you expect, and correct it. All of it behind the scenes, with no user input and no service call.
Advanced setup will still need to take place in MobileCollect Xpress or MobileCollect Extended Setup software. There are currently two setup configuration files that the MobileCollect Base utilizes; Xpress Setup and Extended Setup. The base only utilizes one configuration file at a time, either Xpress or Extended. This API is based off the Xpress Setup configuration file and thus parameters set with the API will be visible in Xpress Setup.** For advanced configuration, have users go to Xpress Setup unless they are configuring a Remote Transmitter, Command Mobile Module, read switch, or need additional Channels. If they have these advanced setup needs, they will need to use Extended Setup and parameters set with the API will not display.
We have downloadable executables and user manuals on our website for both Xpress and Extended Setup.
** The API offers additional flexibility over Xpress Setup and some parameters may not show exactly as they we’re setup via the API. This may lead users to change settings in Xpress and those settings will have to be reconfigured via the API
Requires Base firmware 6.30 and Mini Mobile Module EVO firmware 6.12.
GageSync and TriggerSync extend the API past configuration into live communication with the gage.
GageSync provides two-way communication with Mitutoyo S1 compatible gages. Your software can read gage identity and calibration data directly from the gage, and send commands to it.
TriggerSync provides host-initiated measurement and transmitter control without requiring an S1 compatible gage. Your software requests the reading rather than waiting for an operator button press.
The base determines which is available on a given channel. Sending <$A:GSnMD5 runs a GageSync capability test on the paired transmitter. If the test passes, GageSync commands are enabled. If it fails, only TriggerSync commands are available. <$A:ICLA reports the result per channel as GS, TS, or --.
Bi-directional communication has to be turned on once per transmitter before any GageSync or TriggerSync command will work. This is the only step that requires someone to touch the hardware.
<$A:GSnMD1. The transmitter confirms with double green, double red, double green, double red.The transmitter stays in Setup Mode until it times out or the operator presses the orange Read button. After that, the setting persists and every subsequent GageSync and TriggerSync command is sent from your software with no operator involvement.
Your software can confirm the state at any time with <$A:GSnMD4, or read all channels at once with <$A:ICLA. Design the enablement step into your own onboarding flow so the operator sees your instructions rather than a MicroRidge utility.
GageSync and TriggerSync commands are stored on the base and forwarded to the transmitter at its next check-in. Out of the box the transmitter runs Smart Battery Management scheme B, so the check-in interval is modulated against gage activity rather than fixed. Check-in behavior is adjustable per channel with <$A:GSnSTx, including a fixed interval if your application needs one.
Commands can be stacked. Multiple commands sent to the same channel are all handled at the next check-in.
Individual-channel pairing is required. These commands do not work on transmitters paired to the global channel.
Every GageSync and TriggerSync command takes n as the channel letter.
n | Channel Number | n | Channel Number | n | Channel Number |
|---|---|---|---|---|---|
A | 1 | F | 6 | K | 11 |
B | 2 | G | 7 | L | 12 |
C | 3 | H | 8 | M | 13 |
D | 4 | I | 9 | N | 14 |
E | 5 | J | 10 | O | 15 |
Because commands are queued for the next transmitter check-in, you get two responses.
Stage 1, immediately on send: the base confirms the command was accepted and queued.
\x0d MBLAPI_SUCCESS \x0d <command you sent> \x0dStage 2, after the transmitter executes: the transmitter reports the outcome, followed by the steady state of the parameter.
Response | Meaning |
|---|---|
MBLAPI_GS_TS_SUCCESS | Transmitter executed the command |
MBLAPI_GS_TS_FAILED | Transmitter failed to execute the command |
Any requested gage metadata (serial number, calibration date, and so on) is returned between the two stages.
The steady state returned in stage 2 may differ from what you sent, and that is expected. <$A:GSASN2 requests the serial number once on the next check-in without enabling it for every reading, so the steady state reported back is <$A:GSASN0.
Steady State | Meaning |
|---|---|
0 | The field will not be sent with every measurement |
1 | The field will be sent with every measurement |
Because x = 2 and x = 3 are one-shot requests, the steady state echoed back is not necessarily the value you sent. Parse the echo rather than assuming your own value came back.
Requesting the serial number once on channel A, without enabling it for every reading:
<$A:GSASN2 host sendsMBLAPI_SUCCESS stage 1, queued<$A:GSASN2<serial number> data returnedMBLAPI_GS_TS_SUCCESS stage 2, executed
<$A:GSASN0 steady state is 0, not the 2 you sentFor commands that have no steady state, the echo is the command exactly as sent. Turning on the transmitter LED on channel A:
<$A:GSALED host sends
MBLAPI_SUCCESS stage 1, queued
<$A:GSALED
MBLAPI_GS_TS_SUCCESS stage 2, executed
<$A:GSALEDEither way, stage 2 always returns an echo line, so your parser can key on the MBLAPI_GS_TS_SUCCESS or MBLAPI_GS_TS_FAILED token and read the following line as the command’s resulting state.
Response | Meaning |
|---|---|
MBLAPI_NO_MODULE_CHAN_n | No Mini Mobile Module EVO paired to channel n |
MBLAPI_INVALID_CHANNEL | Channel value n is not valid |
MBLAPI_GS_TS_NOT_ACTIVE_CHAN_n | GageSync and TriggerSync are not activated on channel n |
MBLAPI_GS_CMD_GS_CHECK_CHAN_n | A GageSync command was sent to a transmitter in TriggerSync mode. The transmitter will verify whether GageSync is available. |
We’re always looking to improve our MobileCollect EVO API. Send us a message if you have an idea for additional features.