MachStdMill Release Notes For MSM Version 2.0.x and later Release/MachStdMill Release Notes.pdf1...

MachStdMill Release Notes

© 2010-2018 Calypso Ventures, Inc. Page 1 of 65

MachStdMill Release Notes For MSM Version 2.0.x and later

Calypso Ventures, Inc.

May 30th, 2018



Table of Contents 1 First things first… ....................................................................................................... 7 2 MachStdMill Install Instructions ................................................................................ 7 3 Known Errata in MachStdMill.................................................................................... 7

3.1 Known Unresolved Errata ................................................................................... 7 3.1.1 M6 handling vs G00/G01 mode. ..................................................................... 7

3.2 Fixed MSM Errata .............................................................................................. 8 3.2.1 Updating from MSM 1.1.18 & 1.1.19 to MSM 2.0.x ..................................... 8

4 Known Errata in Mach3 .............................................................................................. 8 4.1 Sometimes Brains Don’t Get Enabled ................................................................ 8 4.2 Button Press Errata Animation: .......................................................................... 9 4.3 The Settings-common page menu on/off buttons vs. plug-in menu: .................. 9 4.4 Button drawn as solid black: ............................................................................. 10 4.5 Mach incorrectly renders bitmaps: .................................................................... 10 4.6 Multiplexing BoBs. ........................................................................................... 11 4.7 GetCurrentTool() returns bad T# value ............................................................ 11 4.8 Setting the Current tool DRO changes Next Tool ............................................ 12 4.9 Current Tool DRO: Same T# => T0 ................................................................. 12 4.10 Code call returning before code is complete ..................................................... 13 4.11 Dialogs unresponsive during screen set load .................................................... 13 4.12 Overlapping button executions can hang mach ................................................ 14 4.13 RunScript Path Length ...................................................................................... 14 4.14 Current Tool DRO use changes Next Tool # .................................................... 15 4.15 DoOEMButton(MachStopButtonNum) via RunScript false Mach error. ........ 15 4.16 Mach allows M6 sequences to be interrupted. .................................................. 15 4.17 Mach window size vs. multi-monitor PCs. ....................................................... 16 4.18 Mach handling of Esc key vs. running scripts .................................................. 16 4.19 Interrupted Scripts are not passed Error Events ................................................ 17 4.20 MDI vs. running G-code ................................................................................... 18 4.21 Feed Hold LED disabled during Cutter Comp ................................................. 19 4.22 G68 related bugs ............................................................................................... 19 4.23 Mach TLO handling bugs ................................................................................. 20 4.24 Art code 904 on exit of mach ............................................................................ 23 4.25 Mach RPM DRO 39 and Plug-ins. ................................................................... 23 4.26 Setting WCO DRO breaks corresponding MF DRO ........................................ 25 4.27 Mach handling of T#M6G43H# in a single block ............................................ 25 4.28 Mach and AntiVirus programs .......................................................................... 26 4.29 Mach infinite loop if G31 w/ probe already triggered ...................................... 26 4.30 Lathe: Current Tool DRO changes wear offset ................................................ 27 4.31 Lathe: Geometry index <> Wear index ............................................................ 27 4.32 Lathe: Tool nose radius being used w/o nose compensation active ................. 28 4.33 Lathe: tool selection are not persistent.............................................................. 28 4.34 Lathe: Tool path bad redraw ............................................................................. 28 4.35 Lathe: lset file rendering depends on record ordering ...................................... 28



4.36 Lathe: OEM DRO 800 <> DRO 0 series .......................................................... 29 4.37 Mach < 3.43.50 WC DROs are broken if G52/G92 is active ........................... 29 4.38 Incorrect handling of non-WC X values in Diameter mode ............................. 31 4.39 Lathe current tool # DRO accepts T# > 99 ....................................................... 34 4.40 Mach, windows focus and Referencing ............................................................ 34 4.41 Mach Turn tool path mirrored bug.................................................................... 34 4.42 Mach Accepts Mill G43 and G49 without error in Lathe mode ....................... 36 4.43 Mach not running ScreenSetUnload ................................................................. 36 4.44 Lathe Offset DRO changes not correctly handled ............................................ 36 4.45 Lathe: Mach accepts M6 w/o error in lathe mode ............................................ 36 4.46 Lathe: Mach calling M6start when in Ignore Tool Change mode .................... 37 4.47 Lathe: Resume from FeedHold Causes Machine Crash ................................... 37 4.48 Lathe: Mach accepts G49 w/o error in lathe mode ........................................... 37 4.49 Mill: Mach ignores wear DROs ........................................................................ 38 4.50 Lathe: X Offset DRO displays incorrect value in diameter mode .................... 38 4.51 MDI vs screen set loads. ................................................................................... 38 4.52 DRO values can be incorrect when read ........................................................... 38 4.53 Windows Non-English Regional Settings Not supported by Mach.................. 39

4.53.1 Cypress Basic’s IsNumeric function bug with non-English number formats. 39 4.53.2 Cypress Basic’s number conversion functions are not aware of international settings. ................................................................................................ 40

4.54 Mach does not wait for Mcodes to complete, resulting in unpredictable parallel execution of Gcode blocks. ........................................................................................... 40 4.55 Mach fails to compile large scripts ................................................................... 42 4.56 G49 and G52 in same block incorrectly calculates G53 position ..................... 42 4.57 #Expand broken in wizards ............................................................................... 42 4.58 GetActiveScreenSetName() broken when wizard loaded ................................. 43

5 Smooth Stepper Specific Errata ................................................................................ 43 5.1 SS moves X when only G31 Y motion was commanded. ................................ 43

6 MachStdMill Reporting and Feedback ..................................................................... 44 7 MachStdMill Release Version Changes ................................................................... 44

7.1 V2.0.0 (MSM Production Release):.................................................................. 44 7.2 V2.0.1 (CVI internal release): ........................................................................... 44 7.3 V2.0.2 (MSM Production Release):.................................................................. 45 7.4 V2.0.2.1 (Limited distribution beta): ................................................................ 45 7.5 V2.0.2.2 (Limited distribution beta): ................................................................ 45 7.6 V2.0.2.3 (Limited distribution beta): ................................................................ 45 7.7 V2.0.2.4 (CVI internal): .................................................................................... 45 7.8 V2.0.2.5 (Limited distribution beta): ................................................................ 45 7.9 V2.0.2.6 (Limited distribution beta): ................................................................ 45 7.10 V2.0.2.7 (Limited distribution beta): ................................................................ 46 7.11 V2.0.2.8 (Limited distribution beta): ................................................................ 46 7.12 V2.0.2.9 (Limited distribution beta): ................................................................ 46



7.13 V2.0.2.10 (Limited distribution beta): .............................................................. 46 7.14 V2.0.3 (Limited distribution beta): ................................................................... 46 7.15 V2.0.3.1 (Limited distribution beta): ................................................................ 46 7.16 V2.0.3.2 (Limited distribution beta): ................................................................ 46 7.17 V2.0.4 (Production Release): ............................................................................ 46 7.18 V2.0.4.1 (CVI Internal Release): ...................................................................... 46 7.19 V2.0.4.2 (Beta Release): ................................................................................... 47 7.20 V2.0.5 (Production Release): ............................................................................ 47 7.21 V2.0.6 (Production Release): ............................................................................ 47 7.22 V2.0.7 (Production Release): ............................................................................ 47 7.23 V2.0.7.1 (Limited Distribution beta release): ................................................... 48 7.24 V2.0.7.2 (Limited Distribution beta release): ................................................... 48 7.25 V2.0.7.3 (Limited Distribution beta release): ................................................... 48 7.26 V2.0.7.4 (Limited Distributuon beta release): .................................................. 49 7.27 V2.0.7.5 (Limited Distribution beta release): ................................................... 49 7.28 V2.0.7.6 (Limited Distribution beta release): ................................................... 49 7.29 V2.0.7.7 (Limited Distribution beta release): ................................................... 49 7.30 V2.0.7.8 (Limited Distribution beta release): ................................................... 51 7.31 V2.0.7.9 (Beta release): .................................................................................... 51 7.32 V2.0.8 (Production Release): ............................................................................ 51 7.33 V2.0.9 (Production Release): ............................................................................ 51 7.34 V2.0.9.1 (Limited Distribution Alpha Release): ............................................... 52 7.35 V2.0.9.2 (Limited Beta Release): ..................................................................... 54 7.36 V2.0.9.3 (Limited Beta Release): ..................................................................... 54 7.37 V2.0.9.4 (Limited Beta Release): ..................................................................... 54 7.38 V2.0.9.5 (Beta Release): ................................................................................... 54 7.39 V2.0.10 (Production Release): .......................................................................... 54 7.40 V2.0.11 (Production Release): .......................................................................... 55 7.41 V2.0.12 (Production Release): .......................................................................... 55 7.42 V2.0.13 (internal use only): .............................................................................. 55 7.43 V2.0.14 (Production Release): .......................................................................... 55 7.44 V2.0.15 (Beta Release): .................................................................................... 55 7.45 V2.0.16 (Beta Release): .................................................................................... 57 7.46 V2.1.1 (Internal Beta Release): ......................................................................... 57 7.47 V2.1.2 (Limited Distribution Beta Release): .................................................... 58 7.48 V2.1.3 (Limited Distribution Beta Release): .................................................... 58 7.49 V2.1.4 (Beta Release): ...................................................................................... 58 7.50 V2.1.5 (OEM Version): .................................................................................... 58 7.51 V2.1.6:............................................................................................................... 58 7.52 V2.1.7.1 OEM Beta: ......................................................................................... 58 7.53 V2.1.7.2 OEM Beta: ......................................................................................... 58 7.54 V2.1.7.3 OEM Beta: ......................................................................................... 58 7.55 V2.1.7.4 OEM Beta: ......................................................................................... 59 7.56 V2.1.7.5 OEM Beta: ......................................................................................... 59



7.57 V2.1.7.6 OEM Beta: ......................................................................................... 59 7.58 V2.1.7.7 OEM Beta: ......................................................................................... 59 7.59 V2.1.8 Production Release:............................................................................... 59 7.60 V2.1.8.1 Private Beta: ....................................................................................... 59 7.61 V2.1.9 Production Release:............................................................................... 59 7.62 V2.2.0 BETA Release: ...................................................................................... 59 7.63 V2.2.1 Production Release:............................................................................... 59 7.64 V2.2.3.4 OEM Beta: ......................................................................................... 59 7.65 V2.2.3.5 OEM Beta: ......................................................................................... 60 7.66 V2.2.4 Internal Release: .................................................................................... 60 7.67 V2.2.5 Internal Release: .................................................................................... 60 7.68 V2.2.6 OEM Release: ....................................................................................... 60 7.69 V2.2.7 Internal Release: .................................................................................... 60 7.70 V2.2.8 Internal Release: .................................................................................... 60 7.71 V2.2.9 Production Release:.............................................................................. 60 7.72 V2.2.10 OEM Release: ..................................................................................... 60 7.73 V2.2.10a Beta (temp OEM Release): ............................................................... 60 7.74 V2.2.11 (OEM Release):................................................................................... 61 7.75 V2.2.11.1 (OEM ATC Alpha Release): ........................................................... 61 7.76 V2.2.11.2 (OEM ATC Alpha Release): ........................................................... 61 7.77 V2.2.11.3 (OEM ATC Alpha Release): ........................................................... 61 7.78 V2.2.11.4 (OEM ATC Alpha Release): ........................................................... 61 7.79 V2.2.11.5 (OEM ATC Alpha Release): ........................................................... 61 7.80 V2.2.12 Production Release: ............................................................................ 61 7.81 V2.2.13 Production Release: ............................................................................ 62 7.82 V2.2.14 Production Release: ............................................................................ 62 7.83 V2.2.14.2 Alpha (internal OEM development Release): .................................. 62 7.84 V2.2.14.4 Alpha (internal OEM development Release): .................................. 62 7.85 V2.2.15 Production Release: ............................................................................. 62 7.86 V2.3.0 (internal beta release): ........................................................................... 62 7.87 V2.3.0.2 (internal alpha release): ...................................................................... 62 7.88 V2.3.1.x (internal alpha release): ...................................................................... 62 7.89 V2.3.2 (Beta release): ...................................................................................... 63 7.90 V2.3.3 (TEMP OEM release): ......................................................................... 63 7.91 V2.3.4 (OEM release): ..................................................................................... 63 7.92 V2.3.5 (OEM release): ..................................................................................... 63 7.93 V2.3.5.x (internal development release): ......................................................... 63 7.94 V2.3.5 (Production Release): ........................................................................... 63 7.95 V2.3.6 (Production Release): ........................................................................... 63 7.96 V2.3.7 (Internal Release): ................................................................................ 63 7.97 V2.3.8 (Production Release): ........................................................................... 64 7.1 V2.3.8.1 (internal Beta) .................................................................................... 64 7.2 V2.3.9 (Production Release) ............................................................................. 64 7.3 V2.3.10 (Internal Beta) ..................................................................................... 64



