|
Post by maurice on Aug 14, 2012 13:57:46 GMT -8
Hi
I just updated to 2.04 from an old version and here is my problem.
When you change tool by TxxM6 the Tool Dro are changed but the Z dro is not updated until you press G43 in the tool page or enter a G43 in the MDI and this even if the TLO is lighted up in the RUN and Tooling page.
Regards
Maurice
|
|
|
Post by DaveCVI on Aug 14, 2012 15:32:09 GMT -8
Hi Maurice, Hi I just updated to 2.04 from an old version and here is my problem. When you change tool by TxxM6 the Tool Dro are changed but the Z dro is not updated until you press G43 in the tool page or enter a G43 in the MDI ... TLO values are not applied until a G43 Hx is executed - so this is how TLO should work. There was a case where mach would apply TLOs without executing a G43; That was when one entered a new tool # into the current tool DRO directly. Doing that would often trigger other mach bugs. I am not sure what the prior version of MSM was that you were running, but to avoid the mach bugs associated with manually setting the current tool DRO, MSM was changed (long enough ago that I don't remember exactly when it was) to not allow the operator to use the current tool DRO that way. Please see item 4.23 in the release notes for a more detailed description of the TLO values and G43 topic. ... and this even if the TLO is lighted up in the RUN and Tooling page. Regards Maurice Now this puzzles me - I'm unaware of a case where the LED and the application of the TLO value can get out of sync (BTW, this is handled by mach). What version of mach are you running? Was the mach version changed when you changed to MSM 2.0.4? Can you tell me a sequence to actions to take to get the TLO LED to be ON when the TLO value is not actually being applied? I'd like to check this out but I don't know how to make that happen. Dave
|
|
|
Post by maurice on Aug 14, 2012 16:38:17 GMT -8
Mach 3.43.62 updated before updating to 2.04
I get the same results starting from the Run or Tooling page:
Let say I am using tool 1, the offset is active and the TLO is on.
Now MDI T2M6
I am moved to Tooling page and the Tool DRO is changed to 2 but TLO is still on but we see that the Z location on the right bottom location of the page is not change.
Hit the cycle start botton and return to RUN page
No update to the Z-DRO but TLO is still on
Finally MDI G43 to update DRO
As mentionned earlier, same result starting from TOOLING page
Hope it help
Maurice
|
|
|
Post by DaveCVI on Aug 14, 2012 19:32:37 GMT -8
Hi Maurice, I get the same results that you gave in your last post. However, I think that is what is supposed to be happening.... I'll try to explain -
let's assume a start state off no tool mounted (I.e. t#0) and no TLO active. I started at MC origin and no WC offsets, so the current position = 0,0,0 in MC and WC. (I also turned off AutoTCP so that I could do the tool changes without moving the current position). This setup makes the numbers easy to see on the WC offsets page.
The initial state can be created by G49 T0 M6 Note that G49 is modal - i.e. the "no TLO value used state" stays that way until the control is told to do something different.
for test purposes I made the tool table numbers simple: T1 TLO = 1 T2 TLO = 2
then I do T1 M6
we get tool 1 mounted and no tlo value is active (correct because we have not told the control to use a TLO value).
Then I do G43 H1
Now we see the WCZ shift by the TLO amount. WCZ is now -1 and the TLO active LED is on.
Again note that G43 is a modal command - so the G43 state (and the applied TLO value) will stay until the control is commanded differently.
Now do T2 M6
Tool 2 gets mounted and the Z position DRO does not change - and it should not as the active TLO value is still the value for T#1.
Now do G43 H2 and mach applies the TLO value for T#2, the TLO value changes and the Current Z WC value changes (it becomes -2).
At all times thru these steps the TLO DRO values and the TLO active LED are consistent with the current commanded G-Code state.
I'm guessing that you expect a M6 to automatically cancel TLO (i.e. do an implicit G49) as part of the tool change actions? However M6 does not do that.
To verify my memory of how this should work, I checked this with all combinations of mach 3.43.37, 3.43.62 and MSM 1.1.22 and 2.0.4. I also did this with mach 3.43.37 and the 1024 screen set. All act the same, so I don't think anything changed here with MSM 2.0.4
Are you certain you used to get something different for this? I'm thinking that this is the way mach has always acted for TLO.
Dave
|
|
|
Post by maurice on Aug 14, 2012 20:21:45 GMT -8
Hi Dave
I get the same results when repeating your scenario but when we get back to the Run page from the Tooling page we are in a dangerous situation:
The tool as been changed and we are in front of a lighted up TLO. The TLO is on but we don't know by only looking at the screen which one is applied (H01--H02-H03......). I would like to have a DRO telling me wich offset is applied. Since 99.999% of the time Txx is the same as Hxx why not apply the Hxx when the tool change is called and confirmed or add a G43 button in the RUN screen that will change automatically the offset to the tool number shown.
Maurice
|
|
|
Post by maurice on Aug 15, 2012 2:10:40 GMT -8
Hi
To my knowledge all other screensets that I have used in the past, including the first versions of MSM (yes I was there), when you enter a value in the Tool # DRO you automaticaly have an update to the Z DRO that is, the Hxx of the new tool is instantly applied.
It would be nice if you can find a way to give us back the opportunity to enter directly the Txx in the DRO and at the same time updating the Z-DRO instead of passing through the hassle of typing 2 lines in the MDI.
What is great with MSM is the direct access to all the different functions of Mach with a single click which is not the case anymore for changing tool from the RUN page
Regards
Maurice
|
|
|
Post by DaveCVI on Aug 15, 2012 8:30:43 GMT -8
Hi Dave I get the same results when repeating your scenario but when we get back to the Run page from the Tooling page we are in a dangerous situation: The tool as been changed and we are in front of a lighted up TLO. Well I'd not call this dangerous in the sense that the control is doing something it should not. The control is in the state it was told to be in. ...and that is what a control should do - it should do as it's told. Nothing more, nothing less. In this case the control is obeying the state commands it has been given. If you want the control state to be different, you can always have the g-code put it into a different state. For example, the gcode could issue a G49 command before doing a M6. Do that and there will be no TLO value applied until you again activate one with a G43 Hx. The TLO is on but we don't know by only looking at the screen which one is applied (H01--H02-H03......). Well, I'd say that we do know what TLO value is applied - it is the last activated TLO value from the H register given with the last executed G43. That TLO value is shown on the WC offsets page as the Tool Offset column. I would like to have a DRO telling me wich offset is applied. If you want the actual H index value, that is DRO 245. The TLO value is dro 32 (which is what is used on the MSM WC Offset page). You can customize your run page to have either DRO. Since 99.999% of the time Txx is the same as Hxx why not apply the Hxx when the tool change is called and confirmed or add a G43 button in the RUN screen that will change automatically the offset to the tool number shown. Maurice The reason is that other 0.001%.... and because that would be inconsistent with how gcode works. This is one of my biggest complaints about mach - IMHO it should never, NEVER, take an action based on "mach knows better than the operator or gcode". Whenever that happens things will crash eventually - as that creates a situation where mach would put itself into a state that is not the same as what the gcode commanded - and that is not good. Also realize that your example, while common, is not the only situation: It is not necessary for the H# to be equal to the tool# for a G43. So assuming that condition will not always be correct. Dave
|
|
|
Post by DaveCVI on Aug 15, 2012 9:01:28 GMT -8
Hi To my knowledge all other screensets that I have used in the past, including the first versions of MSM (yes I was there), Yep, I know you've been with this since the early days - I'm glad you're still around! when you enter a value in the Tool # DRO you automaticaly have an update to the Z DRO that is, the Hxx of the new tool is instantly applied. and I hated this as it's an example of when mach thinks it knows better than the operator what should happen. This is a case of where typing into that DRO to change the current tool number would also do the equivalent of: G43 H# where Number was the same as the # typed into the DRO. OK, while I didn't personally like that action, I ignored my personal opinion and treated the DRO as a special mach control that had those semantics. It was very dangerous because that DRO would really do T# M6 G43 H# That puts mach into a state that is different from what the gocde state is. Mach just turned on G43 without ever executing a G43 command... and it picked an H# index to get a TLO value from.... so you now could have a loaded, running gcode program that is supposed to be in control of the machine, but mach is now not doing what the gcode program says... that really is physically dangerous. And when the DRO was used this way, mach would not actually run the mach tool change sequence code! It just changed the current tool # and the applied TLO value. So things that are supposed to happen in MSM as part of a tool change, get skipped as mach would only do "part" of a tool change.... Honestly, this is a place where mach3 is rather messed up internally (an opinion expressed by Brian to me numerous times). More and more problems associated with typing a # into the current tool DRO were discovered - and they cause other things inside mach to change (break) also - the current tool DRO is the source of multiple mach bugs. I've reported the bugs, but they don't get fixed in mach.... (That's why the list of documented, verified and unfixed mach bugs in the MSM release notes keeps getting longer instead of shorter). I've been told they will not be fixed in mach v3 - I'm told it's not worth the effort that would be required. Those other bugs caused other MSM users to complain and that caused MSM support issues. MSM support questions cost me time and $ - so I try to minimize them. Thus, I eventually decided that it was best not to tempt users into using a part of mach that only causes problems and crashes machines. So I removed the ability to type a number into the current tool DRO from MSM. The result was that all required working functionality was retained (from the standpoint of the control functions) and the bug reports (and hence my support time) was reduced - because a major source of problems stemming from "mach knows better than the operator and the gocde" went away. That is a very good trade off from my viewpoint. It would be nice if you can find a way to give us back the opportunity to enter directly the Txx in the DRO and at the same time updating the Z-DRO instead of passing through the hassle of typing 2 lines in the MDI. What is great with MSM is the direct access to all the different functions of Mach with a single click which is not the case anymore for changing tool from the RUN page Regards Maurice Alas, I can't do that without hitting the bugs inside mach that happen when the DRO is used that way. If the bugs are ever fixed in mach, I'll reconsider my position. Until then, I'm "damned if I do and damned if I don't".... So since I'm damned anyhow, I'm going to stay with consistent, correct control operation. Sorry, I'm guessing that's not what you want to hear, but at least you know why and what the trade off is... Dave P.S. if you really want your mach/MSM installation to optimize for the special (and common) case of T#=H# and to automatically apply a TLO as part of every tool change, you could easily program your g-code that way, or modify your cam post processor to always emit a G43 H# after a M6. This is a case of individual users can can make trade offs for their personal system that are ok for them, but would not be OK for me to do for all MSM users.
|
|
|
Post by maurice on Aug 15, 2012 9:50:12 GMT -8
Hi
I must say that I agree with most of your arguments but I still beleive that it is quite dangerous when operating directly from the RUN page not to know and seeing in front of you the active TLO. I know to be on the safe side I should G43 Hxx right after the tool change but you can easily get distracted once in a while and then you are in trouble.(It is not a problem when operating from a file, the post will take care of all the code)
I know that I can easily customize my page to add a Hxx DRO but then I will have to update again each time you have a new version. So I still say it would be nice in one of your next update to add a Hxx DRO on the RUN screen. You have a nice little place on the right of the T#DRO.
Thanks for your complete answer to my questioning.
I appreciate
Maurice
|
|
|
Post by DaveCVI on Aug 15, 2012 11:12:30 GMT -8
Maurice,
Are you wanting a display of the H index # on the run page, or a display of the actual TLO offset value?
Dave
|
|
|
Post by maurice on Aug 15, 2012 16:26:54 GMT -8
Hi
Only the display of the H index #. It wil then easy to check that you don't have Txx Hyy when you are expecting Txx Hxx.
If you decide to have it a little more sophisticated add a small led between the T# and H# or beside, red when Txx Hyy and green when Txx Hxx
I hope you will have a great success with MSM because you are realy listening and take time to discuss with your customer.
Regards
Maurice
|
|
|
Post by DaveCVI on Aug 23, 2012 11:53:13 GMT -8
Hi Maurice, FYI - MSM 2.0.4.2 beta has been posted. There is now a TLO index (H register) display on the run page.
I've declined the idea to add LEDs that show red/green when the TLO index is not equal to the current tool. While that is a common usage convention, it is not an error condition for a TLO index to be used that is not the same as the current tool number.
Dave
|
|