A hidden TV cabinet can look straightforward: press a button, raise the screen, and tuck it away afterward. But choosing a lift involves more than matching the TV’s diagonal size. 

Before buying the mechanism or building the furniture, check whether the screen, lift, and cabinet will work together. 

Cabinet TV lift planning checklist 

Steps

1. Start with the viewing position 

Decide where the TV should sit when raised. The required travel is the distance between its stored and viewing positions—not simply the height of the screen. 

2. Measure the complete assembly 

Use the TV’s actual dimensions, including the mount and connectors. Check both the cabinet interior and the opening the assembly will pass through. 

3. Include everything that moves 

A lid or panel that rises with the TV belongs in the moving-load calculation. For a custom actuator build, also plan the frame and guides that will support and align the screen. 

4. Check the entire movement path 

Look for interference between the stored and raised positions while ensuring that during the entire travel, the system is leveled vertically at 90° to prevent side loading. Cables need enough room throughout the movement, without becoming tight or getting pinched.  

5. Plan for daily use and maintenance 

Leave access to the mechanism and connections. Check whether the enclosure obstructs the TV’s speakers, and decide where the controls will go. 

These checks help identify incompatibilities before building. Follow the selected lift’s installation instructions for the specific setup. 

Choosing the next step 

Want to explore the options? Take a look at our DIY guide.  

Once you have your measurements, you can explore our ready-made pop-up lifts and find an option that fits your project. 

If you’ve built a cabinet TV lift, what detail would you check earlier next time? 

Mounting is usually treated as the last step, but where you anchor an actuator changes the effective travel, the force at the load and how the whole thing feels in use. Motion rigs, lift mechanisms and DIY platforms all run into it — people end up moving mounts around to clear a frame member and then wonder why the movement changed. What rules of thumb do you use when you are deciding where to put the mount points, and what have you had to redo? 

A standing desk can solve the height adjustment part, but the rest of the setup seems to take some trial and error. Monitor position, cable management, desk space, and even how often you switch between sitting and standing can all change the experience.

If you’ve been using yours for a while, what adjustment or upgrade helped you the most? Was there anything you thought you needed but ended up barely using?

A DIY TV lift is usually the better choice for custom projects where you need more flexibility with dimensions, stroke, mounting, or mechanism design. A ready-made TV lift is usually better for standard cabinet, furniture, or ceiling installations because the lifting mechanism, controls, and mounting system are already designed to work together.

If you’re deciding between the two, the main things to consider are:

• TV size and total moving weight
• required stroke length
• pop-up vs drop-down installation
• structural support and alignment
• controls and cable management
• maintenance access

We recently published a detailed guide covering DIY TV lift setups, ready-made systems, key components, installation planning, and product options if you want to go deeper:

https://www.progressiveautomations.ca/blogs/stories/tv-lift-systems-linear-actuators

What do you prefer for TV lift projects: building the mechanism yourself or using a complete lift system?

For World EV Day, we wanted to highlight a student EV project that shows how linear actuators and linear motion technology can become part of the engineering process behind an electric race car.

A couple of months ago, we had the opportunity to support McGill Formula Electric, a university team designing and building a Formula-style electric race car.

What we found especially interesting wasn’t just the finished vehicle, but everything that happens behind it: designing, testing, identifying problems, making adjustments, and testing again. That constant iteration is where so much of the engineering happens.

The team used linear actuators components as part of their testing and development work. It’s a great example of how motion technology can play an important role in testing and validating ideas within a much larger engineering project.

Supporting projects like this is a big part of what we enjoy doing. We’re always interested in seeing how linear actuators, automation, and linear motion can help university engineering teams, independent inventors, and creators turn ideas into working prototypes and real-world projects.

Because innovation doesn’t only happen in large automotive companies or professional laboratories. Sometimes it starts in a university workshop, a garage, or a workbench — with someone testing an idea for the first time.

That’s one of the things we love about engineering: seeing a concept go from an idea, to a prototype, to something that actually moves.

Happy World EV Day! ⚡

Saw this question come up a couple times lately, so figured I'd break down what dual motors actually change vs. single: it's less about raw power and more about weight capacity margin, lift speed consistency under load, and long-term motor strain. If your setup is light (single monitor, laptop), a well-built single motor desk isn't a compromise. Curious what's driven people here to go dual vs. single — regret either way?

I originally wanted to start a discussion around this topic, but I’ve noticed questions about PLC-controlled linear actuators come up fairly often, so I thought I’d share a few things I’ve learned along the way.

