Hi,
I love MSM, and as I've used it, I've come up with a list of a few things I would like that would make it even better.
Thanks - I always like ideas from users. below are some initial thoughts on reading your post.
1. On the tool change screen, it would be nice to have "Current Tool" or "Tool in spindle" still show in the "Next Tool" window. If I don't happen to look at the screen while machine moves to TC position and the "Current Tool" still shows, I sometimes forget what number I am taking out of the spindle.
I think I understand that you’d like an easier way to remember what tool # is being removed from the spindle when you are changing tools. I’d approach this differently than the solution (using next tool panel) that you’ve described.
If I made the next tool panel on the tooling page operate as suggested, the “next tool” info would not correspond to the G-Code T-Word. Let me explain:
The “next tool” panel was designed to always show the current information about what the “Next Tool” number is that has been commanded to the system. In G-code, the “next Tool” is specified by the “T” word. Thus the block “T6” tells the system that the next tool to be mounted is #6. The Tool number DRO in the next tool panel always shows the last executed value of the T word.
I’d say that most of the time, particularly for machines without a tool changer, the G-code used for a tool change is typically (I’ll use tool #6 in the example):
Example 1:
T6 M6
When used as a single block (line of code in mach), the sequence is that mach executes the T word and learns that the next tool is #6, then it executes the M6 which causes the actual tool change sequence.
However, the T word does not have to be in the same block as the M6. Consider this example:
Example 2:
<lines of g-code>
T6
<more lines of G-code>
M6
Example 2 will also end up changing the tool to #6,
when the M6 is executed. The difference is that the T6 lock was executed a significant amount of time before the M6…. Consider a machine where it takes the tool changer some time to get the “next tool” into the correct physical position so that it’s ready to be used for a tool change. Example 2 gives the T6 time to complete (it’s done in parallel with the “<more lines of G-code>” actions. The result is that the overall program run time is reduced because the T# actions can be done in parallel with other machining actions. That’s important when the profit margin on a part depends on minimizing the machining time per part.
What I think you really want is to modify when the current tool DRO changes from the “old tool #’ to the “new tool #” during the tool change sequence. Right now the mach “stop and wait” sequence of events is:
1) M6
2) Mach runs M6start script (the 1st part of the tool change sequence)
3) Mach stops and prompts user to insert the “next tool” (the number last specified by a T word).
4) User puts tool in
5) User presses cycle start to tell mach the tool is mounted
6) Mach runs M6end script (the 2nd part of the tool change sequence)
7) Program continues
For various reasons internal to mach, the current tool DRO in the current tool panel changes from the “old tool 3” to the “new tool number” at step 2.
I personally think it would make more sense for it not to change until step 5 or 6.
However, this is not what mach V3 does. It was on the list of things to change in mach V4 – but whether that list is actually getting done in mach V4 is not yet known.
Technically, I could probably, with enough fiddling, make the MSM current tool display not change to “next Tool #” until the tool is actually mounted. But, if I made MSM work that way, then MSM would not be doing the same thing that mach without MSM does – and every time I’ve been down that road, I get support issues as people then complain that “MSM is not doing the right thing”… So I think the current operation will have to stay as is, and it can be revisited when (if?) mach v4 shows up.
2. Skip the tool change sequence if the tool being called for is already in the spindle.
This had been considered this in the past.
The logical test would be simple: If next tool # = current tool # then skip tool change.
Alas, if one thinks about doing that in detail some gotchas arise….
The entire tool change sequence would be skipped – and that also means that none of the MSM tool change options would be executed for this case. If the system is set up to measure tools during a tool change, the measurements would also not happen. There are cases (perhaps pathological ones) where this might cause a problem (think about a tool that may have changed length slightly while being used). Thus this was not included as an tool change option.
I’d like to hear some more input from other users re this idea.
3. The ability to preset values in probe operations. For example, if I am probing for a Z zero, and I want the surface found to be Z = .010 as my first operation is a facing op. Nice if like me, you program part zeros at the part boundaries, not stock boundaries.
I think you are suggesting that MSM have some “probe offset DROs”.
Currently, when doing a “Probe Z-“ operation, the surface found is set to Z0.
If this was generalized a bit to be: “Set found surface to value of probe offset DRO” then the found surface could be set to any value in the Probe offset DRO. If the Offset DRO was set = 0 then the actions would be the same as what MSM does currently.
(I’ll constrain my thinking to straight line probes along an axis direction to keep things simpler for now – I’ll have to think more about things like the A and B axis probe operations).
Is the desire for this only for Z? Or would this be useful for X and Y also?
What do others think? Is generally useful for multiple users?
Dave