Hi,

The reason I say that it is not simple, lets take an easy one such as the Keyboard Function, I would think that this would have an easy option to make it come on as soon as Mach is opened but it does not.

When you fire up Mach in standard form the keyboard is inactive, as a safety measure. Press one button and its active....seems simple enough.
If you wish it come on automatically at start up and accept the risk of an active keyboard rather than actively and specifically turning the
keyboard on, then add one line to the PLC script:

KeybordsEnableToggle().....thats it, one line of code in the PLC script. If this is the feature you want then turn it on!

Craig

Hi,
Jeez, its even simpler than that......you don't need to add a line to the PLC but rather just comment one line out!

The first thing you need to understand is that the onscreen button that you press to enable the keyboard is just a trigger for a function.
What function you ask....check out the pic. It shows the screen editor open and showing the event of the <KeyboarEnable> button.
Note that te function is called KeyboardEnableToggle().

Given that its a toggle, if you press the button it changes from Off to On or from On to Off, simple enough.

In order to enable the keyboard automatically you want the function to run, just once somewhere near the beginning of the program.

When Mach starts up the first part to run is the ScreenLoad script. As the name suggests it loads all the screen elements. It might be possible to run a function here
but what happens if that function relies on another piece of code that has not loaded yet?. The smart way to do it is to wait until ALL the code has loaded and THEN run
the function. As it turns out there is a good way to do this.

The PLC script is equivalent to the macro pump in Mach3. It runs every 10 milliseconds or so. So the process is that the ScreenLoad script runs and once it completes and everything
is loaded then the PLC script runs for the first time. What we don't want however is for the function to run and then a little while later run again...and again...and again...etc.
The PLC has a counter called 'testcount' and is set to 1 at start up and increments every time the PLC runs. There is a small section of code within the PLC script that runs ONLY when testcount=1,
ie it runs only once, at first startup and thereafter given that testcount is no longer equal to 1 not again.

This is that section of code:
-------------------------------------------------------
--  PLC First Run
-------------------------------------------------------
if (testcount == 1) then --Set Keyboard input startup state
    local iReg = mc.mcIoGetHandle (inst, "Keyboard/Enable")
    mc.mcIoSetState(iReg, 1) --Set register to 1 to ensure KeyboardInputsToggle function will do a disable.
    KeyboardInputsToggle()
   
---------------------------------------------------------------
-- Set Persistent DROs.
---------------------------------------------------------------

    DROTable = {
[1034] = "droEdgeFinder",
    [1035] = "droGageBlock",
    [1036] = "droGageBlockT"
    }

This is found by opening the screen editor and looking at the events tab of your screenset, the very topmost element of the file tree.

And look at that, there is the code to turn the Keyboard on, and then for safety its toggled Off by the exact function we want to run. If you comment it out
it will not run and therefore the Keyboard will remain on. Is that what you want? So just add two '-' marks in front of the function call KeyboardInputsToggle()
and you're done. It should look like this:
-------------------------------------------------------
--  PLC First Run
-------------------------------------------------------
if (testcount == 1) then --Set Keyboard input startup state
    local iReg = mc.mcIoGetHandle (inst, "Keyboard/Enable")
    mc.mcIoSetState(iReg, 1) --Set register to 1 to ensure KeyboardInputsToggle function will do a disable.
    --KeyboardInputsToggle()
   
---------------------------------------------------------------
-- Set Persistent DROs.
---------------------------------------------------------------

    DROTable = {
[1034] = "droEdgeFinder",
    [1035] = "droGageBlock",
    [1036] = "droGageBlockT"
    }

Couldn't be much simpler than that. The functionality that you want is already right there, all you have to do is decide whether you want it ON or Off. NFS chose Off for safeties
sake, and can't really fault them for that, but you may choose otherwise, and by adding a couple of comment marks its done.

Craig

HAHA you did it!! I turned it on and now the keyboard is active when I start MACH although the button doesn't turn green anymore which isn't a huge deal!! Thank you. I hope I can set up a Xbox controller.
Now I will try and turn on the Z axis BUT I have a question about that.
A) how do I know which script I should be in when modifying these buttons like Screen Load Script or Screen Upload Script or PLC Script?
B) In the Move to work zero script, If I want Z to move to a Safe Number First before X+Y moves, say it raises to Z=-500 below MACHINE ZERO then X+Y Move to zero then Z drops to work zero IS THIS POSSIBLE TO DO? This is how Mach3 worked, and I like that as I could have several pieces being cut in G54, G55 etc? Hope that makes sense.
I have caught Z not where it should be several times and I am not sure how else to make sure its on top of the part unless I watch it.

