Designed & Made in the USA Since 1983
A channel number tells you which transmitter sent the reading. GageSync tells you which gage took it, and whether that gage was in calibration.
This post is also available in:
MicroRidge Systems is excited to announce the launch of GageSync and TriggerSync, two new capability sets for the MobileCollect EVO API that let SPC and quality software communicate in both directions with the MobileCollect Transmitter and gage. Both are available now on MobileCollect EVO Base firmware 6.30 and Mini Mobile Module EVO firmware 6.12. Update your firmware here.Â
Until now, the MobileCollect EVO API let third party software configure a wireless system: pair transmitters, assign channels, set output formats. Data still flowed one way, from the gage to the host. GageSync and TriggerSync change the direction of the conversation.
GageSync gives software direct access to the instrument itself on Mitutoyo S1 compatible gages. An application can read the gage serial number, last and next calibration dates, model number, and gage code, and can send commands back to the gage, including a remote zero.
TriggerSync lets the host request a reading rather than waiting for an operator to press a button, and works without an S1 gage. It also adds remote TIR Mode, a continuous read cycle for Total Indicator Runout that returns the reading count, minimum, maximum, and range as a single result, plus commands to identify a transmitter by its LEDs.
Two questions decide whether a measurement can be trusted, and until now the data stream answered neither of them.
Which gage produced this reading? In a conventional wireless deployment, the answer is inferred. The record carries a channel number, and the channel identifies a transmitter, not a gage. Everything after that is an assumption about which gage was connected to that transmitter at that moment, and it is an assumption that survives right up until a gage is swapped between fixtures, a cable is moved during a shift change, or a spare goes into service without anyone updating a spreadsheet.
The gage serial number is the only positive answer. GageSync reads it from the instrument and lets software attach it to the measurement, once on request or with every single reading. That converts gage identity from something reconstructed later into a field on the record.
Was that gage in calibration at the time? GageSync reads the last and next calibration dates from the gage alongside the serial number. Software can compare the next calibration date against the system clock and refuse a reading from an out-of-calibration gage before it ever reaches the database, rather than discovering the problem during a records review three months later.
The two work together. A calibration date is only meaningful if you know which gage it belongs to, and a serial number only tells you the gage was the right one, not that it was fit to use. Read together and attached to the reading, they turn a traceability record from something a quality engineer reconstructs during an audit into something that arrives already assembled. For anyone running a calibration recall system under ISO 9001, IATF 16949, or AS9100, that is the practical difference.
Model number and gage code come back the same way. Both are most useful on the procurement side, when a gage has to be matched and reordered.
Reading data from the gage is one half. Sending commands to it opens a different set of problems.
Consider a multi-gage fixture placed on a part. Before any measurement is taken, software can query the serial number of every gage in the fixture and confirm that the correct gages are actually in it. It can then zero each gage and read each one back to verify that the zero took. It can collect a series of readings from each position to confirm the fixture is stable before recording the value that counts.
Every one of those steps was previously a manual procedure, an assumption, or both. Now, none of them require an operator to touch anything.
TriggerSync means the host decides when a reading happens. That matters most where pressing a button is inconvenient, unreliable, or unwise.
A gage mounted in a wash-down cell, inside a machine enclosure, or anywhere an operator should not have a hand during the measurement can now be read on command from software. TIR Mode extends the same idea to a full runout check: software starts the cycle, the part turns, and the count, minimum, maximum, and range come back as one result, with no one standing at the indicator watching the needle and no button press between the operator and the measurement.
GageSync and TriggerSync via the MobileCollect EVO API are built for the companies who write SPC and quality software. The commands are the interface, and the experience around them belongs to the application, not to a MicroRidge utility the operator has to be walked through.
Every capability is exposed through the MobileCollect EVO API as a documented serial command over a virtual COM port. There is no separate utility to install and no configuration dialog your users have to be walked through. Commands are stored on the Base and delivered to the transmitter at its next check-in, with a two stage response: a confirmation that the command was queued, and a second response when the transmitter has executed it. A single one-time enablement step at the transmitter turns bi-directional communication on, and everything after that is under software control.
Smart Battery Management ships alongside them. Rather than holding one fixed check-in interval, the transmitter modulates its own check-in rate against gage activity, faster while a gage is in use so command latency stays low, slower as it goes idle so current draw drops. Three schemes target 9 months, 1.5 years, and 2+ years of battery life, and software that needs deterministic latency can set a fixed interval anywhere from 500 milliseconds to 60 seconds.
This is a foundation more than a finished feature set. Two-way communication with the gage was the hard part, and now that it exists, the capabilities that build on it get considerably easier to add. Nor is it confined to one module: the command structure was designed for the MobileCollect platform rather than for a single transmitter, and more of the lineup will speak it over time. An integration written against the API gets broader as that happens, without being rewritten.
We intend to keep extending the command set, and we would rather do it against real integration work than in isolation. If your application needs something from the gage that is not in this release, tell us.
GageSync and TriggerSync are available now and require MobileCollect EVO Base firmware 6.30 and Mini Mobile Module EVO firmware 6.12. Both are free downloads for existing MobileCollect EVO hardware. There is no new hardware to buy and no license fee for the API.
Full command documentation, parameter tables, and response formats are on the MobileCollect EVO API page, along with the downloadable Implementation Guide.
SPC and quality software developers: the API page has everything needed to scope an integration. If you want to talk through a specific use case, MicroRidge provides direct engineering support and demo hardware at no cost.
Quality managers and end users: GageSync and TriggerSync are capabilities your SPC software has to implement. If gage identity and calibration status arriving with every reading would change how your traceability or calibration recall process works, ask your SPC provider about integrating them, and point them at the API documentation. We are happy to work with them directly.
Because every command is plain ASCII text over a virtual COM port, the entire feature set can be exercised by hand before a single line of integration code exists.
Start with <$A:ICLA. One command, and the base reports every channel it has: which transmitters are paired where, and whether each channel has GageSync available, TriggerSync only, or neither. Before sending anything to a gage, you know what you are working with. In this example the transmitter is paired to channel A, and channel A comes back with neither, because bi-directional communication has not been turned on yet.
Turning it on is the one step that involves the hardware. Put that transmitter into Setup Mode at the module and send <$A:GSAMD1. That is done once per transmitter, and from there you are off and running, with everything typed into ComTestSerial. <$A:GSASN2 returns the gage serial number, <$A:GSANC2 returns the next calibration date, <$A:GSAGR1 requests a reading, <$A:GSAZG1 zeros the gage, and <$A:GSAMD4 reports the state of that channel any time you want to check it. Send <$A:ICLA again and the channel that read as neither a minute ago now reports GageSync.
ComTestSerial’s twelve user definable buttons will hold a working command set, so a developer scoping an integration can load the commands they care about, click through the whole sequence, and see the exact response strings the code will have to parse. That is the fastest way to answer the two questions that come up first: what does my gage actually return, and how long does a command take to round trip at the check-in rate I have configured. It is also the tool to reach for when an integration misbehaves in the field, since it shows whether the problem is on the wire or in the software.
The full command set, parameter tables, and response formats are on the MobileCollect EVO API page.
Contact:
MicroRidge Systems
541-593-1656
info@microridge.com