Thincster

Remote Chuck Switch adjustment option:

Eliminate the hassle of constantly having to physically adjust the chuck clamp prox switch.

Using laser and or fiber optic  technology, the Okuma API, and .net programming, we are able to adjust the clamp signal directly on the control.

Settings are taught and saved by program name, then recalled when the program is called up, providing the chuck setup has not changed.

This allows for faster setup times, no panels to remove, and no tools needed to make the adjustments.

Contact Jimi Brown at Gosiger Inc.

jbrown@gosiger.com

Phone 800-888-4188

After using the Okuma I/O application for a while I found that I was missing the ability to see what signals were around the signal I was monitoring. So I added the ability to sort for the other 15 signals for the address of the currently highlighted signal. While I was adding this feature I also optimized how the search and filtering feature works. When I originally wrote the first version I was just learning on the CollectionView class worked. Now that I have a better understanding of it I was able to take advantage of its really easy to work with filtering mechanism. I learned that using the ICollectionView interface allowed me to use the Filter method which takes a predicate function to determine whether or not the items in my collection should be included in the view. You can read more about it here.

You can download the source here: Okuma IO source
or download the compiled version here: Okuma IO

Our customer has some LB machines in automated cells. Because the layout of the cell the operator has to stop the cell in order to make tool wear adjustments. They wanted to be able to adjust the wear offset from outside the cell using an external computer. Because these are dedicated machines and they only need to adjust two tools the user interface was pretty easy. The only thing of any interest on the user interface side is that I bound the Max and Min settings of the Numeric Up Down controls to a calculation based on the current comp and the max comp the machine will allow. So that if the current value for X is .7 MM and the maximum allowed on the machine is 1 mm the max for the control will be set to .3 mm.

The application shown in the video below runs on their PC. To handle the remote communication I went with a WCF service hosted on the machine. Here is the contract I used for the WCF service:

Imports System.ComponentModel
Imports System.ServiceModel
Imports System.ServiceModel.Web

<ServiceContract()>
Public Interface IOkuma

<OperationContract()>
 Function GetMachineType() As Gosiger.Utilities.enumMachineType

<OperationContract()>
 Function GetToolData(ToolGroupNumber As Integer, Turret As EnumTurret) As ToolInfo

<OperationContract()>
 Sub AddOffset(OffsetNumber As Integer, Axis As EnumToolWearAxis, Turret As EnumTurret, NewValue As Double)

<OperationContract()>
 Function IsInInch() As Boolean

<OperationContract>
 Sub Close()

End Interface

The GetToolData method returns an object containing information about the tool group such as tool life remaining, current tool in the group etc.

Microsoft has made it much easier to work with WCF in 4.0 by adding default endpoints automatically for you like the HTTP Basic endpoint that I’m using here.  I call this sub everytime before I make a function call to make sure the channel is open and connected based on example found on SO.  The “BasicHttpBinding_IOkuma”  was automatically added to the app.config when I add the service reference.  I only had to reference it by name.

Private Sub CreateChannel()
 If _Okuma IsNot Nothing Then
 If DirectCast(_Okuma, ICommunicationObject).State = CommunicationState.Opened Then
 Return
 End If
 End If

Dim channel__1 = New OkumaServiceRef.OkumaClient("BasicHttpBinding_IOkuma", My.Settings.ConnectionAddress) '"http://192.198.191.144:8080/latheAPI"

AddHandler DirectCast(channel__1, ICommunicationObject).Faulted, Sub(s, e) DirectCast(_Okuma, ICommunicationObject).Abort()

Try
 DirectCast(channel__1, ICommunicationObject).Open()
 Catch generatedExceptionName As EndpointNotFoundException
 ' don't worry
 Return
 End Try

_Okuma = channel__1

End Sub

Here is a short video to show how the application works.

I’ve been playing around with the idea of using Gmail as an easy way of sending commands or getting information from a machine.  This is the ultimate “lazy man” solution.  I wrote this application to monitor the contents of the subject line of emails sent to a Gmail account that I made specifically for a machine.  When the application sees an email with subject matching one of my keywords it processes the message and sends the appropriate reply.

You could use this application to monitor a variable number or a parts counter.  If you have a machine with a barfeeder you could send an email to set a variable which stops the loop or set the number of parts to make.  You could even have your program waiting in a loop and command it to run a certain part by setting a common variable value.  You can ask it to send you an email if the machine alarms out or when the cycle is complete.  If you have any suggestions for commands put them in the comments.

The “window” for the application is a little button that sits under the vertical function keys.  Pushing the button will toggle monitoring mode on/off.  Pushing and holding the button will bring the settings window up.  Double clicking the button with close the application.

If you want to run this on your Okuma machine you will need to have API V1.15.0 and .NET Framework 4.

Get the source code here: Gosiger GRC

Here is is a sample email message:

Over the last few weekends I’ve been working on a remote offset application.  The idea is to give an operator an easy way of getting an offset to one or more machines from a central location.  Sometimes doing this requires shutting down automation or running between machines.

The behind the scenes communication is really simple.  The idea came from Jimi who suggested using the File Watcher to monitor a folder a CSV file which contains the data.  To keep it simple he suggested just writing the data in the file to common variables and letting the cutting program decide how to apply the offsets.

I decided to use the JSON format instead of CSV.  So the Remote Offset Server runs on any PC outside the cell and the Offset Client runs on the machine.  The server generates a JSON formatted text file based on the users input and drops into a folder that is monitored by the client app running on the machine.  The client app then reads the file and sends the values to the appropriate variables.  I used Json.Net by Newtonsoft to serialize and deserialize the “adjustment” object.  Each adjustment has a unique ID which is logged at both ends.