7.4 V2.3.10.3 (Internal Beta) .................................................................................. 64 7.5 V2.3.11 (Internal Beta) ..................................................................................... 65 7.6 V2.3.12 (Production Release) ........................................................................... 65 7.7 V2.3.13 (Beta) ................................................................................................... 65 7.8 V2.3.14 (Production Release) ........................................................................... 65



1 First things first… Welcome to the MachStdMill enhancement package for Mach3 v3. Calypso Ventures, believes you will find this package to be a valued improvement to Mach3. The Software will install itself and be fully functional during the trial period. After the trial period, you will need to activate the Software to continue using it. The software installation is automated and is generally trouble free. Even so, it is strongly recommended that you take the time to read the release notes to see what has changed since your last MSM version.

Honest, I kid you not, it’s a small amount of reading time well invested…

NOTICE: MachStdMill REQUIRES Mach 3.043.xxx series. The exact minimum major.minor.build level required is given in the Readme file. MSM will NOT allow you to run MSM on a sub-minimum Mach version.

2 MachStdMill Install Instructions The installation of MachStdMill consists of two steps:

1) Install Mach3 2) Install MachStdMill

The MachStdMill install is handled by an install package. Please see the MachStdMill Readme file for MachStdMill installation instructions.

3 Known Errata in MachStdMill This Section contains the known errata for this version of MachStdMill.

3.1 Known Unresolved Errata

3.1.1 M6 handling vs G00/G01 mode. An M6 sequence is not supposed to change the current mode for G00/G01/G02/G03. However, the MSM M6 handling leaves the control in G00 at the end of the M6 sequence.



After 5 years of MSM use in the the field, this showed up when a CAM post processor assumed that motion mode was constant across M6 and the code failed (a G01 motion ran as a G00). This can’t be fixed as there is no known way to ask Mach for the current motion mode,. Therefore MSM can’t restore it at the end of M6 handling.

3.2 Fixed MSM Errata This section lists only Errata for the 2.x.x release series. For earlier MSM releases, please see the release notes for the MSM 1.1.x releases.

3.2.1 Updating from MSM 1.1.18 & 1.1.19 to MSM 2.0.x The MSM 2.x.x installer forces an uninstall of MSM 1.x.x as one of the first steps of a 2.x.x. install. This is necessary due to technical changes between MSM 1.x and 2.x. A side effect is that the following bug in MSM 1.1.8 and 1.1.19 may impact users updating from those version to MSM 2.x.x

3.2.1.1 Uninstalling MSM 1.1.18 removes Mach3.exe The MSM installer for 1.1.18 had an option turned on that marked mach3.exe file as having been installed by the MSM installer. This causes MSM 1.1.18 to delete mach3.exe when it is uninstalled. This is fixed in MSM 1.1.20. Updating from MSM 1.1.18 to MSM 1.1.20 (or later) will fix the problem. However, any direct uninstall of 1.1.18 will end up deleting the mach3.exe file.

The recovery solution is to re-run the mach installer to get the mach3.exe file back.

4 Known Errata in Mach3 This Section contains the known errata for Mach3 which have been observed while using MSM and are verified bugs in Mach3.

4.1 Sometimes Brains Don’t Get Enabled

NOTE: as of MSM 2.2.0, MSM no longer used any Mach 3 Brains. Therefore this issue should only apply to MSM versions before 2.2.0. Brains placed into <mach install dir>\ Brains\Autoload are supposed to be enabled and loaded automatically by Mach each time mach starts. Unfortunately, this does not always happen.



When Mach does not load the brains correctly, this disables a couple of key MSM controls:

• The Rapid Override LED • The Spindle Override LED • The Tool change page dynamic Cycle start button

If these controls are not working in your installation of MSM, please do this to correct the problem:

Go to the mach menu and select operator/brain control, then look for 3 brains, each of which start with the word MachStdMill...

MachStdMill Rapid OR LED MachStdMill Spindle OR LED MachStdMill Tool Pg CS Button LED

Each of them should be checked as enabled. If they are not enabled, please tick the check box to enable each one, then click the "reload all brains" button. The override displays are controlled by these brains. They are supposed to be enabled and automatically started by Mach but for some reason, on some systems, usually for a first time MSM install, Mach does not always load these correctly. Once the brains are loaded manually, the problem seems to go away.

Verified on Mach 3.43.22

4.2 Button Press Errata Animation: If a button runs script code, sometimes Mach is doing the “compress the button bitmap” on down click but not doing the “decompress the bitmap” after the code runs. This is only a visual redraw issue and doe not impact functionality. Verified on Mach 3.43.22

4.3 The Settings-common page menu on/off buttons vs. plug-in menu: These work but they cause the plug-in menu items to be lost. This is a bug internal to Mach V3. MSM also remembers the menu state you requested and will restore it on load. If you turn off Mach’s menus, you will hit the mach bug and this results



in no plug-in menus when running MSM. If you leave Mach’s menus on, the Mach bug is not tripped. After turning the Mach menus back on, a restart of Mach is required to get the plug-in menus back. MSM leaves it to the user as to which is more important to them: control of menu visibility or always having the plug-in menu entries. Verified on Mach 3.43.22

4.4 Button drawn as solid black: Sometimes a button on a screen will be drawn by Mach as solid black instead the button image. This has only been seen with transparent buttons – instead of drawing the transparent rectangle, mach is drawing a solid black rectangle. This seems to occur when a dialog box is open (for example: file open dialog) and the item clicked in the dialog box is located such the mouse cursor is “over” a mach transparent button which is behind the dialog box. When the dialog box exits the underlying transparent button is drawn incorrectly. This is only a visual graphics issue that does not impact functionality. The correct button image can be redrawn by changing to another page and coming back to the prior page – this refreshes the page and the button gets redrawn correctly.


4.5 Mach incorrectly renders bitmaps: When mach starts it loads all the bitmaps for a screen set and statically loads them into memory. Sometimes when loading will incorrectly render a LED image. Instead of opening a loading the image for the LED, Mach will load a non-image LED bitmap image for an image LED. Because mach only loads bitmaps at startup, it is necessary to close mach and restart it to clear this condition. The LEDs effected are random and appear to be impacted by what else is running on the PC when Mach loads – this appears to be an internal timing hole in the Mach bitmap rendering logic. Because MEM uses Mach LED bitmaps to show button states, this can appear as if an MSM button has been drawn incorrectly. Verified on Mach 3.43.22



4.6 Multiplexing BoBs. There are a couple of Break out boards on the market with use a non-publicly documented feature of the Mach parallel port driver to do “pin multiplexing”. These BoBs offer a feature where they connect more input lines to the BoB than there are pins physically available on a single PP. The multiplexing causes the combination of the PP driver, the BoB plug-in and the Mach kernel to report incorrect probe signal states to scripts. The incorrect state reporting causes MSM probing operations to fail. The problem appears to be in the BoB hardware to mach interface and is not specific to MSM. Correcting this problem is an issue for NFS and the BoB vendors. Therefore, Probing operations are NOT SUPPORTED with multiplexing BoBs (when they are in multiplexing mode). Further, the random timing hole nature of the problem means the use of multiplexing BoBs is NOT RECOMMENDED as it could also effect other signal states besides the probing signal. Verified on Mach 3.43.22

4.7 GetCurrentTool() returns bad T# value

Update: this bug appears to have been fixed in mach 3.43.35 as GetCurrentTool() tracks OEMDRO 824 as of that release. This means that scripts which were coded to work around the bug will need to be updated now that GetCurrentTool() is again doing what is should. This bug is stil listed in the MSM release notes as MSM will run on versions of Mach earlier than 3.43.35. Verification of bug test process: MDI: t0m6 MDI t0m6 yes I did it twice in a row on purpose.... then I ran this msgbox "GetCurrentTool = " & GetCurrentTool() & chr(13) & _ "CurrentToolDRO = " & GetOEMDRO(824)



the results are: GetCurrentTool = 0 CurrentToolDRO = 0 now do MDI: t1m6 run script again, the results will be: GetCurrentTool = 0 CurrentToolDRO = 1 now do MDI: t2m6 run script again, the results will be: GetCurrentTool = 1 CurrentToolDRO = 2 now do MDI: t3m6 run script again, the results will be: GetCurrentTool = 2 CurrentToolDRO = 3 The value returned by GetCurrentTool is lagging 1 TC behind the DRO.... Verified on Mach 3.43.19 and 3.43.22

4.8 Setting the Current tool DRO changes Next Tool Using the Current Tool DRO to set the current tool will also cause mach to set it’s internal next tool value to the new value of the Current Tool DRO. This is a Mach bug which is not expected to be fixed in Mach V3. Verified on Mach 3.43.22

4.9 Current Tool DRO: Same T# => T0 Normally writing to OEM Dro 824 will set the current tool information for Mach. However, there is an odd bug when writing to OEM DRO 824. If the value being written is the same as the value already in the DRO, then Mach sets the DRO value to 0. This indicates T#=0 which is the indication to mach that “no tool is mounted”. Example:



OEM DRO 824 = 3 Write 3 to OEM DRO 824 OEM DRO 824 will get a value of 0 instead of the value of 3 that you wrote. This is one reason the MSM manual says not to use the Screen DRO to set tool number. The recommended practice is to always use MDI to change tools (ex: T3 M6).

4.10 Code call returning before code is complete If the code string includes an M6 word, the Code() is not waiting for code to complete before returning. Test case to show bug: code "t1m6" msgbox "you should not see this msgbox until after the M6 completes, but you do" Verified on Mach 3.43.22 Update: In Mach 3.43.48 there is now a way to work around this. An M6t sequence is internally implemented in Mach as calls to user scripts M6Start and M6end. This prevents a script which invokes and M6 word from using IsMoving” to wait for the M6 to finish (as the user M6 scripts could make multiple motions and mach does now have a way to correlate motion from the scripts to the M6 state). The alternative is to wait on the Mach tool change LED – however that was also broken until mach 3.43.48. Prior to 3.43.48, mach turned off the tool change led After M6start finished and before M6End was called. As of 3.43.48, the tool change led now stays on until M6End completes. This allows a script to use a work around for the special M6 case, but still does not cause the Code call itself to not return until the M6 word is finished.

4.11 Dialogs unresponsive during screen set load If Mach displays a dialog box when initializing (say to pick the hardware output device to use), the dialog will appear but then be “frozen” - until after Mach finishes loading the screen set. Once mach has finished loading, the dialog will be come active and you can then respond to it. The work around to this Mach V3 bug is to simply be patient and wait for the screen set load process to complete.



Note that if you have watchdog timers enabled, that Mach may reset when the screen set load is finished as mach does not update the watchdogs while loading a screen set. Verified on Mach 3.43.22

