|
|
Post by mrprecise on Jun 30, 2012 16:04:42 GMT -8
Hi Dave:
About half the time, when the program gets to a M6T# line, it just stops and sits there, and doesn't open the tool page.
I can force it by doing MDI/M6, but often it takes from 2 to 6 or sometimes even 10 tries using MDI before the page opens, and the spindle moves to the tool change position.
If I force it with an MDI as mentioned above, after hitting cycle start after changing tool, it stops at the M6T# line, and only moves on to start spindle after I hit cycle start again.
Sometimes, but not always, the tool change sequence works as it should. It does seem about a 50/50 OK, not OK tool change.
MSM 1.1.22
Mach3 ver. 3.043.062
Win XP, all service packs
Controller: Vital Systems dspmc, Ethernet controller.
I re-load all brains per suggestion.
I always use G43H# after the T#M6 line.
Checked box in General Config, wait for tool change.
Tool change position set on tooling page.
I am thinking, there is some obscure setting, or CB in Mach that is causing this. I am using no special CB coding.
The Vital systems controller does have it's own plug-in. I have not asked them about this yet.
Any suggestions?
Thanks,
John
|
|
|
|
Post by DaveCVI on Jun 30, 2012 16:53:08 GMT -8
John, OK, what you wrote all sounds right to me re configuration. Of course, I have no idea what the vital systems plug-in is doing that may or may not be impacting things.... However, I'd not immediately suspect the plug-in for a problem with M6 sequences as I think the M6 handling is pretty much all handled by Mach. AFAIK, the Mach gcode interpreter sees the M6 and then mach calls two CB scripts (M6start and M6end) to implement the actual tool change actions. MSM supplies MSM specific M6start and M6end scripts for MSM - it is in the M6start script that the page change is done by a call back into mach form the script. The typical sequence is: M6 -> M6start Page change move to TCP M6start exits mach waits for cycle start mach calls M6end Thus the page change is (as far as I remember) before any motion and therefore I'd not expect the plug-in to be involved at that point as the motion plug-ins get called for physical movement, but not for starting and running scripts. I always use G43H# after the T#M6 line. I was not sure now to read that - do you mean that you always do: T# M6 G43 H# in a single line, or that you always do T# M6 G43 H# (i.e. in two lines)? If you are using one line, you will hit a mach bug (see section 4.27 of the release notes), but I don't think that bug would give you the symptom described. Yeah, and this will sound off the wall as a something to check... I've seen this symptom once on a desktop machine that I use for coding. The symptom was that the page changes would sometimes get skipped when an M6 sequence was executed. I finally learned that mach has some not very nice timing holes in it's implementation and that if the internal actions of starting and running a script take to long, that mach seems to just skip or ignore the script - and does not issue any error. In my case, I figured out that my antivirus software was causing this to happen.... if I turned off the AV engine, the problem would go away. Turn it back on and it would reappear. My theory was that the AV processing time that happened then the script file was opened by mach was causing a failure inside mach somehow. For me, this happened for a couple of weeks, then I believe an update to the AV engine changed the system timing and it was no longer a problem for me as mach stopped failing in this way. Alas, that also meant that I no longer had a test case, and thus no way to demo the problem to Artsoft... so it was treated as a non-reproducible bug and not tracked by them any further. I was using Kaspersky AV on that PC. So, as far fetched as it sounds, if you have AV software on the PC, try disabling it to see if that makes a difference. Dave |
|
|
|
Post by mrprecise on Jul 1, 2012 9:19:21 GMT -8
Thanks Dave:
RE: M6T#
I write the M6T# on the first line,
and G43H# on the line after, then the S***M3 on the next line.
I have also tried M6T#, and T#M6, but saw no difference.
I am using Avast free AV software. It is pretty highly rated, as I am told.
I will disable it, and run my dummy 4-tool program.
Read all your posts re: Mach3, and it is really an odd-ball mixture. In a way, it is a wonder it works as "good" as it does! I remember reading a while back, Art gave a pretty interesting description of how he put it all together, and kept adding things in as people asked for mods. I remember when I first began getting my machine running, there were something like 22 OEM codes for the spindle alone! I just wanted a mechanical panel button to turn the spindle off, through Mach. No such luck.
I will post my efforts of disabling AV software.
Thanks,
John
|
|
|
|
Post by mrprecise on Jul 1, 2012 21:14:42 GMT -8
 Well, it was something simple, after all. After disabling the AV software, the refusal to move to the TC page remained. So, I just started studying the pages, and check boxes again. On the tooling page, box "TC Options & Master Tool Mode", the box "TC Auto TCP" was not highlighted green, or ON.  I know it was checked (ON) sometime before, but got changed inadvertently.  At program start, it still will not move to the TC page at the first T#M6, even with the wrong tool (last tool in the program) showing in the current tool box on the Run page. I think the best solution is to do a manual MDI/T1M6 to load the first tool. In the past, with the TC problem, I tried writing T#M6 twice, using 2 lines. That worked, although it doesn't seem the right way. Other than that, all is well. Regards, John
