Mach3 stop working

[iambeo]

I think I found the problem:
I downgraded MSM to 2.0.12 and now everything seems to be ok. tomorrow I'll do some test to be sure but for now, finally, I can run the code to the end without problems.
Mach3 support tested my gcode files on a system like mine: win10, mach3 last version, smoothestepper, without any problem and I can confirm that.
It's clear at this point the issue is in MSM.
My only regret is I bought a new license to use the last MSM version but it seems a waste of money for now.
I'll post my test result tomorrow.
Thanks

Bruno

[DaveCVI]

I ran your code (posted above) on mach 3.43.66 with MSM 2.3.12 and it runs fine for me.
That tells me that there must be something unusual in your configuration (because it all works fine for others and for me).

I'd like to figure out what problem you are seeing. If you can give me the following information, I may be able to start to figure this out:
1) do you see the error happen on EVERY M6 tool change?
2) Does it happen for M6 from the MDI line?
3) you say it happens with the gcode file you posted, does it happen for every M6 in the gcode file? OR just some of them?
3) what version of MSM are you seeing the error with?
4) what version of MSM were you using before you started seeing the error?
5) your mach3 is version 3.43.66 - correct?
6) what mach3 profile name are you using when this happens?
7) can you go to c:/mach3/macros/<your profile name> and send me a zip of the M3, M4, M5, M6*.* files in that directory? I'd like to see if the profile macros are correct or not.
8) what cam program generated the gcode you posted?

Dave

[iambeo]

Dear Dave,
Thanks for your help.

1) not every time at the same point of the code, it's erratic. But there is no way to run the code without the problem.
2) yes, sometimes from the MDI line too, it's erratic.
3) I tested many files and I got the same error.
4) around 2.0.12 I believe.
5) correct
6) mill (I attached the config file)
7) see the attachments
8)PCB-gcode the last version 3.6.2.4 (http://pcbgcode.org)

regards

Bruno

[DaveCVI]

Hi,

If you are willing to do some testing for me (since I can't make the problem happen here), I would appreciate it if you would do this:

1) install MSM 2.3.12 (latest production release). (the debug commands below do not work in the earlier MSM version you re running)
2) go to the settings common page and use the "run maint script" button to run "TurnMSMM6DebugLoggingON". that will turn on some M6 debug tracing.
3) run the attached test file: M6 bug test rev 2.tap
This is just the M6 and T codes from your PCB code - so it is just the tool change lines.
4) if/when it fails. please send me the history.txt file.

5) The run M6 bug test rev 3.tap
if/when this fails, please send me the history.txt file

6) when done testnig, you can run TurnMSMM6DebugLoggingOFF to turn off the M6 debug tracing.
Dave

[iambeo]

Hi Dave,
No problems with both files you sent me.
So I run my file and the error occurred.
I can't find any history.txt file so at the first error I got I saved the file from the "Hist" button on the MSM screen, when mach3 stop woking I used the lasterrors file in mach3 folder.
Is this ok?
Thanks

[DaveCVI]

Hi,
it is odd that the M6 only files run ok, but the dull drill file does not. I'm suspecting that there is a race condition somewhere. What is puzzling is how you see it in every run of the drill file, but I can;t make it happen and I have no other reports of this problem. Here is another test case...

The drill file you posted had some slightly odd gcode in it... (this is from the drill.txt file you most recently uploaded, which is different from the 1st one you uploaded earlier in tthe thread).

Code: Select all

G90
S20000                                       ; set spindle speed
G00 Z2.0000                                ; go to Z2 which is not very much Z clearance for a metric program
G00 X0.0000  Y0.0000                  ; go to X0Y0 - the program seems to use this as a Home position between tool changes, I hope there was nothing taller than 2mm in the way  
M03                                           ; turn spindle on...
G04 P0.000000                            ; dwell/wait 0 seconds - that seems useless
M05                                           ; now turn the spindle back off
G00 Z25.4                                  ; 25.4 mm or 1 inch above Z0
M06 T01                                     ; this is probably ok. I would put the T01 before the M06 so that the order was clear. 
                                                ; The mach3 gcode manual is not real clear on the execution order of these two words. It appears mack will to do the T first then the M6. 
G01 Z0.0000  F508                       ; feed down to Z0 - so now the tool tip will be touching the part.
M06                                           ; then it does another tool change to the same tool already mounted. 
                                                ; in the process of the tool change, the X,Y,Z position will move and not be known by the program
G00 Z1.0000                               ; now go to Z1... but we don't know where we are in XY after the tool change
M03                                           ; now turn on the spindle
G04 P0.000000                            ; and wait the useless 0 seconds again
G00 X45.2568 Y23.8061                ; go to the first hole location

In the attached test file I've changed the tool changes to be as as follows:

Code: Select all

M05
G00 Z25.4000
T01 M06                                ; just making the code explicitly read as it is intended
G01 Z0.0000  F508                  ; I still don't see why it goes to Z0 only to go to Z01, but I left is as it was
; here is were I removed the 2nd tool change M6
G00 Z1.0000                           ; back up to z1.0
M03                                      ; spindle on
G04 P0.000000                       ; left the useless dwell 
G00 X16.9581 Y18.9842           l go to hole location

I'd be interested to know if this file runs OK for you. It runs in my gcode sim editor and in mach for me.

Dave

[iambeo]

Dear Dave,
thanks for your help.
I run the code you sent me and I got the same error.
In the Lasterror file there is nothing unusual, I think...
regards

Bruno

[DaveCVI]

Hi,
I appreciate your doing the testing. I have to admit that I am sure of what this could be.
The last error log shows that the code was not in a tool change sequence (it says the last tool change was completed).
An art code 9988 is a message from the days before Art sold Mcah3 to Brian at Artsoft. From searching the mach forums I found that
Art once said that art code means there was a divide by zero in the update loop.. But that is way down in the internals of mach - MSM does nto use any plugin just so that it can not hook into low levels of mach. MSM is all done with basic scripts - so they are all run by mach.

I am not sure how to track this down without you needing to do a lot of testing...

Are you runign any back ground scripts? for example a macro pump for a pendant?

Are you runnnig any other processes besides mach that could be interfering? Antivirus etc?

Here are config that I run which have run your drill code successfully (multiple times):
1) win XP 32 bit, mach 3.43.66, parallel port driver, MSM 2.3.12 (this is the actual control on my mill).
2) Win 10 64bit, mach 3.43.66, no motion driver installed, MSM 2.3.12 (this is a desktop I use for simulating programs).

I see one some obvious difference between my setups and yours: the Smooth Stepper.

A test you could try:
a) On any pc other than your control PC, set up a clean mach 3.43.66, no motion driver, MSM - doe this fail? If so, I lean toward an issue in the SS plugin. IT would be best to do this on a 32 bit Win version. omst things will work without a motion device - but probing will not (all probe moves require a motion device driver).

I'll keep thinking about what we might do to narrow this down, but right now I'm out of ideas.

Dave