Hi,

A) how do I know which script I should be in when modifying these buttons like Screen Load Script or Screen Upload Script or PLC Script?

That is all part of the Mach4 learning curve. It was not really necessary to understand the inner workings of Mach3, all features, good and bad were exposed
and in many cases automatic. Mach4 is very different that that regard. It is a structured software with significant modularity. Understanding how control flows from
one section to another is both important and a challenge. Its a case of starting small and working your way up. You have now encountered two scripts, the
ScreenLoad and PLC scripts....that will keep you going for a while yet.

The ScreenLoad script is the most significant one, and it is where you'l place most of your function definitions. It is also the location of the SigLib{}, aka Signal Library Table.
That is where you'll be putting code for inputs and outputs.

The PLC script is also important if you need or want  a polled input. The downside with the PLC is that it runs every wee while....if you make a mistake in your coding its going
to fail again and again, often locking you out.You should thoroughly test any code 'in a sandbox' before you put it in the PLC script.

The Screen Unload script is what runs when Mach shuts down, things like storing data, and settings. It is largely automatic and seldom needs editing or additions.

In the Move to work zero script, If I want Z to move to a Safe Number First before X+Y moves, say it raises to Z=-500 below MACHINE ZERO then X+Y Move to zero then Z drops to work zero IS THIS POSSIBLE TO DO?

But isn't that exactly how Mach4 works now?

The <GotoWorkZero> function as shipped, moves the Z ie Z zero in machine coordinates ie to the very top of travel and out of harms way, THEN moves to the X,Y  zero. Thereafter, if you
have programmed it so the Z axis descends into the work zone. Isn't that exactly what you want, but rather than go to 'some safe height' it goes to the very top of the Z axis,
surely that is a safe as you can get?

My preference is as Mach ships where the X and Y axes got to zero, but the Z axis remains out of harm way right at the top, rather than drive down into the work zone
Then I jog the Z axis down manually. I can confirm that my Z zero is correctly set without risk. Having it drive down automatically risks any mistake being found but only AFTER a crash.

You can code it to go to some other height, say Z zero (work coordinates) plus some safety allowance, say 50mm. Note this is not standard code but would require you edit the
standard code to reflect your preference.

Fusion 360 allows a parameter 'Clearance Height' and is very convenient and is related to the part you are working on. When the tool path is simulated it
is the perfect opportunity to preview the Z zero and its suitability. When I do rotary four axis paths I specify a safe Z location, but that is done on a per part basis.

The thought of automatically driving to Z zero (work coordinates), especially without some safety allowance gives me the chills!

Craig

That is all part of the Mach4 learning curve.
You can say that again!


But isn't that exactly how Mach4 works now?
No. The Z would go to zero, trip the switch and all would stop. I then tried to give Z a neg-.500 number to stop it from hitting the switch and then the z would travel up and just stop. I then figured out that A is also included in this operation and it did not like it. I removed A0 from the code and now it works as it should. I want to isolated A and remove it from being a slave and have it home independently but that is a completely other video:)

My preference is as Mach ships where the X and Y axes got to zero, but the Z axis remains out of harm way right at the top, rather than drive down into the work zone Then I jog the Z axis down manually.
I do not disagree with this but again it reverts back to a normal process I was use to with Mach3 and being new with 4 I hate to make to many changes to soon. I will probably revert it back and do as you suggested for safety.

Fusion 360 allows a parameter 'Clearance Height' and is very convenient and is related to the part you are working on.
This is also a learning curve. I just recently purchased 360 because I bought a CNC mill and needed the CAM side of things. I am trying to learn it but this will take a while. I use Aspire for this Mach4 machine. I really like Aspire and its capabilities. Its not as much as 360 but its simple and the drafting is endless.

Now all I need to do is figure out how to install the AUTO Touch Plate with a new button and I will be making wood chips again. I believe Avid did a video on this a few years ago but I cant seem to find. I will though.

