HSMAdvisor SDK - Integration Options for Developers

February 15, 2023, 8:10 pm by admin

Two Ways to Add HSMAdvisor Speeds and Feeds to Your Software

If you build CAM software, a tool-management system, a shop-floor app, or any program that needs cutting data, you don't have to write your own speeds-and-feeds engine. HSMAdvisor offers two integration routes, each with an open demo project on GitHub. They solve the same problem in very different ways, and the right one depends on what your host application looks like.

Option 1: HSMAdvisor.Integration (recommended)

Repo: HSMAdvisor.Integration-Demo

This is the current, preferred approach. Your application doesn't load HSMAdvisor's engine at all. Instead it talks to the user's installed copy of HSMAdvisor, which acts as a local speeds-and-feeds server. Requests and responses are JSON messages sent over a per-user named pipe. The small client library, HSMAdvisor.Integration.dll, handles finding HSMAdvisor, starting it in the background, and sending requests. It's the same mechanism behind HSMAdvisor's Mastercam hooks.

What this gets you:

  • Your process stays clean. No HSMAdvisor code runs inside your application. If something goes wrong on the HSMAdvisor side, your app doesn't crash with it, and you don't have to worry about conflicts between its dependencies and yours.
  • Modern .NET support. The client comes in net48 and net8.0 builds, so it works in .NET Framework hosts and in .NET 8/10 hosts like Mastercam 2027.
  • Updates you don't have to ship. You don't redistribute HSMAdvisor binaries. Users update HSMAdvisor on their own schedule, and your integration keeps working as long as their version is at or above the minimum you set (currently 3.2.0).
  • The user's own data and license. Calculations use the user's materials, machines, tool library and license. Licensing isn't your problem.
  • Not just C#. The wire format is length-prefixed JSON, so Python, C++ or anything else that can open a named pipe can use it. The demo includes a raw-protocol example.
  • Asynchronous and cancellable. Requests are async, dialogs are owned by your window, and cancelling a request closes the HSMAdvisor dialog it opened.

The API covers headless calculations (milling, HSM with chip thinning, slotting, drilling, machine-limited cuts), the full HSMAdvisor calculator as an OK/Cancel dialog, material, machine and tool-library pickers, saving cuts to the library, reference data lookups, unit conversion and translation into the user's HSMAdvisor language. The demo app walks through 26 of these tasks.

The trade-off: HSMAdvisor must be installed on the user's machine, and the first request takes a few seconds while it starts in the background.

Option 2: Direct DLL integration (legacy)

Repo: HSMAdvisor-DLL-Test

The original approach loads HSMAdvisor's engine, HSMAdvisorCore.dll, plus its database and plugin libraries, directly into your process. You call Core.init(), create a Calculation object, set properties, and call Calculate(). It's simple, synchronous, and familiar to anyone who has referenced a .NET assembly.

Where it still makes sense:

  • An existing .NET Framework 4.8 application that already uses it and works well.
  • Tight in-process access, such as the machine database editor or license dialog, called directly from your code.
  • Older toolchains. It builds with Visual Studio 2015 and later.

The costs:

  • .NET Framework only. HSMAdvisorCore.dll doesn't run on .NET 8 or later, so it's a dead end for hosts moving to modern .NET.
  • You ship and version-lock the engine. Your release carries specific HSMAdvisor binaries, so engine improvements reach your users only when you redistribute.
  • Shared process, shared problems. The engine and its dependencies (such as Newtonsoft.Json) live inside your application, with the usual risk of version conflicts.
  • Licensing still applies. The library can be redistributed, but it may only be used on fully licensed computers. Material ID 227 is available for license-free testing.

Which one should you pick?

Your situation Choose
New integration of any kind Integration
Host runs on .NET 8/10, or is moving there Integration
Non-.NET host (C++, Python, etc.) Integration (raw pipe protocol)
You want users to get HSMAdvisor updates without a new release from you Integration
You need to keep your process isolated from third-party code Integration
Existing .NET Framework 4.8 app already using the DLL, no plans to migrate Direct DLL (for now)
Stuck on an old Visual Studio toolchain Direct DLL

Bottom line: start new projects on HSMAdvisor.Integration. It's decoupled, works with modern .NET and other languages, and lets HSMAdvisor update independently of your product. Treat the direct DLL route as a legacy option for existing .NET Framework integrations, and plan a migration if your host is heading toward newer .NET.

Both demo projects have the same task-based test app, so you can run each one, look at the API calls and output, and compare them side by side before you commit. Get HSMAdvisor at hsmadvisor.com/download.