Tainuo Hengchuang Technology on TiJet

Current Print Workflow

Mon, 01 Jan 0001 00:00:00 +0000

Current Print Workflow

This document describes the actual print workflow across the C client, C SDK, and tijet_1/tincore gRPC server.

This document only describes the current codebase and client behavior, and does not include future refactoring plans.

Source Baseline

Module	Repository	Branch
Proto contracts & C SDK	`tijet_1/sw-grpc-libraries`	`master`
tincore gRPC server	`tijet_1/tincore`	`feature-grpc-cpp`

Participants

Participant	Responsibility
Qt Client Business Layer	Register event callbacks, upload print data, retry `START_PRINT`, wait for final result
C SDK Call Thread	Encapsulate `SetPrintData` and `StartPrint` RPC calls
C SDK Event Thread	Continuously read `SubscribeEvents` server stream and invoke registered callbacks
`TinCoreServiceImpl`	gRPC protocol layer, dispatches RPC requests to server Handlers
`DefaultTinCoreHandlers`	Handles print data reception, data readiness validation, and async print start logic
`gAFBridge` / Printhead Hardware	Processes print data in background, controls driver board power, communicates with printhead and enables high voltage

Current Call Sequence

sequenceDiagram
 autonumber
 participant Caller as Caller
 participant Callee as Callee

 Caller->>Callee: tijet_client_set_event_callback(callback, user_data)
 Callee-->>Caller: Callback registered

 Caller->>Callee: tijet_client_start_event_subscription()
 Callee-->>Caller: TIJET_OK
 Note over Callee: Background event thread created
 Note over Callee: SubscribeEvents() polling

 Caller->>Callee: tijet_client_set_print_data(data, index, is_static)
 Callee-->>Caller: SetPrintDataResponse{success=true}
 Note over Callee: Print data enters background processing
 Note over Callee: DATA_READY may still be 0 on return

 loop START_PRINT retry, total timeout 10s
 Caller->>Callee: tijet_client_print_control(START_PRINT)
 alt DATA_READY == 0
 Callee-->>Caller: TIJET_ERR_SERVER
 Note over Caller: Wait 1s before retry
 else DATA_READY != 0
 Callee-->>Caller: TIJET_OK
 Note over Callee: High-voltage thread created
 end
 end

 Note over Caller: After START_PRINT success, wait for PrintStarted

 alt High voltage successful
 Callee-->>Caller: PrintStarted{success=true}
 Note over Caller: Ready for printing
 else High voltage failed
 Callee-->>Caller: PrintStarted{success=false}
 Note over Caller: Failure, message contains failed head count
 else PrintStarted not received within 10s
 Note over Caller: Timeout
 end

Retry & Timeout Flow

flowchart TD
 A["Caller: Connect to server"] --> B["Caller: Register callback<br/>Start event subscription"]
 B --> C["Caller: set_print_data() upload print data"]
 C --> D{"Callee: Upload RPC successful?"}

 D -->|"No"| D1["Failed, flow ends"]
 D -->|"Yes"| E["Callee: Data enters background processing<br/>DATA_READY may still be 0"]

 E --> F["Caller: Start START_PRINT retry timer"]
 F --> G["Caller: print_control(START_PRINT)"]
 G --> H{"Callee: Is DATA_READY == 0?"}

 H -->|"Yes: data not ready"| I{"Total retry time reached 10s?"}
 I -->|"No"| J["Caller: Wait 1s"]
 J --> G
 I -->|"Yes"| K["Failed: Print data preparation timeout"]

 H -->|"No: data ready"| L["Callee: Create high-voltage thread<br/>Return TIJET_OK"]
 L --> M["Caller: Wait for PrintStarted event<br/>timeout 10s"]
 M --> N{"Result"}

 N -->|"success=true"| O["Success: High voltage enabled<br/>Ready for printing"]
 N -->|"success=false"| P["Failed: High voltage activation failed"]
 N -->|"Timeout"| Q["Failed: High voltage activation timed out"]

Current Return Value Semantics

