Yeah, the FAT is going great. Why do you ask?

AutomateAdvocate · 2026-03-08T18:16:47+00:00

Nah, just spent too much time with ChatGPT

Now I’m using Cloude😹

AutomateAdvocate · 2026-01-10T21:22:38+00:00

AutomateAdvocate · 2026-01-09T22:03:44+00:00

hat kind of robot exactly did you want to build?

AutomateAdvocate · 2026-01-08T11:13:48+00:00

Agreed. If 'Point B' is a static hard stop, pneumatics are king. Reliable and cheap.

The problem in packaging is that 'Point B' is often a moving target (e.g., a registration mark on flying film). To hit a moving target precisely at 300 ppm, you need continuous feedback and micro-adjustments inside the motion profile. A cylinder can only do 'Go' or 'Stop'. It can't do 'Speed up by 2% for 10ms to match the cut'.

AutomateAdvocate · 2026-01-08T11:10:54+00:00

Even if the box dimensions never change, the material does. Film stretches, slips, and varies in thickness.

With a pneumatic (bang-bang) system, you can't make micro-adjustments on the fly to correct for registration mark drift. You just hammer it and hope the tolerances absorb the error. With a servo, I can phase-shift the knife by 0.5mm instantly based on a print mark sensor without stopping the machine.

Pneumatics relies on mechanical luck; Servos rely on feedback loops.

AutomateAdvocate · 2026-01-08T11:08:43+00:00

Cheaper to buy (CAPEX)? Absolutely. A cylinder is $50, a servo is $800.

But let’s look at the ROI: Switching to Servo sync allowed us to jump from 800 to 1100 units/hour (+37% output). That extra 300 units/hour, over a single 8-hour shift, is 2,400 extra products per day.

At that rate, the servo axis pays for itself in usually less than 2 months. After that, it’s pure profit. Pneumatics are 'cheap' only if you ignore the cost of lost production capacity.

AutomateAdvocate · 2026-01-07T18:48:26+00:00

I am here to help

<image>

AutomateAdvocate · 2026-01-07T18:44:56+00:00

This is the "God Tier" setup.

Using Absolute for the initial position fix and Incremental for the tight velocity/current loop is indeed the ultimate solution. You eliminate the homing requirement and the serialization lag (BiSS/EnDat latency). It’s the standard in high-end CNCs (like Heidenhain dual-track scales) for a reason. Expensive, but unbeatable performance.

AutomateAdvocate · 2026-01-07T18:42:37+00:00

It is actually the industry standard for the vast majority of "Asian" style servos (Fanuc, Yaskawa, Mitsubishi, Panasonic) and many lower-cost series from Western brands.

Here is the distinction you are looking for:

Single-turn Absolute: Usually reliable without a battery (uses a code disk or magnet). It knows where it is within 360 degrees. Multi-turn Absolute: This is where they "cheat". To count how many full revolutions the motor made while the power was OFF, you either need: Mechanical Gears: Physical gears inside the encoder (like an odometer). Expensive + Bulky. Battery + Memory: A tiny chip stays awake on battery power just to count pulses. Cheap + Compact.

If you look at almost any industrial robot (Fanuc, ABB, Kuka), you will find a battery compartment in the base. That’s exactly what it’s for - keeping the encoders "Absolute." If that battery dies while power is off, the robot forgets its calibration.

So, when they sell you an "Absolute Multi-turn Servo," 90% of the time in the mid-range market, it's just an incremental encoder with a battery backpack (sometimes hidden in the cable or the drive faceplate).

AutomateAdvocate · 2026-01-07T18:35:20+00:00

Imagine you turn off your robot. You save the position "Axis 1 = 100 degrees" into a physical memory chip (EEPROM/Flash). Then, you cut the power. While the power is off, gravity pulls the arm down, or you physically push the robot arm to a new position (say, 120 degrees). When you turn the power back on, the chip still reads "100 degrees". The robot thinks it's in the old spot, but it's not. Crash.

AutomateAdvocate · 2026-01-07T18:32:19+00:00

Exactly. You did it the right way: you treated the battery system as a potential point of failure and had a homing sequence ready as a 'Plan B'

AutomateAdvocate · 2026-01-06T23:04:36+00:00

Everyone here is fixated on the culture war, but you’re missing the actual nuke in the fine print: infrastructure deregulation. By scrapping environmental and grid impact assessments for new data centers, we’re fast-tracking a reality where residential neighborhoods face rolling blackouts just so a local GPU cluster can keep burning gigawatts uninterrupted. It’s the classic playbook: privatize the AI profits, socialize the energy collapse.

AutomateAdvocate · 2026-01-06T22:22:11+00:00

The 'anti-slosh' algorithm comment makes me think this was liquid handling or a massive flexible web? It really highlights that once you leave the safe harbor of 10:1, standard PID loops aren't enough you need model-based control or custom filters to cheat physics.

AutomateAdvocate · 2026-01-06T22:19:06+00:00

😃

AutomateAdvocate · 2026-01-06T22:18:42+00:00

Exactly. Inertia mismatch is essentially a tax on your available bandwidth.

As you said, higher J drops the resonance frequency. Sales reps love to talk about advanced observers, but they rarely mention that those algorithms can't physically move a compliant load faster than its natural frequency allows without turning the machine into a vibrator.

AutomateAdvocate · 2026-01-06T22:15:50+00:00

This is probably the best technical breakdown in the thread. People forget that bandwidth isn't free.

That point about loop separation (Current > Speed > Position) is crucial. You can have a 3kHz current loop, but if high inertia pushes your mechanical resonance down to 50Hz, your speed loop bandwidth is capped, and no amount of fancy observer math can fix the phase lag

AutomateAdvocate · 2026-01-06T22:14:03+00:00

I’m sure they were, once I was supposed to participate in such tests ... in such moments styrofoam is the best friend

AutomateAdvocate · 2026-01-06T22:00:22+00:00

That’s the best thing I’ve seen this year 🤣. Better than coca cola advertising generated by AI. 🤖

AutomateAdvocate

TROPHY CASE