No MSM Beta Release is currently available

[DaveCVI]

This thread will announce MSM beta releases

Dave

[DaveCVI]

<Jan 25, 2011>
Sigh,
if you got 1.0.2.d17 before I replaced it with .d18, please toss it out.
.d17 was missing a file and that prevented access to the new probing routines. Should be fixed in .d18

Dave

[DaveCVI]

.d18 was missing two page background bitmaps in the 12x9 resolution set.
This is corrected in .d19.

Dave

[DaveCVI]

<Jan 26, 2011>
Some more missing files were found -
in .d20 I have added back the missing new probing ops scripts...

Sorry guys, the failed source control branch merge messed up the release package more than I thought. I have now compared all the files and *think* I have all the corrections made in .d20...

Dave

[DaveCVI]

<Jan 26, 2011>
Hi,
I retested 1.0.2.d20 this afternoon- found a bug.

The X, Y width measurement DROs for the valley/ridge and pocket/post new probing pages were correc tin 10x7 but now 12x9. They DRO $s are fixed in 12x9 in .d21.

Dave

[DaveCVI]

<jan 26, 2011>
Hi,
I've posted 1.0.2.dev22
This corrects some errors in the X,Y,Z touch DROs that are shown on the probing pages in the probe results area.

In prior versions the touch positions shown would be in the WC system that was in effect when the probe op was started. This made the coords hard to relate to the probe position at the end of the Op when the probe op also reset an axis zero.

In Dev22 the results will now be relative to the WC origin as of the end of the successful completion of the probe Op. This is more consistent and it makes using a probe op to make a series of measurements much more intuitive.

Here is an example:
1) use a corner probe op to set x,y,z to the corner of a block.
The results will generaly be x,y,x = 0,0,0 (we just set the origin to the corner).
2) turn on "probe only"
3) use other prob ops to find the other corners, or the center of the block etc - the results will all be relative to the zero point at the first corner.

I have been doing this to measure points on the top surface of a block to see how much the surface varies from the zero point at the planes corner... Amazing what a bit of probe work can tell you.

Dave

[DaveCVI]

<Feb 4, 2011>
I've posted 1.0.2.d23 -
This has a fix to turn off the MSM Tool Change LED if an M6 sequence is interrupted by a stop button action.

Dave

[DaveCVI]

<Feb 5, 2011>
I have posted 1.0.2.d24

The more I looked at the interactions of mach allowing the stop button to abort the execution of the M6 scripts, the more I felt that just turning off the tool change LED and going on was not a safe action.

There is no way to clean this up from MSM. Mach should never allow this to happen in the first place (it’s a violation of the GCode definition of a block as an atomic execution unit). Since the m6 scripts can get aborted anywhere, and mach does not raise an error flag when it does this, the scripts (and the M6 sequence) are left in a state that can not be determined. In reality, this should be a control fault (a word and block partially executed) so in .d24 when MSM detects this situation, it now resets mach. This is the only safe thing for MSM to do – it can’t entice the user to continue from an unknown state as if all were well.

When this happens, it is highly likely that due to the way mach handles "current tool" and "next tool" that the current tool info still matches the tool physically mounted in the spindle! This is because a mach tool change swaps "current tool" into for "next tool" info at the start of the M6 sequence (before the tool is physically changed). The operator needs to be forced to go check things before going on. Again, if the M6 is not interrupted, this would be ok - but the interruption leaves the state inconsistent. Note that this core problem is not an MSM issue, but a Mach problem. The same thing can happen with the stock mach 1024 set M6 scripts.

MSM is now just smart enough to notice this when you press the stop button and notify you that as a result of that action things are messed up. Note that this detection code is part of the MSM stop button logic – if you execute a DoOEMButton(MachStopButton) from a script during a tool change, you will create the same problem (but MSM will not know it happened), so this improvement in MSM helps the UI level but not the scripting level (that would require a fix inside mach).

The good news is that I managed to get MSM to go back to the prior page when a Stop event interrupts a tool change...
Dave

[DaveCVI]

<Feb 11, 2011>
Hi,
FYI: I have confirmed that when going from 1.0.2 (release version) to 1.0.2.d24 (beta version) that there is an installer bug that causes a config file not to be updated correctly by the beta install. The symptom shows up as type mismatch script error when attempting to do a probing routine.

The bug is fixed and and will be in a new beta once I get some other stuff under development ready to go.

In the mean time, the work around is to uninstall 1.0.2 (start menu / mach /Machstdmill / uninstall) before installing the d24 beta. This causes the beta installer to install the correct config file and the problem is then avoided.

Dave

[DaveCVI]

<Feb 23, 2011>
MSM beta v1.0.2.d49 is now available.

Lots of small changes (see release notes).

A major addition is the support for probing operations to help setup the A and B axes. You can now
find the center of the A & B axes;
measure the axis' alignment with the corresponding linear axis;
Position WC zero at the center top, bottom or side of a cylinder;
Find the rotation angle around A or B (this can also be used to find the angle of an inclined plane).

MSM will now rotate the WC system to match and edge angle measurement - please see the user manual for notes on why this may or may not be a good idea. PLEASE BE AWARE of how Mach handles jogging when coordinates are rotated!

Dave