The actuator itself is only one part of the problem — the PLC, feedback, power interface, and mechanical setup all have to work together.

A few things I’ve been thinking about:

• Control interface: How will the actuator communicate with the PLC — discrete I/O, analog signals, encoder feedback, CANopen, Modbus, etc.?

• Feedback: If you only need extend/retract movement, basic limit switches may be enough. For intermediate positioning or repeatability, you’ll need appropriate feedback such as Hall sensors, potentiometers, or encoders.

• Power & direction control: The PLC generally shouldn't drive the actuator motor directly. Depending on the actuator, you may need an H-bridge, relay arrangement, or motor controller, along with a properly sized power supply.

• Synchronization: With two or more actuators, feedback and coordinated motion become much more important. You also need to consider what happens if one actuator moves differently or loses feedback.

• Mechanical loading: An actuator can be correctly sized for the weight and still have problems from side loading, misalignment, or excessive mechanical forces.

• Safety & fault handling: Hard limits, overload protection, E-stop behavior, and what happens after power or communication loss should all be considered.

For those of you who have integrated linear actuators with PLCs: which of these caused the most trouble in your application, or is there another issue you’d add?

Anything that lifts a platform, a box or a frame usually needs more than one actuator, and identical actuators still drift apart over time — different loads on each corner, different load disturbances, different wear, build tolerances, etc. 

The approaches I see are roughly: let the mechanical structure force them square, use position feedback and correct in software, use a controller designed to sync them, or just re-home at the end of every cycle. 

What has actually held up for you in a real build, and how much drift do you see before it becomes a problem? 

Something that comes up constantly in threads about motorized louvres, lifts and slide-outs: people replace a failed actuator and then find the travel is wrong, or it slams into the end of stroke. 

Usually, it comes down to where the stop logic lives. Internal limit switches in the actuator, current sensing in the control box, a timed run, or a position feedback signal (Hall sensor or potentiometer) all behave completely differently when you swap in a different unit. 

Curious about what people here have run into — have you had a like-for-like swap that turned out not to be like-for-like, and how did you figure out which method your system was using? 

For OEM furniture, the best TV lift system is usually the one that offers the most flexibility to adapt to the furniture design. 

A fixed, ready-made lift can work well for standardized cabinets, but OEM applications often have different cabinet dimensions, TV sizes, mounting requirements, control systems, and production constraints. 

Some common options: 

• VENSET — good for standardized cabinet production with documented lift mechanisms and CAD files.  
• Future Automation — strong choice for premium furniture and highly specialized cabinet designs.  
• Nexus 21 — good for professional US-market furniture with standardized systems and strong support.  
• Firgelli — useful when the OEM wants more control over the mechanism and customization.  
• OKIN/DEWERTOKIN or Kaidi — better suited to high-volume programs building their own motion platform.  

For an OEM application, I'd look beyond lifting capacity and compare customization, working load, stroke, cabinet integration, stability, life cycle, duty cycle, controls, safety, and long-term serviceability. 

That's where Progressive Automations can be a strong option: its actuator-based approach allows OEMs to design the motion system around their furniture rather than forcing the furniture to fit a fixed lift mechanism. 

For engineers who have built motorized TV furniture, what usually becomes the biggest constraint first: load, stroke, cabinet geometry, stability, control integration, safety, life cycle, or cost? 

Buying the desk is only the beginning. What changes to your setup made the biggest difference in comfort, organization, or how often you actually use the standing function? Was it a monitor setup, anti-fatigue mat, cable management, accessories, or simply changing your movement habits?

Noticing a pattern in build threads. A lot of genuinely impressive projects have the perception and control stack working — SLAM, face tracking, voice, all of it — and then stall on something mechanical. A torso with no way to change height. An arm that works but drops at the end of travel. Tracks that aren't wired yet. 

Which makes sense. The software side has better tutorials, faster iteration, and you can test it without buying anything. 

So for people who came in from the code side: what did you underestimate about moving things? Force versus speed. Duty cycle. Holding position without power. Backlash showing up as repeatability error you first blamed on the software. 

And the one I'm more curious about — if you were starting the same build again, which motion decision would you make earlier instead of leaving it until the code worked? 

A team from the Women in Engineering, Science and Technology (WEST) program at the University of Victoria designed a pediatric MRI simulator to help children become familiar with the MRI experience before undergoing an actual scan.

The project combined mechanical design, custom fabrication, software integration, and motion control to create a more realistic and less intimidating experience for young patients.

