Brother C00 - Running registered G/M codes in MDI

mutiny · Jun 19, 2021

To start, I'm on Brother CNC-C00 version 11.001 (2018 Speedio S1000X1).

I'm trying to improve some setup workflows by moving certain tool and part probing routines into MDI. According to the manuals, this should be possible, but I just can't get it figured out. I feel like I've tried every combination of parameters at this point.

I know that gkoenig has tried to figure this out in the past, and he's mentioned in past threads that there was a bug in the C00 control that prevented it from working. Maybe V11 has this issue?

Here's what I want to do:

I have a UTIL directory that contains various utilities. I have programs O0001-O0021 in there containing essentially the following:

Code:

(SWITCH TO TOOL CURRENTLY IN POT 1 AND MEASURE)
T[#3701] M6
P8026 M98

I want to get this into the MDI with something like

Code:

M600 A1

which would be registered to a program that looks like this:

Code:

T[3700 + #1] M6
P8026 M98

Here's what I've tried:

All the parameters I've changed have been in the Data Bank -> G/M code macro section. Here's my understanding of the parameters:

G code macro program folder / M code macro program folder - These are both set to UTIL. All subprograms/macros are also in that directory.
Macro program call control type - This is set to 1 (Type 2), which I believe means that M code macros will execute in a G code macro and vice versa.
System G/M code calling during MDI operation - I believe this is the parameter that essentially says "ya I want to use this in MDI", and I've set it to 1 (Yes).
On the actual G/M code registration pages (I've tried both) the parameters are pretty straight forward except for Call Method for G-codes, but for that it should be 0 (Type 1) which is equivalent to G65 instead of G66.

With the settings above, I get error SM4063 Macro program call not possible. The description seems relevant, but I'm confused about how it applies here:

1. The macro program was called by the G code or M code in MDI.
2. After the G code macro call is executed, when the <Call type> for the G/M code is set to <1: Type 2>, the macro program is called by the G code by the time the G67 command is executed.

I'm getting this error regardless of registering the macro to a G code with Type 0, or an M code that can't specify the type at all (and is implicitly equivalent to Type 0).

---

Has anyone gotten this to work or can someone point out mistakes I'm making above?

Thanks!

gkoenig · Jun 19, 2021

The G/M Code in MDI function simply does not work. The feature parameters and setup options have been in the C-00 since V7 of the firmware (or even earlier, but at least that far back), and nobody has gotten it to function. Brother knows about this (both in the US and Japan) and there is no word on when it will work.

I get the West Coast techs to always send me the latest/greatest firmware, primarily because I want this to be fixed. Use any system long/deep enough and you are going to come up with a set of gripes. The limited MDI would be on the gripe list, but the lack of custom G/M codes in the MDI would be literally at the top of my list of Speedio changes. All the more infuriating because Brother clearly recognizes this is important (hence all the UI stuff to enable custom G/M codes in MDI), but that they don't bother to hook it up is totally crazymaking.

mutiny · Jun 19, 2021

Okay, at least I can put the entire notion aside for now then and move on to other things. Definitely frustrating, though.

LOTT · Jun 19, 2021

What is the advantage to calling programs from MDI rather then in Memory mode? Why is typing an M or G code better than typing the program number?

gkoenig · Jun 19, 2021

LOTT said:
What is the advantage to calling programs from MDI rather then in Memory mode? Why is typing an M or G code better than typing the program number?

Primarily for setup and in-machine inspection. Right now, we have this convoluted solution of having a bunch of (almost) single-line programs in the top level directory for doing individual probing operations (1-22 are tool length, 700-710 for individual spindle probe routines). This is silly.

I should just be able to assign the main probe routine (program 8700) to a G-code, and be able to fire it off from the MDI with variables. Like if I assign P8700 to G700, I could probe in +X and set the result to G54 just by typing "G700 X.25 W54". Or set your tool probes up with a custom G-code and do all your setup from MDI.

Right now, there is a LOT of having to bounce between MDI, Memory and Edit if you're doing lots and lots of setups and it is super frustrating when it could be *SO MUCH* faster.

mutiny · Jun 20, 2021

What Greg said. It's primarily about simplifying the MDI/Memory/Edit dance. It's not the worst thing but it's an example of unnecessary inefficiency that Speedios usually do so well at avoiding.

LOTT · Jun 21, 2021

Gotcha. Here I finally make it to the probe club and there's a software glitch... Figured the reason it took so many steps was because I was doing something wrong.

Most of what we do is reoccurring parts that go from Talon Jaws to soft jaws, or are on pallets. I add a G10 line to the part program when cutting the jaws or pallet, so we can go a week without finding a WCS.

Stephan@AC · Feb 7, 2022

I just run in the same problem at a Brother B-control. You can not run sub programs (G65) from MDI at the machine.
My solution is not perfect, but for us much easier than changing the current programm just to run a probing macro.
As all of our programs are ouput by a post processor I simply add some lines at each program that check if a macro variable is set.
For example to probe the tool lenght of a tool we set #600 to the tool number. The just start the current program and it checks if #600<>0 and executes the probing program at any tool number.
For probing the position of a workpiece you can e.g. set #601 for X and #602 for work coord. number. Then you can do it the same way.

After finishing the macro the parameter is set to 0 by the program.

Brother needs years to fix something and life is not endless - so you need to find a workaround.....

gkoenig · Feb 7, 2022

Stephan@AC said:
Brother needs years to fix something and life is not endless - so you need to find a workaround.....

There were some (apparently) deep technical reasons having to do with the architecture of the system that made the G/M macro code infrastructure not work. Add a little language barrier, and the typical Big Business one hand not knowing what the other is doing friction and that is how we ended up with the infrastructure for G/M codes in MDI, but it not working at all. To be fair, custom macros do work in programs from memory, just not MDI.

Having said all that, the problem is fixed in the D-00 control, and the MDI is now multi-line. You can even write simple apps (in Java Script, IIRC) to do whatever front-end control stuff you want. You can, for example, write a simple app for a specific process so operators can be walked through - step by step - how to do the more complex stuff they often screw up on the factory floor.

Brother can be intransigent and opaque, but they listen very intently and basically always come through. The amount the C-00 evolved over it's 7 year run puts every other control on the market to shame - and it all came through firmware updates. I haven't gotten to play with a W1000 with the D-00 control yet, but from what I've been hearing, it improves dramatically on everything you would want to be improved upon in the C-00.

dstryr · Feb 7, 2022

Easiest solution....

Make all your probing programs set G54.1 P47

Write a simple conversion macro that you can run when done to read P47 and write into G[#700] where #700=G54,G55,G56 etc

gkoenig · Feb 7, 2022

dstryr said:
Easiest solution....

Make all your probing programs set G54.1 P47

Write a simple conversion macro that you can run when done to read P47 and write into G[#700] where #700=G54,G55,G56 etc

Even better yet-

Have all the probe programs set #4414 in place of hard coding the work offset number. The probe routines now shoot data to whatever the active work offset it. If you are one of those kinky types who likes working regularly in extended work offsets, you can go a little further and have it detect that you are in G54.1 and write to them as well.

I think we could even go a bit further and make it easy to write to the Rotary Fixture Offsets as well, but I haven't gotten that installed on my machine yet, so haven't played with it.

I'll find the code and post it later if people want. It turns probing in the Speedio from being a bit monotonous into being the fastest work setup probing machine made. No templates, no code to write, just 5 programs (X+, X-, Y+, Y-, and Z-)... touch touch touch and done.

Matt@RFR · Feb 7, 2022

gkoenig said:
the D-00 control yet, but from what I've been hearing, it improves dramatically on everything you would want to be improved upon in the C-00.

What are the things you would want improved on the C00?

(EDIT) Removed old man get-off-my-lawn-isms about touch screens and not fucking with a good thing.

couch · Feb 7, 2022

dstryr said:
Easiest solution....

Make all your probing programs set G54.1 P47

Write a simple conversion macro that you can run when done to read P47 and write into G[#700] where #700=G54,G55,G56 etc

Even easier, just have the W value in all the probing routines be W#900 (or whatever) then just edit that variable with 54. through 59. for standard offsets or -1. through -48. for extended. I’ve updated all my probing routines to work like this, same with the XYZ, Width/Diameter and Safe Distance (R) and it works awesome. No editing of any probing routines this way.

As for probing and writing to the Rotary Fixture Offsets, check this thread out. I wrote a pretty detailed response to it with instructions and the sample program to handle it. Works really well.

Everything noted above is for the Yamazen/Blum cycles.

Brother S1000 4th Setup

gkoenig · Feb 7, 2022

couch said:
Even easier, just have the W value in all the probing routines be W#900 (or whatever) then just edit that variable with 54. through 59.

This makes no sense to me, and Livingston and I got into this debate years ago. Why should users go to Data Bank - Macro Variables - Page Over (to the 900s) to go set a number buried 3 pages deep? Just use the active work offset, since you are probably in it via MDI during a setup anyhow. Burying critical variables deep in the macro tables is a poor UI practice that is rife with opportunities for error.

Just update your main probing routines as below. You'll literally never need to set a work offset in a program or buried in some table. Just MDI into the work offset you want and probe away:

As for the G54.1 P_n_ offsets, here is the code:

(SINGLE TOUCH X+);

#101=0;
;
N1 IF[#4014 EQ 54.1] GOTO 10;
#101=#4014;
GOTO 30;
;
N10 #101=#4130/-1;
GOTO 30;
;
N30 G65 P8700 W#101 X.25;
M30;

Matt@RFR · Feb 7, 2022

gkoenig said:
Why should users go to Data Bank - Macro Variables - Page Over (to the 900s) to go set a number buried 3 pages deep?

Assign each variable page to a shortcut menu. Ie: Shortcut2 > 8 gets you to the 800 variable page in two button pushes.

couch · Feb 7, 2022

Matt@RFR said:
Assign each variable page to a shortcut menu. Ie: Shortcut2 > 8 gets you to the 800 variable page in two button pushes.

Exactly!

gkoenig said:
This makes no sense to me, and Livingston and I got into this debate years ago. Why should users go to Data Bank - Macro Variables - Page Over (to the 900s) to go set a number buried 3 pages deep? Just use the active work offset, since you are probably in it via MDI during a setup anyhow. Burying critical variables deep in the macro tables is a poor UI practice that is rife with opportunities for error.

How do you handle outside/inside width/bore?

All of the probing routines that Blum supplies can be run with these simple variables. You could even populate the variables thru MDI if you really wanted to.

gkoenig · Feb 8, 2022

Matt@RFR said:
Assign each variable page to a shortcut menu. Ie: Shortcut2 > 8 gets you to the 800 variable page in two button pushes.

Again, why do I want to go to a third place? I'm bouncing between MDI and Memory already. I also have the active work offset right in front of my eyes in MDI mode.

Honestly, I am also usually working on A- Other people's machines and B- Most of my job is making processes bulletproof/easy for low-skilled operators to manage. I have an allergic reaction to anything I see as complexity without an extremely compelling and common utility. My goal is to remember as few numbers as possible, as few variable addresses as possible, and absolutely no math in my head. The more of those you add up, the higher risk of problems you run into.

couch said:
How do you handle outside/inside width/bore?

I have wrapper programs for the center of a .25 bore, with a Q value of .375. That gives me any bore down to .228 (my pre-drill for form tapping, so a common use case for me) and up to 1". That range covers almost all my bore measuring.

Between X+/-, Y+/-, Z and the Bore work offset locating program wrappers, I get about 90% of my probing done and it happens way fast. For everything else, I have one program called (PROBE SCRATCH) that I have very good muscle memory to get to. There I just modify a G65 P8700 call over and over as needed, hence "scratch". I basically use it the same way one would if Brother's MDI wasn't fucking stupid.

This is easy because the Blum/Yamazen macros are dead simple to make calls to very easily. The Renishaw macros are a whole can of nightmare that would probably take me way longer to memorize, but I can whip the Blum ones out instantly.

Rick Finsta · Feb 9, 2022

I use the Blum phone application to get the macro calls since I can't remember shit. It would be nice to call them from MDI instead of having to bounce between modes and folders, editing existing call programs, and then going back to run them in Memory.

Brother C00 - Running registered G/M codes in MDI

Cast Iron

Titanium

Cast Iron

Stainless

Titanium

Cast Iron

Stainless

Plastic

Titanium

Diamond

Titanium

Titanium

Cast Iron

Titanium

Titanium

Cast Iron

Titanium

Stainless

Similar threads