Hi,

No. The Z would go to zero, trip the switch and all would stop

My apologies, I've had a much closer look at the code and realised its not quite how I thought. These are the two lines in the function:

mc.mcCntlMdiExecute(inst, "G00 X0 Y0")--Without Z moves
    --mc.mcCntlMdiExecute(inst, "G00 G53 Z0\nG00 X0 Y0 A0\nG00 Z0")--With Z moves
Note the first line  mc.mcCntlMdiExecute(inst, "G00 X0 Y0") just moves direct to x0y0 irrespevtive of where the  Z axis is. If its up above the material
all is well but if the tool is still down in the material then it will drag through it on the way to x0y0.

The second line  mc.mcCntlMdiExecute(inst, "G00 G53 Z0\nG00 X0 Y0 A0\nG00 Z0") goes to Z zero, but in machine coordinates, and then to x0y0, and then to z0
in work coordinates. Thus the initial move is up and out of the way. When you say the machine stops is because it hits the Z axis limit switch. That's your own fault...
whats the point of having a Home location that errors out? The home location should be say 1mm inside the Limit switch so that you can drive to the Home location
without a Limit fault.

Just as an example: my mill has three switches on each axis, two Limits and one Home switch. The Limit switches are and the very end, about 1mm inside the mechanical
stops. I have set the SoftLimits to be about 1mm inside the Limit switches and the Home switch about 1mm inside the SoftLimits. That means my Home location is 2mm
inside the Limits, and consequently I can drive to the Home location WITHOUT triggering either a Limit OR a SoftLimit.

I have attached a pic. You can see the switch on the left is slightly closer to the top of the Z axis and is the Z axis upper Limit switch whereas the switch on the right is somewhat lower,
ie the Z axis Home switch.

I have elected to have two Limit switches and one Home switch per axis, and all on their own breakout board input but you don't have to do that. You could use the upper limit switch
as a Limit and a Home, but you need to set a realistic Home Offset parameter so that Mach can distinguish between a Home and a limit. Lets say you choose a Home Offset of 2mm
then in the code above the Z axis would go to the near (within 2mm) the top, but would not trigger the Z axis limit. 

Craig

When you say the machine stops is because it hits the Z axis limit switch. That's your own fault...
Nope it wasn't my issue. It did not like the A0 command. You are somewhat correct but I changed to"G00 G53 Z-.5\nG00 X0 Y0 A0\nG00 Z0") in the G53 and it still stopped. Then I removed the A0 from the 2nd command and it corrected the issue. That was a bit painful but nun the less I fixed it and now my Z only rises to just below Z0.
As I said prior I really like having my A motor as a NON SLAVE on the Y Axis and will post again when I start to change this. I have tried and for some reason I am missing code such as the above to make this work but I am going to cut some stuff first before attempting this again. Appreciate your help.

Hi,

You are somewhat correct but I changed to"G00 G53 Z-.5\nG00 X0 Y0 A0\nG00 Z0") in the G53 and it still stopped.

Yes, that will work, but that also means that the machine Z zero is at the very top of the axis and that is where the Limit switch is.
If you have any code that calls for a G28 or G30 for instance you're going to run into the same problem.

I would suggest that you experiment with Home Offset. It does a very similar thing but makes the Z zero just inside the Limit switch.
Then you can go to Z zero without triggering a Limit. That is what Home Offset is for, and indeed it worked in identical fashion in Mach3
so has been around for twenty years.

You are correct, when you use wx4.set you get A axis moves, being the fourth axis. If you have a three axis machine you need to strip them out.

Craig

So, I really want to have my A/slave axis home on its own that way I am 100% my gantry is always perfect. I have had several issues in the past where a tooth might skip or something gets in the way and the gantry will slightly become out of square and I want that to go away. I am in the process of putting all the axis on there own switches like joeaverage posted in some pics but setting up A axis to do its own thing has proven a bit difficult.
Is there a video someone is aware of that demonstrates how to set this up? All I can find is how to home vids that are not working.
I have started the process but I am struggling as it completely stops this axis when I try to move it.
Could there be a coding issue like I experienced with the z axis? If I can get a feel for how to set this up I think I can figure it out.

Since A is a slave to Y is it even possible to have all 4 motors home independently?