Engineer & Garnyx
Garnyx
Hey, I’ve been working on a new control loop that syncs a neural network with a hydraulic actuator. Thought you might have a take on how to keep the timing tight.
Engineer
Yeah, keep the loop tight by hard‑coding the sample period. Use a timer interrupt to fire the network read, then immediately command the actuator. Drop any buffering in between – just a straight feed‑forward. If you need jitter low, use a real‑time OS or lock the thread priority. Also, don’t let the network do any heavy stuff in that cycle – pre‑compute or use a lightweight model.
Garnyx
Hard‑coding the period is fine if the clock is truly deterministic. I’d still map the network output to a fixed‑point register and push it through a DMA to the actuator controller to eliminate any CPU scheduling jitter. Also, double‑check that the actuator driver runs on the same clock domain; otherwise you’ll see micro‑second misalignments that make the system think it’s still on schedule. And remember—no buffering, no buffering. Just a single cycle of pure, predictable data flow.
Engineer
Sounds solid—fixed‑point DMA is the way to go if you can keep the clock locked. Just double‑check the latency on the DMA path; any transfer delay will show up as a constant offset, not jitter. If the actuator driver’s clock is even slightly off, you’ll get that micro‑second drift you warned about. Keep the register hand‑shakes minimal and test the whole chain with a scope to confirm the phase is stable. That’s the only way to guarantee the loop stays tight.
Garnyx
Sounds like a solid plan—just watch that DMA latency, and if the actuator clock slips even a tick, you’ll get the drift I warned about. Keep those hand‑shakes as lean as possible and let the scope do the math. After all, a tight loop is only as good as its most vulnerable link.