yes, it is please share control generation ( osp type ), and a macro that you have in mind
Hello everyone. I recently started a new job, and I am working with Okuma VMC's, which I have never used before. I am wondering if it is possible to create your own G and M codes on an Okuma Genos M560-V. At my previous job, I used Haas machines, and it was pretty easy to create your own G and M codes. The Haas manuals call it "Aliasing", and it is a very helpful feature, but I don't know if this is just a Haas thing, or if other brands can do it as well. Any advice would be greatly appreciated. Thanks
Similar Threads:
yes, it is please share control generation ( osp type ), and a macro that you have in mind
we are merely at the start of " Internet of Things / Industrial Revolution 4.0 " era : a mix of AI, plastics, human estrangement, powerful non-state actors ...
Both machines I am using are Okuma Genos M560-V machines. One was manufactured in Nov. 2010, OSP20M/OSP200M. The newer machine was made in Nov.2017, but that's all I know about that one. The controller for the newer one is almost identical to the older one, so I'm assuming it's an updated version of the older controller. I didn't get around to finding the generation or software version, etc. As of right now, I don't have any macros written, only an idea in mind. I would like to simplify the way we measure tool geometry with the table mounted laser. I'm thinking I would like to be able to go to MDI, type in something like "G112 T(tool#) R(tool rad.)", hit cycle start and have the T and R values carry into the programs we already have for touching off tools.
I should probably have clarified this in my last post, but I am trying to find out if I can create my own G&M codes on these machines, and how to do it. Since I'm a new employee at this company, I stay busy getting trained at other, higher priority things, so I don't have time to sit around and read through the manuals at work. That's why I'm trying to learn what I can from home, after hours.
hy chip
1) about soubroutines that target only the controller ( like helix, drilling, facing ) etc : after the code is written, it is possible to register it as a "macro", or leave it inside a" ssb" file, or use a "lib" file that may be automatically loaded into the flash memory when the machine starts ( this last method will consume space from the read-ahead buffer ); onestly, i don't like macros, because i spent too much time near the controller registering them, so i simply write my codes inside a ssb file, and i put them inside the MD1 folder, and i don't worry about registering them; there is syntax a difference :
... macro : G*** P( value sent to the macro )
... ssb : CALL O*** LV01=( value sent to the ssb )
* yes, the 2nd one is longer, but i like it
"macro" , "ssb", "lib" : these are official methods i can deliver also custom methods, that target same result, but with less input time ( something like next level i-map )
2) about soubroutines that target optional specification, with hardware <> Okuma, but Okuma compatible ( tool senzors, 4-5 axis, automation ) :
... if this option is not common, you may need specialized help, and i don't have experience with laser senzors
... if this option is common ( like simple senzors, or Nikken rotaries with Okuma servos ) : you have a bit more chances to receive an answer
kindly
we are merely at the start of " Internet of Things / Industrial Revolution 4.0 " era : a mix of AI, plastics, human estrangement, powerful non-state actors ...
hello again, a while ago i have received attached guide about G&M registration i hope you find it usefull ...
i don't use it, because the file has to be located inside MD1 folder, so whatever content it has, i preffer to call it directly, and not through a G/M assignment, which also requires *.lib extensions, and *.lib will steal space from the read-ahead
i don't see a big difference between M201 and CALL OMCOD
the only way i would use a G/M macro would be if the file could be stored in a place <> MD1, and i would be able to call it from a *.min or a *.ssb, and not through a *.sdf, and also i would call that soubrouinte many times from programs, so to justify the buffer-size reduction
if you look to call it only from MDI, i recomend the *.ssb extension can you share your actual codes for the tool senzor, and how you wanna change them ? i may help you create the ssb file / kindly !
we are merely at the start of " Internet of Things / Industrial Revolution 4.0 " era : a mix of AI, plastics, human estrangement, powerful non-state actors ...