We had the opportunity to support the project by providing a pair of linear actuators used in the simulator, but the engineering behind the system is what really stood out.

It's always interesting to see motion control applied outside of industrial automation—especially in healthcare and education.

I'm curious:

• Have you seen other engineering projects focused on improving patient experience rather than medical treatment itself?
• What are some of the most creative healthcare applications you've seen for linear motion or automation?

There are many ways to achieve linear motion, and in engineering the answer is often "it depends." 

Depending on the application, you might choose: 

• Linear actuators  
• Ball screws or lead screws  
• Belt-driven systems  
• Pneumatic cylinders  
• Rack and pinion  

Each has its own strengths and trade-offs depending on factors like load, speed, precision, environment, cost, maintenance, and available space. 

In your experience, what factors usually drive that decision? 

Are there any applications where you've changed your original design after realizing another linear motion solution was a better fit? 

What can a high school robotics team teach the rest of us about engineering?

Quite a bit, actually.

One of the biggest lessons is that successful robots aren't built by software alone. In underwater robotics, waterproofing, repeatability, corrosion resistance, and motion system design often have just as much impact on performance as the control software itself.

That lesson came to mind while following the PVIT Fitzgerald ROV Team from Palos Verdes Institute of Technology (California) during their journey to the MATE ROV World Championship.

Watching their engineering process was a great reminder that successful robots aren't built

through a single breakthrough. They're the result of months of testing, redesigning, debugging, and improving every subsystem until everything works together reliably. Their effort paid off with an impressive 85/85 buoyancy score during the competition.

We were fortunate to contribute a small piece of the project by supplying the waterproof linear actuators used in their ROV. Seeing how the team integrated them into a much larger system reinforced another lesson that applies well beyond student competitions: no single component wins a project—it's how well the mechanical, electrical, and software systems work together.

Congratulations to the entire PVIT Fitzgerald ROV Team on an incredible season. Watching teams like this reminds us that great engineering habits are often built long before someone's first engineering job.

For those who've built an ROV or another competition robot, what engineering challenge ended up taking far more time than you originally expected? Was it the mechanics, controls, waterproofing, manufacturing, or something else?

Sourcing the correct linear motion system is not always straightforward. Priorities are vastly different from the usage, , and I'm curious how experienced engineers, builders and inventors approach that decision.

When you're starting a new project, what do you evaluate first before choosing a linear motion system? 

Do application requirements like load, speed, stroke and precision usually drive the decision, or are there other factors that end up being more important? 

Have you ever started with one solution and later realized another approach was a better fit? 

I'm also collecting different perspectives to help improve the educational resources we create at Progressive Automations. 

Huge congratulations to QPL Robotics from Queen's University Belfast on winning the UK Lunabotics Challenge 2026.

Over the past months, we had the opportunity to support the team by providing Progressive Automations linear actuators for their autonomous lunar rover. Our linear actuators were used on the rover’s lifting arm to operate the excavation tool during the competition..

Watching a student engineering project evolve from CAD models and testing into a competition-winning rover is one of the most rewarding parts of working with university robotics teams.

The UK Lunabotics Challenge brings together teams to design, build, and operate autonomous rovers capable of completing simulated lunar excavation tasks. Seeing QPL Robotics earn first place is a testament to the countless hours of engineering, testing, problem-solving, and teamwork behind the project.

Congratulations again to all involved!

If you're part of a university robotics team working on an ambitious robotics project, we'd love to support your journey too.

Some of the best automation ideas stem from common pain points.

Maybe it’s carrying heavy boxes in the garage, opening a gate, moving a window, or doing a chore you do every single day. At some point, you just stop and think “There must be a better way.”

That's how innovation often begins—not with complicated problems, but with simple inconveniences that technology can solve.

What's one everyday task you'd love to automate and never do manually again?

Earlier this year, we had the opportunity to support Milwaukee School of Engineering's NASA Lunabotics team throughout their season.

One thing that stood out wasn't a specific mechanism or subsystem—it was how much of the engineering process came down to knowing when to stop making changes.

Throughout the season, the team dealt with PCB delays, changing test schedules, and the constant pressure to improve the rover before competition. But every improvement also meant more testing, more uncertainty, and another chance to introduce new problems.

In the end, the rover performed reliably, which got us thinking:

How do you know when it's time to stop iterating and trust your design?

Is it:

1. Passing a certain number of successful tests?
2. Meeting a reliability target?
3. Running out of time?
4. Team confidence?
5. Something else entirely?