|
|
|
|
Post by DaveCVI on Jul 1, 2012 22:51:13 GMT -8
Hum, Maybe I misread your earlier post and thus misunderstood the reported problem... When you say Well, it was something simple, after all. After disabling the AV software, the refusal to move to the TC page remained. So, I just started studying the pages, and check boxes again. On the tooling page, box "TC Options & Master Tool Mode", the box "TC Auto TCP" was not highlighted green, or ON. I know it was checked (ON) sometime before, but got changed inadvertently. The Auto TCP ( Tool Change Position - not Page) button controls whether MSM moves the spindle to the Tool Change Position as part of the M6 Tool Change logic Sequence. The word "page" may have thrown me - the movement to the TCP is a physically movement of the machine, and not a change of the "page" that MSM displays. However, as part of the M6 handling, MSM does dynamically change the screen page that is displayed.... MSM changes to the tooling page as part of M6Start, and then goes back to the prior screen page as one of the last steps of M6 handling. I thought you were saying that the screen page being displayed was not changing for all M6 instances... But it now seems to me that you are saying that the machine does not always move to the TCP - but that the page change does happen? The AV info was wrt to the screen page changes, not wrt to the move of the spindel to the TCP. so which is the following referring to At program start, it still will not move to the TC page at the first T#M6, even with the wrong tool (last tool in the program) showing in the current tool box on the Run page. 1) The physical movement to the TCP, or 2) the change from (for example) the run page, to the tooling page and back to the run page? Dave |
|
|
|
Post by mrprecise on Jul 2, 2012 10:32:56 GMT -8
Hi Dave: Let me see if I can clarify my observations. Sorry to have used incorrect terminology regarding the specifics. When "malfunctioning", when the program got to the T#M6 line, nothing at all would happen. No switching to the tooling page; no moving to the tool change position; no machine motion. It would just sit at that line, stopped, and wait forever. In the message line area at the top of screen, it would say to "press cycle start". Then, if I hit cycle start the program would go on to the next line, but the current tool number would stay unchanged, even though it went past the G43H# line, and never go to the tool change position, nor would the tool screen ever come up. It acted like there was no such thing as a tool screen, or tool change position. If instead of hitting cycle start, I did an MDI/M6, often two or three times was necessary, but sometimes ten or twelve times!! doing MDI/M6, it would then switch to the tool page, and move to the tool change position. It would switch to the next tool on the screen. Although it moved to the tool change position, and the tool page screen, it seemed OK, but when I would hit cycle start, the screen would change back to the run page, but no spindle on would take place. Instead, the program would be stopped at the T#M6 line, and the message area would say "press cycle start". After I then pressed cycle start, the spindle would start, and the program would continue. When the program would go through the tool change sequence normally; meaning automatically switching to the tool page screen when the program got to an M6T# line, and moving to the tool change position, after hitting cycle start, the screen would switch to the run page, the spindle would start, and continue the program. Only one "press cycle start" required. I realize that the screen tool page must be showing, and the MDI or program call for what ever tool is needed in the program must happen for the proper tool length offset to be used in the program. When setting up tool lengths, I always use the MDI, as per your instructions. When the program does not go to the tool change page screen, and move to the tool change position, after an M6, something is wrong. Now that I have the green box "TC Auto TCP" showing properly, the tool change sequence upon reaching a T#M6 line in the program works every time; except at the beginning of the program, with the first tool. ------------------ In answer to your question 1, and 2; 1. It does not move to the tool change position. 2. It does not change the page from the run screen to the tool screen, and back again. The program just stops at the M6T# line, and sits there. Again, I can force it to go to the tool page screen, and move to the tool change position by doing a MDI/M6, but it takes often two tries. Perhaps, I should do a tool change to the first program tool, as the last operation, and then do an M30, program end. Then, on starting the program, it would reach the M6T1 line, and I can just push cycle start, and it will read the G43H1 line, to move down to the work, and start the program. Anyhow, as things are working now, I am happy with the operation, and feel really dumb to have overlooked the TC Auto TCP box. John |
|
|
|
Post by DaveCVI on Jul 2, 2012 11:34:14 GMT -8
Hi, I think I can explain part of what you are seeing - the part after the M6 does not run. What I'm puzzled by is why the M6 sequence is not running - that should always be happening... When "malfunctioning", when the program got to the T#M6 line, nothing at all would happen. No switching to the tooling page; no moving to the tool change position; no machine motion. It would just sit at that line, stopped, and wait forever. In the message line area at the top of screen, it would say to "press cycle start". I'd bet that for some reason (mach internal timing, the phase of the moon or whether you've swung a black cat lately in the grave yard at midnight) mach just did not run the M6start or M6end scripts when it encountered the M6 in the Gcode. The message in the Top Line of the page to hit cycle start is from mach - that tells me mach thinks the M6start step is finished. If this happens again, I'd be interested to know what the line in the MSM Tool Change panel on the tooling page says at that point - this would tell me if the MSM M6start script actually got run or not. Then, if I hit cycle start the program would go on to the next line, but the current tool number would stay unchanged, even though it went past the G43H# line, and never go to the tool change position, nor would the tool screen ever come up. It acted like there was no such thing as a tool screen, or tool change position. This makes sense to me - if the M6 scripts were not run, then the scripts did not change the current tool # to the newly mounted tool #. This is one of the actions that M6end does when mach calls it after the cycle start button is pressed. This is consistent with the theory that neither of the M6 scripts were run by mach. If instead of hitting cycle start, I did an MDI/M6, often two or three times was necessary, but sometimes ten or twelve times!! doing MDI/M6, it would then switch to the tool page, and move to the tool change position. It would switch to the next tool on the screen. Although it moved to the tool change position, and the tool page screen, it seemed OK, but when I would hit cycle start, the screen would change back to the run page, but no spindle on would take place. Instead, the program would be stopped at the T#M6 line, and the message area would say "press cycle start". After I then pressed cycle start, the spindle would start, and the program would continue. Yeah, the fact that this did anything at all is probably another mach bug. Until the current M6 sequence is done, mach is technically still in the process of executing the M6 it saw in the G-code. From a state machine perspective, we are in the "gcode is running state". Alas, this state does not prevent one from entering command via the MDI line! Which is a huge, and very dangerous bug. What mach does is take the MDI command and insert it into the gcode buffer at whatever point mach it at when the MDI line is open and the enter key is pressed. See the MSM release notes item 4.20 for more on this dangerous bug. Then I suspect that the multiple M6 MDI inputs tripped across mach bug 4.16 in the MSM release notes.... The result will be unpredictable as at this point mach has come close to going belly up. Essentially, I think this forced mach to re-enter code that is not meant to be re-entrant inside mach - and at that point all bets are off. I realize I'm bitching about mach's implementation a but here - please excuse that - I have no other way to explain what I think happened except to point out how some know mach bugs probably played a role here. FYI - These are bugs that I've documented, tested, and reported a long time ago (2+ years) - and it annoys me that Artsoft just ignores them. The typical response I hear from Brian is "I don't want to fix it V3, it'll all be better in version 4".  That makes me want to scream  - I can't seem to get the idea across that mach V4 is a mythical creature outside of artsoft (and has been for years) and that mach customers only care about software releases they can actually download and run.... OK, Rant mode off.... When the program would go through the tool change sequence normally; meaning automatically switching to the tool page screen when the program got to an M6T# line, and moving to the tool change position, after hitting cycle start, the screen would switch to the run page, the spindle would start, and continue the program. Only one "press cycle start" required. Yep, that's the normal, expected set of actions. I realize that the screen tool page must be showing, and the MDI or program call for what ever tool is needed in the program must happen for the proper tool length offset to be used in the program. When setting up tool lengths, I always use the MDI, as per your instructions. When the program does not go to the tool change page screen, and move to the tool change position, after an M6, something is wrong. It appears that what is wrong is that the M6 scripts are not always getting run. The only time I've seen that is when I had the AV interaction I described in the earlier post. Now that I have the green box "TC Auto TCP" showing properly, the tool change sequence upon reaching a T#M6 line in the program works every time; I find this a tad troubling in that the button should control wether the machine moves to the TCP or not; however, the other actions should still occur (i.e. the page change etc). If you turn off the auto TCP button does this cause the situation where I suspect the M6 scripts are not getting run? What should happen is the M6 sequence, only with out the movement to the TCP. except at the beginning of the program, with the first tool. This also bothers me - I don't see this, whenever I do a T#m6 I get the tool change sequence. I've tried this a bunch of times just after starting MSM 2.0 and it always works. I'm thinking about how to find what is happening here, but I've not had any good ideas yet. This is not a place where I have debug instrumentation built into MSM (like I do for the probing library operations) as I just count on mach doing what it is supposed to for tool changes. The program just stops at the M6T# line, and sits there. Again, I can force it to go to the tool page screen, and move to the tool change position by doing a MDI/M6, but it takes often two tries. When this happens, I'd like you try a couple of things (separately): 1) Stop the running gcode by pressing the stop button. 2) Stop mach by pressing the ESC key 3) Stop mach by pressing the reset button. I'd be interested if each of these reset mach enough for you do be able to do the MDI T#M6 to recover. I'd also be interested in how mach responds to each of these actions - it may give a clue as to what to suspect in mach. If you want to keep debugging this, another test would be to switch mach back to 3.43.37 - That is the release that has the most usage time, by the largest number of MSM users and has proven very stable. I'd be interested to know if the symptom is linked to 3.43.62 or not. Dave |
|
|
|
Post by mrprecise on Jul 2, 2012 17:42:46 GMT -8
Hello Dave:
I will try all of your suggestions, and make notes during the process.
It may be a few days before I do the tests you suggest.
Thanks for your input.
Regards,
John
|
|
- I can't seem to get the idea across that mach V4 is a mythical creature outside of artsoft (and has been for years) and that mach customers only care about software releases they can actually download and run....