4.12 Overlapping button executions can hang mach Mach has an unfortunate habit of firing off each button script for asynchronous execution in separate thread. However, the mach scripting APIs do not provide any semaphore protection support.... If two buttons call common code that is not thread safe, it can put the main mach thread into a hard hang that only a reboot can recover from. As this is a fundamental design aspect of mach3, the potential for this type of problem can not be eliminated. MSM code is protected from this problem, but it can still occur with mach internal code and cause a mach hang. I can only suggest, that users don’t try to click mach screen buttons as fast as possible back to back… :-( Verified on Mach 3.43.22

4.13 RunScript Path Length The Mach API RunScript has a problem with long paths. RunScript can not handle a full length legal path and file name string that is valid in Windows. Path/filename strings longer than about 114 characters cause RunScript to return an unknown error code. As RunScript is used extensively by MachStdMill, this limits where script files may be located in the file structure. An example of this error can be seen if you use the MSM “run maintenance script” button to try to run a script that has a long path to the script file. Fortunately, the default mach install location of C:\ keeps all the paths for MSM installed components under this limit. Verified on Mach 3.43.22



4.14 Current Tool DRO use changes Next Tool # If you click the current tool DRO and change the T# value instead of doing a tool change via T<#>M6, mach sets both the current T# and the Next tool (T#) to the entered value. Verified on Mach 3.43.22

4.15 DoOEMButton(MachStopButtonNum) via RunScript false Mach error.

Use of DoOEMButton(MachStopButtonNum) via RunScript causes false Mach error message.

If either DoOEMButton or DoBUtton is used in a script that is invoked via RunScript, Mach may (or may not) generate an error message to the history file. Whether this happens is dependant on internal mach async timing and thus may or may not happen on a given machine. The error message generated is:

"Error on line: xxx - Application defined or object defined error” The error message is a false positive. The stop function always works. In addition the lien number given is not the line number of the base script but the line number of the invoking script and is the line number of the RunScript call. Verified on Mach 3.43.22

4.16 Mach allows M6 sequences to be interrupted. Because Mach executes M6 scripts without treating them as critical sections, an M6 sequence can be interrupted. This means that Mach can partially execute the M6 word and the gcode block containing the M6 word (which is a violation of the definition of a gcode block as an atomic execution unit). This is likely to leave the control in an inconsistent state from which it is not safe to continue gcode execution. If a tool change is interrupted, the user is strongly advised to be very careful to check the state mach’s tool information etc. For example mach’s current tool info is likely to no longer match the mounted tool. This can not be fixed at the UI level in Mach (i.e. MSM can’t do anything about it, because it is not told that it happened).




4.17 Mach window size vs. multi-monitor PCs. If Mach is run on a multi-monitor PC and the Mach window is closed from a onitor other than monitor #1, mach does not remember it’s window size or location when it next starts. Instead mach starts on monitor 1 at a default windows size.


4.18 Mach handling of Esc key vs. running scripts Update: • Mach 3.43.35 has patches to correct this Mach bug. As the bug is an operator

safety issue, because the Mach bug that allowed scripts to continue after esc/stop/EStop is a serious safety issue, the user should give serious consideration to using mach 3.43.35 with MSM. However, mach 3.43.35 is a Mach development version (it is not a Mach lock down revision), as such it has an unknown set of additional changes and at least one new bug. Therefore the MSM user needs to decide if mach 3.43.22 or 3.43.35 better suits theirs needs.

If a user presses the Esc key while a script is running, most users expect the script to be interrupted and stopped. Unfortunately, this is not what Mach does in all cases. If a script is running that can do multiple movements (for example a complex probing routine) and in the middle of the script processing the user hits the esc key, only the current movement in Mach is interrupted. It appears that mach sees the esc key event and interrupts the operation that the script has asked Mach to do (say a movement started via Code) I'm not sure of what happens inside mach, but this is how it appears from the scripts viewpoint: • Mach stops the current movement, then Mach returns control to the script. • It appears that mach does not raise an error during this sequence.

o (Error handlers in the scripts are not notified of the esc key event) • Since the script is not notified, and the script is not stopped, there doesn't seem to

be any way within a script to know that this happened. This is dangerous as only part of what the script commanded mach to do gets aborted, but the script does not know that, and when the script gets control back from mach it keeps going...... this can result is a crash of the machine. Since Mach provides no support for esc key notification, this can not be fixed or handled within a script.



The only advise is to NOT attempt to interrupt script actions via the Esc key. Use EStop instead – and even then be careful!

I have seen cases where Estop NOT clear the mach movement buffer! I have hit Estop (the hdw input line, not the Mach reset button) in the middle of a probe script; mach stopped; but when I cleared the estop condition, Mach executed previously queued movement! I have also seen the still running script issue movement commands to Mach which arrive after the EStop condition is cleared and Mach accepts the command and creates motion…. very scary.


4.19 Interrupted Scripts are not passed Error Events I have recently been told that a specific bug in Mach v3 will not be fixed. The bug prevents a script, with an error handler, from having the error handler routine invoked when either the esc key is pressed or an estop occurs. This means that if the operator presses esc or Estops while many of the MSM scripts are running, that the script will get summarily stopped. However, the script will not (and can not) know that this has happened as the error event does not make it to the script. Therefore the script can not clean up it's interrupted condition if either of these two events occur. Even scripts with error handler routines are helpless as their error handler does not get invoked. This has nasty system level side effects as any resources held by the running script are now lost. Objects for which memory has been allocated can not be released and files that are open can not be closed. Repeated interruption of script execution via the use of esc will create a memory leak that is not resolved until Mach exits. Nor can the interrupted scripts do anything in reaction to the events to make the user interface appear in a consistent state. To add insult to injury, after killing the script, Mach then reports that a script error has occurred and puts this message in the Mach message bar area. This action misleads the user into thinking that there is a bug in some script code, when in fact it is Mach that created the error condition, did not tell the script it happened, and then lies about what has happened via the message bar. Uers are advised if they see an error indicating that there is a script error, to open the MACH error history (the history button does this ) and look for a recent message that the EC key or an step has occurred. Script error messages shortly after and ESC or Estop message are due to this Mach bug and not the fault of the Script.



As a direct result of this bug, I can pretty much guarantee that if any of the MSM logging features are turned on for debugging or performance measurement purposes, any Esc or Estop action is going to create a state which will require you to exit and reload Mach before the system will run correctly again. To minimize the impacts of this Mach bug, I have tweaked several routines to try to keep the time window during which they hold crucial resources as short as possible. This approach can help lower the probability of this problem happening, but it can not be eliminated unless the bug in Mach is fixed. Fortunately, MSM become stable enough well before first production release to ship with debug logging off by default. This lets MSM avoid the impact of this bug for most normal operations. However, if you are running with any MSM debugging facilities ON (for example to help CVI support find a bug), this Mach bug can create a lost resource / deadlock situation.


Update: Mach 3.43.35 has improved Mach’s actions wrt to this situation. MSM has been altered correspondingly as of MSM v1.1.2. However, not all issues have been fixed.

4.20 MDI vs. running G-code Mach does not lock out the MDI control when running gcode. This can be very dangerous. If a MDI command is entered while a Gcode program is running, the MDI action will be asynchronously inserted into the GCode execution queue at the time the MDI command is entered. This can (and probably will) crash the machine. For example if you enter G90 G0 X0 while running gcode, you will find that mach will insert a G90 G0 X0 in the middle of the running gcode! This is an internal Mach design issue, and users are strongly advised to not use the MDI control while gcode is running.




4.21 Feed Hold LED disabled during Cutter Comp Mach does not activate the Feed hold LED (805) if feed hold is invoked while cutter comp is active. The symptom of this show up in MSM as: The bug can be seen with the MSM happy face sample gcode. In that program T#1 operations use cutter comp and feed hold will stop movement, but the feed hold LED is not turned on by mach (so in MSM the center of the feed hold button does not blink) - it also seems that the cycle start/run led in mach is not turned off (as the MSM cycle start button keeps blinking the white triangle); finally something is also wrong in mach when this happen with the cycle start action - as the Cycle start button seems disabled (as it does not restart motion). If you try feed hold during the happy face program's T#2 operations, all works as it should since cutter comp is off and the mach bug does not rear it's head.


4.22 G68 related bugs The following bugs discovered have been verified on Mach 3.43.22:

1) The Mach vars that report probe points do not handle G68 rotated XY WCs. They report non-rotated WCs even though the WC is rotated.

2) There is no interface to get the current G68 rotation parameters from mach. a. You can get the G68 angle but not the G68 rotation point. This makes it

impossible to do the math outside of Mach to compensate for the incorrect Probe point coordinates reported by Mach.

3) The WC DROs in Mach do not give correct coordinates when G68 is active. 4) The Multimode DROs do compensate for a rotated WC, but these can not be used

in many cases as the mode can be asynchronously be changed from WC to MC or DTG. That would blow up calculations that expect WCs and might get MCs or DTGs instead.

a. Essentially the mode setting of the MultiMode DROs needs to be treated as a critical resource and protected with a lock – but Mach has no such concept.

5) The Zero X and Zero Y OEM button calls are broken in Mach if G68 is active. They appear to set the WCO for the axis as if the WC was not rotated. This makes the WC position of both X and Y incorrect (even from the multi mode DROs) if you zero either X or Y while G68 is active.

6) Mach does not jog correctly when XY is rotated. Mach always does no-rotated jogs (square to the Machine axes). Since Jog movements (step distances etc) are



specified in WC, it should jog along X and Y WC axes. If G68 is active, this really mess up machine operation as people do not realize that they are not jogging in the WC direction that they commanded. Jog motions are specified as WC movements, but are not correct when G68 is active.

USE OF G68 WITH MACH V3 IS NOT RECOMMENDED until such time as G68 handing in Mach is repaired. MSM bug reports with G68 active will be declined due to the state of Mach v3 G68 implementation.