Location	Return Value	Current Actual Meaning
`tijet_client_set_print_data()`	`TIJET_OK`	Print data upload RPC completed; does NOT mean backend processing is done or `DATA_READY=1`
`tijet_client_print_control(..., "START_PRINT")`	`TIJET_ERR_SERVER`	gRPC call failed, or server returned `success=false`; client does not distinguish cause, retries after 1s
`tijet_client_print_control(..., "START_PRINT")`	`TIJET_OK`	Server sync validation passed and created high-voltage start thread; does NOT mean high voltage is enabled
`PrintStarted.success`	`true`	High voltage enabled successfully, `setDataParamReady(true)` called
`PrintStarted.success`	`false`	High voltage activation failed, `message` contains count of failed heads

Source Index

C SDK

sdk/c/src/tijet_core.cpp:342: tijet_client_set_print_data().
sdk/c/src/tijet_core.cpp:396: Register event callback.
sdk/c/src/tijet_core.cpp:408: Start event subscription and create event thread.
sdk/c/src/tijet_core.cpp:641: tijet_client_print_control().
sdk/c/src/tijet_core.cpp:655: Match START_PRINT and call StartPrint RPC.
sdk/c/include/tijet_core.h:441: Print data upload C API declaration.
sdk/c/include/tijet_core.h:480: Event callback registration C API declaration.
sdk/c/include/tijet_core.h:500: Event subscription C API declaration.
sdk/c/include/tijet_core.h:650: Print control C API declaration.

Proto Contracts

proto/print.proto:7: SetPrintDataRequest.
proto/print.proto:19: StartPrintRequest.
proto/print.proto:22: StartPrintResponse.
proto/event.proto:48: PrintDataStatus.
proto/event.proto:53: PrintStarted.
proto/tincore.proto:27: SetPrintData RPC.
proto/tincore.proto:28: StartPrint RPC.
proto/tincore.proto:33: SubscribeEvents RPC.

`tijet_1/tincore` gRPC Server

The following paths are relative to the feature-grpc-cpp branch of tijet_1/tincore:

Hugo Image Optimization: Cutting an 8.6MB Background to 310KB

Tue, 04 Aug 2026 00:00:00 +0000

1. Why Optimize Images

Images are usually the biggest culprit for slow static sites:

Reason	Explanation
Large file size	A 2560×1440 PNG can be 8-10MB
Inefficient format	PNG is lossless — great for screenshots, bad for photos
No lazy loading	Page loads all images at once
No caching	Re-downloads on every visit

Core idea: make the browser download smaller files.

2. Hugo Image Processing Pipeline

Hugo has built-in image processing that runs at build time:

Jenkins CI/CD Hands-On: Building an Automated Pipeline from Scratch

Tue, 04 Aug 2026 00:00:00 +0000

1. Why Jenkins

Jenkins is an open-source CI/CD tool. Its core purpose: after code is pushed to a Git repository, automatically run “fetch code → build → test → package → deploy”.

2. Installation

Prerequisite: Java

Jenkins requires Java 17 or 21. Newer versions (e.g., Java 26) fail to start:

Running with Java 26 ... not yet fully supported. Supported Java versions are: [17, 21]

wget https://get.jenkins.io/war-stable/latest/jenkins.war -O /tmp/jenkins.war
/opt/jdk-21/bin/java -jar /tmp/jenkins.war --httpPort=9090

Recommended: Docker

docker run -d \
 --name jenkins \
 -p 9090:8080 \
 -v jenkins_home:/var/jenkins_home \
 jenkins/jenkins:lts-jdk21

3. Initial Setup

Visit http://localhost:9090:

Secure Boot and Firmware Signing: A Practical Guide for Industrial IoT Devices

Wed, 22 Jul 2026 00:00:00 +0000

1. Why Bother?

In industrial control, a compromised firmware image isn’t just a data breach — it’s a physical safety hazard. A tampered firmware could disable watchdog timers, override thermal shutdown thresholds, or silently exfiltrate proprietary motion-control parameters.

Yet most industrial IoT devices ship with JTAG left open and firmware images verified by nothing more than a CRC32 checksum. CRC32 catches bit flips; it does nothing against a motivated attacker.

Taming Linux Jitter: Achieving Sub-50µs Cycle Times with PREEMPT_RT and Xenomai

Tue, 21 Jul 2026 00:00:00 +0000

1. The Challenge: Soft PLC on a $30 SoC

Tainuo’s next-generation motion controller needed to run a soft-PLC runtime doing 20 kHz closed-loop PID control on six servo axes simultaneously. The target hardware: a $30 Allwinner A40i quad-core Cortex-A7. No FPGA, no dedicated DSP — just plain ARM cores running Linux.

