Hi
Having some issues with M3 and M4. Mach is blowing right past it. This is happening on two different machines with the same mach version. .056
The error I get is "Scripter compile error in M4.M1s." Although this is probably mach related, since it's a MSM macro that is causing problems I figured I would start here.
Thanks
Derek
Edit:
Here is some pertinent error stuff:
Fri - 12:16:37 ---Scripter Compile Error. In:M4.m1s
Fri - 12:16:47 ---Scripter Compile Error. In:M4.m1s
Fri - 12:16:58 ---Scripter Compile Error. In:M4.m1s
Fri - 12:17:09 ---Scripter Compile Error. In:M4.m1s
Fri - 12:17:12 ---tap 5/16-18 rotate 90
Fri - 12:17:35 ---Scripter Compile Error. In:M4.m1s
Fri - 12:17:46 ---Scripter Compile Error. In:M4.m1s
Fri - 12:17:57 ---Scripter Compile Error. In:M4.m1s
Fri - 12:18:07 ---Scripter Compile Error. In:M4.m1s
Fri - 12:18:18 ---Scripter Compile Error. In:M4.m1s
Fri - 12:18:29 ---Scripter Compile Error. In:M4.m1s
Fri - 12:18:54 ---Mag pocket rotate 90
Fri - 12:19:08 --- Spindle Stopped
Fri - 12:19:26 ---Tool Change Complete.
Fri - 12:34:06 ---Too Fast for Pulley..Using Max.
Fri - 12:47:06 ---Mag pocket rotate 270
Fri - 13:00:28 ---Offset #38
Fri - 13:00:49 --- Spindle Stopped
Fri - 13:01:07 ---Tool Change Complete.
Fri - 13:03:37 ---Offset #38
Fri - 13:06:18 ---Offset #30
Fri - 13:06:29 --- Spindle Stopped
Fri - 13:06:51 ---Tool Change Complete.
Fri - 13:06:52 ---Too Fast for Pulley..Using Max.
Fri - 13:08:42 ---Offset #30
Fri - 13:10:45 ---tap 12/24 rotate 270
Fri - 13:10:58 --- Spindle Stopped
Fri - 13:11:20 ---Tool Change Complete.
Fri - 13:12:23 ---Scripter Compile Error. In:M4.m1s
The first error was in the middle of a tapping cycle. Fortunately when the spindle didn't reverse the tap pulled out of the collet. I wasn't watching the machine so I didn't realize it happened. The second set tap 12/24 I happened to be standing there when the spindle didn't reverse. It seems to be a random thing. The second set of 5/16 has 8 cycles. it only errored on 6. On the 12/24 it completed 3 before it kacked.
Edit 2:
Just found a post of mine where I was having similar problems with M3 before I installed MSM. I'd still like to hear back from anyone who may have suggestions.
Thanks
Derek
M4 compiler error
Re: M4 compiler error
Hi,
It may or may not be an MSM issue -
MSM uses special versions of M3 and M4 in order to do the things that MSM checks when starting a spindle (like checking to see if one is trying to start the spindle with a probe tool mounted).
It should not be too hard to debug this with you.
1) we don't need a gcode program to test, we can use the MDI line
Click the "clear" button at the top of a MSM page, this will clear the error msg line so that we start with it blank.
go to the MDI control and simply type M4 and hit the enter key - do you get the "scripter error"?
If you do, click the history button - it might give more info about what the error.
2) does the error happen for M3 also? or just M4?
I ask because the MSM macros run other script files which are common between M3 and M4, so if one of the sub script files got clobbered it would likely effect more than just M4.
3) Have you done any hand configuration of things lately? Maybe like making a new profile by manually copying directories and files instead of use the mach loader to create a profile?
4) the macros live in a directory that is dependent on the name of the running profile:
C:\Mach3\Macros\<profile name you are using>\
can you go to that dir and post the m4.m1s file that is there?
5) MSM installs master copies of the M3, M4 etc macros in this dir:
C:\Mach3\MachStdMill\Profile Macro Masters\Mill
You can go there and get a copy of the MSM M4.m1s and copy it to your profile's macro directory (See #4 above) to make sure the M4.m1s is a good copy of the MSM M4 macro.
Dave
It may or may not be an MSM issue -
MSM uses special versions of M3 and M4 in order to do the things that MSM checks when starting a spindle (like checking to see if one is trying to start the spindle with a probe tool mounted).
It should not be too hard to debug this with you.
1) we don't need a gcode program to test, we can use the MDI line
Click the "clear" button at the top of a MSM page, this will clear the error msg line so that we start with it blank.
go to the MDI control and simply type M4 and hit the enter key - do you get the "scripter error"?
If you do, click the history button - it might give more info about what the error.
2) does the error happen for M3 also? or just M4?
I ask because the MSM macros run other script files which are common between M3 and M4, so if one of the sub script files got clobbered it would likely effect more than just M4.
3) Have you done any hand configuration of things lately? Maybe like making a new profile by manually copying directories and files instead of use the mach loader to create a profile?
4) the macros live in a directory that is dependent on the name of the running profile:
C:\Mach3\Macros\<profile name you are using>\
can you go to that dir and post the m4.m1s file that is there?
5) MSM installs master copies of the M3, M4 etc macros in this dir:
C:\Mach3\MachStdMill\Profile Macro Masters\Mill
You can go there and get a copy of the MSM M4.m1s and copy it to your profile's macro directory (See #4 above) to make sure the M4.m1s is a good copy of the MSM M4 macro.
Dave
Productivity Software for Personal CNC Machinists
http://www.CalypsoVentures.com
http://www.CalypsoVentures.com
Re: M4 compiler error
Hi Dave.
It's an intermittent problem. Yea we love those!
It's happening during a G84 cycle on the M4. This time. In a few weeks it may be the M3. I created the profile through the mach loader and I haven't modified the M4 or M3 macros. Ran it half a day today with no errors.
After doing a bit of digging this has been a problem with mach for a while. I've experienced it before. The fix is always restart mach and it goes away. So this morning I started mach,shut it down and restarted. As I said I ran it a bunch with no issues.
I'll send you the m4 and m3 macros monday when I get in.
I hate mach. There just is no good solution for me based on the investment in equipment I have.
Edit:
It may do 10 G84 in a row and miss the next 6
It's an intermittent problem. Yea we love those!
It's happening during a G84 cycle on the M4. This time. In a few weeks it may be the M3. I created the profile through the mach loader and I haven't modified the M4 or M3 macros. Ran it half a day today with no errors.
After doing a bit of digging this has been a problem with mach for a while. I've experienced it before. The fix is always restart mach and it goes away. So this morning I started mach,shut it down and restarted. As I said I ran it a bunch with no issues.
I'll send you the m4 and m3 macros monday when I get in.
I hate mach. There just is no good solution for me based on the investment in equipment I have.
Edit:
It may do 10 G84 in a row and miss the next 6
Re: M4 compiler error
Hi Dave
Can you have a look at the post Graham made here:
http://www.machsupport.com/forum/index. ... cseen.html
Any thoughts.
Thanks
Derek
Can you have a look at the post Graham made here:
http://www.machsupport.com/forum/index. ... cseen.html
Any thoughts.
Thanks
Derek
Re: M4 compiler error
Interesting, grahm's thread says there may be (another) bug in the Mach3 gcode interpreter.
What were the results of testing via MDI?
If Grahm's theory is good, and it is supposed to fail when the M3/4 and S words are in the same block (Line in mach3), then this may explain why it runs OK from the mdi line when only the M3/4 is entered.
Does M3 S1000 on the MDI line fail?
Of course it could be (I'd guess, probably is) a timing problem inside mach (of which there are many) and in that case, failure depends on what else mach or any other process in the machine is doing - all it takes is one thread to get delayed or to run a tad faster than the code assumes it will.. that's the problem with not using critical section locks inside the Mach3 code (I was told by the mach author years back that this was the case).
The M3 & M4 macros that MSM uses are different (more complicated) than the stock mach M3/$ macros - so of course they will take a different amount of time to run. Whether that is at play here or not I can't tell. This further complicates timing related issues as it is easy for MSM users to get into a situation where "stock code runs, but not MSM's, therefore it must be MSM's fault". There is a certain logic to that, but it is not always correct.
<rant on>
These are the types of things that drive me nuts with Mach. When mach screws up, MSM gets blamed, and I get support work to do. That would be OK, IF, when the bugs were verified, a test case created and it was all submitted to Art Soft, the bug would get fixed (eventually). Alas, Brian has flatly told me that he will not work on Mach3... and thus there are 50+ documented and reported Mach3 bugs in the MSM release notes... Artsoft is happy to take your $ for it, but don't expect to get any new releases or bugs fixed. I note that the last release of Mach3 was April 2012 - more than 2.5 years ago. As far as I can tell, Mach3 is now an unsupported product.
<rant off>
Dave
What were the results of testing via MDI?
If Grahm's theory is good, and it is supposed to fail when the M3/4 and S words are in the same block (Line in mach3), then this may explain why it runs OK from the mdi line when only the M3/4 is entered.
Does M3 S1000 on the MDI line fail?
Of course it could be (I'd guess, probably is) a timing problem inside mach (of which there are many) and in that case, failure depends on what else mach or any other process in the machine is doing - all it takes is one thread to get delayed or to run a tad faster than the code assumes it will.. that's the problem with not using critical section locks inside the Mach3 code (I was told by the mach author years back that this was the case).
The M3 & M4 macros that MSM uses are different (more complicated) than the stock mach M3/$ macros - so of course they will take a different amount of time to run. Whether that is at play here or not I can't tell. This further complicates timing related issues as it is easy for MSM users to get into a situation where "stock code runs, but not MSM's, therefore it must be MSM's fault". There is a certain logic to that, but it is not always correct.
<rant on>
These are the types of things that drive me nuts with Mach. When mach screws up, MSM gets blamed, and I get support work to do. That would be OK, IF, when the bugs were verified, a test case created and it was all submitted to Art Soft, the bug would get fixed (eventually). Alas, Brian has flatly told me that he will not work on Mach3... and thus there are 50+ documented and reported Mach3 bugs in the MSM release notes... Artsoft is happy to take your $ for it, but don't expect to get any new releases or bugs fixed. I note that the last release of Mach3 was April 2012 - more than 2.5 years ago. As far as I can tell, Mach3 is now an unsupported product.
<rant off>
Dave
Productivity Software for Personal CNC Machinists
http://www.CalypsoVentures.com
http://www.CalypsoVentures.com
Re: M4 compiler error
Hi Dave
My S word has always been separate. The errors I posted were during a G84 tapping cycle. MDI and spindle toggle has always worked for me. There have been times with an oem screen set where the spindle didn't start and I just clicked the spindle button and it turned right on. You know how it is with mach If your standing in front of it you can usually beat it into submission. It's the unattended stuff that is problematic.
As I stated early on I'm sure this is a Mach problem but I'm looking for help anywhere I can find it.
Here is what I added to the mach post:
Hi Grahm
Thanks for taking the time to write that up.
Here is what I did for half a day Saturday and all day today. I started up Mach then shut it down. Then I started it again and ran my job. So far using this method I have not had a single problem. I have about 4 or 5 days on this job which has 3600 tapping calls. I'm going to keep doing this until I either get through the job or it screws up again.
On thing I changed when I rebuilt my computer was I auto started Mach. I'm wondering if that is causing the problem. Something along the lines of if you start mach before windows fully loads then it causes problems.
What sucks is I could go 6 months with it working like this and then have it start up again.
And then this:
Hi Graham
No PP driver. UC-300 motion controllers.
Since hopefully this will become a repository of what people are trying let me add some more. I'm using the Calypso Ventures MSM screen set. It uses custom M3 and M4 scripts. I don't think that's the problem though as I have the same issues with other machines running the OEM screen set.
One thing I did that I forgot to mention was I opened the M4 macro in the mach script editor. The one listed under operator. I ran the script and when I closed it I was asked if I wanted to save it. I said yes.
So I've made a fundamental mistake on trying to nail down a problem. Change two things at once. I remembered this last night.
My other machine that is running MSM screen set is unmolested. It was missing the M3 command on a regular basis. I'll be trying the restart on it.
You know I could live with this if mach would estop on compiler issues. I understand Brian not wanting to mess with Mach 3 but this is absolutely influencing my decision to move to Mach 4. I have a huge investment in time and money in mach 3 compatible hardware, screen sets, and custom macros. I try not to monetarily reward this type of service.
And yes I'm pissed. Been using Mach since it was master 5 so I feel entitled to be pissed.
Derek
My S word has always been separate. The errors I posted were during a G84 tapping cycle. MDI and spindle toggle has always worked for me. There have been times with an oem screen set where the spindle didn't start and I just clicked the spindle button and it turned right on. You know how it is with mach If your standing in front of it you can usually beat it into submission. It's the unattended stuff that is problematic.
As I stated early on I'm sure this is a Mach problem but I'm looking for help anywhere I can find it.
Here is what I added to the mach post:
Hi Grahm
Thanks for taking the time to write that up.
Here is what I did for half a day Saturday and all day today. I started up Mach then shut it down. Then I started it again and ran my job. So far using this method I have not had a single problem. I have about 4 or 5 days on this job which has 3600 tapping calls. I'm going to keep doing this until I either get through the job or it screws up again.
On thing I changed when I rebuilt my computer was I auto started Mach. I'm wondering if that is causing the problem. Something along the lines of if you start mach before windows fully loads then it causes problems.
What sucks is I could go 6 months with it working like this and then have it start up again.
And then this:
Hi Graham
No PP driver. UC-300 motion controllers.
Since hopefully this will become a repository of what people are trying let me add some more. I'm using the Calypso Ventures MSM screen set. It uses custom M3 and M4 scripts. I don't think that's the problem though as I have the same issues with other machines running the OEM screen set.
One thing I did that I forgot to mention was I opened the M4 macro in the mach script editor. The one listed under operator. I ran the script and when I closed it I was asked if I wanted to save it. I said yes.
So I've made a fundamental mistake on trying to nail down a problem. Change two things at once. I remembered this last night.
My other machine that is running MSM screen set is unmolested. It was missing the M3 command on a regular basis. I'll be trying the restart on it.
You know I could live with this if mach would estop on compiler issues. I understand Brian not wanting to mess with Mach 3 but this is absolutely influencing my decision to move to Mach 4. I have a huge investment in time and money in mach 3 compatible hardware, screen sets, and custom macros. I try not to monetarily reward this type of service.
And yes I'm pissed. Been using Mach since it was master 5 so I feel entitled to be pissed.
Derek
Re: M4 compiler error
This sure has the feel of a code timing hole inside of mach3. Alas, that makes it impossible for me to do any thing definitive to try to resolve the issue for you - as a technical investigation into the issue would require access to mach3 source code.
There are things I could suggest to alter the run time of the M3 / M4 scripts - but since the problem is intermittent with a long period between failures, I suspect that doing that would just add variables to situation.
Another variable is the use of the UC300 motion device. I have some experience with the devices - I have one and have played with it for nominal testing, but I don't use it for real part cutting work. Long ago I set my main systems up on PP and over the years, I've been glad I did that. For better or worse, the PP is the "gold standard" for how mach should behave (as it is built into mach3). Using a PP eliminates any 3rd party motion device and plug-in complications.
Any other motion device uses a plug-in to connect to mach. The plug-in interface is very low level in Mach (timed access ring buffers etc) and it makes for a vulnerability in mach - any mistake by the plug-in can mess up mach. I'm not saying that this is the case with the UC-300, just that it is a possibility that one should keep in mind.
For example, a lot of MSM copies go to people interested in MSM's probing support - and I've found that some vendors are better than others at making their devices work like a PP wrt to sequence of actions etc. Some are great, and a few are truly horrid (those few know what they did wrong but have refused to fix the problem).
I know this may not be a welcome idea, but you might consider converting to a PP... but even that will not guarantee a "Stable mach3 machine" - without mach3 maintenance releases, that phrase may be an oxymoron
Dave
There are things I could suggest to alter the run time of the M3 / M4 scripts - but since the problem is intermittent with a long period between failures, I suspect that doing that would just add variables to situation.
Another variable is the use of the UC300 motion device. I have some experience with the devices - I have one and have played with it for nominal testing, but I don't use it for real part cutting work. Long ago I set my main systems up on PP and over the years, I've been glad I did that. For better or worse, the PP is the "gold standard" for how mach should behave (as it is built into mach3). Using a PP eliminates any 3rd party motion device and plug-in complications.
Any other motion device uses a plug-in to connect to mach. The plug-in interface is very low level in Mach (timed access ring buffers etc) and it makes for a vulnerability in mach - any mistake by the plug-in can mess up mach. I'm not saying that this is the case with the UC-300, just that it is a possibility that one should keep in mind.
For example, a lot of MSM copies go to people interested in MSM's probing support - and I've found that some vendors are better than others at making their devices work like a PP wrt to sequence of actions etc. Some are great, and a few are truly horrid (those few know what they did wrong but have refused to fix the problem).
I know this may not be a welcome idea, but you might consider converting to a PP... but even that will not guarantee a "Stable mach3 machine" - without mach3 maintenance releases, that phrase may be an oxymoron
Dave
Productivity Software for Personal CNC Machinists
http://www.CalypsoVentures.com
http://www.CalypsoVentures.com