4.23 Mach TLO handling bugs Mach will not (it simply refused to apply TLO when the TLO value for the current tool = 0. Worse than that, if TLO is on, and you mount a tool for which the TLO=0, Mach will turn off TLO compensation. This is a Mach Bug that can really screw up a gcode program as it creates situations where Mach arbitrarily changes the state for the control system to be different than the state that the gcode program called for.

Verified on mach 3.xx.xx (and probably mach 2 series as well – this has been broken for a long time).

To understand what mach (incorrectly) does, let's start by dissecting the typical gcode tool change block (a block is the correct technical term for the set of gcode words that get executed together - in Mach a line in the gcode window is a "block"). I'll an example of T1M6. That block consists of two words the T1 and the M6. The gcode preparatory words could be executed in different blocks (different lines) as T1 M6 but it's quite common to see them together. The T1 says "the next tool will be #1" and the M6 says" change to whatever the next tool is". So the combined effect is that T1M6 is "Change to tool #1". When you enter this block via MDI and press enter, that is what happens - Tool #1 gets mounted. Now then, some users new to gcode have been known to expect the physical mounting of the tool to also activate the TLO associated with the tool, but that isn't how gocode



works. The activation of the TLO is done by another GCode - most common is the use of G43 (there is also a G44). G49 turns off TLO compensation. (Note that the important her is that TLO state is defined as being modal. Once the TLO state is set via gcode it is supposed to be persistent.) So the next block after a T#M6 in most programs is G43 H#. The G43 says turn on TLO compensation and use the value in the register given by the H#. the example this would be G43 H1. (Note that H3 does not have to = T#, but this is a common convention used by a lot of gcode programs. To avoid other bugs in mach, it is recommended that Mach gcode programs always use T#=H# for Mach v3). Try it - Do the T1M6 in mdi and hit enter - finish the tool change. then enter G43 H1 into MDI and hit enter - you will see that the "TLO active" led will come on. (IF and ONLY IF the TLO value for the Tool is NOT zero - this is a serious mach v3 bug described further a bit later in this text). If you don't tell the control to use TLO compensation it doesn't. This is how gcode is defined and is supposed to work. It is often important to be able to separate the physical change of the tool from when the TLO compensation is turned on. OK, I know - at this point you're thinking I'm nuts..... You're probably reading this and muttering something like "that idiot, he doesn't understand, it works when I put the number in the Current Tool DRO...." Typing a number into the Mach current tool DRO does turn on TLO compensation. IMHO it should NOT! Typing a number into the current tool DRO an pressing enter is the equivalent of (using your example) T1 M6 G43 H1 all at the same time. Note how mach assumes the H# to use when the Current tool DRO is used….. This is a place that Mach is being to damn helpful and assuming what the operator wants to do - that "I know better that the operator" attitude that mach has can and does cause trouble. Honestly, if I could change (fix) the action of the Current tool DRO in MSM, I would. It is best to just forget that you can type a value into the DRO (You will note that MSM does NOT shade it with a green border to indicate that it is a DRO that can take a value - if/when mach V4 ever arrives, I’ve been told it will not do this). Better practice is to always use MDI to do a tool change - and enter G43 T# when **you*** (not mach) wants TLO active.



You can use the G43 anf G49 buttons in the current tool panel to turn TLO compensation on and off (IFF the TLO value <> 0) - you will see as you do this that the WCOz does not change. What happens is that a value appears in the Tool offset column for Z when TLO comp is on. This is correct as the actual location of the WCZ0 does not move when TLO is on or off. TLO comp just tells the control (mach) where to position the spindle in Z to put the tool tip at the desired WCZ location. There is another TLO related case where mach will not do what you told it to: when TLO=0. What’s really annoying is that if you mount a tool which has TLO=0 (let say T#2), mach will turn TLO OFF – ignoring the fact that you told mach that TLO was ON by invoking the G43 modal state. Try this: Set up the tool table so that T1 TLO = -1.0 T2 TLO = 0 Use MDI to mount T1 and activate TLO T1 M6 G43 H1 The TLO light is on – you told Mach via gocde to enter the modal state G43. Now do T2 M6 Notice the TLO light – it is still on – as it should be ….. Now enter G43 T2…. The TLO light goes out…!!!!!!! No where did you tell mach to turn of G43 – but it does. Mach thinks it knows better than you do – and refuses to apply a TLO value of 0. (I guess that adding zero to another number is just to difficult for mach to figure out…. ). Many people never notice this odd behavior by Mach. But if you are using a master tool and hence Master tool mode in MSM, these mach bugs become very obvious (as the TLO for the master tool is always = 0). The recommended work around is to not use a cutting tool as the Master tool. That way the MT is never called up in a gcode programs, TLO will not be = 0, and mach will not screw up the gcode state by “trying to help”.



4.24 Art code 904 on exit of mach This appears to be a timing hole in mach that causes the error on exit depending on what is going on when you exit mach. Here is a “happens more often htan not” test case:

Start Mach with MSM, do nothing else - not even take mach out of reset Open mach help about dialog - see that the version is 3.43.35; close help dialog exit mach say yes to exit confirmation dialog - as mach closes, mach will give a “art code 904” dialog box. Say no to recovery attempt, and then you get the Windows “application has encountered a problem and needs to close” dialog. The art code 904 can be made to happen sometimes by just exiting without ever having reset mach between start and exit.

Verified on Mach 3.43.35 Does not happen on Mach 3.43.22

4.25 Mach RPM DRO 39 and Plug-ins. Some MSM users are using 3rd party hardware/software to derive RPM information. These products use a mach plug-in to nterface to their hardware and the pug-in code tries to update the mach RPM DRO (DRO 39). Two example I know of in the category are the Huanyang VFD plug-in and the VIstaCNC tach plug-in. With both the Huanyang VFD plug-in and the VIstaCNC tach plug-in, no index pulses appear on any input pin to mach. Hence Mach sets the value of DRO 39 to 0. Further, DRO 39 is "special" in that it is normally (almost always) is set by Mach - so if the plug-ins attempt to update the DRO from plug-in code, Mach will often overwrite the value the plug-in wrote. Which code (mach or plug-in) will be the last to update each time thru the mach 1/10 sec refresh loop, is indeterminate (I'm told mach runs this loop as as a timing race condition). There is a way for a plug-in to take over DRO 39 and update it - however, currently, a plug-in which attempts to do so must be a full motion plug-in - i.e. it must be handling all motion for mach (otherwise mach's motion code, including the code that updates DRO 39) is still being run.



Neither the Huanyang VFD plug-in or the VistaCNC tach plug-ins are "full motion" plug-ins. Therefore they are unable to update DRO 39. The requirement that only a full motion plug-in can update DRO 39 may change in a future version of mach, but that ability does not exist in mach as of today. To muddy the waters a bit more, it may have been possible for a non-full motion plug-in to update DRO 39 with some older versions of mach (it changed when art did some changes to how the mach driver determines timing) - this is likely the reason that the plug-in authors think they have seen it work in the past. In any case the mach versions where that may be possible are not mach versions that can support MSM. Until Mach is revised and a change makes it into a mach release, the only option is to have the plug-in update a user space DRO # and for the user to edit MSM to change the RPM DRO # from 39 to that #. Some "RPM plug-ins" already offer the ability to update an user space DRO instead of DRO 39. Because a) different plug-ins use different alternative user DRO#s, and b) mach does not provide support dynamically altering a screen DRO # at run time, MSM can't automate this for the user. If you are using a plug-in to derive RPM, then you will need to customize MSM for use with that plug-in. The good news is that this works fine as this is what several Huanyang plug-in users have successfully done to integrate MSM and the Huanyang plug-in. Update: As of Mach 3.43.37, Mach now handles the setting of the SETParam(RPMOverRide) flag differently. Apparently, this call was ignored if issued by a script in Mach versions prior to 3.43.37. AS of 3.43.37, setting the flag STOPS the mach driver from updating the RPM DRO (so that some other process can do so). This is a change in mach 3.43.37 that was not in the Mach release notes I suspect that any script or plug-in that tries to use this flag on mach prior to 3.43.37 will not be able to update the DRO 39. However, things may be working if the script or plug-in is setting the flag and mach is 3.43.37 or later.



4.26 Setting WCO DRO breaks corresponding MF DRO If you set a WCO DRO (830 OEM # series) to change the WCO for an axis, mach messes up the corresponding multifunction DRO for that axis. Apparently the MF DRO get put into MC mode instead of WC display mode. This happens only for the Axis that you set the WCO for. This results in some MF DROs being in WC mode and some in MC mode… so the user sees bogus DRO values. To avoid this write the desired WC value to the MF axis dro, this causes mach to set the WCO register value correctly and does not mess up the mode of the MF axis begin set. If you set the WCO via the DRO 47 # series, the WCo is set and the MF dro is not messed up. However, the 47 series WCO DROs do not always display the correctr WCO values. So it appears that you have to use the 830 series to get correct screen value displays, but use the 47 series to set WCOs directly. Verified on Mach 3.43.48

4.27 Mach handling of T#M6G43H# in a single block There appears to be a bug in Mach when it is asked to execute a single block of gcode that contains T#M6G43H#. It appears that mach is processing the G43H# part of the block before the M6 portion of the block has completed. In the Mach Gcode documentation, it says that mach will do the M6 code before the G43... but this is an area where weird stuff happens and it's been problematic for Mach in the past. Mach implements the M6 as calls to user scripts and it appears that Mach is not waiting for the M6 scripts actually end before it starts the G43 action. The result appears to be that Mach can do the G43 in parallel with the M6 sequence and thus the TLO gets (re)applied part way thru the M6 processing - that really upsets the MSM M6 handling code as it turns off TLO and then TLO gets turned on again out of left field... The symptom is that sometimes T#M6G43H# will work and sometimes it will cause a tool crash. The exact result each time depends on when different processes get the CPU... Recommended Work Around: Place the T#M6 and G43H# into separate blocks (separate lines). This removes the potential for parallelism as Mach is forced to finish one block of code before it can to the next one.



If you are using a CAM post processor that creates a single block for T#M6G43H#, change the post processor to emit two separate blocks (lines) of gcode instead.


4.28 Mach and AntiVirus programs CVI has experienced some odd errors from Mach while running Kaspersky 2011 Antivirus. There appears to be some interaction between how Mach opens script files and Kaspersky that can cause errors in Mach operations. The most common symptom is that Mach does not actually run the M6Start script as part of “stop & wait” tool change mode. When this happens, Mach does not report any error, instead it behaves as if the script were run successfully (when it fact is was not ever invoked). This of course messes up the MSM tool change logic and set things up for a later error during gcode execution. We have found that either disabling Kaspersky or setting Mach3.exe as a trusted file in Kaspersky resolves whatever this problem is.


4.29 Mach infinite loop if G31 w/ probe already triggered Mach has a bug when handling G31 if the probe is already triggered when the G31 is issued. The bug results Mach performing an infinite loop of motion. Test sequence to demo bug:

(Feed and distance #’s are in imperial units, same thing happens on Metric setup units machine). 1) Start machine 2) ref all home 3) zero X, Y & Z (WC now = MC) 4) MDI: G90 G54 x.5 y-.5 z-.5 (we will call this location P1) 5) taped probe shaft over so is permanently triggered 6) MDI: F40 7) MDI: G91 G31 X1 8) Mach shows error about probe already being triggered on the status line. This is correct, but mach seem to then fail to abort the G31 and instead this motion sequence starts: 9) At a feed rate of about f=0.4 (as shown on run screen for actual F rate) all three axes start toward 0,0,0 10) at around 0.2, -0.2, -0.2 the F drops to about 0.0001"/sec (this is where all the time goes.....)



11) Several minutes later, it seems to give up on this slow feed rate and then at the normal home reference motion rate it does the ref all action (X then Y then X) and goes to the home position. 12) then at the 0.4 F rate it starts moving back toward P1 13) when P1 is reached, it loops back to step 9) and this seems to go on forever. 14) hit esc key to kill motion. Verified on Mach 3.43.37 and 3.43.53. This has been verified by multiple users, on both a PP and SS system. You are not likely to see this Mach bug when running MSM later than 1.1.17.d4 as MSM added strict tests to try to avoid issuing a G31 command to mach if the probe is already triggered.


4.30 Lathe: Current Tool DRO changes wear offset If you select the current tool DRO, then type xx the current tool # will change to xx. This has all the same bad side effects (like only changing the T# and not loading the corresponding offset values) that occur in mill mode. Lathe mode has additional bugs when this is done: the wear index is also changed to XX, even though the operator did not enter any value for wear index.


4.31 Lathe: Geometry index <> Wear index Many of the same problems that mach has in mill mode when a H register is used that is not the same H# as the T# seem to be present in Lathe mode. It is worse in lathe mode because the syntax for a tool change (Txxyy) requires that both the Geometry index (xx) and the wear index(yy) be given. If you do specify XX not equal yy (perfectly valid syntax) many bad things appear to happen:

The offset DROs do not show the correct values for the active wear index (they seem to show only for xx=yy).

The mach mill bug of “no TLO if TLO = 0” seems to get applied for lathe and seems to be “no offset active if geometry offset values= 0” with a complication that if the geometry offset values in the yy row of the tool table = 0 the offsets get turned off (It should only look at geometry offsets in the XX row of the table).

Recommendation: Do not use Txxyy where xx <> yy Verified on Mach 3.43.37



4.32 Lathe: Tool nose radius being used w/o nose compensation active

I have observed cases where mach appears to be including the tool node radius in the MC to WC calculation – even though tool nose radius compensation (G41, G42) are not active

Verified on Mach 3.43.37 Reported fixed on Mach 3.43.62

4.33 Lathe: tool selection are not persistent Even when you have the general config option for persistent tool selection checked, mach does not start up with the same tool selections as when it was shut down.


4.34 Lathe: Tool path bad redraw When scrolling the tool path window contents, mach will incorrectly redraw the late stock. This appears to be a function of where the XZ zero is compared to the center of the tool path window. It is draw correctly when not near the center, but incorrectly for small distance on either side of the center.


4.35 Lathe: lset file rendering depends on record ordering Some observed facts: 1) when mach runs in mill mode, it enforces some (undocumented) rules for screen set objects. For example, tool paths are always rendered on top of other bitmap objects. 2) When mach runs in lathe mode the same rules do not apply - different rules seem to apply (exactly what they are is not known). I do know that in lathe mode, the rendering order of screen objects is dependent on the record order of objects within the lset file. 3) When Screen4 is used to edit a screen set file, the edited record is always moved to the last record of the file... Combination result: editing a lset file with screen4 can destroy the screen set appearance when screen4 reorders edited records - and that can cause things (like a tool path) to disappear visually.



Recommendation: No not use Screen 4 to edit lset files, use MachScreen. Machscreen does NOT reorder records. If you ever do get a screwed up lset file, Klaus has tentatively added a feature to machscreen to allow one to selectively reorder records. With this (not yet released) feature one can (sometimes) fix the mess made by screen4. You really don't want to have to be doing this. We (Klaus and I) have only inferred some of the ways a lset file can become messed up by record swapping - you are better off avoiding the problem.


