Messages

1

Mach4 General Discussion / Re: How to mark an axis as "Homed"

« on: October 08, 2019, 04:41:14 PM »

I gave you the correct answer and then possibly muddied the water by trying to demonstrate how and why the profile functions are used.  For on the fly changes, which is what you are doing, do this:

Code: [Select]

--Set Mach 4 to home all axes in place at run time to take effect immediately.
--The changes will be written to the profile when Mach is shut down.
--If you don't want the changes to be permanent, then change them back before shutting down Mach.
mc.mcAxisSetHomeInPlace(inst, 0, 1)
mc.mcAxisSetHomeInPlace(inst, 1, 1)
mc.mcAxisSetHomeInPlace(inst, 2, 1)
mc.mcAxisSetHomeInPlace(inst, 5, 1)

--Mach 4 API call to home all of the axes (in-place)
--The home offset in the config dialog will automatically be applied! 
-- No need to programmatically set the home offset every time as it probably won't change.
mc.mcAxisHomeAll(inst)
 
        --Do we really need to swap back? 
mc.mcAxisSetHomeInPlace(inst, 0, 0)
mc.mcAxisSetHomeInPlace(inst, 1, 0)
mc.mcAxisSetHomeInPlace(inst, 2, 0)
mc.mcAxisSetHomeInPlace(inst, 5, 0)

Use the above code. 

But to clarify the profile use case: (which you should NOT use in this circumstance).

Code: [Select]

--change Mach 4 config for all axes to home in place, save & reload the profile
mc.mcCntlConfigStart(inst)
mc.mcProfileWriteInt(inst, "Axis0", "HomeInPlace", 1)
mc.mcProfileWriteInt(inst, "Axis1", "HomeInPlace", 1)
mc.mcProfileWriteInt(inst, "Axis2", "HomeInPlace", 1)
mc.mcProfileWriteInt(inst, "Axis5", "HomeInPlace", 1)
mc.mcProfileFlush(inst)
mc.mcCntlConfigStop(inst)

Either way will work.  But going the config state and profile route is a LOT slower. 

Also, for brevity, none of these examples are looking at the return codes from the API calls.  You REALLY want to do that in your real live script. 

One more thing.  Usually, for ABS encoders, this would be the setup:

1. Conifgure Mach axis homing tab. 
2. Set home in place for each axis with a ABS encoder. 
3. Set the offset for each axis in machine coordinates.  Find this for each axis prior to configuring the homing by:
   a. Put the position DROs in machine coordinates mode.
   b. Jog to the desired home position and record the current machine coordinates.  This will become your home offset.
4. Set the desire home order.  Base 1.  Z is usually 1 on a mill.  X and Y can usually be homed together set as 2. Maybe not important for ABS encoders.  But set it for completeness. 

Then the regular homing buttons will just set the home offset with no modifications required.  After a RefAll, issuing "G00 G53 X0 Y0" in MDI should carry the axes to the home positions. 

You do not need to set the home offsets again unless you change the encoder to table relationship. In most cases, this would only need to be done once and would not need to be update unless the machine was repaired or something.  If you are worried that this relationship will change and need to be updated every so often, I would consider that a mechanical problem that needs to be fixed.  Loose servo motor coupler, etc.. 

But if you have to have the optional switch homing, then you can expand on this stuff.  If want to use the profile method to set the home offsets, look at the profile and find an Axis# section (where # is 0 to 5) to get the keys you are interested in.  (section, key, value)

If you set values wit the mcProfile*() functions, use mcProfileFlush() to make the modifications stick.  If you modify axis values with the API functions, use mcProfileSave() to make the modifications stick.

Steve

2

Mach4 General Discussion / Re: How to mark an axis as "Homed"

« on: October 08, 2019, 01:49:08 PM »

Code: [Select]

        --change Mach 4 config for all axes to home in place, save & reload the profile
