Mostly untested Brother / Speedio C00 post processor written mostly from scratch

[SpammersDeserveDeath]

This post is LARGELY UNTESTED! It's been tested by precisely one person so far: me. Please use with extreme caution!

I'm an amateur machinist and I'm not a programmer, but I went and wrote a post processor for my Speedio anyway. I started with a blank document and wrote everything that I could and copied everything that was either too complicated for me to decipher or already worked fine as it was. I also removed some things that are probably very important to some people so I'd like to reiterate that this post has only been tested by me, and I'm not really a qualified post tester.

OK, so what did I do? This isn't everything, but here's a list of things that I'm calling "improvements"...

It never outputs G49 (this is the first thing I did to any post processor for my Brother and I think it's important to stress its importance)

High Accuracy Mode B word selected and inserted based on machining strategy (3D adaptive = M285, 2D contour = M282, etc.)
HAMB turned off before helical moves and turned back on after (I don't believe High Accuracy Mode B is capable of doing helixes, but I've heard that I might be wrong about that, please weigh in on this) -- perhaps a better option for helixes is to use a High Accuracy Mode A command, but which one?)

Oh, turning off HAMB is only done for circular moves that use IJK addresses, circular moves that use radiuses are not modified so may fail I guess.
Automatically reduces feed rates higher than the user parameter "highFeedrate" to equal the "highFeedrate" value when HAMB is M289

It makes a fancy tool table (optional)

It adds fancy section headers (optional)

Tool changes are not called if the tool should already be in the spindle, but spindle speed and direction is always called

Turns on chip shower at final tool change (optional)

