← Help contents

Calculation Tools

Seventeen exact answers the assistant is not allowed to guess

Ask a language model for a CRC and it will give you one. It may even be right. This is precisely the kind of work a model should not be doing from memory, so ComIO.Studio does not let it: seventeen calculation tools are built into the app, and the assistant calls them instead of working the answer out in its head.

They are pure arithmetic — no port, no network, no files. Nothing here can touch your device or your disk, which is why they run without asking permission every time. You can still switch any of them off under ⚙ → Tools & Permissions in the AI settings if you want to.

Where they are

There is no tab for them — and there is nothing to look for in the sidebar. You reach them by asking, in the AI panel or from an outside agent over MCP:

“What is the Modbus CRC of 01 03 00 00 00 0A?”
“Decode 44 7A 00 00 as a big-endian float.”
“Registers 0x4048 0xF5C3 as a float32, word order AB — what is that?”
“How long does 256 bytes take at 9600 8E1?”

Two of them also work for you without any assistant involved: the Modbus RTU table on the send bar fills in its CRC column through the very same code (see the Sending Data chapter). The checksum in front of you and the one the assistant quotes come from one place, so they cannot disagree.

Checksums

  • CRC — Modbus CRC16, CCITT, CRC8 and CRC32 by name, plus a custom mode where you give the polynomial, the initial value, the reflection flags and the final XOR. That covers the house protocols whose manual prints a polynomial and nothing else. The answer comes back both as a value and as the complete frame with the checksum already appended.
  • Simple checksums — LRC, XOR, 8-bit and 16-bit sums, for the older and lighter protocols that use them.
⚠ A CRC value and CRC bytes on the wire are not the same thing. Modbus sends the checksum low byte first, so the value 0x0C44 travels as 44 0C. When you are going to send the frame, take the complete frame the tool gives you rather than gluing the value onto the end yourself — that is where the byte order gets reversed by accident.

Numbers and registers

The everyday arithmetic of reading a device manual:

  • Convert — one number in hex, decimal, binary or ASCII, returned in all of them. Give a width and say it is signed, and you also get the two's-complement reading: 0xFFFF as an int16 is −1, which is the difference between a sensor reading minus one degree and one reading 65535.
  • Float — IEEE-754 single and double precision, hex to number and back, with the byte order you choose.
  • Registers — the classic Modbus problem: two 16-bit registers holding one 32-bit integer or float, and the manual not saying which register comes first. Both word orders, both readings, pick the one that is not nonsense.
  • Endianness — swap bytes or words across a whole string.
  • Bits — test, set, clear or toggle a single bit; pull a field out of a word by its [hi:lo] range; decode a status word into labelled flags.
  • Scale — fixed-point in both directions: value = raw × scale + offset, and the inverse for when you need to write a value back in engineering units.

Decoding a whole block at once

When a device answers with a structure rather than a number, describing it field by field is faster than converting each one. Give the raw block and a layout — offset, type, byte and word order, scale, a label — and you get a table of named values back. It is not Modbus-specific: a register block, a GPS sentence payload and a sensor's telemetry struct all decode the same way.

Modbus frames

  • Build — assembles an RTU frame for functions 1–6 and 16, with the CRC16 filled in.
  • Parse — the other direction: checks the CRC, splits the frame into its parts and, importantly, recognises an exception response rather than reporting it as odd data. A device that answers “illegal data address” is telling you something specific.
  • Reference — the background knowledge: port settings and why so many devices insist on 8E1, RTU against ASCII, how addressing is written in manuals, where the data layout traps are.

Encoding, text and timing

  • Serial timing — how long N bytes take at a given baud rate, and the inter-frame gap that goes with it. This is the tool for “is my timeout too short?”: at 9600 baud a 256-byte answer needs a quarter of a second before the last byte can possibly have arrived, and a 100 ms timeout will never see it.
  • Hexdump — offsets, hex and ASCII side by side, the same view the terminal's HEX mode gives, for a block you have pasted in.
  • Parse ASCII — splits a line on its separator and verifies the checksum: NMEA sentences with their *47 ending, CSV, plain KEY:VALUE lines.
  • Byte stuffing — SLIP encoding and decoding, for framing binary data on a link that has no other frame markers.
  • Base64 — encode and decode.
💡 This is why the assistant is worth trusting on frames. When it tells you a checksum, quotes a float or works out a timeout, that number was computed, not recalled. Every call leaves a card in the conversation — click it open to see which tool ran and with what arguments.