The problem was obvious: standard Linux, even with SCHED_FIFO, routinely exhibits 200–500µs scheduling jitter on this class of hardware. For a 20 kHz control loop (50µs period), that’s a non-starter. Missing the deadline means a phase error that accumulates and destabilizes the mechanical system.

FPGA-Accelerated Visual Inspection: How We Cut Latency from 200ms to 8µs

Mon, 20 Jul 2026 00:00:00 +0000

1. The Problem: Software-Based Visual Inspection Hits a Wall

In Tainuo’s PCB printing pipeline, one of the most critical steps is real-time solder-paste inspection. Each board passing through the production line has less than 50ms total for defect detection — any slower and the line stalls.

For years we ran a GPU-accelerated OpenCV pipeline on an x86 edge node. It worked — mostly. But under peak load with high-resolution 8K images, the pipeline occasionally hit 180–220ms per frame. That 180ms of jitter meant missed defects, false passes, and production-line backpressure. The root cause was architectural: a general-purpose GPU pipeline, no matter how optimized, introduces unpredictable scheduling latency and PCIe transfer overhead.

Rust on Bare Metal: Rewriting Our Bootloader Without a Single Page Fault

Sun, 19 Jul 2026 00:00:00 +0000

1. The Bootloader Problem

Tainuo’s industrial control boards ship with an MCU that manages power sequencing, watchdog timers, and over-the-air (OTA) firmware updates. The bootloader — roughly 8,000 lines of C — had been stable for years, but “stable” in the embedded sense means “the bugs are known and we have workarounds.”

Every 6–9 months, a new OTA edge case would surface: a buffer overflow during firmware image verification, an off-by-one in the flash erase routine, a use-after-free in the CAN bus command dispatcher. Each of these bugs required a full recall-cycle OTA fix, which on a deployed fleet of industrial controllers is a multi-week ordeal.

From Proprietary Protocols to gRPC: A Major Leap in Tainuo's Heterogeneous Industrial Control Communication Architecture

Sat, 18 Jul 2026 00:00:00 +0000

1. Why We Had to Abandon Our Legacy Proprietary Protocols

For a long time, Tainuo’s industrial control boards communicated with the host computer and print control terminals using self-built proprietary protocols. These protocols were indeed lightweight, flexible, and easy to modify during single-category development. However, as Tainuo gradually moves toward Industry 5.0 standards, our system architecture is evolving into a “universal industrial-grade heterogeneous computing and intelligent control platform.”

Against this backdrop, the legacy proprietary protocols exposed three irreconcilable pain points: prohibitively high multi-language SDK maintenance costs (C#, C++/Rust heterogeneous endpoints required manual parser rewriting), lack of strong type safety boundaries, and difficulty in flexibly extending RPC services across heterogeneous systems.

Tainuo Hengchuang Technology on TiJet

Current Print Workflow

Current Print Workflow

Source Baseline

Participants

Current Call Sequence

Retry & Timeout Flow

Current Return Value Semantics

Source Index

C SDK

Proto Contracts

tijet_1/tincore gRPC Server

Hugo Image Optimization: Cutting an 8.6MB Background to 310KB

1. Why Optimize Images

2. Hugo Image Processing Pipeline

Jenkins CI/CD Hands-On: Building an Automated Pipeline from Scratch

1. Why Jenkins

2. Installation

Prerequisite: Java

Recommended: Docker

3. Initial Setup

Secure Boot and Firmware Signing: A Practical Guide for Industrial IoT Devices

1. Why Bother?

Taming Linux Jitter: Achieving Sub-50µs Cycle Times with PREEMPT_RT and Xenomai

1. The Challenge: Soft PLC on a $30 SoC

FPGA-Accelerated Visual Inspection: How We Cut Latency from 200ms to 8µs

1. The Problem: Software-Based Visual Inspection Hits a Wall

Rust on Bare Metal: Rewriting Our Bootloader Without a Single Page Fault

1. The Bootloader Problem

From Proprietary Protocols to gRPC: A Major Leap in Tainuo's Heterogeneous Industrial Control Communication Architecture

1. Why We Had to Abandon Our Legacy Proprietary Protocols

`tijet_1/tincore` gRPC Server