Note: for an updated look at this topic, see this article.
The Okuma THINC controls are advanced CNCs that are based on the Windows platform. This makes it easy to provide solutions using off-the-shelf Windows software. Additionally, Okuma provides a THINC API to enable .NET developers to create new applications that interface with the CNC.
For this example, I’ll develop a simple application that addresses a common problem: changing the CNC panel mode. This is not a new idea: I’ve seen at least three different implementations, and it makes a simple introduction to THINC development.
Like many Okuma P200 owners, we run VNC remote desktop software on our P200 controls. This means that I can view the screen and control the P200 from my desk, using my keyboard and mouse.
Unfortunately, one thing I cannot do from my desk is change the panel mode. This is done from the operator panel at the control, and there are no keyboard shortcuts for it. So if I want to look at the Tool Data screen to adjust tool wear offsets, but the THINC control is in Parameter mode, I need to get up from my desk, walk over to the control, and press the “Tool Data” button.
Fortunately for me, I can develop a THINC application to change the panel mode, sparing me that little bit of exercise.
(Incidentally, if you just need to be able to adjust Tool Offsets or Tool Wear Offsets remotely, dataZen has a THINC App for that.)
Before We Begin
First, I’ll need to make sure I have a few things:
- An Okuma THINC control, such as a P100 Mark II, P200, or P200A. The Okuma P300 CNCs are now available, but I have not yet had the pleasure of working with one.
- Okuma THINC API. This is an “application programming interface” that allows us to program THINC. Okuma provides two flavors: one for lathes and another for machining centers. You need to make sure you install the right version for your CNC. You can get THINC API from Okuma or from an Okuma distributor.
- Microsoft Visual Studio. I’ll be developing in VB.NET, but you can code in any .NET language. If you don’t have access to one of the paid versions, you can download the Express edition free from Microsoft.
What We’ll Be Doing
For this example, we’ll create a simple application that displays on the screen. It’ll sit in the upper-right corner of the screen, out of the way. When I tap on it, it’ll expand and allow me to choose a panel mode.
As a bonus, I’m going to include a button that mimics the Windows key. The operator panel on the P200 doesn’t include a Windows key. This is a minor annoyance when I’m at the control and want to open Explorer (Win+E), the Run Dialog (Win+R), or view the desktop (Win+D).
Creating the User Interface
For an application this simple, I like to lay out the user interface first. I have a form named ScreenChangeForm that looks like this:
This is a fairly standard Windows Form: a few buttons and a couple of timers. I won’t go into too much detail, but I will make note of a few things.
First, I’ve made the buttons 62 pixels in height. The default size is a little too small for comfort on the THINC touchscreen. 62 pixels is about the height of the other buttons in Okuma’s HMI applications, such as the vertical toolbar at the right of the screen.
When the form loads, it will position itself at the top-right of the screen’s working area. It’ll collapse so that only the “expand/collapse” button is visible. It’ll also reduce its opacity to 50% (meaning that it will be 50% opaque and 50% transparent). This should keep it from getting in anyone’s way when it’s not needed.
When the “expand/collapse” button is tapped, the form will expand to its full size and become fully opaque so that it is easy to see.
I’ve included two timers on the form:
ThincTimer will attempt to connect to THINC API if we do not already have an open THINC API connection (more on that later). This can happen if my application runs at startup, before THINC API is ready. An easier way to avoid this problem is to use Okuma’s THINC Startup Service to launch the application after a short delay.
TopmostTimer just bumps the form back up to the top of the window stack periodically. Okuma’s HMI software occasionally makes itself the topmost window. This prevents Okuma’s HMI from getting lost beneath other applications, but I’ve already made my little panel mode form as unobtrusive as possible, and I need to be able to access it easily.
Writing the THINC Interface and Implementation
Now that my user interface is done, I need to write the THINC code to change panel modes. Within a component of the THINC API known as the Command API, there is a class named CViews, with a method named ChangeScreen. All I have to do is create a CViews object, and call its ChangeScreen method.
But there are two flavors of THINC API: one for lathe and one for machining center. Both are very similar, with minor differences. I want my application to work on both of them.
Fortunately, Jon Weaver at Gosiger has already posted a video of using .NET interfaces for machine neutral THINC applications. If you’re unfamiliar with .NET interfaces, it’s worth the 13:54 of your time. I also “borrowed” the Okuma Utilities DLL used in the example.
I’ll be creating the same architecture: an IThinc interface with a ChangeScreen method, then three classes that implement that interface: one for lathe, another for machining center, and a third that just simulates a panel mode change so that I can test on my development PC instead of on a control. I’ll use a Factory pattern to instantiate the appropriate type of object.
Each of the Panel Mode buttons on my ScreenChangeForm will just have to call that IThinc.ChangeScreen method.
Yes, this is pretty much the simplest THINC app possible.
One Minor Detail
THINC API provides an enumeration named PanelGroupEnum. To change the Panel Mode, you simply pass the appropriate value to CViews.ChangeScreen. For example, if I want to switch to program mode, I just pass PanelGroupEnum.ProgramMode, something like this:
Dim views As New CViews() views.ChangeScreen(PanelGroupEnum.ProgramMode, "")
The problem is that there are two flavors of the THINC API, so there is one PanelGroupEnum for lathe and another for machining center. All of the values are the same, but the lathe API isn’t available on the machining center, and vice versa. Even though all of the values are the same, and the semantics are the same, .NET doesn’t know this and will complain if I try to use one or the other.
As a workaround, I created yet another enumeration with exactly the same values. In my ThincLathe class, I cast the enumeration to the corresponding lathe enumeration. In my ThincMill class, I cast the enumeration to the corresponding mill enumeration. Not a big problem; just a little redundant.
With the THINC code taken care of, I just need to implement the Windows key functionality. To implement this, I just make a Windows API call to a method named keybd_event.
For our purposes, the only important parameters for keybd_event are the first and the third. The first parameter tells Windows which keypress to simulate. The third tells Windows whether we want to simulate pressing the button or releasing it.
In the StartButton_MouseDown event, I use Keys.LWin, which is the keycode for the “left Windows key”. This simulates pressing the Windows key.
In the StartButton_MouseUp event, I use the same keycode, but I pass KEYEVENT_KEYUP as the third parameter. This simulates releasing the Windows key.
Now if I click on the start button on my ScreenChangeForm, it should act just like pressing the Windows key. If I hold down the start button on that form, I should be able to use keystroke combinations such as Win+E to open Explorer, or Win+R to open the Run dialog.
Lo and behold, it works. At least on my development PC.
Running the Application
If I run the application on my development PC, it looks like this:
The top of the image shows the collapsed ScreenChangeForm: 50% opaque, only the “expand/collapse” button is visible. The bottom of the image shows the expanded ScreenChangeForm: fully opaque with all buttons accessible.
Of course, my development PC is not a THINC control, so if I click one of the panel mode buttons, all I see is a popup message that I added for debugging. The next step is to test it on an actual control…
To the THINC Control
So what does my Panel Mode Change application look like on the THINC control? Here’s a screenshot in the same layout as the previous one: the top is my Panel Mode Change application, collapsed and out of the way; the bottom is the application expanded and ready to use.
And it works. Through VNC remote desktop, I can change the panel mode of the THINC control from my desk. If I’m physically at the control, I can use the “Start Button” on my app just like the real Windows key.
This is just about the simplest possible example of a THINC app. If I wanted a more robust application, I would include exception handling, an installer, and so forth. (If you’re looking for a panel mode application with a complete onscreen keyboard and numeric keypad, dataZen provides one.)
Okuma’s THINC API allows us to do much more than just this. Using the API, we can query the CNC’s status (axis positions, execution mode, I/O, workpiece counter, etc.), read and write tool information such as tool life, offsets and wear offsets, read and write common variables, load part programs, and so forth. This opens a large number of possibilities for machine monitoring, control, and integration.
To learn more about what THINC API can do, you might want to visit some of these sites: