Hi
I'm running Mach4 v:4809 with ESS v: 285 on an oldish Windows 7 machine, i5 650 @ 3.2GHz Lenovo with SSD main drive - So, reasonably fast. 

I migrated from Mach3 a couple of months ago, because I was having issues trying write macros where Mach3 was obviously having timing issues, because I'd program a "G0 G91 Z-1" and it would end up going in the wrong direction.  Through the MDI, it worked as expected.  So, rather than fight Mach3, I thought it was probably about time to upgrade to Mach4.  Overall I would say my experience with Mach4 hasn't been great.  Given that Mach4 is close to 6 years old, I would have expected a modicum of reasonably mature documentation - I would probably give it a 3 or 4 out of 10, and that's only because I'm feeling generous today! 

That being said - here's my issue:
In trying to develop my macros I regularly manage to get Mach4 to throw up error boxes on start up - basically saying "machine.ini access denied". 

• I've ended up replacing the Machine.ini with with one from the backup folder. but it's not always successful. 
  
• Sometimes I've been successful editing the machine.ini file with (in my case, VS Code, and doing nothing more than adding a space, saving and then deleting the same space) and next attempt at startup it's worked!
• I've also had situations where I've ignored the error dialogs, made changes via the Screen editor, saved and restarted and problem went away

Comparing the current Machine.ini with previous versions there's nothing obvious that would be considered corruptions of the file (e.g. values change and [TMC3in1] parameters have changed position within the file, but otherwise no change)

I'm suspecting this is a bug, but if anyone has any insight I'd love to hear it.

Regards
Peter

Maybe try right clicking and running Mach4 as administrator. I don't think you ever need to manually edit machine.ini, it's basically a storehouse.  I can't remember back as far as Windows 7, but running as administrator on modern versions of Windows seems to work better than NOT running as administrator!! Worth a try:)

Tom Many thanks, 
I suspect that may be the solution.  I know that Windows 7 is very fussy about access control, even though I've tried to make sure that everything is in the admin environment.

I'll try setting the loader to "run as admin" and see what that does.

Peter

I did have high hopes that Running as Admin would solve the issue, but unfortunately it doesn't.

I can't prove it yet, but I get the feeling that Mach4 doesn't shut down gracefully if there's any kind of error - which is likely happening because I'm fumbling around trying to get macros and modules to do what I want them too.  Until I get to the point of being proficient with Mach4 from a coding point of view, it's inevitable that I will cause errors, and probably lots of them.

Over the last few week or so, I've had several occasions when I've come out of Screen editor, and I've had error messages come up along the lines of "can't find ScreenScript" or "ScreenScript can't be updated".   I have also experienced the "there's already an instance of Mach4 running" error after trying to restart, often, but not always, related to the previous errors.  Usually it's ended up with Mach4 crashing - this just gives me the uneasy feeling that Mach4 file handling isn't very robust.

Peter

Hi,
there are two, maybe three chunks of code when Mach is running. If you crash one chunk often times the GUI chunk will carry on running.
In that circumstance its necessary to use the Windows Task Manager to close the remaining chunk that is still running so that you can fire up a fresh instance
of Mach.

When you are coding you work on only a small part. When you want to run that code it gets combined with all the other fragments of code, many hundreds of chunks and they
are compiled into one mega chunk, variously called the 'Screen Script'. If that script fails to compile because of an error in anyone of those code fragments then Mach will fail also.

You are correct, if you are coding and not going too well you can often bugger up Mach, but if you correct, or delete the offending piece of code everything comes back to normal.
I have not encountered any file corruption, other than of my making, in the eight or so years I've been running Mach. To my knowledge Machs file handling is robust but a particularly
clever operator can always screw it up no matter how robust Mach is! ....I've done it plenty!

Craig

Hi Craig,

Thanks for responding.  It's nice to know that once I'm out of the coding/development darkness and into the light of actually using Mach4, that the platform is stable.  At the moment I'm not sure how much further the darkness goes on.  I know that, to a large extent, I'm probably reinventing some of the wheels, but that's one of my foibles - my wife would be happier if I stopped tinkering with code and got on with using my expensive CNC machine . 

I did discover that stopping the GUIexe process helped but not always, and I've had the experience of having to fix a broken code file externally before restarting.  I'm coming to the thought that in addition to the nut holding the wheel, Mach4 and Lua don't help the situation.

