There was one instance I saw on a really old Okuma lathe that had an electrical short in the feedrate knob. It would cause the machine to take off in random movements when the feedrate knob was in the exact right position of the short. They replaced the panel and it fixed the issue.

Here is a more recent summary including the Multus U3000 we added in August. The Multus B250, or the baby Multus, as we call it, only runs about 6-7 part numbers of our higher volume parts. That thing only stops running to change chuck jaws and robot jaws once a day or so. The Multus U3000 only has a dozen proven programs so far and we are still working out chips issues with the lower turret that keep us from running more than 8 hours unattended. We have had a few successful runs of 12-16 hours unattended but we have also had a few that ended up with a couple of broken tools and a tray of scrap parts.

So in 5 years when Haas owns more of the market than Fanuc will you say they have the best control? Biggest market share doesn't automatically make something the best.

Getting a Fanuc machine in an Okuma house is like trading your smart phone for flip phone. Why would you want to.

LOL, Are you Pelosi? You have to buy it before we tell you if it can do it or not. How is sharing standard functions that a control can do comparable to sharing the Anarchists CookBook. I'm calling BS. Put up or admit Okuma builds a better control.

Care to share. We have looked at both Nakamura and Matsuura as an alternative to Okuma but when I ask their engineers for details on I can do the things I do now in our OSP I get no answers. Example; The code below will check to see if the feedrate and spindle speed knobs are at 100% and alarm if they are not. ( FEEDRATE OVERRIDE CHECK ) IF[VORD[0019]NE 1]NALM1 GOTO NALM2 NALM1 VUACM[1]='FEED NOT 100 %' VDOUT[992]=1234 NALM2 ( SPINDLE OVERRIDE CHECK ) IF[VORD[038C]NE 1]NALM3 GOTO NALM4 NALM3 VUACM[1]='SPEED NOT 100 %' VDOUT[992]=1234

We check the I/O for chuck clamp signals in our lathe programs to see if sub/main spindle is clamped for each toolpath. If the chuck is not clamped it has a GOTO to skip that toolpath. It allows us have one program that can run main spindle only, sub spindle only, or both simultaneously regardless of which turret is doing the machining. In our twin turret machines It simplifies robot programming because the robot does not have to switch programs for first piece, middle pieces, and last piece. We also have safety checks in our machine to make sure coolant buttons are not turned off/etc. It also comes in real handy with OSP TOOL RESTART function. This function gives you a graphical list of restart points to select form for safe restart. When activated, if a chuck is not clamped on a part it doesn't give you the toolpaths for that spindle as restart points. I actually don't do the parsing of a text file anymore because I made apps in C# using the API to write the data from the PLC into the controls common variables. They also write data out to the PLC as well, like machine status, door open/closed, unlocked, etc. However the READ/WRITE/GET/PUT Okuma function allows you to parse a text file as a string and read specific characters and write them to common variables for calculation. It is one of the common ways people read in gauging data from a CMM/gauge output file to update tool/work offsets in an automated cell.

OSP5000 = 1981 That's almost 40 years. For me the power, user friendliness, and flexibility of OSP are far greater. Two things I do routinely are check status of machine I/O from NC code, and parse a text file to read in specific data. I have asked many a Fanuc "guru" if those things could be done and gotten no as the answer. The other big one for me is the open API in the OSP control. Every single one of our machines has custom apps that communicate data bi-directionally from the Okuma control to external PLCs and Robots.

Fanuc trying to copy OSP again by adding named variables. OKUMA OSP has had named variables for decades.

Below is code for Multus U with lower turret. Note: in the output file the G13/G14 will be output with () around them. It is a limitation of the READ/WRITE that won't allow it to output a G13/G14, the workaround is to output them with (). Just delete the () when you paste the offset code into your program.

Typically a singularity occurs when the machine is in a position that it interprets an infinite or multiple number of solutions to a command. I have seen it happen before on a table/head machine where the head movement was crossing the exact centerline of the table axis in an arc move. If you have your work offset set at the exact center of an axis it can happen. If it does try moving the work offset of center by a tiny amount (X.0001, Y.0001). In 6 axis robot it often occurs when you end up with axis 4 and 6 inline with each other or a move that will pass through them being inline. Most robots have programming tools to allow the robot to slightly deviate path to avoid the singularity.

That is the normal selling objection when selling that type of machine. When I worked for a Hydromat distributor a lot of companies would see the quote and say why wouldn't I just buy x number of robodrills or other small machine. There are advantages to multiple machines. They allow for down time without losing all production, as well as the ability to run different parts when production needs change.

What is the material? Even the best thermal comp machines don't account for coolant temp and material temp. I have seen aluminum parts change size and go out of tolerance from adding coolant to the machine.

I got ya! I know in the Hydromat systems I have seen they would have a robot loading and unload from outside the machine.

At the 2 min mark they show the parts being indexed between spindles.