Let’s code a panel mode switcher application for Okuma THINC! An app that lets you switch panel mode from a VNC or other remote desktop application.
Wait, but why? After all, there’s already a panel mode application on the Okuma App Store, and it works quite sufficiently.
Just about every THINC developer has, at some point, coded a panel mode app. It’s the THINC equivalent of “Hello, world!” And since it’s been eight years since I last wrote about it, now’s a good time to look at how THINC app development has changed.
This THINC app will be a .NET Framework application. The latest THINC API version (that I can get my hands on) is 1.21.1, which is built on .NET 4. I’ll add references to the THINC API 1.21.1 assemblies in this project.
I’m developing on Visual Studio Community 2019, which is available for download from the Visual Studio website.
Last time, I coded the panel mode application as a Windows Forms application, using VB.NET. Even though many developers still use WinForms, WPF has become more widespread for Windows desktop development.
And though VB.NET is still around, its continued development is in question, whereas C# has long been the favored language for .NET development. This panel mode application will be written in C#.
The THINC Interface
Okuma THINC API continues to exist in multiple flavors: one for lathe CNCs, another for machining centers. (A third flavor now exists for grinders, but a quick look at the documentation reveals no panel mode support.)
For the panel mode app to work, we need to define a common interface the application can use. This interface is pretty simple: a method to change the panel mode, another to read the current panel mode, and an event to be raised when the panel mode changes.
We’ll create three concrete implementations of this interface: one for lathe, another for MC, and a third for simulation on a PC for testing. To choose which implementation to use, we’ll use the factory method pattern.
And here’s something new since the last panel mode app I wrote: the Okuma SCOUT library. This library has several convenience methods for getting information about the current machine, including what type of machine it is.
That’s handy: no need to check obscure paths for the presence or absence of lathe- or mill-specific DLLs. Now there’s just a static function that tells me whether the app is running on a lathe, mill, NC-Master, PC simulator, or just a plain old PC.
Obviously, this comes in handy for that factory method.
The User Interface
Since I’m coding in WPF, my UI is laid out in XAML, an XML-based markup language for specifying how the user interface should look.
WPF developers commonly use a design pattern called MVVM (model-view-viewmodel) to separate the UI design from its logic. However, MVVM can be overkill for small projects such as this.
Instead I’ll develop this app using codebehind, much as I would have for a WinForms application. For experienced WPF developers reading this, just know that there’s no reason not to use MVVM for THINC development — I just decided against it in this case to keep things simple.
I will take advantage of XAML databinding for updates: rather than writing code to update the UI display when the panel mode changes, I’ll update properties in codebehind and let the UI handle its own updates.
I’ve also added a few niceties: the app can be collapsed to the width of a single button, and becomes translucent when it’s collapsed. It will also snap to any edge of the screen when dragged close enough, though it defaults to the top left corner of the screen.
In my article on tips for THINC apps, I mentioned a few important items.
In my lathe- and MC-specific implementations of IPanelMode, I call CMachine.Init() before doing anything else with THINC API.
These implementations also check the current panel mode on a timer. If the user at the CNC panel changes the panel mode, the change will be detected and an event raised for the UI. This timer code runs once a second. According to the documentation, I could poll the API every 100 milliseconds, but there’s no need to update so frequently for this application.
I’ve made sure the panel mode app is visible to Alt-Tab, and I’ve added basic logging of startup, shutdown, and errors using Serilog. A change to the app configuration should allow logging this to a log file.
One important item that I have not verified is whether the app actually works. Unfortunately I do not have an Okuma THINC control available to me, so I’m limited to testing on my own PC.
So that’s an overview of developing a Panel Mode THINC App; something so common it might be considered the “Hello, world!” of learning to develop with the THINC API.
If you’re curious about the implementation, the source code for this app is available at this GitHub repository. But remember: this app is untested, and meant only as an introduction to THINC development. If you’re looking for a more robust solution, or one with more features, check out GO.PanelMode on the Okuma App Store — or code your own!