From what I understand (I may be wrong here) Lua relies on the application program (ie Mach4) to take care of error handling, and Mach4 hasn't done a great job.  What that means to me is I can inadvertently introduce an error and it doesn't get reported, and... Mach4 allows me to shut down without warning me of the error or giving me the chance to correct it before any damage to the consolidated code file is done.  For example,  It's taken me a while to train my muscle memory not to close to editor window directly, but instead click on the Operator|Edit Screen - that's resulted in Mach4 crashing and me having to go through hoops to restart it.  Most Windows programs that I've used will flag a warning dialog giving you the option to go back or save.

Yesterday I found that one of my mcCntlLog calls with a string.format was trying to handle a boolean as a digit (%d), which it didn't like - but there were no warnings, nothing.  I'm sure there are other similar errors I've introduced that aren't being flagged - maybe the coroutine process interferes with that too.  Altogether it doesn't make for a friendly developing environment.  In some ways Mach3 was better in that respect, but I'm not going back now.

Peter   

Hi,

From what I understand (I may be wrong here) Lua relies on the application program (ie Mach4) to take care of error handling, and Mach4 hasn't done a great job.

Lua has very basic error handling where it has any at all, you get a stack dump and thats about it.

Lua is a scripting language, it takes your Lua instructions and generates what amounts to C code. As you know C is very good, but it has to be in every
way perfect to run, all the data types must match exactly, any and all data structures must match perfectly and so on. Lua is a great way to generate
simple but useful code BUT DOES NOT require the level of perfection and expertise that C code demands.

Amongst the things that simplify Lua is being essentially type free....however it is also one of the areas that cause the most grief. If you feel that simplification comes
at too greater cost then write your code in C.

All Lua code should be written and tested in a sandbox. It must be compiled on its own and then tested by single stepping through it with Zero Brane. Only once its
written, tested and de-bugged should you commit it to being combined with all the other code and compiled into the Screen Script. If you write code and introduce it
into the screen script without de-bugging it first you are asking for trouble.

Mach4 is a CNC software, it primary purpose is a Gcode interpreter and trajectory planner. It has a GUI to assist and a scripting program to assist users
to generate their own code.......but its not a software development environment. If you expect all the bells and whistles of an IDE like MSStudio you'll be disappointed.
Your wife is right, have you noticed they always are, you need to start making chips. Mach4 is largely complete and does not require any additions in order for you to
make parts.

When I started with Mach4 I too wrote a suite of additional code......almost all of it has since been deleted....I just don't need it, I thought I did but practical machining
showed me that I did not. I have maybe four macros that I use day in and day out and could not work/make a living without them....all the rest is just time
wasting.

Craig

Plundikar,

You might want to do what I do when I am messing around with the code.
Make a copy of the Mach4 folder.
Change the code on the original Mach4
If it works great.
Delete the copy and go on my way.
If i messed up (frequent occurrence).
Delete the Mach4 folder and rename the copy to take its place.
Try again.

Bill

Bill, Craig,

Thank you both.  I appreciate the tips.  I'm well backed up and in a sandbox situation, so I'm not too worried about screwing anything up.  It would just be nice not to have to fight the copy/paste directory/file situation as often as I do, but I guess Mach4 is what it is, and I'll have to live with it 

Peter

Hi,

It would just be nice not to have to fight the copy/paste directory/file situation as often as I do, but I guess Mach4 is what it is, and I'll have to live with it 

I have found situations rather like that where I might wish Mach4 had more the characteristics of a good IDE......but it doesn't and that's the end of it. Several hours later when
you've been making parts and Mach has done a great job....that's when you realise that Mach4 is doing EXCATLY as its meant to. Whenever I feel some frustration coming on
when I'm trying to code something I try to remember this. After using Mach4 for about eight years now I can go months at a time when I never invoke the editor or write
so much as a line of code.

I spend hours with Fusion 360 generating and simulating Gcode and my machine just consumes it. The biggest issue I have to worry about is 'did I touch off to that surface
or was it that surface?', or 'did I allow for that clamp?' or something along those lines, I never really have to consider how Mach works, it just does, and 99.999% of the time seamlessly.

Craig