Machsupport Forum
Mach Discussion => General Mach Discussion => Topic started by: Davek0974 on February 18, 2018, 06:29:44 AM
-
Hi all
I'm trying to run one of my first batches of parts on my wonderful Bridgeport conversion and Mach is doing it damnedest to P me off!
Halfway through the third run of the second part, so its made about 15 toolchanges and start/stop cycles already, it decides to start the code with no spindle motor, luckily i was close enough to an E-Stop to save my work and tool.
Going to MDI - S1000 M3 all you get is the "Scripter Compile Error in M3.m1s" - not had this for a while but have suffered tool breakage plenty of times before - there is NO trigger for it, just random.
I restarted Mach and it still will not run so i'm stuck now and no idea what to do, parts need to go tomorrow so the pressure is there as well :(
Was there ever a definitive fix for this issue?
I really can't use it with this uncertainty which i thought was gone.
Any quick suggestions?????
Using V062 BTW
-
Delete the M3.m1s macro, and create a new one with this line:
DoSpinCW()
This seems to happen repeatedly for a small number of users. I've never seen it in 10 years.
-
I did have a look inside it as i read there can be 'odd' characters in there but it looked ok, had a coffee and sandwich, calmed down, went back out and the damn thing worked ok??
I'll try the delete and remake next time but is there a trend for this error in certain versions??
It can get expensive if you're not 100% on the stop button.
How could Mach alter the file - surely it just reads macros, not re-writes them each time??
-
Hi Dave,
you're right it doesn't sound like the source file changing, its fine on most occasions just occasionally the complier will
fail.
Is it possible to have the macro complied and sitting in the macro folder so it doesn't have to get complied at runtime?
Mach4 does something like that, it will compile a source file if theres no object code but otherwise it reaches for
the object code, ie compiled code, preferentially.
If Mach3 could do the same thing it would avoid the potential compiler error.
Craig
-
As far as i know, no.
I can't understand how it fixed itself either, but it's really annoying when you're already being careful because of changes made to the machine etc, have work to do, not much time and it throws this pointless random error up.
Even restarting Mach and re-homing did not fix it, just left it 45 minutes and off it goes again?
-
Hi Dave,
my guess is that its the compiler that fails not the source code.
VB is, to my knowledge, an interpreted language and as such subject to runtime compile errors.
Craig
-
Hi Dave,
i had the same Thing a couple of years ago, well without the self Fixing after 45 minutes.
the only Thing i noticed, when i watched my M3 macro with a HEX Editor was,
that the EOF() was directly behind the ")" of the DoSpinCW().
All i did was to put a couple of 'empty' lines (CRLF) after the DoSpinCW().
The Problem never came up again.
i really can't tel you wether it was
-coincidence
-woodoo
-or just luck.
Thomas
-
Thanks, i'll try that
Can't do any harm :)
-
Dave, Make sure you are wearing your lucky hat when you do make the change.
Mike
-
Needs more than luck with Mach3 i think, the planets have to be aligned sometimes!
-
Hi Dave,
one of the arguments in favour of Mach4 is that Lua is stable.
Craig
-
Hmmm.....
-
Thomas's suggestion 'feels' right.
Try putting 'end <LF> at the end (ie a comment).
Cheers
Roger
-
I deleted the file, made a new one with a couple of returns after the code.
Not had the issue again yet.
-
And.....It's back :(
Ran all day yesterday, not a hint of trouble. Tonight I had one quick job and this time I get no tool length compensation.
The error message this time was "scripter compile error in M6End.m1s" - this is why no TLC as that is in my M6End macro.
Now, last time the M3.m1s played up I saved it as M3.mcc which i believe is pre-compiled?
Seems odd that it now failed on the M6 macro - I have now saved both M6Start & M6End as .mcc files - in the vain hope that it will stop it doing it again. Of course there will always be another macro to fail I guess. :(
-
witch Version of Mach3 are you running?
-
V062
-
ok i turn the "i know something better" mode ON again,
v022 and i am happy with it
"i know something better" mode OFF
-
Yes it has been mentioned before, trouble is, i can't find out what, if any, things may stop working or not work how I expect when downgrading - this i s a fairly customised setup I think and I don't want to risk buggering something up ;)
Also, where do i find the old version?
-
The error message this time was "scripter compile error in M6End.m1s" - this is why no TLC as that is in my M6End macro.
You do know that if you bring up the Operator/VB Script Editor you can run the M6End macro from there, and it will (normally) stop at the problem line?
Cheers
Roger
-
But there is no "problem line" - the code has been running perfectly for some time now, this is a totally random bug.
-
Sigh. I Know.
It sometimes seems that those macros can get corrupted. Dunno how. Does Mach3 rewrite them? Dunno.
I would reboot the PC, restart Mach3, and then explore the M6End macro with the VB Script Editor. Costs nothing to do this, and might be productive.
Cheers
Roger
-
It seems saving them as .mcc is a fix but it only passes the failure on to the next .m1s macro.
I now have M3, M6start, M6end as .mcc versions, I think I will do M5 etc just in case it faults when it should be stopping the spindle....
Next time it fails I will try stepping through whatever one it fails on.
-
It seems saving them as .mcc is a fix but it only passes the failure on to the next .m1s macro.
Really???
That does NOT sound like a macro problem to me. That sounds like a bug in Mach3 or possibly in the XML file.
Since Mach3 normally runs OK, I would think about the XML file. We do know it can get corrupted.
Yes, I have seen that error msg a few times, but I think it was usually due to a bug in a new macro I was developing. I was normally able to get rid of it by tidying up the macro code.
Cheers
Roger
-
From what I've read over the years, it seems that some people run into this all the time, and most never see it.
Of course, that doesn't help at all.
One thing about version 3.043.022 mentioned earlier. It has a serious bug that can cause Mach3 to hang on M6's, depending on the contents of the M6Start macro.
While testing when I first found it, I could get it to freeze when the M6Start had just one line of code. It definitely doesn't work with the M6Start in the 2010 Screenset.
-
Um. That kills .022 for me!
Cheers
Roger
-
From what I've read over the years, it seems that some people run into this all the time, and most never see it.
Of course, that doesn't help at all.
One thing about version 3.043.022 mentioned earlier. It has a serious bug that can cause Mach3 to hang on M6's, depending on the contents of the M6Start macro.
While testing when I first found it, I could get it to freeze when the M6Start had just one line of code. It definitely doesn't work with the M6Start in the 2010 Screenset.
And that there stops any thoughts of using 022 for me too - I have a fair bit in M6 and I use the 2010 screen set.
There is nothing worse than a random bug, there is no pattern to it, most of the time it will run all day then others it will fail after a few hours and others like yesterday it will fail upon first run.
I'm very limited in what software I can run due to using a CS-Labs controller.
-
At what stage does the CS-Labs controller become a serious limit to what you can do?
Cheers
Roger
-
Limited support for software - you can't use stuff like UCCNC on etc
-
What about CS Labs new software?
-
just a question, how does your Cam create M3 call's?
M3 S1234 or
S1234
M3
-
What about CS Labs new software?
They have one in Beta, I have it downloaded, have not tried it because it has limited functionality, no macro editing and no screen editing - i could not use it on my mill without these functions.
They say it will all be there but after the beta stage is done so no idea when.
-
just a question, how does your Cam create M3 call's?
M3 S1234 or
S1234
M3
(END PROFILES)
N10 M5
N12 M9
N14 T3 M6
N16 S4000 M3
N18 G54
N20 M7
N24 G0 X232.214 Y5.999.........
-
i have changed this on my machines to
S1234
M3
years ago, but realy can't remember why.
-
Interesting, its the same format in my Vectric code too.
-
during trying to remember why i did this, i was googling arround,
and found this:
https://www.machsupport.com/forum/index.php?action=printpage;topic=28339.0
-
Interesting, more food for thought.
-
I have saved all my macro's as .mcc files and deleted all the .m1s copies.
Will see if that makes any difference.
BTW do not do this to macropump.m1s - it stops it running ;)
-
Interesting.
I write my own g-code programs (out of my head) and use the following format:
f100 s2000
m3
As far as I can remember, this has never given the Scripter Compile error.
But playing around with the g84 command seems a bit risky as it is greyed out in the manual, meaning it never got passed Art's checking (or Brian's?). Obviously there was a bug in it they could not find. My spindle can't do tapping anyhow (DC servo, not suited to those speeds) so I thread mill instead. Yeah, slower.
On the other hand, if I launch Mach3 .062 and go straight into a program, the first Spin parameter can be missed, with the spindle going to max speed. If I spin the spindle up just once by hand first, all is well for the rest of the day. There is a funny in there somewhere. (Just one???)
Cheers
Roger
-
I don't mind messing with post coding but, and thats a big but, i probably will not do it as this is a random issue - if the code was wrong it would fail, every time. This issue seems to have a bit of luck attached to it - most of the time it will work, then fail, i've had it mostly fail in the middle of the day i.e. not right on start-up so it will have done many starts and stops but then just decide to fail, most of the time in the middle of a code file.
All the apps i post code with have the same format so i can't see how it can be that.
My CS-LABS controller has a custom code M84 instead of G84 - pretty certain the rigid tapping is done directly in the controller not Mach.
-
My CS-LABS controller has a custom code M84 instead of G84 - pretty certain the rigid tapping is done directly in the controller not Mach.
Problematic, but ...
You see, when Mach3 tries to interpret the G84 instruction, it has to do something. It was not written (afaik) to be able to hand off an entire g-code instruction to an external controller. In fact, I don't believe such external controllers even existed when Art started writing Mach1 and then Mach2.
So what Mach3 is doing internally - dunno, but I am sure it is trying to sync the spindle index pulse to the Z axis movement - in exactly the same way that Mach3Turn does threading. It is EXACTLY the same same thing.
Now, if CS-Labs is using a macro M84 instead - it would be extremely interesting to know what the macro contains! What is it telling the controller? How is it handled? Enquiring minds want to know!
Greg and Andy at Warp9 are trying to get the ESS to handle a full encoder rather than rely on the Index pulses. This is tricky for two reasons: Mach3 does not rely on the external engine for the sync process (as above), plus there is limited room in the FPGA in the ESS for a PID control loop. But the demand is there in the customer base. That means we keep hassling Andy about the delivery date for this.
What we really need is for Mach5 (5, not 4) to be able to negotiate with an external pulse engine over how to handle the more complex commands. That is, Mach5 needs to be able to send the whole command to the external engine and to be told when the instruction has completed. That also means we will need a whole new generation of external controllers. That is going to take some time to happen. Yeah, dreaming ...
Cheers
Roger
-
Here is the M84 code.....
'V2
Parg = Param1()
Qarg = Param2()
Rarg = Param3()
Speed = GetRPM()
Zpos = GetOEMDro(180)
If Parg = 0 Then
Message"M84 ERROR P = 0"
DoOEMButton(1003)
Sleep(50)
DoOEMButton(1002)
End
End If
If Rarg = 0 Then
Message"M84 ERROR R = 0"
DoOEMButton(1003)
Sleep(50)
DoOEMButton(1002)
End
End If
If Speed = 0 Then
Message"M84 ERROR S = 0"
DoOEMButton(1003)
Sleep(50)
DoOEMButton(1002)
End
End If
If Zpos < Qarg Then
Message"M84 ERROR Zstart < Q !!!"
DoOEMButton(1003)
Sleep(50)
DoOEMButton(1002)
End
End If
If Zpos = Qarg Then
Message"M84 ERROR Zstart = Q !!!"
DoOEMButton(1003)
Sleep(50)
DoOEMButton(1002)
End
End If
Qarg = Qarg - Zpos
Qarg = Abs(Qarg)
If Qarg < 0.001 Then
Message"M84 Canceled"
End
End If
Message"M84 START"
' set parameters in user dro
SetUserDRO(1511, Qarg) ' depth
SetUserDRO(1512, Parg) ' pitch
SetUserDRO(1513, Speed) ' rpm ffd
SetUserDRO(1514, Rarg) ' rpm rev
' start rigid tapping cycle
NotifyPlugins(10101)
' wait for csmio-ip end of rigid tapping cycle
SetUserDRO(1510, 0)
While(GetUserDRO(1510) = 0)
Sleep(50)
NotifyPlugins(10102)
Wend
Message"M84 DONE"
And here is what the input code looks like...
(M5 TAP)
N3036 M5
N3038 M9
N3040 M1
N3042 T6 M6
N3044 G54
N3046 M7
N3050 G0 X-9.5 Y-7.9
N3052 G43 Z34.612 H0
N3056 Z24.612
N3058 Z23.612
N3060 M84 Q11.262 P0.8 S350 R350
N3062 Z23.612
N3066 Z34.612
Would there ever be a Mach5?
While converting macros to .mcc versions, I did find one bug - the macro Feedrate.m1s would not compile, syntax error, it contained this line of code....
Feed = commanded feed() Setfeedrate ( feed )
I split it onto two lines and it saved ok, no idea what it does or even if it ever gets used but would not compile in its original form.
-
Art's inventive genius never ceases to amaze me.
OK, the magic sauce is that line NotifyPlugins towards the end, which triggers the MyNotify function in any loaded plugin. A parameter (10101) is passed which the CS-Labs Plugin recognises as being for M84. The plugin reads data from the DROs which were just set up and sends that info to the CS-Labs external engine. The limitations of the 'standard' comms (basically G1 and G0) are bypassed that way.
The difference here is that the CS-Labs hardware relies on the SW plugin running under Mach3 for the extra info. As I said, Art was a bit of a genius.
The FeedRate macro had been corrupted somehow by Mach3. There should have been a Linux-style LineFeed between the two instructions, but Windows is not real good with that Linux feature: it prefers <CR><LF>. Trying to edit a macro using NotePad can be tricky: you need to use the embedded VB Script Editor to get the right line format.
Cheers
Roger
-
The FeedRate macro had been corrupted somehow by Mach3. There should have been a Linux-style LineFeed between the two instructions, but Windows is not real good with that Linux feature: it prefers <CR><LF>. Trying to edit a macro using NotePad can be tricky: you need to use the embedded VB Script Editor to get the right line format.
Cheers
Roger
Yes, always use the editor, Notepad does make a mess of it, as does TextEdit on a Mac (worse in fact)
-
Notepad works perfectly fine. I've used it for all of the macros I've written, and never had a problem.
The Mach3 editor doesn't use carriage returns, and saves macros as one long line of code.
Would there ever be a Mach5?
Since most Mach3 users don't appear to want to move to Mach4, it's highly unlikely.
By the time Mach4 is 100% complete, it will probably have taken 7+ years of development. As a ground up new program, this was their chance to make the best Mach that they could.
Maybe that's what they did, but it's not the Mach4 that many wanted.
-
The Mach3 editor doesn't use carriage returns, and saves macros as one long line of code.
Not quite. Open a macro up with Notepad and indeed that's what it looks like.
Now open it up with the VB Script Editor and you will find it nicely laid out.
Different NewLine characters is the reason. <NL> as opposed to <CR><LF>
Ah well, there is always UCCNC and so on.
Cheers
-
Since most Mach3 users don't appear to want to move to Mach4, it's highly unlikely.
By the time Mach4 is 100% complete, it will probably have taken 7+ years of development. As a ground up new program, this was their chance to make the best Mach that they could.
Maybe that's what they did, but it's not the Mach4 that many wanted.
I should not be crytical because I could certainly not do anything better myself but +1 to Gerry for summing up the situation regarding the original, long-term, Mach3 users.
Ah well, there is always UCCNC and so on.
Ohh Roger, what are you thinking ;D
Tweakie.
-
:)
-
Ah well, there is always UCCNC and so on.
Not if you invested in a CS-LABS controller ;)
-
Notepad works perfectly fine. I've used it for all of the macros I've written, and never had a problem.
The Mach3 editor doesn't use carriage returns, and saves macros as one long line of code.
Would there ever be a Mach5?
Since most Mach3 users don't appear to want to move to Mach4, it's highly unlikely.
By the time Mach4 is 100% complete, it will probably have taken 7+ years of development. As a ground up new program, this was their chance to make the best Mach that they could.
Maybe that's what they did, but it's not the Mach4 that many wanted.
That explains why i blamed Notepad - on opening in NP the files are indeed one line, open in editor and they are ok - my presumption was that Notepad did not open it correctly and was therefor Fubar :)
I stand corrected, thanks
-
Create it in Notepad, it looks correct in both Notepad and the editor.
Create in the Editor, and it only opens correctly in the Editor.
Not if you invested in a CS-LABS controller
I would think you could get 75% of it's original cost on Ebay. ;)
-
Maybe but
1 - its only just been built :(
2 - what other unit is as robust, complete and will work with 0-10v servos ?
-
Analog servos limit your options. CNC Drive is supposedly working on an analog board, but I have no idea what it will cost, or when it will be available.
-
Hi,
CsLabs have a Mach4 plugin which by there own admission is a work in progress but all the basic stuff works.
You could therefore use your existing hardware with Mach4. Lua is precompiled and so you don't get
compiler errors at runtime.
Craig
-
Thanks, I have been looking at this tonight, just catching up really.
I gather i would need the industrial license to be above board - i run a micro business but the price is out of my range at present.
I'll stick with Mach3 for present, lets see how it likes precompiled macros ;)
-
.
-
Hi,
an industrial licence might be neccessary eventually but what I'm suggesting would cost nothing...just download
Mach4Hobby and the CSLabs plugin and firmware an try it in demo. Free is within even my budget!
Craig
-
My issue is not wanting to upset my machine - it gets used, a lot. Updating the firmware would mean ensuring i can return to my version, Its not just a matter of trying it - i have little doubt it would probably work but, to actually "use" it would mean a lot of macro work, screen customising etc - i need two installs as i have a separate high-speed head on my mill so i use a different profile because this setup does not work like the standard Bridgeport setup.
I would need touch-plate probing on one, rigid tapping on the other, tool length comp fed to the knee axis, a custom file load option to comment out any G43 lines as the TLC is fed direct to knee, spindle power DRO, height-setter DRO with buttons for loading the tool table, soon it will have a power drawbar of some sort and in the future it will sport an ATC.
Simple really ;)
-
Hi Dave,
if you rule out all other solutions it rather sounds like 'scripter compile errors' are a fact of life.
Craig
-
:) It is what it is, not an average Bridgeport conversion.
Lets see how it plays with pre-compiled macro's.
Errors and bugs are ok, but this particular one breaks tools and spoils work and to make it worse it is random :)
-
Hi,
yeah precompiled macros are a definite way forward...can Mach3 do that, or rather can VB do that?
Craig
-
Seems so, just save them from the editor as .mcc instead of .m1s
-
Hi,
makes me scratch my head...if its compiled then all other scripts would have to be compiled and
be linked for it to be ready to run. That does not seem to be the case.
I would guess that if indeed the script is compiled it will be object code and still needs to be linked before it can run.
It occurs to me that 'compiled' means that only half the job is done and the remaining half (linking) which by necessity has to
be done at runtime would still be subject to random errors.
Given VB's essential 'interpreted' DNA I am unsure that precompiling will be sufficent to overcome your problem.
Craig
-
What this so-called pre-compiling MAY do is prevent Mach3 or the VB interpreter from rewriting the file back to disk incorrectly after it has used it. The .mcc suffix might even be just a flag telling Mach3 not to write out to disk. Given how often the XML file can get corrupted, this could be a good idea ...
Cheers
Roger
-
The wonders of Mach3 :)
Once the file is saved as .mcc it is filled with gobbledygook and can not be edited with Notepad etc any more so there is certainly some conversion going on there.
The editors Save-As dialog box lists "Pre-compiled" as an option as well.
Interesting
-
I learn something new every time. I had never looked at the options for the save command. Never bothered.
So I saved a 'spare' macro as a .mcc file, and then opened it with Notepad. Hum ... a lot of gibberish, then the text of the original macro in a slightly mangled manner, and some more gibberish. OK - sort of packed?
Then I tried to open that file with the VB Script Editor. I had to type in the extension as .mcc was not an option, but it loaded. Well, sort of: the 'Cypress enable' at the start appeared, but nothing else. Almost as though the Script Editor stopped loading as soon as it ran into non-ASCII characters.
At least, it seems that once the file has been pre-compiled, Mach3 is not likely to try and change it! This could have some value.
So ... why doesn't Artsoft ship most of the macros pre-compiled?
And why isn't there anything about the .mcc extension in any of the manuals I have looked in recently? Sigh.
Cheers
Roger
-
Hi,
when code is compiled it gets turned into object code, the gibberish, yet it retains a few references to the variables in the form of a table. The object code
is passed to the linker which resolves the last variable references to produce executable machine code.
A de-compile process is the secret wet dream of every hacker....its not going to happen. Likewise you can't edit it either, you'll just break it.
Any code that NFS wants for us to run but doesn't want us to have the source code is often shipped as object code only. It is mentioned in Mach4 as a method for your
own code to be published and used but without releasing the source. I can only guess that Mach3 was written and its manuals published in an earlier and less
cynical time.
Craig
-
I learn something new every time. I had never looked at the options for the save command. Never bothered.
So I saved a 'spare' macro as a .mcc file, and then opened it with Notepad. Hum ... a lot of gibberish, then the text of the original macro in a slightly mangled manner, and some more gibberish. OK - sort of packed?
Then I tried to open that file with the VB Script Editor. I had to type in the extension as .mcc was not an option, but it loaded. Well, sort of: the 'Cypress enable' at the start appeared, but nothing else. Almost as though the Script Editor stopped loading as soon as it ran into non-ASCII characters.
At least, it seems that once the file has been pre-compiled, Mach3 is not likely to try and change it! This could have some value.
So ... why doesn't Artsoft ship most of the macros pre-compiled?
And why isn't there anything about the .mcc extension in any of the manuals I have looked in recently? Sigh.
Cheers
Roger
Yep, I did read somewhere, that once compiled you cannot edit so you MUST save a copy in a folder somewhere, you must delete the .m1s files or Mach will simply read those instead.
-
A de-compile process is the secret wet dream of every hacker....its not going to happen.
Oh???
There are any number of Disassemblers on the market - many of them free. Must be a lot of wet hackers out there ...
Let us start with a simple macros:
'M126 write top pulley speed
TPS = param1()
MPS = param2()
setoemdro(57,TPS) ' pulley max
setoemdro(121,MPS) ' pulley minimum
End
What you find in the .mcc file looks like this but the first line is repeated many times before we get here:
þÿ2 þÿ2 þÿ3 þÿ3 þÿ4 þÿ4 þÿ5 þÿ5 þÿ6 þÿ6 þÿ7 þÿ7 Z ÿÿ ÿÿÿÿ p a r a m 1 ôÿ T P S Z ÿÿ ÿÿÿÿ p a r a m 2 ôÿ M P S þÿ9 Z ÿÿ ÿÿÿÿ S e t O E M D R O ôÿ þÿy Z ÿÿ ÿÿÿÿ S e t O E M D R O ôÿ ð : ÿÿ ; ; < ;ÿÿÿÿ = ÿÿ > > ? >ÿÿÿÿ <ÿÿÿÿ @ÿÿÿÿ A ÿÿ B Bÿÿÿÿ
I think I can see the source code there - slightly mangled of course, but NOT object code or binary assembler.
Takes all sorts.
Cheers
Roger
-
Hi Roger,
a disassembler or de-compiler loses references to the sources variables. Object code retains some, may all of those references but is by and large
impossible to reverse.
You or I would be wasting our time when we could be making billions if we could come up with a de-compiler/disassembler that can take executable code
and produce source code.
I suggest you try a disassembler or two and explore their limitations, I did and was shocked at how much you lose. I could not follow the disassembled
code despite me having written the source code and in assembler at that. How much worse would it be trying to de-compile C?
Craig
-
Hi Craig
I started writing in Assembler around 1970. At one stage I 'knew' just about every microprocessor language - and then gave up tracking the ones which I knew were not going anywhere. I also knew most standard high-level languages until they too got boring (being little more than variants on each other).
I have written everything from device drivers to science packages to database systems (not the app, the system), robot and machine controllers, image analysis systems, ...
I have debugged OSs, compilers and ... Both the first OS and the compiler were fun, as I was able to tell the vendor exactly where the bug was without the source code.
Now - I am retired.
So yes, I know what a disassembler can and cannot do. I agree with the limits you gave.
Mind you, decompiling C is not that hard: there is little difference between the two!
Cheers
Roger
-
I had a small run of parts on the mill today, about 15 tool changes in all - all worked perfectly, no scripter errors.
Too early to say fixed or not but it's promising.
-
Running again this morning - still no sign of trouble :)
-
Fingers crossed!
Mike
-
hello Dave,
you wrote that you are using rigid tapping
with cs lab enc module?
in G84 or with M84 ?
Thomas
-
Hi
yes, I modded my posts to output M84
-
Hi Thank you for the reply,
if i use M84 my System allways get stuck.
-
Have you got the full M84 output code?
Should appear like this...
M84 Q11.262 P0.8 S350 R350
-
what a actual do is:
Z = 0
then
M3
M84 P2 Q-20 S50 R100
i suggested that it will go to -20 and then go back
but it goes to -20 spindle stops wait for the 2 sek start's spindle CW again
and goes with f200 further down (Z-) until i press stop
-
Take the M3 out, the spindle is controlled internally by the M84 routine - its scary but does work ;)
Your parameters are in the wrong order too :)
Should be M84 Q P S R
-
Hi Dave,
i have taken to original exaple form CS Lab
%
G18 G21 G40 G50 G80 G90
G0 X0
Z0
M84 P2 Q-30 S50 R100
G0 Z5
X10
M5
M30
%
if i try to run this it get stuck at M84 line.
M84 will only start with a M3 before.
BTW how are your setting's in spindle Setup.
Thank You
i have tryed
M84 Q-30 P2 S50 R100 as well no difference.
-
Ok, did you copy the new M84.m1s macro to your macros folder - it will not work without this.
Next, the parameters must be in the right order.
P = Pitch
Q = thread depth
R = speed feed
S = speed retract
Next, I am not using feedback, in spindle I am only using "use spindle feedback in sync modes" - i found closed loop/PID not to work very well.
Dave
-
ok Problem found.
M84 uses the Outputs for spindle controll witch are configured directly.
i am using them only virtualy and do the control in M3/M4/M5.
thank you
-
Glad you sorted it.
My mill has been running a fair bit today, still no sign of the scripter compile error :)
-
To the best of my knowledge, PID control only works when you are using the PP directly. It does not work with any external motion controller (ie it is not implemented).
Cheers
Roger
-
That explains it :)
It sort of worked but was very poor in response.
-
Another 3-1/2 hours of running and no scripter compile errors :)
Confidence is rising.......
-
Still working ok, I think I can safely recommend anyone that is suffering the random compile error to save all their macros as .mcc ones.
-
Hi All,
sorry to "revive" an old thread!
I am getting the "scripter compile error" message appear. I am trying to use the "save m1s file as mcc" fix, but when I select "save file as .mcc" from the Vb editor in Mach3 it doesn't seem to do anything. I can see no files with the extension .mcc in the folder - all it seems to have done is re-save the original file.
Am I doing something wrong, or does the Mach3 Vb editor no longer save this file type? I'm using Mach3 R3.043.062.
Many thanks for any help you can give,
Mike.