Problem running Renishaw TS27R setter macro

[wrench]

I have a new to me Mitsubishi Meldas M3 based machining center to which I want to add a Renishaw TS27R tool setter. I got the CD to generate the macros and ran that. Fundamentally, the output is a collection of 10 or so macros, one of which is configures all of the common variables. The start of this macro is as follows:

%
O9750(REN_SETTING)
(F-4012-0584-0Y)
G90G80G40G0
#129=1(MM)
IF[#4006EQ21]GOTO10
IF[#4006EQ71]GOTO10
#129=1/25.4(INCH)
()
()
()
N10
#101=8.(FIRST*PROBE*TOUCH)
#127=197.(RAPIDTRAVERSE)
#110=0.394(TOOLS*ABOVE*ROTATE)
#111=3.937(CUTTER*DIA*ABOVE*SINGLE*SIDE)
#138=0.(LONG*TOOL)
#139=0.(SHORT*TOOL)
#124=79.(SEARCH*FEEDRATE)
#113=3.937(INITAL*CLEARANCE)
#114=0.394(SECONDARY*CLEARANCE*Z)
#125=0.2(RADIAL*CLEARANCE*)
#117=0.2(DEFAULT*OVERTRAVEL)
#145=0.0002(ZONECHK)
#105=0.012(BACK*OFF)
()
#102=1.(OFFSET*TYPE)
#120=520(BASENUMBER)
#104=-1.(PROBE*ORIENT)
#103=1.(SINGLE*SIDED*SELECTION)
()

Unfortunately, I cannot get the Renishaw macros to run because I end up with a format error. I single stepped through the macro and found that the error (#33) is on the line that is fourth from the botton: #120=520(BASENUMBER)

I looked at this for a bit and realized that the only difference between it and the preceding lines was the fact that 520 did not have a decimal point on it, so I added it and ran again. Lo and behold, the macro got through this line but failed on another one later on. But this puzzles me for several reasons. First, why would Renishaw create a product specific for the Meldas/Fanuc type controls that produces content that cannot be run... That just doesn't ring true... Second, although not a definitive test, I hand load common variable 120 with 520 (no decimal point) and the value is taken. Finally, and perhaps most curious, I wrote a small MDI program that exercised the common variable:

#120=300
#120=10
#120=150
#120=520

This runs without any error. I also tried changing the program number to something that wasn't in protected memory (in this case, O111) but the format error still shows up (frankly, what I expected).

So, I'm in a conundrum. I'd like to understand what is *different* about the program versus my tests. Maybe this is a parameter setting someplace? If so, I didn't see anything that looked like it was related to this type of behavior in the manuals (granted, the manuals are not very good though...). I've also searched the web for people with similar problems, but that hasn't netted any decent results...

Does anyone have ideas?

Thanks!

Full Disclosure: This is a new machine to me. My previous machines were all conversational, so my experience with G code is limited. Further, this is the first time I have setup (or will have used) a Renishaw probe. Again, however, the problem I'm seeing now is stock out of Renishaw's macro generation program, and there are no options in that process that look like they'll address the issue.

I check the manual and couldn't find anything to i

 

[wrench]

I have an update, although it just adds a little more mystery into the equation.... Consider the following trimmed down macro:

%
O9750(REN_SETTING)
(F-4012-0584-0Y)
G90G80G40G0
#129=1(MM)
IF[#4006EQ21]GOTO10
IF[#4006EQ71]GOTO10
#129=1/25.4(INCH)
()
()
()
N10
#101=8.(FIRST*PROBE*TOUCH)
#127=197.(RAPIDTRAVERSE)
#110=0.394(TOOLS*ABOVE*ROTATE)
#111=3.937(CUTTER*DIA*ABOVE*SINGLE*SIDE)
#138=0.(LONG*TOOL)
#139=0.(SHORT*TOOL)
#124=79.(SEARCH*FEEDRATE)
#113=3.937(INITAL*CLEARANCE)
#114=0.394(SECONDARY*CLEARANCE*Z)
#125=0.2(RADIAL*CLEARANCE*)
#117=0.2(DEFAULT*OVERTRAVEL)
#145=0.0002(ZONECHK)
#105=0.012(BACK*OFF)
()
#102=1.(OFFSET*TYPE)
#120=520(BASENUMBER)
#104=-1.(PROBE*ORIENT)
#103=1.(SINGLE*SIDED*SELECTION)
M99
%

Now, that one fails with the format error (33). However, I can make it work by changing:
#102=1.(OFFSET*TYPE)
to
#102=1(OFFSET*TYPE)

A simple presence of the '.' on the preceding line controls whether or not the macro can successfully run... Is there something illegal about having the decimal there?

 

[sakis]

You may have a machine parameter deciding that a value of 1 with no decimal is interpreted as .0001 instead of 1.0000

 

[wrench]

Thank you for the response. Your thought is interesting, but I think I'm OK there. "1.000" is the desired value, and "1." is the same thing. Also, I didn't really do a good job in the follow-up thread. There are actually two ways I can fix the problem. They are:

change "#102=1.(OFFSET*TYPE)" to "#102=1(OFFSET*TYPE)" (so, no decimal point) **OR**
change "#120=520(BASENUMBER)" to "#120=520.(BASENUMBER)" (adding the decimal point)

Either of these solutions will actually allow me to continue. It is worth noting that the first version still leads to #120 being set to 520.0000 in the common variable when I'm done. So, although there might be a parameter that allows for a change of behavior when you don't have a decimal point, I think the value is already set correctly (because the 520 is loaded correctly and it does not have a decimal point).

 

[PROBE]

I have a new to me Mitsubishi Meldas M3 based machining center to which I want to add a Renishaw TS27R tool setter. I got the CD to generate the macros and ran that. Fundamentally, the output is a collection of 10 or so macros, one of which is configures all of the common variables. The start of this macro is as follows:

%
O9750(REN_SETTING)
(F-4012-0584-0Y)
G90G80G40G0
#129=1(MM)
IF[#4006EQ21]GOTO10
IF[#4006EQ71]GOTO10
#129=1/25.4(INCH)
()
()
()
N10
#101=8.(FIRST*PROBE*TOUCH)
#127=197.(RAPIDTRAVERSE)
#110=0.394(TOOLS*ABOVE*ROTATE)
#111=3.937(CUTTER*DIA*ABOVE*SINGLE*SIDE)
#138=0.(LONG*TOOL)
#139=0.(SHORT*TOOL)
#124=79.(SEARCH*FEEDRATE)
#113=3.937(INITAL*CLEARANCE)
#114=0.394(SECONDARY*CLEARANCE*Z)
#125=0.2(RADIAL*CLEARANCE*)
#117=0.2(DEFAULT*OVERTRAVEL)
#145=0.0002(ZONECHK)
#105=0.012(BACK*OFF)
()
#102=1.(OFFSET*TYPE)
#120=520(BASENUMBER)
#104=-1.(PROBE*ORIENT)
#103=1.(SINGLE*SIDED*SELECTION)
()

Unfortunately, I cannot get the Renishaw macros to run because I end up with a format error. I single stepped through the macro and found that the error (#33) is on the line that is fourth from the botton: #120=520(BASENUMBER)

I looked at this for a bit and realized that the only difference between it and the preceding lines was the fact that 520 did not have a decimal point on it, so I added it and ran again. Lo and behold, the macro got through this line but failed on another one later on. But this puzzles me for several reasons. First, why would Renishaw create a product specific for the Meldas/Fanuc type controls that produces content that cannot be run... That just doesn't ring true... Second, although not a definitive test, I hand load common variable 120 with 520 (no decimal point) and the value is taken. Finally, and perhaps most curious, I wrote a small MDI program that exercised the common variable:

#120=300
#120=10
#120=150
#120=520

This runs without any error. I also tried changing the program number to something that wasn't in protected memory (in this case, O111) but the format error still shows up (frankly, what I expected).

So, I'm in a conundrum. I'd like to understand what is *different* about the program versus my tests. Maybe this is a parameter setting someplace? If so, I didn't see anything that looked like it was related to this type of behavior in the manuals (granted, the manuals are not very good though...). I've also searched the web for people with similar problems, but that hasn't netted any decent results...

Does anyone have ideas?

Thanks!

Full Disclosure: This is a new machine to me. My previous machines were all conversational, so my experience with G code is limited. Further, this is the first time I have setup (or will have used) a Renishaw probe. Again, however, the problem I'm seeing now is stock out of Renishaw's macro generation program, and there are no options in that process that look like they'll address the issue.

I check the manual and couldn't find anything to i

1. You did not mention the exact meaning of the alarm 33. I do not have the access to M3 list of alarms, but in other MELDAS controls it means FORMAT ERROR. I believe it is standard in all Meldas controls. The erroneous syntax of your command line is causing the problem. Let us know the syntax you are using to allow us to elaborate the problem.

2. Due to the "look forward" option of the control, the fact that the alarm is raised when the block #120=520 is executed, is meaningless. By the way this syntax is OK. In order to ensure this, check the content of variable #120 once the alarm is raised. It is 520.

Stefan
Cogito Ergo Sum

 

[wrench]

Hi Stefan,
Thank you for the response.... Sorry, I thought I inferred the error as being a format error, but perhaps I missed that. I've been looking at this until I'm blue (or red) in the face, so some of the thoughts in my mind might not be adequately expressed when I posted. So, let me be more explicit there... Yes, the Meldas family, as best as I can tell, shares a *very* common structure which includes error codes. The M3 control documentation shows error #33 as being a Format Error. The suggestion on what causes the error, however, is not great nor is the suggestion on how to resolve the issue. As I recall, it simply says something like "fix the program".

Clearly the macro processor in the machine believes that there is an error with the program, but I can't see it. I have pared the program down to the point where it causes an error in an effort to have others review it. My next task will be to remove lines above the problem area until, I hope, I can get it down to one or two lines. However, let me comment on #2 of your post explicitly... I actually checked common variable #120 when I first ran into the issue and it was *not* loaded with 520. However, when I changed the line from "#120=520" to "#120=520." (added a decimal point), then I *did* see 520 in common var 120.

In subsequent investigations, I discovered that I could keep the original setting syntax of 120 (being set to 520) if I changed the preceding line from "#102=1." to "#102=1" (in this case, REMOVING the decimal point.

I haven't seen, but certainly could have missed, any documentation in the manuals relating to the presence (or lack thereof) of a decimal point in a common variable set value.

Again, thank you for your post. I'm eager to get past this problem as it is frustrating. I can hand edit the macros, I suppose, but I'd rather understand the underlying cause (what is giving the syntax error). If it appears as though any of my comments are brusque, that it purely unintentional. I'm trying to be concise in an effort to minimize any ambiguity; I really do appreciate your help!

 

[wrench]

OK, this is getting even stranger.... I was trying to pare down the code above the line that appears to give the error in an effort to narrow the problem further. What I found was bewildering. I found that pretty much any edit seemed to make it work. I finally decided to make a *completely* useless edit; in this case it was to remove the "()" comment line (line #9, for instance). The macro worked! I added back the comment and the macro fails with the 33 (format error). If I *add* a fourth comment, then the macro works again!

What the heck... I am just plain baffled.

 

[wrench]

I wanted to give an update to this.... Although I managed to get through the settings macro with the above hack, I was worried if I would have issues later on. Let's face it, after all... Removing a *comment line* is absolutely not a legitimate fix! And, sure enough, I ran into a boatload of issues with the other Renishaw macros.

In the end, I found someone else that had a Mitsubishi M3 based machine, and I had him run the macro setup, etc. They worked fine. This made me suspect the firmware. Mine version is 261W000-A3 on the firmware and 261W610-A1 for the MACRO (both are embedded into 12 EPROMs which, of course, are soldered to the board!). The other gentleman's version were 261W000-C0 and 261W610-B1.

I did try to go through the whole restarting the machine from scratch and reloading *everything*, but this didn't seem to matter. Fortunately, I was eventually able to find another firmware cartridge with the newer version (after trying an even older, A2, version without any luck) and BINGO! Suddenly I was able to get through the macros without errors.

So, if you are running into problems, let me know. I plan on *desoldering* all of the EPROMs eventually so that I can archive the EPROMs. My greatest fear on all this old iron is lost bits within EPROMs because technically all of these EPROMs are years beyond their designed for retention life....