4.36 Lathe: OEM DRO 800 <> DRO 0 series The 800 series OEM DROs fail to include G52/G92 offsets in the current position calculation. The older non-OEM series 0 DROs do the correct calculation. This failure only seems to be in lathe mode and not in mill mode for Mach.


4.37 Mach < 3.43.50 WC DROs are broken if G52/G92 is active Here is how I come to that conclusion: Basic Equation coordinate equation: WC = MC – WCOffset – G52/G92 For Y axis (I was testing with Y, but this will happen for any of X, Y or Z): WC = OEM DRO 801 (or standard DRO 0) MC DRO = 84 WCO = 48 G52/92 DRO = 17 My screen shots are for Y axis. I did this using MSM 1.2.0.d7 with the mill-turn screen set – made for an easy test environment for me. Start up Mach; I happen to be running in lathe mode, but I can make the problem happen in mill mode also. I used Mach 3.43.37. I’m sure 3.43.22 is also bad as I’ve been trying to isolate a test case for this for a long time. mdi G53 x0 y0 z0



mdi G92.1 – clears G52/92 dros to 0 Zero axis using button (the button does OEM Code 1009 for Y axis) Set All WCO = 0 (I just manually entered 0 into the WCO dro) Here is what mach shows:

Now I’ll build up to show the problem: Mdi G53 Y3 - Good

That’s a good result Set Y zero:

So far ok, to set WC to 0 at current MC, mach calculated the needed WCO and set it to 3 - good Now apply a G53 offset Mdi G52 x1

OK, and note that WC changed to account for the G52 offset that was applied. - good Zero Y (button) and you get

Good – the WCO was shifted as expected and WC = 0 MDI G92.1 Clear WCO dro = 0 So we are at G53 y = 3

WCO = 0 G52 = 0 - no offsets are applied…. Zero WC DRO:



WCO shifted as expected - good Mdi G52 Y1

First problem occurs: the G52 was applied, but the WC DRO was not updated! It reads 0 and it should read 3-3-1 = -1 The equation no longer balances. Now zero WC again

THIS IS WRONG. It appears that MC AND G52 were used with the target WC=0 to correctly calculate the WCO – which is correct at +2

HOWEVER: again the WC DRO is left showing an incorrect WC coordinate. Instead of showing MC-WCO-G52 it is showing only MC-WCO.

MDI Y0 – no motion occurs – as part of mach thinks (correctly?) that it is already at Y0, but the WC DRO shows +1 instead of 0 – you would have expected movement if you now do MDI Y1 you DO GET MOVEMENT and the result is

This is also bogus for WC value. From here mach is all screwed up – and the result is that any scripts that use the WC DRO to get a WC value are now hosed….

Verified on Mach 3.43.22 & 3.43.37 Fixed in Mach 3.43.50

4.38 Incorrect handling of non-WC X values in Diameter mode Mach has some serious bugs when running in diameter mode. From what I can observe, when in diameter mode, mach assumes that any value input (from the user via MDI or via a gcode file) is a diameter. That's a bad assumption.



It is a) only true for X axis values, AND b) only true for WC values (it is NOT true for MC or direct Offset values, like G52). The bug is that mach is (incorrectly) assuming that all X input values are diameters. Mach is not differentiating between WC and non-WC (MC or G52) input values. What mach is doing is mathematically wrong. It appears like mach is using a simple minded /2 filter on gcode input for all X word values (which would explain why MDI acts this way as it just inputs a single block to the mach gcode interpreter). This can be seen with MSM by going to the WC Offset page and watching the X line in the top panel where the MC to WC calculation is shown. For this sequence, start with all offsets = 0 1) MDI G53 x0 to start us from MC=0 which is also WC = 0

2) Now try MDI X4 You will see that we end up at WC=4 and MC = 2

mach took the input value (4), divided by 2 to get 2, applied the offsets (all 0) and sent the machine to MC=2, which is what should happen. Now for the bugs: 3) Next try MDI G53 X2 we are already at X2 so no movement should occur. But mach screws up - the G53 X2 is converted (incorrectly) as mach treats the G53 X word as a diameter value (which it is not). So G53 X2 gets converted to G53 X1 and the axis moves because we were at 2 and mach now thinks we told it to go to X1.

Re DRO values, the mach MC DROs do show the correct MC location at any given time (I.e. they do NOT multiply by 2 before putting the value into the MC DRO).



The problem is in Mach's handling of X value in diam mode - mach is not differentiating between WC and MC values when processing gcode. It gets worse... consider G52. 4) Input G52 X4 ... what should you get? I claim you should get a G52/92 offset value = 4; but you don't, instead you get a G52.G92 offset value = 2.

That's wrong. Mathematically an offset is a dimensionless unit. Mach should not be assuming a "diameter unit" for a dimensionless quantity and then doing a conversion. 5) Now try G92 out.... MDI G92.1 to reset the G52.G92 offsets.

MDI G92 X-4

At least this works - we want to set the G92 offset so that the current MC position becomes WC = -4. Mach takes the -4, divides by 2, and uses the result to calculate the desired G92 offset - and it gets that right. (probably because the data flow in this case matches the assumptions of the broken diameter input filtering). Finally, if you write to the Mutlimode DROs, mach does get the WC offset calculation correct. Enter 10 into the X DRO:

Writing to a MM DRO causes mach to set the WC value (independent of the mode the MM DRO is in, it will set the WC value) this requites that mach calculate the correct WC Offset to get the WC to become the specified value; fortunately mach correctly calculates the required WC offset. When running diameter mode, you have to be very careful of what you do because thee



bugs will bite you. If it were not for the fact that many lathe gcode programs are written for diameters, I'd not run mach in diameter mode in order to avoid these bugs.

Verified on Mach 3.43.37 (broken on all versions tested, these are very old mach bugs)

Fixed in Mach 3.43.62

4.39 Lathe current tool # DRO accepts T# > 99 In turn mode, tools are selected with the T word and the format is Txxyy wher xx is the tool number and yy is the tool offset index. Thus neither the tool # nor the offset number can ever be > 99. In fact the mach will throw an error on T words with more than 4 digits. However, the mach current tool number DRO, accepts #s larger than 99 when mach is in turn mode. Thus typing 0101 into the current tool DRO will result in a tool number = 101 and an tool offset index = 0 – and that is not what you intended!


4.40 Mach, windows focus and Referencing Changes made to mach re windows focus and jogging has broken the reference operation. Start a reference sequence then shift the focus shifted to another window. That will stop the reference movement that was in progress (as if the home switch had been found). One can sort of understand the motivation behind stopping a manual jog motion if focus shifts away from Mach when that motion is being driven from a hot key being down . However, a focus shift should not terminate a reference operation. Actions that a script is doing can't be subject to interruption due to the windows focus leaving mach. Any focus shift event will act like an termination interrupt to running scripts and that messes up any scripted action if the focus leaves Mach.

Verified on Mach 3.43.38+ Fixed in Mach 3.43.59

4.41 Mach Turn tool path mirrored bug Here is the “tool path mirrored” bug description:



In mach releases up to and including mach 3.43.56, I load some test code and I get this for the tool path display (as expected):

But as of mach 3.43.57 and 3.43.58, loading the exact same gcode file, with the exact same settings, results in this tool path display:

Both the above pics are from mach running in diameter mode.

Verified on Mach 3.43.57 and 3.43.58 Fixed in Mach 3.43.59



4.42 Mach Accepts Mill G43 and G49 without error in Lathe mode You can issues G43 and G49 to mach in lathe mode, this does not cause an error message from mach, and the results are unpredictable.

Verified on Mach 3.43.58 and 3.43.59

4.43 Mach not running ScreenSetUnload This used to work in mach 3.43.16 when it was first tested. Sometime since then, it has gotten partially broken. SSU seems to get run when unloading the main screen set to load another screen set. SSU is not being run when unloading in order to load a wizard screen. SSU is not being run when mach shuts down (or it is being started and mach is not waiting for it to finish? Hard to tell). Because SSU is not getting run, MSM is not calling UserSSU scripts per the manual.

Verified on Mach 3.43.37, 3.43.58 & 3.43.59

4.44 Lathe Offset DRO changes not correctly handled You can write the Lathe mode Offset DRO (245), this dynamically changes the offset index and hence the X and Z offsets in effect. The X & Z offset DROs change correctly, but the WC DROs do not update – they appear to continue using the prior offset values. This makes the WC position reported wrong. Remounting the tool, will cause the WC DROs to get reset to using the new offset. Recommendation: do not use the Offset index DRO to change offsets dynacmically.

Verified on Mach 3.43.38 & 3.43.59

4.45 Lathe: Mach accepts M6 w/o error in lathe mode Mach seems to not be very good about syntax checking of gcode when in lathe mode. If you type T2M6 (which are mill mode G-Code words) on the MDI line the result is not very sensible. I might expect mach to take the T2 as a short version of Txxyy and treat it the same as T0202. The M6 however, should have caused a syntax error as M6 is not a valid lathe mode M-Code (according to the mach manuals).