mc.mcCntlConfigStart(inst)
mc.mcAxisSetHomeInPlace(inst, 0, 1)
mc.mcAxisSetHomeInPlace(inst, 1, 1)
mc.mcAxisSetHomeInPlace(inst, 2, 1)
mc.mcAxisSetHomeInPlace(inst, 5, 1)
mc.mcCntlConfigStop(inst)
mc.mcProfileSave(inst)
mc.mcProfileReload(inst)

Why use all of the profile stuff when you are doing nothing with the profile at all? 

mc.mcCntlConfigStart(inst) puts the machine in the configuration state.  The idea is that you would then write things to the profile with mcProfile* functions.  Then call mc.mcCntlConfigStop(inst).  This is EXACTLY what we do with the control configuration dialog.

1. Enter the config state.
2. Read the profile's existing settings and display them in the dialog.
3. Allow the user to make changes.
4. If Ok or Apply is pressed, write the changes to the profile.  Then mc.mcProfileFlush(), which makes the changes stick.
5. Exit the config state.  This causes the control to re-read the profile and bring in the new settings. 

This is a very controlled process and can only be done with the control in the Idle state.  Not good for on-the-fly changes at run time. 

Code: [Select]

        --Set Mach 4 to home all axes in place at run time to take effect immediately. 
        --The changes will be written to the profile when Mach is shut down.
        --If you don't want the changes to be permanent, then change them back before shutting down Mach.
mc.mcAxisSetHomeInPlace(inst, 0, 1)
mc.mcAxisSetHomeInPlace(inst, 1, 1)
mc.mcAxisSetHomeInPlace(inst, 2, 1)
mc.mcAxisSetHomeInPlace(inst, 5, 1)

Steve

3

Mach4 General Discussion / Re: Axis Enable API Call?

« on: October 06, 2019, 08:17:54 PM »

No, I was talking about opening the screen editor, clicking on a particular control you are interested in and looking at the properties in the properties window.  Those are the properties that you can set with scr.Get/SetProperty().  The property names can be taken verbatim and they are case sensitive and all spaces need to be there too.  For instance, the "Button State" property of a toggle button.  The capital B and S as well as the space in the name is important. 

By clicking on each type of control, and looking at the properties window each time, you can build a list of properties for each control that you may be interested in.  Pretty much the only ones you really don't want to mess with are the "Enable With Machine" and "Enabled States" as you can paint yourself into a corner with those.  They are not considered run time changeable.  And changing control actions, signals, and scripts at run time will probably not yield the desired results either. 

scr.ButtonUp() isn't a property.  It is a function that mimics what happens when a button is let up.  It really should NEVER ever be used.  Ever.  It is there simply because there was a similar function in Mach 3.  But it doesn't follow the paradigm of Mach 4 screen programming at all. 

Steve

4

Mach4 General Discussion / Re: Turn | Is eccentric turning possible with Mach4?

« on: October 06, 2019, 04:34:51 PM »

There is nothing in standard G code that specifically does this.  Hence why SolidCAM would not post a program to do it.  There may be machine that have custom G codes for this type of operation though.  And it would have a specific post processor for SolidCAM to use it. 

If your motion controller is capable of real time gearing of the X axis motor to the encoder on the spindle, you could do something like this.  For instance, I know a Galil could do this. 

Otherwise, to me, this would be more of a 4th axis milling type of operation. 

Steve

5

Mach4 General Discussion / Re: How to mark an axis as "Homed"

« on: October 06, 2019, 04:25:38 PM »

There is no script API to set the homed state of a motor (and thereby the axis it is attached to), only in C or C++ can you do that.  So set the axes to use "home in place" in the configuration dialog and call the regular homing API (mc.mcAxisHome() to turn the LEDs on and mc.mcAxisDeref() to turn the LEDs off)  Then do what you want. 

Steve

6

Mach4 General Discussion / Re: Axis Enable API Call?

« on: October 06, 2019, 04:20:30 PM »

Just set the "Button State" property of the toggle button to "0" for up, "1" for down.  No need to make it even more complicated with color and text changes.  Just set the state of the existing button. 