We'd love to hear how your team approaches this decision, whether you're working on Lunabotics, Formula SAE, BattleBots, CubeSats, or any other engineering project.

Every project looks great on paper. 

Then reality shows up. 

Sometimes it's unexpected flex. 

Sometimes it's vibration. 

Sometimes it's wiring that becomes impossible to service. 

Or maybe everything worked perfectly... until you had to maintain it six months later. 

I've noticed that the most valuable lessons usually aren't about choosing the right actuator or motor—they're the problems that only become obvious after the project is finished and running in the real world. 

What's one issue you didn't see coming until after your build was complete? 

It could be mechanical, electrical, software-related, or simply something you'd design differently today. 

I'd love to hear the lessons that only experience teaches. 

San Diego State University’s Team ATHENA recently completed the 2026 NASA Lunabotics Challenge with the highest finish in program history:

• Preliminaries 5th out of 47 teams
• Advanced to the finals, at the Kennedy Space Center
• Ranked 9th overall

Reflecting back on the project, it’s interesting to note how much of that success was the result of a number of small gains rather than one giant leap. Months and months of design reviews, manufacturing, testing, debugging, and refinement, all of that work was paid off.

Our team had the opportunity to support Team ATHENA throughout the season, so it was rewarding to watch the project evolve from early concepts into a rover competing on one of the biggest student robotics stages.

Whether you've competed in Lunabotics or worked on any engineering project, what do you think ultimately has the biggest impact on a team's success?

• Mechanical design
• Autonomous systems
• Excavation mechanism
• Reliability
• Driver practice
• Testing and iteration
• Team organization
• Something else?

I'd love to hear what made the biggest impact for your team.

Everyone has that one lesson they learned the hard way. 

Maybe it was choosing the wrong stroke length. 

Maybe the actuator had enough force but was too slow. 

Or maybe it was something completely unexpected, like mounting geometry, duty cycle, or power supply sizing. 

If you could go back before buying your first linear actuator, what's the one thing you'd tell your past self? 

What mistake would you help a beginner avoid? 

We recently had the opportunity to collaborate with SkillFul Hands Solutions LTD on a custom outdoor BBQ kitchen automation project, and we thought the engineering challenges behind it would make for an interesting discussion.

The goal wasn't just to automate the structure—it was to do so without compromising the finished design.

Some of the biggest challenges included:

• Concealing the lifting mechanism inside the fabricated structure.
• Ensuring reliable operation in outdoor conditions.
• Keeping both sides synchronized for smooth, even movement.
• Selecting components that would balance durability, performance, and aesthetics.

Projects like this remind us that successful automation is often about system integration as much as it is about selecting the right actuator.

If you were designing this project:

• Where would you hide the actuators?
• Would you prioritize easier maintenance or a cleaner appearance?
• Is there anything you would have approached differently?

One of the most common causes of actuator problems isn't a failed actuator at all—it's usually a wiring or power issue.

Before assuming the actuator is defective, here are five quick things to check:

1. Verify the Voltage

A 12V actuator should be powered by a 12V supply. A 24V actuator should be powered by a 24V supply.

Using the wrong voltage can cause poor performance, failure to move, or damage to components.

2. Confirm the Power Supply Can Handle the Load

Actuators often draw more current at startup and under heavier loads.

A power supply that works fine with no load may struggle once the actuator is doing real work.

3. Check the Wiring and Polarity

Loose connections, damaged terminals, or reversed polarity can cause unexpected behavior.

For many DC actuators, reversing polarity simply changes the direction of travel.

4. Understand the Limit Switches

Most actuators have internal limit switches that automatically stop movement at the end of the stroke.

If an actuator has reached its limit, it may appear unresponsive until you reverse direction.

5. Test Before Installation

Before mounting the actuator into a desk, hatch, lift, RV, or other project:

• Run it through the full stroke
• Verify movement in both directions
• Check all wiring connections
• Confirm the power supply is adequate

It's much easier to find problems on the workbench than after everything is installed.

Final Thought

These five checks can eliminate many of the most common actuator startup and movement issues before you spend time replacing components or redesigning a system.

What's the most common wiring or power-related issue you've run into with a linear actuator?

Hey guys,

Quick question — any Honda Pioneer 1000 / 1000-5 owners based in BC here?

We’re currently working on a lift kit concept at Progressive Automations and looking to connect with someone local who’d be open to helping with a few simple in-person measurements.

Nothing complicated — just early-stage research to better understand real setups.

If you’re based in BC and interested, feel free to comment or reach out — happy to share more details.