Machsupport Forum
Mach Discussion => Mach4 General Discussion => Topic started by: lrgoodger on February 07, 2025, 06:22:50 PM
-
I have been all through the Mach 4 and ESS configuration screens and I can find nothing that would affect just the rotational axis zero buttons.
The A and B axes are configured correctly and work fine with keyboard jogging or programming. I can zero them with the g92 command, but that is not nearly as convenient as the zero buttons when setting up.
Anyone know how I can turn them on?
All other greyed out buttons come on when Mach is enabled, but not those.
-
I'm not the guy who's the expert, but first place I'd look is go into the screen editor, look at the code in those buttons and see if there's something there to enable them. Might be just not enabled for normal 3 axis use for less confusion for those guys. This is a WAG!!!!
-
Hi,
Tom is right, the Baxis zero and Caxis zero are disabled by default. You need to enable one or both at need.
In the Properties Tab of the Caxis zero button (pictured) click the Enable box, and then, and this is important you need to save the setting. Then close Mach,
as that forces the change to be propagated to the .ini file. When you re-start Mach that setting (ie Caxis zero) will be enabled.
Craig
-
So there is a way to do it. Now all I have to do is figure out how to open that Screen Tree Manager window. I've never seen that.
-
Look at those screenshots Craig posted. On the top left, chose Operator, pick Edit Screen or Screen Editor, or whatever it says!!! You'll have to stumble around in there to find what you need, but the screenshots will get you going.
-
Hi,
sometimes it is possible to edit the screen set and yet those settings get lost at the next restart. Following the procedure that sees the changes 'saved', ie get written to the .ini file
is essential. Don't be alarmed if you make a setting but find that it does not 'stick', you will find the right procedure and thereafter it will 'stick,
but still not actually work until the next restart (where the .ini file is read and implemented).
On a similar matter....I assume you are using wx6.set as screenset? What you have done is change that screenset to better suit your machine. If you update Mach4 at a later date a new
and updated wx6.set will be read into the Mach4Hobby folder and your carefully hand edited copy of wx6.set will be overwritten and you lose all your edits. PITA.
What you should do is make a personalised copy of wx6.set, with a unique name and thus it will never be overwritten even if you update Mach4 at some later date.
On my machine I use wx6.set along with my own edits, scripts etc. I have called the screen set MYwx6.set. By having a unique name prevents it from being over written in those very rae
circumstances where I update Mach4.
Craig
-
Heck, I can't even get my coordinates to save. I searched it before I paid for Mach 4 and what I found said coordinates were automatically saved when you shut down Mach 4. I have never once had it boot up with the same coordinates it had when I shut it down. At least Mach 3 always asked you if you wanted to save them when you shut it down.
The more I use Mach 4, the more issues I find. Maybe its just the version I'm using.
-
Hi,
of course mach4 can save coordinates, you have to program it to do so however.
At least Mach 3 always asked you if you wanted to save them when you shut it down.
Thats how mach3 did it, it that is by no means standard or even common.
If you have been starting to use the edit Screen functions then you will have seen various core pieces of code, namely the ScreenScript, the ScreenUnloadScript, the PLCScript,
the MessageScript, the TimerScript ans ScreenVisionScript. All have their uses, and some I'm not at all familiar with, but the ScreenUnloadScript is the code that runs
when Mach4 is shutting down. In that script there is code to save data you want to save for a new session at a later date. The Mach4HobbyAPI gives you a number
of functions to both read and write data to the .ini file, also called the Profile file.
In lots of respects this is much MUCH better than Mach3, because you can record all manner of data, not just coordinates, but filenames, filepaths, Gcode modals and whatever else you determine you
want. Just because its flexible and powerful does not obviate the need for you to roll your sleeves up and program it to suit your purposes.
Craig
-
Hi,
there is of course an even simpler way of saving coordinates, or rather than simpler, one that does not require you to write any code. Save coordinates
in registers and make those registers 'Persistent'
When you instantiate a register for whatever reason you can choose to make the register persistent. That in effect saves the register in the .ini file on shutdown and
at the beginning of the e new mach session it reads the .ini file and re-populates the register.
This is really only an automation of the more formal method of using the ScreenUnloadScript.
Craig
-
Hi,
a part of the problem is that I never shut Mach4 down, it will run for weeks or even months at a time.
The only time I shut it down is if I need to depower the machine for maintenance or repair or another addition.
The only other time I shut it down...its not controlled or deliberate, its a crash. The other day for instance I accidentally clicked a button that causes a rather complex
homing routine to run involving multiple axis moves and probing moves. It works fine, but in this case I triggered it accidentally, and was concerned that it would physically crash
my machine. Even hitting the <Enable> button did not work, as when the script is running the screen is in effect isolated, and any screen input is ignored until the script is finished.....
not much bloody help when you are trying to abort the motion script!!.
As a note I should have had this script running as a coroutine with the screen script.....then the screen would accept input even when the motion script was running. Didn't think of that when
I wrote it!
Thus I hit the power switch and 'crashed' Mach.
Even if I had a 'Save Coordinates' function in the screen unload script, because I crashed Mach the script would not have chance to run normally. That's often the way, the only time you need the coordinates saved
is exactly the time that they DON'T get saved because Mach closed abnormally. I used to have a coordinate saving script....but I don't bother now for that reason. The only time I really
needed it......it does not work!
One thing that I am considering though is a backup script.
Yesterday I was working at my machine and after a tool change I touched off the Z axis to reflect the new tool height....not a problem, situation normal. As a result
of brain fade though I accidentally zeroed the X and Y axes also, and therefore lost the centre point of my part. Had to devise a means of re-establishing the X,Y zero
before I could continue. PITA!! What I was thinking though was if I had the current work offsets saved then I could go back to them. The only time I have a cockup like this I know
I've mad a mistake within seconds. If I could retrieve the work coordinate offsets from only a minute before I'd be fine.
That's what I'm thinking about now. If I use the PLC script to automatically save the current work offsets every 15 seconds or so in a queue that holds the last half hour say, then I could wind back
from the current pile of 'do-do' I've just created a few minutes to when everything was 'sweetness and light'.
Craig
-
Hi,
just to flesh the idea out a bit.
Imagine that every 15 seconds, or 4 times a minute Mach records the coordinates. I would suggest for completeness you would want to record
the current work offsets, all six axes.
One possibility is to record these data sets in a file. Only downside to that idea is that if Mach crashes, which is exactly when you really need this whole strategy to work
then its possible the file will be left open and therefore subject to corruption, it would however allow a large volume of data to be stored.
Another alternative is to store the data in registers. If half an hours worth of data is stored that would require 6 x 4 x 30=720 registers, which is quite a few, but probably not impossible.
I would want to check with smurph about the advisability of using that number of registers.
Second thought is that what I would not want to do is use a FIFO buffer, as at each instant where another six data items are stored, all the remaining registers would have to be shuffled six places
closer to the end of the buffer. Seems like a waste of processing power.
The alternative I like is to use a 'barrel register' where there are 720 registers in a ring. When a six item data set is to be recorded it is written into the first six available slots. At the next
save interval the pointer would advance by six and the data be written into those six slots and so on. Thus the pointer is pointing to the current data set, whereas (pointer-1) points
to the penultimate data set and (pointer+1) points to a data set recored hale an hour ago.
I think that would work.
Craig