Have a look at ALL of the properties of the various screen elements.  And do some empirical testing to see what they do.  Most can be set with scr.SetProperty().  The ones with True/False, On/Off, Up/Down are usually set with "0" or "1" and not the actual text value that shows in the properties window.  The color properties are in HTML format, e.g. "#RRGGBB" where RR is the red component, GG is the Green component, and BB is the blue component.  To truly determine what sets the property, use scr.GetProperty() to see what it brings back.  Because I'm not going to document this stuff when only .001% of our users will ever need this information.

Look at the OSIG_MACHINE_ENABLED signal state to determine the enabled state of the machine. 

Steve

7

Mach4 General Discussion / Re: Axis Enable API Call?

« on: October 03, 2019, 11:13:07 PM »

There is no such thing as axis enable outputs.  There are motor enable outputs.  The concept is that motors are attached to some sort of drive that needs to be enabled.  No axis is connected to any such creature.  Enabling an axis is basically telling the G code interpreter that the enabled axis is ok to use in G code.  if the axis is not enabled and it is used in G code, the interpreter will balk.

The enable button is enabling the control and the motors.  So if that is what you want to duplicate, that API call is:

mc.mcCntlEnable(inst, 1) -- enable
mc.mcCntlEnable(inst, 0) -- enable

There is no code in the enable button itself.  It is simply a toggle button with the up and down positions tied to the stock action of "Enable On" and "Enable Off"  Open your screen in the editor and click on the enable button.  Then in the properties window, click on the little lightening bolt button to switch from the properties view to the events view.  Here you will see how the enable button is setup. 

But basically, the stock action of "Enable On" is equivalent to mc.mcCntlEnable(inst, 1) and "Enable Off" is equivalent to mc.mcCntlEnable(inst, 0).

To keep someone from pressing the enable button unless some inputs are activated, all you need to do is "disable" the enable button.    You do that with the Enabled property and scr.SetProperty() screen API function. 

scr.SetProperty(cntlName, propertyName, value)

where:
cntlName is the value of the "Name" propert of the enable button.  In my scree, the enable button is "tbutton2".
propertName is the name of the property that you wish to modify.  "Enabled" in this case.
value is what you want to set the property to.  It is always a string value.  Use "0" for disable and "1" for enable.

scr.SetProperty("tbutton2", "Enabled", "0")  -- to disable the button so that a user cannot press it. 
scr.SetProperty("tbutton2", "Enabled", "1")  -- to enable the button so that a user can press it. 

So now you need to tie that all together in the screen load, possible the signal library, or the PLC script.  The button should be disabled initially in the screen load script.  Next, the idea is to see if all of the conditions are there for the button to be enabled, or not, and set the Enabled property appropriately in the PLC or signal lib. 

Steve

8

Mach4 General Discussion / Re: cant modify M function

« on: October 03, 2019, 10:50:28 PM »

It could be in any macro.  The end result is that you new modification is not getting rolled up into the mcLua.mcc. 

The first thing that happens when all .mcc files are removed is each .msc file is compiled into a .mcc file.  If a compile error happens, you will see .mcc files for the ones that compiled successfully and then the rest without .mcc files.  One of the macros without a .mcc file is the culprit. 

So you can use that to try and shorten your search.  The longer way is:

1. Delete all .mcc files from the macros directory. 
2. Open each .mcs file with the mcLuaEditor.exe program (Not ZeroBrane because ZB will not compile to mcc files) and attempt to compile it. 
3. If successful, go to the next .mcs file and repeat.  If not, then look at the compile error. 

You will eventually find the file with the error. 

Steve

9

Mach4 General Discussion / Re: Axis Enable API Call?

« on: October 03, 2019, 07:40:34 PM »

That is the call to enable an AXIS.  An axis is different than a motor.  An axis can drive one or many motors. 

Currently, there is no way to enable/disable a motor from script. 

Steve

10

Mach4 General Discussion / Re: cant modify M function

« on: October 03, 2019, 07:34:25 PM »

You have a syntax error in the macro file.  Thus it will not compile and merge into the mcLua.mcc file.