Here is a screen capture of the application in action.  The window to the left is the server that would be running on a PC.  The window on the right is the client application that would run on the Okuma P control.

Here is a look at the probing application we’re working on.  The app uses the probing macros written by Gosiger Applications Engineer Paul VanCamp.  The concept for the application was also based on Paul’s original probing app written in VB.NET windows forms.  Paul and I added some probing cycles and gave it face lift using WPF.  This was originally part of a bigger custom HMI that we developed for a customer.  We decided to take just the probing part of the application and make it a stand-alone application.

The idea is to make it easy for an operator to setup or inspect a part by allowing him to use a graphical interface instead of having to remember all of the input variables that are required for a probing cycle.  The operator only needs to manually jog the probe close to the surface, fill in the blanks and run the cycle.

We’re planning to ship this application with every machine that has a probe by the end of the summer.

For years I’ve been wanting to create a more user friendly I/O monitor application for the P control.  If you’ve ever  tried to quickly look up a signal on a machine you know what a  pain in the neck it can be.  If you don’t happen to have all of the signals memorized you either have to page through the slaves in physical mode or go find the electrical drawing.  Oh, and don’t forget the search is case-sensitive.  So I decided to make my own just for fun.

My goals for the project are that the user can:

• Search either comment or symbol name
• Search non case-sensitive
• Use it on any Okuma machine or off machine
• Carry it around on a memory stick (no installer)
• Add signals to a watch list
• Sort signals by type
• Save watch lists to an XML file (Chris Heeg’s idea)

Getting the signal Info

There is no way to get the names of all of the signals on the Okuma through the API. there is also no way to read the status of an I/O signal by the symbol name.  A generic set of I/O names won’t work because the mapping of the I/O signal addresses change from model to model.  The around this problem is to use the IOTXTOUT.EXE tool to generate a CSV file.

This command will generate a CSV file with this format:

Date=20120928,Time=080854
ID=IX Logical Input
Addr,Bit,A,Msk,St,Label,Comment
0,0,,,0,ipNCST,NC start ..PB
0,1,,,1,ipNTS_B,NC feed hold/ .PB

As you can see the top of the file contains a timestamp followed by a section header, in this case inputs, followed by the column headers.  The columns we care about are the Address(Addr), Bit, Logical/Physical(A) , Label and comment

Parsing the data

Now that I had the data I wanted to find a way to quickly search this file to pull out the information needed.  There are a few different ways I could have gone with this and I’m not sure this is the best but I decided to use Matt Perdeck’s cool LinqToCSV libray.  This allowed me to write LINQ queries over the data in the CSV file.

Before I could use LINQ to query the data I had do clean up the CSV file.  The first problem is that the file generated by the IOTXTOUT tool prints out a line for every potential I/O point not just the ones which are mapped. As a result at least 50% of the lines contain no useful data. As this will inevitably slow down any query I wanted to remove all of the blank data lines.  The other problem is that the tool generates section titles and headers for each type of I/O so I also had to remove them as well.  The LinqToCsv has no idea what to do with column headers which show up in the middle of the data.

<CsvColumn(Name:=”Addr”, FieldIndex:=1, canBeNull:=True)>

    Public Property Address As Integer?

…

I then created a CsvFileDescription which describes the CSV file:

 _inputFileDescription = New CsvFileDescription() With {.SeparatorChar = “,”, .FirstLineHasColumnNames = False, .EnforceCsvColumnAttribute = True}

With this in place I was able to read the data by passing in a path to the clean CSV file along with my description object

rtnIoList = _OkIoContext.Read(Of OkumaIOPointInfo)(FilePath, _inputFileDescription)

Now after all this the the end result is that we can do queries like this on our data:

Dim InputsThatContainDoor = From iop In _IOList
Where iop.Comment.Contains(“Door”) AndAlso iop.IOType = 0
Select iop

Making it machine type neutral

To make the application machine type neutral, meaning it can run on any Okuma machine, I implemented the factory pattern I described in previous post.

The interface is very simple.  It describes a function to get the status of an I/O signal, a function to get the machine type and a sub to handle closing.

Public Interface Iokuma
Function GetIoBitStatus(Signal As OkumaIOPointInfo) As Boolean
Function GetMachineType() As enumMachineType
Sub close()
End Interface

I have 3 classes which implement the IOkuma interface.  One for  a mill, one for a lathe and the other for off machine simulation.  This allows me to program against the IOkuma interface on the MainWindow rather than creating a new Window for each of the three scenarios.

WPF Databinding

The only other somewhat interesting about the application is how I was able to use WPF’s Databinding to display the I/O status.

In Visual Studio 2010 if you add an “Object” data source and point it at a class in your project you end up with a CollectionViewSource in the Window.Resources.  I bound the ItemsSource of a ListBox to this collection.  I then used a User Control (uc_IoPoint) to display the name and the status of the signal in the Listbox.

<ListBox x:Name=”lbIO” HorizontalAlignment=”Left” Width=”393.183″ ItemsSource=”{Binding}” Margin=”0,0,10,5″ VirtualizingStackPanel.IsVirtualizing=”True” SelectionMode=”Multiple”>
<ListBox.ItemTemplate>
<DataTemplate>
<StackPanel>
<local:uc_IoPoint Margin=”5″/>
</StackPanel>
</DataTemplate>
</ListBox.ItemTemplate>
</ListBox>

Making it portable

I attempted to use the Costura VS addin to embedded all of the required Dll’s into the exe.  For some reason the Okuma Dll’s refuse to be loaded via stream.  If anyone has any insight on this I would be very grateful ( test project).  I would eventually like to get it down to a single file executable.  For now it is the Okuma IO.exe and the Okuma DLL files.

Required to run on machine

• .NET Framework 3.5
• API Version =>1.9.1

The source code for this project can be downloaded here.