Rejiggered canned cycles some (I don't really remember the changes I made)

Decimal places added after most (all?) coordinates

Cleaned up what I'm calling "modal defaults" (G90, G17, G54, etc.)
Created option so that modal defaults aren't output before the sections/operations

Added stuff to make running the code as a subroutine "better" (well, it's better for me, probably useless for most people) (optional)

Added option to put % at start and end of file

Removed restriction from using anything other than numbers for the program name (so it can be called something like "o1001" in the setup and it will output as o1001.NC without error)

Added option of what kind of spaces to put between words (so the space can either be removed or additional spaces can be added)

Digits after the decimal for coordinates controlled by a single option (I couldn't change it from within Fusion 360 for some reason, but it seems to work correctly if modified within the post file)

Rewrote 'writeBlock' function to make sure blocks are less than 127 characters long and also trims off leading and trailing spaces

Rewrote 'writeComment' function to take advantage of the following two changes...
Greatly expanded character set (every character in my list will display on my screen (YMMV)) (underscores are in the "valid characters" list, so remove it if it's going to cause you problems, or add it to the list of replacements below)
Added special find-and-replace for some characters (º is replaced with * ; % is replaced with '/. ; parentheses are replaced with squiggily parentheses)

Created 'writeHeader' function to write comments that will be easier to spot while scrolling through the code (with optional length and optional filler character) (length currently set to 85 characters, but I keep forgetting to check if that is the perfect number when I'm at the machine)

Reordered the program metadata (program name, program comment) output

Date and time output using ordinary month to number conversion (January = "1", not "0"), leading zeros added to time elements

Coolant outputs made to be complete (I think) and correct (I think) (eg. TSC = M494/M495 instead of M88/M89)

Renamed most of the default address variables ("xOutput" is now "xAdd", "feedFormat" is now "fAdd" (I used "Add" because it's only three characters and works for both "address" and "addition"))

Tried to make the default functions (onSection, onClose, etc.) relatively clutter-free to facilitate easier editing

Tried to follow a more strict indentation format, also to facilitate easier editing


************************************
** Not included and/or removed **

************************************
All 5-axis motion code (that I saw) was removed - this could be real bad, but I can't test it so I just removed it
The post has no way to output A, B, or C words

************************************
** Not included and/or removed **

************************************

No functionality to insert sequence numbers other than before tool changes

************************************
** Not included and/or removed **

************************************

All "optional block" and "optional section" stuff was removed, I imagine these are important to some people, sorry!

************************************
** Not included and/or removed **

************************************

All dwell functionality has been removed and/or broken (adding dwells seems to turn some cycles (maybe all of them) into non-canned gcode and that scared me so I made it worse by removing the dwell code too)

************************************
** Not included and/or removed **

************************************

Sections of code that seemed to only be used if "useParametricFeed" was set to true. This includes the "activeMovements" section of the "getFeed" function

************************************
** Not included and/or removed **

************************************

It doesn't do any in-controller tool diameter compensation (it has no way to write a "D" address, so that kind of compensation probably isn't possible with this post processor, at the moment)

Attached is the post. Be gentle, "es mi dia primero". I've added the version number (2.07b) to both the file name and to the inside of the document. If you make changes and upload the file, please reference what version you started with.

A couple ideas I've had, but not attempted yet...

Make the post check the operation name for "HAMB" modes and apply them if they're found (in other words, check the name for "M289" and override the machining-strategy-based mode with the mode parsed from the name (I hope that makes sense)

Put the A, B, and C axis outputs (aAdd, bAdd, and cAdd) into the post and also put the strategies that use them back into the post too. I can't test these so I didn't want to try to make code that works with them.

[glrra30]

Thanks for posting.  I'll try to compare it to the work I've been doing on a Brother post.

Mine is posted here:

https://forums.autodesk.com/t5/hsm-post-processor-forum/brother-post-updates/m-p/7702579

Amen on eliminating G49.  This is the FIRST reason I got into modifying the Brother Post.  

I think I've noticed the issue with dwell breaking cycles into manual, hadn't gotten a chance to deep dive it yet.

Mine is trying remain compatible with A00 and B00 controls, so not using expanded character set.

[tacticalkeychains]

Here is a sample helical move that works fine.  As you can see my post calls out 281. I hear people complaining about helical moves but I have made thousands of them with 281.

G54
G100 T10 X-11.1265 Y-0.3728 G43 Z6.5185 H10 D10 S15000 M03
M08
M281
G17
G00 X-11.1265 Y-0.3728 Z6.5185
Z6.3615
G01 Z6.2815 F60.
X-11.1109 Y-0.3884
G03 X-11.0952 Y-0.3728 J0.0156
X-11.1577 Z6.269 I-0.0312
X-11.1464 Y-0.3969 Z6.2655 I0.0313
X-11.1066 Y-0.3487 Z6.253 I0.0199 J0.0241
X-11.1464 Y-0.3969 Z6.2405 I-0.0199 J-0.0241
X-11.0991 Y-0.3879 Z6.2335 I0.0199 J0.0241
X-11.1539 Y-0.3577 Z6.221 I-0.0274 J0.0151
X-11.1555 Y-0.3843 Z6.2175 I0.0274 J-0.0151
X-11.0974 Y-0.3613 Z6.205 I0.0291 J0.0115
X-11.1168 Y-0.3431 Z6.2015 I-0.0291 J-0.0115
X-11.1361 Y-0.4025 I-0.0097 J-0.0297
X-11.1168 Y-0.3431 I0.0097 J0.0297
X-11.1365 Y-0.3531 I-0.0048 J-0.0149
G01 X-11.1265 Y-0.3728

[SpammersDeserveDeath]

Welp, there's no ambiguity there... I wonder what I gotta do to make them work with mine.

[tacticalkeychains]

I'm not sure. i installed my own circuit board, is your's actually installed? haha - Also go into parameters/settings/somewhere and you should see what your max G1 feedrate is, If you find it let me know and I can look.  This would tell us if they actually installed it properly.  I remember them doing some trickery in some maintenance or version menu as well.

[SpammersDeserveDeath]

I installed mine myself too. I use 30000mm/min all the time for non-engagement moves so I think that's my limit. (~1181IPM)

[tacticalkeychains]

It doesn't change G0 moves as far as I remember.

[SpammersDeserveDeath]

Right, G1 <coords> F30000.

From the setting in the attached image.

[tacticalkeychains]

Ok, I didn't think G1 went that high, but maybe. Not sure when I'll have speedio on again but I'll check when I use it.

[SpammersDeserveDeath]

I didn't plan to update this so soon, but I found that I actually left capital "W" out of the list of acceptable characters, so that needed to be addressed.

I've made a few other changes too...

Number of digits after the decimal place of coordinates is now controlled by the units of the program. (MM = 3 digits, IN = 4 digits)

I also changed the name of that variable (from "coordDecimals" to "coordDigitsAfterDecimal") for the sake of clarity. I also removed it from the user properties section.

Added a new user property called "submicronCoords" which, when set to true, will increase the coordDigitsAfterDecimal value by 1 so that MM programs will have 4 digits after the decimal and IN programs will have 5 digits after the decimal. Changing this from false to true in the post processor file works, but changing it with the Fusion 360 UI doesn't seem to work. I don't know why but I suspect that's a bug.

Moved the variable "useRadius" back to the user properties.

Added a "delayFirstTSC" property (idea lifted from glrra30 (thread 1 linked below))

- I changed the pause time to 4 seconds since my TSC seems to take about 3 seconds to get going. I also added an optional block skip character (a slash - "/") so that the pause can be skipped if you want.

Added a "useA00Interpolation" user property (idea lifted from Laurens-3DTechDraw and glrra30 (thread 2 linked below)

When set to true this outputs circular moves as G02, G03, G102, G202, G103, and G203 and omits all the plane selection words.

Moved the fancy section start header code to its own function so that the onSection function is less cluttered.

Improved the WCS output so that WCS Offset values less than 0 (if that's possible) and greater than 54 throw an error. WCS Offsets from 0 to 6 are handled like you'd expect and WCS Offset values from 7 to 54 are output as G54.1 P1 through G54.1 P48.

Changed the setPlane function to return its output instead of writing it as a block itself. This is better for my rewritten onCircular function while barely effecting anything else.

Created a turnOnTSC function now that more code is involved because of the delayFirstTSC property. This lets there be just a single copy of the necessary code which keeps things tidier and also makes it easier to edit and understand.

Created a writeError function so that error messages can be output to the program being generated and also the normal localize thing. I also updated the few error events to use this function.

And the biggest change: a complete rewrite of the onCircular function. I haven't liked any of the other ones I've seen because so many of the commands are repeated over and over making adding edits tedious and error-prone, not to mention making it hard to interpret once the edits were in place. This one has very little repetition, yet adds both useHighAccuracyModeB and useA00Interpolation functionality as well as handles useRadius, and full circles better (in my opinion) as well as checking for the linearizing conditions all at once and right at the beginning. After seeing how this works, I'm considering moving to the A00 method and switching over the radiuses as I think that'll make the gcode easier for me to read.

OK, I think that's it. I'm calling this version "2.08 beta".

Referenced threads...

https://forums.autodesk.com/t5/hsm-post-processor-forum/brother-post-updates/td-p/7441963

https://forums.autodesk.com/t5/hsm-post-processor-forum/post-processor-for-brother-tc-s2b/m-p/608603...

A couple things that were present in 2.07 beta as well...

Removed G20 and G21 output.

Made it so the work coordinate system used in the first operation is reset at the end of the program. I haven't, personally, used anything other than G54 for anything other than the most minor of things, but I figure it's better to set the machine back to the WCS of the very first op than to just set it to G54 every time.

I confirmed that 85 characters is the optimal length for comments on my screen. (When displaying a single column the screen allows for 88 characters per line, the end of block character (";"), and the two parentheses leaves 85 for the comment text.

[SpammersDeserveDeath]

I can't leave well-enough alone. Another quick update. This has an "expandedCharacterSet" user property that allows the use of... uh... the expanded character set that I put together. If expandedCharacterSet is turned off, comments will be written with the limited character set that apparently works with more machines. Underscore was removed from the limited character set. Many of the removed characters will be replaced by an "=" symbol, so at least there will be some indication that there was a character there before. (I chose "=" because it's not used very often, is valid, and probably won't cause confusion.

Surely more characters can be used, anyone with an A00 or B00 machine want to see what works and what doesn't?

(Look for the "validateCharacters" function if you want to edit the character sets.)

[SpammersDeserveDeath]

I haven't been updating this post much lately, so I figured I'd upload where it is at the moment...

Changes since version 2.09 beta...

**** Important changes ****

- Rewrote the output of all canned cycles (details below)

- Made it so helical moves are performed with M265 (High Accuracy A "High Speed" Mode) instead of M289 (High Accuracy off) if user property "useHighAccuracyMode" is set to true/yes

**** Minor changes ****

- Removed High Accuracy application from "onRapid" function, as it's not needed on rapid moves and will be applied later if it is needed

- Replaced brute-force helical check with "isHelical" check in "onCircular" function

- Removed "B" from High Accuracy variable names (because it sometimes High Accuracy Mode A is used)

- Edited "resetAllWords" function to that it resets fewer things and renamed it to "forceNextXYZFSMotionModal"

- Recreated "writeOptionalBlock" function

- Updated variables with "TSC" in their name to use "CTS" instead, to match what Brother calls it

**** One more thing ****

The output generated when "useA00Interpolation" is set to true/yes seems to look good (to me), but I'm not sure if having this option is appropriate for this post processor since it's geared for the C00 control. After thinking about it for a while, I wonder if it might not be a good idea to use ~G203 words with C00 since they would be used for G19 helical moves, and the C00 manual that I have doesn't say anything about G203 being compatible with helixes.

**** Changes to canned cycle output (compared to "brother.cps" revision 41851 (2018-02-16) downloaded from Autodesk) ****

Trying to "improve" this code was tricky because C00 uses the same letter for multiple different parameters. For instance, depending on the cycle, "Q" may be the peck distance (G73, 77, 78, and 83), the shift distance (G76 and 87), or the rotation angle (G86). Because of this, creating a "qAdd" variable wouldn't be practical and using brute-force methods to output the code wouldn't be elegant. To deal with this I made a "cycleAdd" function that uses three arguments: prefix, value, and format.

prefix can be anything, but will generally be a single letter

value is the... numerical value you'd like to use, typically you'd use a variable

format can be "coord", "feed", "speed", or "radian" (The format type will determine how the value is rounded, the digits after the decimal point, and whether a decimal is used for integers. The "radian" format will convert the value from radians to degrees.)

Here are a couple sample lines using the "cycleAdd" function...

cycleAdd("Q", cycle.incrementalDepth, "coord")

cycleAdd("L", tool.spindleRPM * 1.2, "speed")

(note: all "notes" are true as far as I can tell, but some of this info is based only on what I've read in the manual)

Changes to formatting in all applicable cycles...
- pause (P) output in seconds instead of milliseconds
- feed rate (F) (optionally) doesn't round to an integer
- all integer coordinates/values output with decimal place

Chipbreaking without dwell (G73)

- no change in output

Chipbreaking with dwell (G73)
- doesn't expand (expand = output G00s, G01s, etc. to mimic cycle motion)
- pause supported (P)
- peck distance supported (Q)

Fine boring (G76)
- shift distance added (Q)
- spindle orientation added (V)
- spindle speed added (S)

Right hand tap with chip breaking (syncro mode) (G77)
- thread pitch added (I) (note: J (thread-per-unit) never needed/used with this post processor)
- P/pause removed (note: not supported with C00 G77)
- spindle speed added (S)
- F/feed rate removed (note: not supported with C00 G77)

- retract spindle speed (L) added, but commented-out (note: Fusion 360 doesn't seem to have a way to enter this value)

Left hand tap with chip breaking (syncro mode) (G78)
- G78 used instead of the G74
- output same as above

Right or left hand tap with chip breaking (syncro mode) (reducing step) (G77 or G78)
- similar output as above, but Q and L aren't output because they aren't used for reducing step cycles
- peck distance supported (W)
- minimum peck distance supported (V)
- (note: peck step reduction multiplier hard-coded in the controller)

Drill (no dwell) (G81)

- no change in output

Counterbore (drill) with dwell (G82)

- no change in output

Break-through drilling (G82)
- doesn't expand (expand = output G00s, G01s, etc. to mimic cycle motion)
- pause supported (P)
- break-through distance supported (V)
- break-through feed rate supported (L)

Gun drilling / guided deep drilling (G82)
- doesn't expand (expand = output G00s, G01s, etc. to mimic cycle motion)
- pause supported (P)
- starting distance supported (W)
- break-through distance supported (V)
- starting feed rate supported (E)
- break-through feed rate supported (L) (note: Fusion 360 doesn't seem to have a way to enter this value)

Deep drilling (full retract) (G83)

- no change in output

Deep drilling (full retract) (reducing step) (G83)
- doesn't expand (expand = output G00s, G01s, etc. to mimic cycle motion)
- peck distance supported (W)
- minimum peck distance supported (V)
- (note: peck step reduction multiplier hard-coded in the controller)

Right hand tap (non-chip-breaking) (G84)
- G84 used instead of G77
- spindle speed added (S)

Left hand tap (non-chip-breaking) (G74)
- same as above

Reaming (G86)
- G86 used instead of G85 so spindle is stopped before retracting reamer
- spindle speed added (S)

Stop boring (G86)
- doesn't expand (expand = output G00s, G01s, etc. to mimic cycle motion)
- pause supported (P)
- feed rate supported (F)
- spindle speed supported (S)

Back boring (G87)

- (note: the code output for back boring cycle differs from the toolpath shown in Fusion 360)

- (note: the code output for back boring cycle differs from the toolpath shown in Fusion 360)
- top of back bore used instead of lowest z point (Z)
- low start level used instead of cycle.bottom point (R)
- shift distance added (Q)
- spindle orientation added (V)
- spindle speed added (S)

- (note: this is untested and probably needs to be edited, I think it's possible that a manual retract move may need to be added)

- (if you plan to use this cycle, take a close look at the code generated before running)

Boring (G89)
- G89 used instead of G85
- retract feed rate supported (E) (note: Fusion 360 doesn't seem to have a way to enter this value)

[tacticalkeychains]

WOW nice! You are a post pro now!

So you still couldn't get helical to work with B mode? That is very odd.

[SpammersDeserveDeath]

Thanks! 😄

Yeah, still no high accuracy B helixes for me. I've talked to a few people at Yamazen, but they're basically clueless.

[SpammersDeserveDeath]

Alrighty, I've been updating the post as I find issues with it and come up with improvements.

It seems the machine I bought brand new at full price is running old software for some reason. It is, indeed, supposed to be able to do helixes in high accuracy mode B. An update has apparently been sent from Brother and will eventually be making its way to me... hopefully sooner rather than later!

OK, back to the post. This one is "2.15 beta", here is the list of changes...

Features Removed

1. I took out the A00-specific stuff. If you're using an A00 control, sorry! I decided that this post would be better served if it was geared specifically to the C00, especially since I don't have access to an A00 control to test with.
2. I removed the ability to output G02/G03 moves with R words. In other words, I removed the "useRadius" user property. It doesn't seem like using radiuses offers a benefit over using I, J, K words for arcs. I'm interested in learning otherwise though, so comment if I should put them back in.

Features Added

• Reposition the table at the end of the program...
• I made it so the machine will reposition the table at the end of the job. You can enable/disable this by changing the "postJobTableReposition" user-property to either true (do reposition at the end of the job) or false (do not reposition at the end of the job). It is set to false by default.
• The coordinates for the repositioning can be set by changing the user-properties "postJobTableG53XCoord" and "postJobTableG53YCoord". Note that these are G53 (machine) coordinates. Personally, I set mine to X-550 and Y0, which puts the table near the door for loading/unloading.
• Change tools at the end of the program...
• You can also choose to have the machine perform a toolchange at the end of the job by setting the "postJobToolChange" user-property to either true (do a tool change) or false (do not do a tool change). It is set to false by default. (Caution: Make sure to read and understand the bullet point with the red text below before changing this option.) 
• The tool that the machine will change to can be set using the user-property "postJobToolNumber". Setting this to 0 will make the machine change to the first tool used in the program. Setting to anything else will change to that tool (if possible). By default it's set to 0, personally I have mine set to 21 so that it changes to my touch probe.
• The tool change option needs a Z coordinate to work properly. The safest way that I know of to command a safe Z coordinate is to have it go to the highest G53 (machine) coordinate possible. For me, this is Z480. The post uses the value in the user-property "postJobToolChangeZCoord". Since the highest G53 Z coordinate for me is 480, I have mine set to... well... 480. To hopefully protect people, I've made the default value for this parameter 2000. Setting the default this way will hopefully force people to change it; I suspect the machine's controller will throw an error if a Z coordinate of 2000 is commanded. I highly recommend changing this value before activating the postJobToolChange option, especially if you're running in imperial or have a column extension installed on your machine. It probably wouldn't hurt to do a couple dry runs with the rapids turned down as well.
• Change tools and reposition the table at the same time...
• The reposition and tool change options can be set independently or in concert. If both are set to true, the reposition movement and tool change will be combined into a single G100 tool change command.
• Helix compatibility mode for machines like mine...
• Since I've learned that my difficulties with helixes are because my machine's software is outdated, I decided to put an option into the user-properties called "disableHelixesInHAMB" and set it to true by default. When both this option and "useHighAccuracyMode" are set to true, the post processor will change the high accuracy mode from B to A for most helical moves. If the high accuracy mode should be M284, this option will change to the "mode A" equivalent: M264. M280 will be changed to M260, M281 to M261, etc.
• Machining strategies that are set to M285 are handled in a special way, instead of changing them to M265, the helixes are linearized and the "correct" high accuracy mode is maintained. This is so adaptive clearing moves faster as I've found it sometimes slows down far more than I would want. Personally, I've also adjusted my machine's parameters to further increase the speed of M285.
• I added a "maxFeedRateHAMA" option to the user-properties. Through testing with my own machine I decided that the max high accuracy mode A feedrate is 20,000 mm/min. The post looks for feedrates higher than this being set when high accuracy mode A is active. If the commanded feedrate is higher than the value set in this option, the post replaces it with the maxFeedRateHAMA value. (I hope this sorta makes sense! Basically, if the CAM is commanding a feedrate that HAMA can't handle, the post will put the kibosh on it.)

Fixes

1. The chip shower function sometimes didn't get added in the right spot. It's supposed to come when the machine changes to the last tool of the program (chamfering, prolly?) OR during the last operation (for programs where only a single tool is used). I don't remember the specifics, but it would do stupid stuff sometimes (like come on at the second-to-last operation, or never at all... I think... I dunno). It now works with all the scenarios I could come up with.
2. The user-property "modalDefaultsIncludeG17" will now output G17 along with the other modal defaults every time. (I don't see how, but I'm pretty sure it sometimes it managed to fail at adding it.)
3. Changed the high accuracy mode of bore and thread machining strategies to M280 ("Shape Accuracy") instead of M285 ("High Speed"). Bores and threads should be accurate, not fast, in my opinion.

Minor things, probably not worth mentioning...

1. Changed the "cycleAdd" function's name to "customAdd". "Custom" makes more sense since it can be used outside of canned cycles.
2. Changed the syntax of "return" commands in the post processor. Both "return(argument)" and "return argument" seem to work just fine, but the style without the parentheses seems to be recommended more often on the web.
3. Changed the "setHighAccuracyMode" function to return a high accuracy mode number (e.g. "285") instead of immediately writing the full high accuracy mode modal (e.g. "M285"). I did this so that I could have the post "figure out" the current high accuracy mode without actually adding it to the code it immediately. It's better, IMO, but shouldn't change the generated code at all.

One more thing...

I made it so changing which high accuracy mode is selected for each machining strategy is easy to edit. Search for "function setHighAccuracyMode" and find the machining strategy you would like to modify. If you want to have "adaptive clearing" strategies to be run with high accuracy mode turned off, move the line that says...

case "adaptive":

... from above "return 285" so that it's above "return 289". Might as well also move case "adaptive2d": while you're at it. This will let you keep "useHighAccurcyMode" turned on, but make your adaptive clearing strategies wicket fast!

[gakoenig]

I'll run 2.15 tomorrow!

Also, from the YouTube conversation we had, your idea of using an M code in the operation name to trigger which one runs is excellent!

Having said that, I started messing with the tuning, and yea... there is a huge amount to be had in moving from the (junky) defaults. This is setting all the deceleration stuff to 800, smoothig at 3, smooth override at 300:

https://www.instagram.com/p/BkehpWpgMxr/?taken-by=lumalabs

It added 2.7 seconds to the cycle time compared to running raw without any HAMB.

And I pointed this out on IG, but this code was basically straight out of your post with HAMB turned all off, and the custom M285 inserted manually after the tool change... So that helical entry is running 100% in HAMB with zero errors.

I need to figure out a way to test these things and measure how much stock it's leaving in blow-out area problems. Drinkwater ran test coupons with a small, spline based pocket that gets roughed out, the walls finished, and a chamfer applied. Nice way to see where the path is blowing things at speed. IIRC, he ran the straight codes without any modifications to the parameters...

We seem to be discovering that even minor modification to those parameters (which as you noted, seem to have no changes between them) yields major positive results. 

[tacticalkeychains]

Glad you are going to test Greg, I've been meaning to.

I'd need to really compare the code to my normal posted code, and haven't had time.

My programs are very large, and I've yet to have a single issue with anything.

Sounds like I need to check into that update aswell.

Also a side note.. I turned off Thermal Comp and have noticed better parts from Cold to Hot.

Before I was getting quite a bit of Z change, and it was over compensating.

[gakoenig]

I haven’t been able to dig into thermal comp yet... I’m still overwhelmed with other learning curves!

Have you talked to Yamazen about this? I read the manual bits on thermal comp, but just like Fanuc, Brother documentation is heavy on engineering, skimpy on practical application.

I underestimated how many ARCA plates I would need on hand to get through the machine transition, so I’m going to run off some on the old Orange pallet fixture today. Perhaps I’ll get to see thermal comp in action?

Also, with probes... we should have a way to calibrate thermals by hitting a datum surface every so often. My theory for your issue is that thermal comp at the factory is calibrated for the typical Speedio production use case- 3-5 tools on a sub 4 minute cycle. You’re running hours long cycles with a tool in the spindle for many minutes. Recalibrating around your application is probably necessary.

You dig into the Speedio and find lots of details like this- they are built/configured for mass production with custom, per application recipes cooked up by big company production engineers. The factory defaults are kind of roughly filled-in blanks Brother expects you to tune up, and have not been configured for general purpose/job shop needs much at all. Like the fact that the M28X parameters the manual says are different are all set from the factory to be nearly identical,

[tacticalkeychains]

Probe? What probe? bwahahaha lol. I just use the machine by hitting start,
and it work every time. lol Well I posted about the issue, and some guy
told me to turn it off, same thing happened to him. he turned off the comp
and has all perfect parts says machine actually only moves like .0002 when
it gets hot, and my cuts were .0015 deeper easy. so ya just turn it off,
not worth the calibration of it. The machine just "Guesses" temps, so it
can never be right.

[SpammersDeserveDeath]

"Also, from the YouTube conversation we had, your idea of using an M code in the operation name to trigger which one runs is excellent!"

Welp, I put something in that seems to work. Basically, it looks for "M2" in the operation name, if it's found, it takes the three characters after the "M" and converts them to an integer, then it checks if the integer is between 260 and 269 or 280 and 289, THEN, if it is within one of those ranges, it'll use that number instead of what it would have chosen based on the machining strategy. It won't accept M268 or M288.

So, if the operation you'd like to override is named "Face1", you can change the name to "Face1 M285" to force it to use M285. You can also call it "M285 Face1" or "FacM285e1". "Face1 M265" would force M265 to be used.

If you name it "M289 Face1 M285", the HAM used will be 289, since it searches for the first instance of "M2" in the operation name.

Naming it "M288 Face1" will use the HAM based on the machining strategy, since M288 isn't allowed. And naming it "M288 Face1 M285" will also use the HAM based on the machining strategy, since M288 isn't allowed and the M285 is ignored because it's not the first instance of "M2". Also, it seems to be case sensitive, so "Face1 m285" won't work. This is probably for the best as you wouldn't want something like "Ream285" or even "Ream2" to be caught as a false positive.

I also put a minor tweak into the way the "disableHelixesInHAMB" option is implemented, to make sure HAMs that get set to M26X aren't converted to M24X.

M24X apparently correspond to "tap time constant" settings, whatever those are (prolly not something that should be programmed accidentally).