What happens is less than useful: a tool change sequence is started by mach, but at the end the current tool is not changed (the current Tool # is the same as before the sequence was executed). That hardly seems to be a useful action for Mach to have done. Unfortunately, fixing this will probably break all code generated by old lathe wizards as they (incorrectly) issue Txxyy M6 as a tool change line which is both redundant and syntactically incorrect.


4.46 Lathe: Mach calling M6start when in Ignore Tool Change mode

Mach is doing auto tool change calls to M6start for ignore tool change mode. M6start should not be called for ignore TC mode.

Verified on Mach 3.43.59 Fixed in Mach 3.43.62

4.47 Lathe: Resume from FeedHold Causes Machine Crash There is a very serious bug that causes Mach to crash a machine (does multiple un-commanded moves and runs tool thru part). WARNING: DO NOT USE FEEDHOLD for Lathe in mach 3.43.56 thru 3.43.59! This was apparently a side effect of a prior change to mach.

Probably broken in 3.43.56 (Dec 27 2011) Verified broken in 3.43.59 (Mar ?? 2012) Fixed in 3.43.62 (Mar 31 2012)

4.48 Lathe: Mach accepts G49 w/o error in lathe mode Mach seems to not be very good about syntax checking of gcode when in lathe mode. If you type G49 (which is a mill mode G-Code word) on the MDI line the result is that Mach will cancel Tool offsets in lathe mode. Additionally, when this happens mach does not always update the tool offset DROs with “no offset” values.



G49 should cause a syntax error. Use Txx00 to cancel offsets for a specific (xx) tool number, or T0000 to both “mount no tool” and cancel tool offsets. This is a problem because some of the mach lathe wizards apparently emit G49 words, thus running code from some wizards will cause mach to display incorrect tool offset values.


4.49 Mill: Mach ignores wear DROs While the Diameter Wear DRos can be set, it appears that mach is ignoring them. Thus changing a wear value appears to not have an effort on paths generated with cutter comp.


4.50 Lathe: X Offset DRO displays incorrect value in diameter mode

The Mach DRO (OEM number 108) displays an incorrect value when an X offset is applied and Mach is in lathe diameter mode. The value displayed is multiplied by 2 compared to the actual (correct) value. The visual symptom in MSM is that the X row Tool Offset value iun the coordinate calculation panel on the WC offsets page of lathe screen is incorrect. This appers to be a DRO value display only issue as the correct value is being used by mach for the MC to WC calulations.


4.51 MDI vs screen set loads. If an mdi control is activated (then used or not) and then deactivated, and the next action is a screen set load; mach will crash from an unhandled exception in Mach.exe.

Verified broken in 3.43.62 Fixed in 3.43.65

4.52 DRO values can be incorrect when read It appears that on some version of mach that DRO values are not updating before the SetOEMDRO call returns.



This code will demonstrate the problem: SetOEMDRO(800, 2) Sleep 500 SetOEMDRO(800, 5) Msgbox “ x value = “ & GetOEMDRO(800) Sleep 500 Msgbox “ x value = “ & GetOEMDRO(800) The two sequential message boxes will give two different values for DRO 800 – first 2, then 5…. This appears to happen with DRO #s < 1000 but not for #s > 1000. The difference is in how mach internally processes the Set operation. For DROs < 1000, it can take 200ms for the Set value to be come active. This means that a script writer has to be very careful about doing anything that would rely on the Set value being correct within 200ms of the set operation. The alternative would be to insert a 200ms delay after every SETOEMDRO operation (which would be very expensive for script performance).

Verified broken in 3.43.37 and 3.43.66

4.53 Windows Non-English Regional Settings Not supported by Mach

Operation with non-US regional settings is not supported. Users are strongly advised to set Windows regional (international) settings up so that the “.” is always used the decimal point character. If a separator char is used, it must be the “,” character. Mach itself, and the Cypress basic interpreter used inside of Mach, do not support internationalization and always assume US/English formatting for all numbers. Attempting to use non-US settings can cause various faults when running scripts. These are fundamental Mach problems which can’t be fixed by MSM.

4.53.1 Cypress Basic’s IsNumeric function bug with non-English number formats.

The Cypress Basic function IsNumeric only handles US/English number formats. For European formatted numbers (comma as decimal point etc), it returns incorrect results.



This caused the MSM browse edit dialog to not work “correctly” on some non-US windows international settings in the sense that numbers in non-English format are not accepted as inputs. While it may be desirable to support windows international settings in MSM, CVI has confirmed with ArtSoft that Mach (v3 series) ignores all international operating systems settings. Therefore MSM could only implement this for a very small subset of the overall Mach user interface. It was decided that it is better to have consistently use US-format numbers rather than have different dialogs handle input differently. Therefore user are advised to always use “.” as the decimal point character for all Mach dialogs and DRO input. The “,” character is treated as a digits separator (and not a decimal point, no matter what the Windows country settings are).

4.53.2 Cypress Basic’s number conversion functions are not aware of international settings.

Example: In real Microsoft VB, the cDbl function will parse string representations of numbers that use non-US settings and generate a valid double result. However, the Cypress cDbl simply faults with a type exception when it runs into a non-US format number string.

4.54 Mach does not wait for Mcodes to complete, resulting in unpredictable parallel execution of Gcode blocks.

An mcode in a GCODE block is supposed to complete before the net gcode block is executed. However, Mach is NOT waiting for mcodes to finish before continuning the motion queue. The trouble appears to be that Mach fires off an Mcode as a separte thread and then does not wait on the thread. This means that scripted Mcodes are actually executing in parallel with gcode that is supposed to be sequential. This appears to work most of the time because most mcodes are short for execution time. However this becomes a serious problem if mcodes take any significant time to complete. Considerthis test case which fails 100% of the time. This test code doe not use any MSM specific calls and fails with the stock 1024 screen set. ' this is a test case to show that mach is not waiting for mcodes to complete before continuing.... ' testing with mach 3.43.66 with PP Code("M1703") ' this mcode opens a dialog box and deos not return... it could just as well do a sleep <big number> etc. While IsMoving()



Wend ' the motion below should not start until the mcode is finished... ' however, this script code fails to wait for the mcode to finish. 'The following move starts immediately after STARTING the Mcode - not after the MCOde finishes! ' from what I can test, this appears to be true for all mcodes - including mach built in mcodes Code("G91 X10000 F10") Exit Sub ' here is the content of the M1703 used for this test: Option Explicit Const YesResponse = 6 Const OKResponse = 1 Const Debug = False WaitMsgbox: If MsgBox("Forced wait in Mcode - continue?", 4+48+256, "Forcing wait in mcode!") = YesResponse Then ' OK, time to go on..... 'DoSpinCW() ' this is a problem, as mach will start cutting motion before the spindle is started! Else ' we got a resposne to the dialog other than "yes" sleep 200 ' to give time for status line to see the next message Message("M1703 not exiting") GoTo WaitMsgbox: End If Message("M1703 Complete") Exit Sub

Verified broken in Mach 3.43.66



4.55 Mach fails to compile large scripts Internal development fo MSM has identified a bug in Mach3 where large scripts will not get compiled. Mach fails to create the .mcc file but issues no error or warning. The result is that you can find that changed source code does not result in changed binaries. Artsoft is no longer supporting Mach3 (Nov 2014) and has not been doing so for some time (Even though they do not state this on their web site for the produict), and the only known work around is to reduce the size of the library.


4.56 G49 and G52 in same block incorrectly calculates G53 position

If you have an active TLO value (EX: -2 inches) and you attempt to execute this gcode block: G69 G53 Z1 You would expect the G49 to cancel the active TLO value then mach should do a G53 move to Z=1. However, mac will incorrectly attempt to move to Z=-3. Apparently mach fails internally and is adding the former TLO value to the G53 Z calcul;ations. This is clearly incorrect since G53 is a machine coordinate move and is totally independent of TLo active or not.


4.57 #Expand broken in wizards The mach programmer ref manual says: 1) if a wizard is NOT loaded (I.e. a regular screen set is loaded, the preprocessor will look for the path-spec in <Mach install dir>\ScreenSetMacros\<ActiveScreenSetName.set>\ 2) if a wizard is loaded, the preprocessor will look for the path-spec in <Mach install dir>\AddOns\<LoadedWizardName>\ The #expand search path is broken when a wizard is loaded; mach is not searching in a location that can ever be found (the search path is malformed by mach).




4.58 GetActiveScreenSetName() broken when wizard loaded When a wizard is loaded, instead of returning the name of the loaded screen set (which would be the wizard name), mach is returning the entire path to the loaded wizard including the extension. Example: If the wizard MyWizard werer loaded, the returned value should be “MyWizard”. However, what is being returned is “C:\Mach3\Addons\MyWizard.set”


5 Smooth Stepper Specific Errata This Section contains the known errata for Smooth Steppers which have been observed while using MSM and are verified bugs.

5.1 SS moves X when only G31 Y motion was commanded. When using a SS (USB or Enet), and running MSM Mill-turn (so Mach is in lathe mode), and Mach is in diameter mode, A G31 Yxxxx command will also cause X movement (in addition to the commanded Y movement). The problem does not happen when using a PP, but has been verified with both the Enet and USB Smooth Stepper. Environment:

mach 3.43.59, lathe mode, diam mode; Command: G91 G31 Y-xxxx movement ENet SS plug-in: ESS_v10da2 USB SS plug-in: v17efb

Here is the summary of the tests: G31 Y vs motion control devices & radius/diam mode test results Command Interface PP SS Enet SS USB Radius Diam Radius Diam Radius Diam

G31 Yxxxx OK OK OK Moves

X OK Moves

X



Update as of Apr 9th, 2012: This is fixed with a change to the SS plug-in. The fix is in these SS plug-in versions (and later versions):

USB SS: V17efe.zip Ethernet SS: V10da5.zip

6 MachStdMill Reporting and Feedback The MachStdMill user community forum at the

The CVI MachStdMill User forums at www.CalypsoVentures.proboards.com is the primary vehicle for end user support for MachStdMill. Please direct any support issues, including installation questions to that forum. Please report any bugs or errata discovered.

7 MachStdMill Release Version Changes Changes between 2.0.0 (the first of the MachStdMill 2.x product releases) and the latest release are in this section.

7.1 V2.0.0 (MSM Production Release): • First 2.x.x Major version level product release of MachStdMill.

o This release has all MSM 1.1.x Mill updates • This is also the first MSM production release with

o Lathe/Turn Support o Mill-Turn Support

• The MSM personal Edition is now available without a license fee (i.e. $0 is the

license fee) . o This provides the MSM GUI for Mill and Lathe to any Mach user. o As with prior versions or MSM, the Personal Edition is only licensed FOR

NON-COMMERCIAL USE. Any Commercial use requires a licensed MSM professional version.

7.2 V2.0.1 (CVI internal release): • Additional functions added to OEM licensed interfaces

http://www.calypsoventures.proboards.com/



7.3 V2.0.2 (MSM Production Release): • Bug Fix: An internal routine to check the probe calibration diameter was being called

when calibration mode not active. This resulted in an error message when attempting to do a circular extrusion probe if the calibration diameter DRO was 0 (which is the default value if it's never been used).

• Added Timing LED to Hardware Signals page. This had been omitted from MSM as

the Mach Parallel Port driver does not use it, but some other hardware interfaces do.

• Bug Fix: The hardware page, set steps per unit script was leaving the machine in G91

mode on exit, it should have left it in G90.

7.4 V2.0.2.1 (Limited distribution beta): Change: When editing a tool table entry, MSM used to treat the condition of Tool Diameter + wear diameter < 0 as an error (a tool can’t physically have a < 0 diameter). This was changed to a warning so that small negative net values could be used for Cutter compensation purposes.

7.5 V2.0.2.2 (Limited distribution beta): Fixed bug where test for net diam of tool (mill mode) < 0 was delayed by one dialog box edit cycle.

7.6 V2.0.2.3 (Limited distribution beta): Fixed bug where two flags that control OEM probing config options (G91G31 and G31ToCP) were indicated by the same LED #.

7.7 V2.0.2.4 (CVI internal): Changes some labels in the probing debug dialog box.

7.8 V2.0.2.5 (Limited distribution beta): Fixed bug where the return value for some OEM calls was incorrect.

7.9 V2.0.2.6 (Limited distribution beta): Mill: Tentatively Changed total diam = diam+wear to Diam-wear (wear is a positive value).



Mill: fixed bug where Browse panel was updating current panel leds for Empty Tool and RH/NRH LEDs instead of the browse panel LEDs.

7.10 V2.0.2.7 (Limited distribution beta):

Fixed bug: If an older format MSM tool table was loaded (pre MSM lathe support), the tool description strings could get shifted by 1 Tool # during MSM initialization.


Internal CVI clean up changes


More internal CVI clean up changes


Fixed bug in low level probing routine that only impacted special setups for Galil controls.

7.14 V2.0.3 (Limited distribution beta):

Bumped revision from 2.0.2.10 to 2.0.3


Fixed bug: Yridge probing routine calculated a transversal height that was too high if ExtraProbeDepth was active.


Added “mm” indiacator that was missing from current tool panels on WC offet pages for lathe screens (was in current tool panels on other pages).

7.17 V2.0.4 (Production Release):

Converted 2.0.3.2 beta to new production release.

7.18 V2.0.4.1 (CVI Internal Release):

Bug Fix: Lathe mode MT#=PT#=0 caused infinite message loop.



Bug fix: Altered “-“ to “+” on WC offsets MC to WC calculations for wear value. This now matches what mach would actually do with the wear value in the equation – when mach is not ignoring the wear value all together.

New Mill Feature: Added a display of the current H register value to the Run page. Not that this feature will only work correctly with mach 3.43.66 or later. Prior to mach 3.43.66, the mach DRO (245) is not updated in mill mode. With earlier version of mach, the DRO value will always be 0.

New Lathe feature: The ability to set front/rear tool post has been added to the lathe tool edit dialog. This will not appear in the dialog unless the running mach version is greater than 3.43.66. This is because prior to that version, there were no Script APIs to get or set this tool attribute.

7.19 V2.0.4.2 (Beta Release):

Bug Fix: Corrected a couple of mis-numbered paragraphs in the MSM user manual.

7.20 V2.0.5 (Production Release): Changed 2.0.4.2 into 2.0.5 release Added a note about mach not handling non-international settings for number formats for DRO or dialog box input/output to release notes.

7.21 V2.0.6 (Production Release): Corrected link to CVI store for Activation dialog to match store update. (relevant for Professional Edition only)

7.22 V2.0.7 (Production Release): Fixed bug where a corrupted PTL entry in the mach tool table would cause MSM’s tool table save as to fault (impacts Pro Edition only). Updated © notices for 2013

Fixed bug: if running with windows regional (international) settings as something other than US where the decimal char is the “,” instead of the “.” a tool table saved to disk by MSM could contain international formatted numbers. This caused a problem when attempting to use MSM load tool table as Cypress Basci (the script interpreter inside



mach) is not aware of regional settings (it always uses US setting no matter what the windows settings are) and this would cause a fault when loading the TT file. Now the files are forced to have US format numbers only.

7.23 V2.0.7.1 (Limited Distribution beta release): Fixed a possible bug in lathe tool table Load and SaveAs when tool units not equal to display units.

7.24 V2.0.7.2 (Limited Distribution beta release): Added MSM 6 axis screen set for 12x9 resolution. This removes the FRO and SRO sliders from the run page, when using 5 or 6 axes, the sliders will have to be accessed from the fly out (as is done when running the 10x7 resolutions screens).

7.25 V2.0.7.3 (Limited Distribution beta release): Fixed bug where Tool Description would not get written to MSM lathe TT file. Documentation Supplement: A common question asked by users is “what is the relationship between Mach’s Tool table and MSM TT files”?. The tool table structures used by Mach and MSM are diagramed in the figure below:



Mach & MSM & tool tables

Mach’s in memory tool table; Changes only apply to the

current mach session!

Tools3.dat saved in current

profile dir(contents are loaded by

mach on start up)

“Save Mach TT”Action causes mach toWrite mach’s session Tool table to tools3.datIf you do not do this, tools3.dat is NOT updated!

MSM .m3tt Tool table file;

Stored on disk in location picked by user

MSM TT “SaveAs”Action causes MSM to write mach’s TT to disk.

MSM TT “Load”action causes MSM to read file & replace contents of mach’s session tool table.

7.26 V2.0.7.4 (Limited Distributuon beta release): Fixed bug in make file that didn’t recompile script for TouchLatheYOffset button when needed. This left the button thinking it was on a personal edition and it would refuse to execute.

7.27 V2.0.7.5 (Limited Distribution beta release): Added beta Plasma specific 10x7 and 12x9 screen support.

7.28 V2.0.7.6 (Limited Distribution beta release): Fixed a SaveAs bug that could let eFormat numbers get written to the MSM Tool Table file.

7.29 V2.0.7.7 (Limited Distribution beta release): Added a fixed offset value DRO for Y in Mill-Turn mode. This supports tooling fixtures where the turning tools are not mounted on a quick change tool post, but are mounted to a plate in the style of gang tooling. Each turning tool would be at a different Y location.



Typically this is used as follows: The master tool is used to determine the reference location. Each of the other tools might be spaced evenly along the tooling plate, for example 2.75” apart. When setting the Y offset of these tools, multiples of the 2.75” spacing needs to be added to the Y offset total to get the tool to go to Y center when the Y offset is applied. If the master tool were tool #1, and each of three additional tools were located at multiples of 2.75 inches (in Y ) from the master, then the fixed Y offset value for each tool would be: (tool # - 1) * 2.75” However, such geometric knowledge is not built into the Y touch off interface (there is not calculation done based on tool number) as this would build a tool fixture geometry into MSM. Instead the implementation is generalized and simple:

The value entered into the “Fixed Y Offset” DRO is added to the value calculated from the Y nub measurement and the total is entered into the tool table as the Y offset.

For turn tooling held in holders for a quick change post (an example shown in the MSM lathe manual) this DRO would typically be set = 0 (as all the holders are at the same general Y location and you can let the Y offset from the nub measurement handle differences from tool to tool (say for insert height).



7.30 V2.0.7.8 (Limited Distribution beta release): Corrected bug in Move to Y0 button for Mill-turn; it worked in G90, but not G91 mode. Code now works correctly for G91 also. Changed Ref-all script: All enabled axes are now referenced. This supports the 5 and 6 axis variations of MSM so that all enabled axes get referenced. Added RefWait call to normal reference operations – this forces the ref actions to be sequential as the Calls are speced, even though mach does not always execute the calls as blocking sequential calls.

7.31 V2.0.7.9 (Beta release): Fixed Ref-all home script – 2.0.7.8 version would not run due to a missing declaration in a header file (the change did not get picked up in the 2.0.7.8 build).

7.32 V2.0.8 (Production Release): Taking 2.0.7.9 beta to production status.

Removed Plasma specific screens from Beta. Not enough feedback to meet production release criteria. If anyone wants the plasma screens and is willing to report on test results with them, contact CVI and we can make a new beta with the Plasma screens in it.

Bug Fix: Ref-all home script would not home for Lathe mode unless Mill-Turn home option was set. In MSM beta 2.0.7.9 a bug was introduced that would not home in standard lathe mode due. This has been fixed in the production release.

7.33 V2.0.9 (Production Release):

Bug Fix: Ref-all home Script was using updated Ref-all home logic in MSM 2.0.8. Alas, the code tries to avoid some mach internal bugs that cause reference operations to fail. The same timing holes make the 2.0.8 MSM ref code fail on other machines…. You just can’t win. So the decision is:

The ref all home script will default to the old (mach 2.x) reference code. This causes the least number of support issues as it is exactly the same code still used in mach 3.43.x. 1024 screen set.

However, the old code is not recommended for 6 axis screen set use (as it will not reference B or C axes. There is a simple const flag at the beginning of this script that will control the type of ref code used. The ref-all Home script has always been supplied in source form sine users often need to modify it. This just becomes one more modification choice that a user can make.



7.34 V2.0.9.1 (Limited Distribution Alpha Release): • Added hook support for a user M6PostATLO script. This is the mirror of

M6PreATLO, same conventions, placement in the profile directory etc.. M6PostATLO is called immediately after the ATLO tool measurement is completed.

• Added support for a 2 input signal approach to interfacing Probe and TP devices. Note: The MSM Mill user documentation has not yet been updated to reflect the existence of this “Two Signal” probing device interface option. Prior to this release, MSM used the Mach Probe input signal and it was assumed to be on a single input pin. This required all “probe/digitizing” devices to be electrically interfaced to the single pin because we can only connect one pin to one signal into mach.. When the mix of devices included both active high and active low devices, some simple electronics was required to combine the device signals, wire-or them and present the composite signal to the one pin and hence the one Probe input signal into mach.

MSM now supports interfacing a probe via one input pin and the touch plate(s) on another pin (diffferent Mach input signal). This removes the need for the external interface electronics at the cost of using one additional physical input pin & one more input signal into Mach.

The choice of the standard “one signal” interface and the “two signal” interface is controlled by the definition of the Mach Timing input signal in the ports & pins dialog. • To use MSM with only the Probe input signal, the Timing input signal must NOT

BE enabled in the ports & pins dialog. • The “two signal” interface will be used if the Timing input signal is enabled

in the ports & pins settings.

When configuring the “two signal” interface, the probe and touch plates are wired to different pins of the break out board.

• The Probe tool must be connected to the mach Probe input pin and the Probe signal must be enabled in ports & pins. The other Probe signal pin attributes (active high/low etc) may be configured as needed for the probe device being used on this pin.

• The Touch plate(s) must be connected to the pin for the mach Timing signal. The other Timing signal pin attributes (active high/low etc) may be configured as needed for the device(s) being used on this pin.



There are some restrictions that must be followed in order to use this “two signal” interface approach:

1) The Mach Probe Signal and the Timing Signal must both be defined and enabled in the Mach Ports & Pins dialog.

2) Both the Probe and Timing Signals must be on input pins. 3) The Probe and Timing signals must be defined on the same Port. This is

crucial, as the interfaces will not work correctly if the two signals are defined on pins that are on separate ports. Attempting to use separate ports may result in machine crashes during probing operations.

Technical notes: 1) The “two signal” implementation makes use of the Mach Timing input

