P200 Apps
How many of you are using apps on your Okuma P200 and up machines?
What are you using?
How do you like it?
What would you like to see that you don't have?
Similar Threads:
Absolutely nobody is using apps for their Okuma?!?
60 some people have read this post, and none replied.
Is this a question of knowing what an app is, not having new enough equipment to utilize them, or simply that you see no need or area that could be improved on using one?
I read it, ..... I haven't used an Okuma for 2 years... so what would you expect to be said...so here's my 2¢Originally Posted by tea hole
IMO... I'd be cautious about putting anything other than what the "tech's" supplied or recommend to be run on the machine ( software wise )
---it's a money maker and cannot afford to be offline due to software corruption ( either web or operator based )
Well to me, a program is a set of instructions laid out in an order, for a computer to interpret, to achieve a particular goal. An application on the other hand, would take user input, to run programs, in a useful manor, based on it's input.
I'm not really aware of any thing I would call a true App in the Okuma world, aside from IGF, and the software that drives the machine its self. No structures I know of even exist that allow a user to input data into a program, with out modifying the program it's self. I know of no suitable way to output instance data back to the user, another thing I would say is a common trend in apps. For example, by a loose definition, I have a probe 'app' for picking a "rail" in an MB-56, (it's posted in a fairly recent thread) but I have no way to ask the user for the required input, he must first modify the program to insert that data. Nor do I have any way to relay him information that might be useful in a well formatted fashion. I can raise an alarm alerting him that the part he is working with is askew, but I can't readily format a string that includes useful information in that alarm message, such as how much it's askew, or where, with out alot of extra coding. In G-Code you have no ability to handle strings, or anything of the sort, things typically seen in application development.
I am a hobbyist iOS developer, I defiantly see the potential to improve the industry at large, by switching to a language that would allow for such constructs, preferably an object oriented language, but i don't see G-Code going away any time soon, and in G-Code, it's not feasible to write true apps, with out writing very lengthy programs, to report back every particular data construct it might encounter. (and then you have a limit on variable declarations as well)
So if there are true apps out there I don't know of them, nor am I on the in&in enough to write them, and out side of the controller, and IGF, I don't know of any true apps, that run on the machine it's self. Every other app I know of in the industry is lives on a PC, and is typically poorly constructed. (like masterCam)
Last edited by iMillJoe; 06-25-2013 at 03:59 AM. Reason: grammer
G-Code, it's not feasible to write true apps
Jeezus Christ! Do You know what you're talking about?
G-code is a common CNC standard for every kind of machines (knitting, sewing, printers, plotters, drilling machines, painting, tissue cutting) for many years. Any shape, any mechanical movement could be described in G-code.
Please, develop your own axis control system, we will convert to G-code in case.
To interface with the OKUMA volante system you would need to use a purpose written API such as the Okuma THINC offering. I can see some advantages but I can also see a lot of negatives too.
Okuma's excel machining is a useful tool for family's of parts, Excel can be used to drive the CAD model as well as the Gcode program to make each configuration of the part. VBA can also be used from the excel file, although there are not really that many uses on a machine controller, however this solution does offer the best bang for your buck in my opinion
I said it's not feasible to write true apps in G-Code, not that its an unpopular language, with out any good use. Many things are missing from G-Code, like the ability to ask for operator input, or give the operator information specific to the data conditions at hand. As I said, you have no strings or string formatters. The concept of arrays does exist in Okuma land, but I don't know if I can declare one, even if I can, I'm probably limited to 250 or so items in the array. The looping structures used in most modern languages are completely absent. G-Code is good for programs, not applications. It's more a matter of semantics than anything. Out side of daemons, apps generally have a user interface, you don't have that ability, in a true sense, in G-Code.
budgieW brought up THINC, I had seen it advertised, but never looked into it until now. With thinc you CAN build apps. They can have a user interface, they are not necessarily seeking an end condition. You can write 'programs' that function on the higher lever that 'apps' semantically occupy. It takes Okuma API, a copy of Visual Studios, a working knowledge of the .NET platform, and a Okuma machine that can run the output, (none of which I know to have) but it seems it can be done. (Using C# (an object oriented programming language), and visual basic)
It may look like gibberish to you, but I'd love to be able to send the machine controller an Object Oriented message like this, (in Objective-C)
(infixed notation is sexy)Code:-(void) roughTurnBezierPath:( a bezier path )path inWork:( the work piece )work withTool:( a tool )tool;
rather than the 1000 lines of code that could take in G-Code, to describe the path with the same accuracy. G-Code is 50 or so years old, it lacks many of the features you might want when writing a program (or app), appealing to its history, or popularity, does not validate anything. The computers it was designed for had less power than my 15 year old graphics calculator. We have come along way since then, it's time the language we use reflect that.
Definitelly, you don't know what you're talking about.
G-code is not a programming language for applications. It's list of coordinates (verstors) presented as text. open, easy, reliable.
There is a lot of space for user input, for dialog. It's not described in G-code standard. Machinebuilders use different approaches for operator dialog, there is no single solution for that.
You don't know a G-code. You mean CAM software, which compiles curves into small pieces of straight lines. G-code itself is compact enough - axis name and number, represents vector. You can create very compact and easy understandable part program using variables and canned cycles.rather than the 1000 lines of code that could take in G-Code
Take a closer look to G-code, change your opinion.
it's not for "apps". It is simple transmission of tool movement vector with additional instructions: tool change, coordinate system transformation and so on.it lacks many of the features you might want when writing a program
It looks a bit similar to programming, because you can translate simple flow charts to G-code in many cases. Loops, conditinal jumps and so on.
A youris void first of all. We need material output, chips.-(void) roughTurnBezierPatha bezier path )path inWork
And next, this line must be converted to machine instructions anyway. Work point movement can't be described as: "order: make me a skull"
Last edited by Algirdas; 06-26-2013 at 09:09 AM.
Hey thats what I was saying.
We can debate on the easily readable.It's list of coordinates (verstors) presented as text. open, easy, reliable.
I think you mean raster, not vector. You still cant define a curve very well, or accurately, without many lines of code, even within a canned cycle.You don't know a G-code. You mean CAM software, which compiles curves into small pieces of straight lines. G-code itself is compact enough - axis name and number, represents vector. You can create very compact and easy understandable part program using variables and canned cycles.
Thats what I said.it's not for "apps".
Well it IS programing. It just lacks modern structures, like the ability to define what to do, if a condition is true or false, locally, rather than jumping to a arbitrarily placed line number anywhere in the program.It is simple transmission of tool movement vector with additional instructions: tool change, coordinate system transformation and so on.
It looks a bit similar to programming, because you can translate simple flow charts to G-code in many cases. Loops, conditinal jumps and so on.
The line is -(void) because it returns nothing. Perhaps it should be -(BOOL) and return a bool if that command will work, but it's an instruction to the machine, to preform an action nonetheless. Yes it needs to be turned into machine (servo) instructions anyway, but like any machine controller will do a better job cutting a circle, when using a G2 or G3, than it will the the 100 or so lines Cam software might put out, it can follow a curve much more accurately, if the machines controller is doing the math, rather than cam software. I'm not saying "machine, make skull" I'm saying machine, you have this work piece, you ask it it's current condition, please remove material along this path, using this tool. Because the tool and work in my example would be 'objects' the machine controller can then ask them questions or access a database, to decide depth of cut, feed, speed etc. It could even call a longer line of code with in that method body, that is the same thing, with the extra arguments that it had deduced, you could even call that longer line of code skipping the part where it figures things out, letting you set those parameters yourself.As your [line of code] is void first of all. We need material output, chips.
And next, this line must be converted to machine instructions anyway. Work point movement can't be described as: "order: make me a skull"
for example, It would look a bit different when you call those, than it looks when it's declared, much more english like, but it reads more like English, than G somethings, with arbitrary parameters following it.Code:-(void) roughTurnBezierPath:( a bezier path )path inWork:( the work piece )work withTool:( a tool )tool usingDepthOfCut:(depth of cut) feed:(feed per rev)feed speed:(spindle speed) speed;
Ok, getting off topic here.
If you don't know what kind of apps are out ther or available, then fine, but I don't really think you understand what I'm talking about.
Since I'm on my iPad right now, the best I can do is reference this: THINC Apps
Scanning a barcode to load a program, the variable pic app to display a jpeg or bmp image when a common Variable goes to a value, chipblasters interface, there are some out there, and in order to get more out there, more useful apps, out there, people need know what people want. Getting the API for the Okuma isn't difficult, and the rest is basic computer programming.
I don't want to get into an argument with you as to weather a "true" app can be utilized. I'm telling you it's happening.
Since its happening, (if you have a pre-p200 control, you have no idea what I'm talking about) companies are developing apps to highlight their capabilities in software or hardware, but not to help the consumer.
What do those who know what an Okuma app is, do with them, or what would you like to do?
Sky's the limit.
Oh, and if you think anyone is trying to write an app using g code, then you don't have any ideal what I'm talking about, respectfully. I would be glad to share and educate you on an individual basis, but this thread is for sharing what is being done, not questioning how its being done, that can be a thread you start.
We have 2 machines with P200 controllers, but I am unsure as to wether the thinc package has been installed on them, I had seen thinc advertised, but not explained. I would like to thank you for bringing this post up, It's looking like I may now have a way do things with the machines I have only dreamed about for years. I have alot of things I'm going to need to learn, like the differences between the X-Code IDE I use, and Visual Studios not to mention programming in C#. It seems I'm going to have to buy a copy of windows, and track down of copy of Okuma's API for this, but I am excited. I can imagine using thinc to drive the probe program library I have built, I am eager to see them with a clean user interface, on the nice touch screen that comes with the P200 controllers. I have tried to make my programs as app like as possible for years, and with thinc, it's looking like I might be able to cross that bridge.
Unfortunately, I don't know of anyone running any of the existing apps for thinc, so I can't comment on them. But I can't wait to dig in and explore the possibilities.
If you have a p200, then you have a thinc.
To demonstrate that, press ctrl and cancel (///) at the same time. It will bring up your windows start menu. In the lower right corner, by the clock, there will be the system tray, if you look there, there may be a white "thought bubble" looking icon with the letters API. If its there,then your API is there. Current version is 1.13.0 if I'm not mistaken. Sometimes I get things backwards, I skim over them so much all I see now is the version. I have a couple simple apps, and they came with the source code, so that'd be enough to get you started if you feel the need.
I have just started toying with the Thinc API. So far I have an app that writes the windows system time and date to variables for machines that do not have the VTIME variable. I am working on a specific app that monitors a button on the control and pops-up a warning page if certain criteria are met when the button is pushed. I also have an idea for an app that is triggered by a variable to turn/off on a usb relay. I also want to make an app that adds visual style conversational interface to be used with Renishaw Inspections plus macros. However, they all take time and my VB.NET coding skills are entry level.
Finished up a simple B axis offset calculator for horizontal MC this morning.
Is the tombstone dynamic (picture change with the jobs), or is it just for visual reference?
Nice job though, come winter I'm planning on making the icons for the probing app I'm building, but I don't know C# or visual basic, so I might give them to someone who wants to replicate the iPad app they will be for in Okumanees.
Picture is just a reference. I have a macro I've used for years to accomplish the same thing, this is just a simplified GUI.
I created a set of Inspection Plus templates for use on a Haas if you want any help.
YoDoug
Are you willing to share your B axis offset calculator. I could use something like that.
How are you guys starting your apps. Are you going into Windows and starting it manually every time you power ON?
I got our apps guy to get the Picture app to run on Windows Start up but it errored out. It needed the Okuma API software running first. So he put a delay on the picture app starting until the Okuma software was running. So now the Picture app starts automatically and is ready to run without our numpty operators having to press any Windows buttons. Or is there an easier way?
Posting Permissions
Reply with Quote