signal. The timing signal was deprecated in mach is no longer used by Mach in the 3.43.xx series, however it is still present in the ports & pins table. This made it a easy signal for MSM to repurpose and use as the touch Plate input.

When using the standard one signal interface, all devices present the single Probe input signal to mach and hence to MSM. Effectively all devices are “OR’ed” together and any device that is triggered will cause an active probe input signal to mach. A convenient side effect of this is that any device will cause the MSM Probe LEDs to turn on when any device is triggered, which makes it easy to manually check the devices for connection and correct operation,

When using the “two signal” interface approach, the probe signal is the default input signal that mach and MSM use. The Touch plate input (the mach Timing signal pin) is dynamically selected during a probe operation and is used to “replace” the Probe signal input only when the touch plate is in actual use for a probing operation that uses a touch plate.

This makes the Probe input the active input 99.9% of the time. Thus pushing on the probe will toggle the MSM Probe LEDs. However, it is now effectively impossible to use the MSM probe LEDs to test the touch plates – as the touch plate signal is only “connected thru mach to MSM” for brief periods during the course of a TP probe operation. This is an unavoidable consequence of the two signal interface implementation.

2) Some break out boards have implemented the electronics required to use

mixed active high and active low signals, combine them and feed the combined SINGLE input signal into mach as the Probe signal (the PMDX 126 is an example of a breakout board which offers this features). In this situation there are two wires, from two devices, connected to two screw terminals on the break out board. HOWEVER, only one signal is provided as input into mach. This is a “one signal” (two pin) interface situation (not a two signal, two pin interface) as mach (and MSM) are only using the single Probe input signal.



Do not confuse this with the Two signal interface. The two signal interface also uses two wires and two physical connections (pins), but it also presents two separate logical signals to mach (one from each input pin).

3) The Two signal interface requires the use of a Mach script interface that is not present in a Mach LockDown release prior to mach 3.43.66. MSM checks to see if the two signal interface is being used and also checks the mach version. If the combination is in compatible, a prominent warning is displayed to the user when MSM starts. MSM allows mach nad itself to go ahead and startup (so that the user can either use the mach ports & pins dialog to rectify the conflict or update the mach release.

Ignoring the warning is a very bad idea!!!

4) The MSM Mill user documentation has not yet been updated to reflect the existence of the “Two Pin” probing device option.

7.35 V2.0.9.2 (Limited Beta Release): Added 2 signal probe/touch plate interface info to MSM mill user manual. The probing two signal interface feature and the M6PostATLO script support (both introduced in MSM 2.0.9.1 alpha) have moved from Alpha to Beta status with this release.

7.36 V2.0.9.3 (Limited Beta Release): Optimized two signal interface handling; fixed some two signal interface bugs

7.37 V2.0.9.4 (Limited Beta Release): Fixed Master tool button bug from bad build of file on 2.0.9.3

7.38 V2.0.9.5 (Beta Release): Fixed a Two signal interface bug

7.39 V2.0.10 (Production Release): Moved 2.0.9.5 beta to production status – this makes the “two signal” interfacing available to those that need it w/o having to run a “beta”.



Fixed: removed an extra Axis DRO LED (for Y axis) from 10x7 lathe wC offset page.

7.40 V2.0.11 (Production Release): Updated © notices to 2014 for OEM releases.

7.41 V2.0.12 (Production Release): Corrected axis display errors on run screen for Mill-Turn 12x9

7.42 V2.0.13 (internal use only):

7.43 V2.0.14 (Production Release): Added test for condition that Probe Tool # = Master Tool # and Master tool mode is ON, if the Active TLO value for the PT/MT is not = 0, then probe operations abort. This detects a condition where the MT TLO value has been either incorrectly set or changed by gcode. An incorrect TLO value for the MT in MTM when doing Z probe ops could cause a probe crash. Bug Fix: M4, after spindle disabled check could start spindle CW instead of CCW.

7.44 V2.0.15 (Beta Release): Due to discovery of the mach bug (See section 4.54) re not syncing Mcodes for scripts, MSM needed to invent a way to make common mcode calls in sync from a script. MSM can only help for the mcodes that mach allows access to – thus we can make M3 and M4 sync. We could do M5, but it has not been a problem so choose not to have to add an MSM specific version of M5 to the release. We can’t do anything for the other builtin mcodes (ex: M7,8,9). What we did is to add a user led definition: Const M3M4WaitSyncLED = 1778 ' a work around for MSM to support sync wait for Mcodes started via code() This LED is turnd off by MSM’s internal M3 and M4 routines as the last step before exit. To use this instead of doing Code(“M03”) do



M03WithWait() or M04WithWait() where those routines are define as follows: Sub M03WithWait() ' the purpose of this routine is to cause a pause until the M3 seqience is completed. ' this is needed because mach (3.43.66) is not waiting for M3 to complete before continuing (That is a mach bug that is unfixed as of mach 3.43.66)... ' so we invent our own primitive sync signaling for M3 to try to avoid the mach bug. ' ' Parameter: none ' start the tool change sequence to mount the tool SetUserLED(M3M4WaitSyncLED, 1) Code("M03") While GetUSerLED(M3M4WaitSyncLED) ' M3 in progress sync LED is on, wait for it to go off sleep 100 Wend Exit Sub End Sub Sub M04WithWait() ' the purpose of this routine is to cause a pause until the M4 seqience is completed. ' this is needed because mach (3.43.66) is not waiting for M4 to complete before continuing (That is a mach bug that is unfixed as of mach 3.43.66)... ' so we invent our own primitive sync signaling for M4 to try to avoid the mach bug. ' ' Parameter: none ' start the tool change sequence to mount the tool SetUserLED(M3M4WaitSyncLED, 1) Code("M04") While GetUSerLED(M3M4WaitSyncLED) ' M3 in progress sync LED is on, wait for it to go off sleep 100 Wend Exit Sub End Sub Note there is already a way to wait for M6 to complete and a way to wait for ref axes calls to complete.



7.45 V2.0.16 (Beta Release): Recompiled Probing library. Some of the changes that should have been in 2.0.15 were not in the compiled library. This happened because there is an interactio9n between Win7 and the automated build scripts that cause dir trees of more than a certain depth to not show all the nodes of the tree. Added more robust recovery handling of a hung probing debug log (due to mach not correctly calling a script error handling block). The lib will now try to delete an existing log file if it detects the hang condition.

7.46 V2.1.1 (Internal Beta Release): OK, I think I finally have figured out why the last few changes made to the probing library were doing nothing… because the library was NOT being compiled. Apparently the MSM probing lib has grown to some size that causes either mach or the cypress compiler to fail when asked to compile the Lib script – and the failure is silent, no error, no warning. Thus while the source was changed the compiled binary was not getting changed. SO… all changes after 2.0.12 have not really made it to release… sigh. Since there is no longer any support for Mach3 from Artsoft, the only choice appears to be to shringk the size of the Probing lib. To do this, the TP and TLO probing routines were separated out into a new 2nd lib. This reduces the size of the original lib by enough to avoid the mach non-compile bug. Compatibility Warning: Any existing scripts that are calling the MSMProbing Lib directly and are using the TP or TLO functions will need to be updated to call the new MSMProbing2 Lib instead. We suspect that this will not impact any MSM end users, but may impact some MSM OEM customers. Because this library split creates a significant change in the internals of MSM, the minor version has gone from 2.0.x to 2.1.x. This forces the MSM installer to uninstall the 2.0.x version before installing 2.1.x. Assuming nothing else was broken during this lib restructure, there should be no end–user apparent difference in probing functionality. A positive note: Now that this restructure has been done, it is again feasible to implement additional probing features.



7.47 V2.1.2 (Limited Distribution Beta Release): Completed the split of MSMProbing into two libs. Corrected some bugs in the debug log file handling logic introduced in 2.0.16 (which were not in the binary lobs due to the prior Mach non-compile script bug).

7.48 V2.1.3 (Limited Distribution Beta Release): Misc typo fixes, update © notices for 2015

7.49 V2.1.4 (Beta Release): Public beta release of 2.1.3

7.50 V2.1.5 (OEM Version): Changed some hooks for OEM control of MSM features. Added OEMSSLHook support.

7.51 V2.1.6: Production release of v2.1.4 beta

7.52 V2.1.7.1 OEM Beta: Added internal support for Comms use for OEMs. Corrected some © notices to 2015 that had been missed. Misc typo corrections in user docs. Bug fix: OEMSSU was not getting called. Bug fix: Sometimes code to put mach in estop would take mach out of estop (the mach call is a toggle), fixed logic to always put mach into reset (estop).

7.53 V2.1.7.2 OEM Beta: Fixed bug the broke “Set editor paths” button.

7.54 V2.1.7.3 OEM Beta: Added support for get/set comport settings. Fix: current tool description edit button was not working



7.55 V2.1.7.4 OEM Beta: Added Z axis referenced test before use of G53 Z0 in OEM tool changer script Fixed COMPortA Constructor bug in MSMSupport lib Changed ComPortA object version to 1.1

7.56 V2.1.7.5 OEM Beta: Added mscomm32.ocx to installer

7.57 V2.1.7.6 OEM Beta: Added M6ATC copy to OEM installer

7.58 V2.1.7.7 OEM Beta: Fixed debug msg control in OEM ATC handling

7.59 V2.1.8 Production Release: Released 2.1.7 beta series to production release software.

7.60 V2.1.8.1 Private Beta: Released 2.1.8.1 beta adds B and C axis jog buttons to fly-out page for 6 axis screen set.

7.61 V2.1.9 Production Release: Released B and C axis jog buttons on fly-out page for 6 axis screen set.

7.62 V2.2.0 BETA Release: Due to multiple recent complaints of brains not working the MSM Brain have been removed. Their function has been incorporated into some MSM periodic scripts. This lets us avoid the Brains problems (which seem to be getting worse and appear to be a case of Mach 3 bit rot since ArtSoft USA stopped maintining mach 3).

7.63 V2.2.1 Production Release: Released 2.2.0 beta to production status

7.64 V2.2.3.4 OEM Beta: Added support for OEM use of “return to page before M6”



7.65 V2.2.3.5 OEM Beta: Removed some msgbox debug lines Did full dependency rebuild

7.66 V2.2.4 Internal Release: Change OEM 2.2.3.5 beta to production status

7.67 V2.2.5 Internal Release: Added tool tip type pictures to the Lathe manual.

7.68 V2.2.6 OEM Release: Fixed bug that killed all TLO probing in OEM 2.2.3.4 release.

7.69 V2.2.7 Internal Release: Reworked DisplayLastPage, an OEM change in 2.2.3.5 broke the “return to previous page after tool change” in end user MSM. Improved MSMBuildDefine handling for internal build scripts

7.70 V2.2.8 Internal Release: Added init of SetLoadedScreenSetName to SSL.

7.71 V2.2.9 Production Release: fixed bug for 2 signal config: Now does not switch to the TP on the timing signal when measuring the Probe tool PTL. The bug resulted in two signal setups crashing the probe tool into the TCP TP.

7.72 V2.2.10 OEM Release: fixed bug where MSMAPIRSReturnValueDRO was not being set for some external LIB calls

7.73 V2.2.10a Beta (temp OEM Release): Fix bad build probing lib problem with 2.2.10



7.74 V2.2.11 (OEM Release): Released 2.2.11 for OEMs

7.75 V2.2.11.1 (OEM ATC Alpha Release): Adding support for an OEM ATC. This required some changes to M6 handling so that MSM TC options can be invoked either

a) after an ATC tool change, or b) after a manual Sop&Wait tool change done in mach’s ATC mode (for tools not

mapped to a tool changer slot) ATC support now “overrides” MSM TCP position in Z. The TCP DROs are still used for Tool changes if Auto TCO is on. However, for any operation that uses the ATC To change tools, the spindle will also be repositioned to the ATC TCP Z value. M6 debug turned on for development… Homing the ATC requires that the user first confirm the spindle is empty, then it also resets both mach’s current tool # and the ATC spindle T# to 0. The home routine also refreshes the spindle map DROs.

7.76 V2.2.11.2 (OEM ATC Alpha Release): More implementation of OEM ATC.

7.77 V2.2.11.3 (OEM ATC Alpha Release): Turned on auto page change to ATC changes. Turned off M6 debug messages

7.78 V2.2.11.4 (OEM ATC Alpha Release): Renamed OEM

7.79 V2.2.11.5 (OEM ATC Alpha Release): Improved SIO port error handling & debug messages

7.80 V2.2.12 Production Release: Bug fix: Tool Table Report button was generating a blank report.



7.81 V2.2.13 Production Release: Bug fix: Restored scripts that errors in build caused to become empty source scripts which resulted in no-op buttons

7.82 V2.2.14 Production Release: Bug fix: Fixed broken tool table Save As button Bug fix: BAXcZm centering option LED/ button was setting BAXcZp

7.83 V2.2.14.2 Alpha (internal OEM development Release): Corrected OEM name for button paths

7.84 V2.2.14.4 Alpha (internal OEM development Release): SIO handling debug improvements

7.85 V2.2.15 Production Release: Fix broken SetTooBlockZero button in Mill-Turn

7.86 V2.3.0 (internal beta release): Changed version to 2.3.x; this marks the transition from Hg to Git repository storage Enhanced checks for MT mode, MT TLO <> 0; added dialog to reset MT TLO and continue probing operation.

7.87 V2.3.0.2 (internal alpha release): Implemented and OEM ATC support package. The ATC support is integrated into MSM professional, and a stand alone wizard was implemented to support the ATC when using non-MSM screen sets. Bug fix: disabled probe tool checks if probe tool # = 0

7.88 V2.3.1.x (internal alpha release): Updated © notices for 2016



7.89 V2.3.2 (Beta release): Beta release for testing. Misc minor bug fixes; some internal restructuring due to OEM features.

7.90 V2.3.3 (TEMP OEM release): Note: this is a TEMP release – not all internal version info is set correctly (built on travel laptop w/o full build environment) – to be rebuilt and replaced shortly. Back ported changes in M6 scripts to other OEM versions. Fixed missing file copies for OEM installer (some were copied by OEM application installer). Changed M6 debug info from compile time to run time. Added new maint scripts to turn M6 debug loggin on/off. Fix M6 page change bug in OEM MSM

7.91 V2.3.4 (OEM release): Converted 2.3.3 OEM to OEM production version

7.92 V2.3.5 (OEM release): Converted 2.3.4 OEM to OEM 2.3.5 (removed temp comment in version string)

7.93 V2.3.5.x (internal development release): OEM ATC support work.

7.94 V2.3.5 (Production Release): Released end user version of OEM 2.3.5

7.95 V2.3.6 (Production Release): Bug Fix: Set TB Zero button in Mill-Turn was broken (it was running the wrong script)

7.96 V2.3.7 (Internal Release): New maintenance script added: RecalculateMTMTLOs This script will go thru the tool table and for each entry where the tool is non-empty and a RH Tool, it will recalculate the Master Tool mode TLO for the tool using the current PTL of the master tool. The script requires that MSM must be in Master Tool Mode when the script is run.



This is useful if you are using MTM but do not have a TCP TP to re-measure tools after the MT PTL has changed.

7.97 V2.3.8 (Production Release): Updated © notices for 2017 Updated install instructions to use explicit admin privileges for MSM installer (on win version with UAC). Bug fix: Some hot key mappings were not set to the keys given in the manual, these have been corrected. The changes are to the Spindle CW, Spindle CCW, spindle off and Single step buttons. Rebranded OEM ATC work to OEN name for installer choices etc. Reorganized OEM ATC control panels PROXY ACTIVAITON is now deprecated. In this release we have deprecated the proxy activation facility. This ability will be removed in a future release and should no longer be used. The proxy activation facilities were included when MSM was first created (2009) and internet connectivity was not always available in a shop environment. It is now 2016 and internet connectivity is common and inexpensive network adaptors are readily available. Additionally the proxy activation facilities were created with ancient visual basic tool kits that are not longer supported on current (not past end of support) versions of windows. The number of customers that use proxy activation has dwindled to almost zero and the effort needed to reimplement the facility using supported tool kits is simply not a viable choice. Therefore, use of the proxy activation/deactivation now result in a warning dialog that the feature is now deprecated and will be removed in a future release.

7.1 V2.3.8.1 (internal Beta) Fix bug in Mill-Turn where axis homing sequence buttons were being ignored.

7.2 V2.3.9 (Production Release) Released 2.3.8.1 as non-beta production version

7.3 V2.3.10 (Internal Beta) Fix bugs in probing when XYClearance > StepOffWidth

7.4 V2.3.10.3 (Internal Beta) OEM ATC work



7.5 V2.3.11 (Internal Beta) OEM ATC work

7.6 V2.3.12 (Production Release) Typo corrections and © notices for 2018 First release with Santa Cruz Engineering ATC support.

7.7 V2.3.13 (Beta) Added hook support for a user M6PostATLO2 script. This is a new script hook in addition to the M6PreATLO script, same conventions, placement in the profile directory etc.. M6PostATLO2 is called immediately after the ATLO tool measurement is completed but not until the spindle has returned to the TCP.

7.8 V2.3.14 (Production Release) Released user M6PostATLO2 script support.

Date post:	20-Jan-2020
Category:	Documents
Upload:	others
View:	12 times
Download:	0 times

MachStdMill Release Notes For MSM Version 2.0.x and later Release/MachStdMill Release Notes.pdf1...

Documents