Machsupport Forum
Mach Discussion => Mach4 General Discussion => Topic started by: RecceDG on February 04, 2024, 03:31:30 PM
-
I have a lathe and a mill powered off the same install of Mach 4 - different profiles.
I have been running 4498 and ESS 258 for forever, but the mill has probes (where the lathe does not) and later versions of Mach and the ESS plugin "fix probing", so it seemed time to upgrade.
Per the instructions, I made a copy of my old Mach4Hobby directory, renamed it, and then installed the new version over the old version.
So now I have 4 profiles: my old lathe and mill profiles, and 2 new lathe and mill profiles.
Attempting to start my old lathe profile spits out a script error, per attachment. This appears to have something to do with new canned cycles as a "Loading Modules" progress widget opens ,but never progresses.
Starting the new lathe profile successfully brings up the UI, but there's no ESS config nor is my custom signal script (which has a TON of stuff in it to support my control panel) active.
(Aside - where do the signal scripts live?)
What's the way to either fix my old profile, or bring my new profile's config info into the new profile?
I assume Mill will do something similar.
-
This appears to be lathe-specific: the old mill profile seems to work fine (although I have not yet extensively tested it).
But it throws no script errors and my control panel works, so that's a good sign.
-
Per the instructions, I made a copy of my old Mach4Hobby directory, renamed it, and then installed the new version over the old version.
Surprised there are no answers here, but that seems to be the way now.
What I do is rename the Mach4Hobby folder to something like Mach4Hobby_4498, then install the new version anew, NOT over the old version. Then I open both folders side by side, and copy over license, plugins, profiles, screensets, docs (if any are new/different), maybe modules. You can then rename folders and go back easily to a working machine, and even switch back and forth to try and figure stuff out!!
That said, since Andy is gone from Warp9, issues between new Mach4 versions and ESS plugins don't get documented nor fixed like they used to, at least where I can find them, so it's a lot more daunting to "upgrade". Things don't work and it's sort of up to you to figure it out. Andy used to keep us abreast of "this Mach4 version works best with this ESS plugin", but now I can't figure that out.
Oh, and signal scripts live in the screenstart script.
Good luck,
Tom
-
I have had this issuewhen updating to newer version of Mach4 .In my case it had to do with my custom Lathe screen .I copied the turn cycles from a new version on Mach4 and importred them into my old screen and all was good .
-
OK, I've got some free time on my hands and I've started to delve into this problem.
I've learned a few key facts so far:
1. Mach4 stores its machine configuration in a file called machine.ini in the profile directory that matches the profile in use.
2. This is a standard Windows .ini file, so it can be edited by text tools (thank Lob that the Spirit of UNIX sometimes made it into Windows!)
3. The ESS stores all its config info in the machine.ini file in a block titled [ESS]
4. Using a file comparison tool (BeyondCompare) I am now working my way through the .ini file and moving obvious config items over from the old profile to the new profile
5. The source of the LUA error is undoubtedly because the new profile uses a different screenset, and the screenset files either contain or provide a reference to the LUA scripts that run on startup.
I should be able to get a running machine again by copying over (using BeyondCompare) all my config values (where the .ini field is the same in both) from old to new, and leaving the new screenset intact. Then I have to edit the screenset file to move over all my custom LUA code.
Alternatively, I could just change the screenset in the old machine.ini file to the new one, and Mach should populate all the new ini file values with defaults on startup?
Maybe that is the easier answer?
Is there a Mach developer around who can discuss how Mach handles .ini files?
-
OK, some weird-ass shiznit is going on.
I copied my old machine.ini to the new profile, then changed the screenset (by editing the .ini file) to point at wxLathe.set.
That worked - it started up without error, axis responded to movement, etc.
Oddly, the jogging tab is unresponsive - it won't let me click on any of the buttons in that tab. But keyboard jogging works, although only in incremental mode (?)
Next was to add the LUA that enables my control panel. So I edited the screen set, immediately saved it as something else, then copied and pasted my functions to the bottom of the screen script. Saved that, restarted the machine, and... weirdness.
Jogging using the MPG works, and the enable/speed selector switch works, but the axis select switch was backwards, and would intermittently fail. As in, Mach would detect the switch state change 100% of the time, but sometimes the code would fall through.
Let's look at this in detail:
Here is the jog axis change code:
----------------------------
-- We use MPG 7
local MachMpgNumberForPendant = 7
local PendantStepSize = 0.001
local PendantDistanceX1 = PendantStepSize * 1 -- Multiply by one (0.001)
local PendantDistanceX10 = PendantStepSize * 10 -- Multiply by ten (0.01)
local PendantDistanceX100 = PendantStepSize * 100 -- Multiply by one hundred (0.1)
-- Constants for readability
local UnmapMPG = -1 -- Use this one for when Axis selector switch is set to OFF
local AxisNumber_X = 0 -- Linear axis X
local AxisNumber_Z = 2 -- Linear axis Z
---------------------------------------------------------------
-- The Pendant's Axis switch changed.
-- Need to handle this for when the axis switch is flipped while jogging is active
---------------------------------------------------------------
function PendantAxisChange()
-- handles
local hAxis_X
local hAxis_Z
local SelectAxis_X
local SelectAxis_Z
-- Before we do anything, we need to check if the jog handle is assigned to axis -1
-- If it is, jog is DISABLED, so we do nothing (the act of enabling jog will read the axis switch)
-- Otherwise we enable jog, which is BAD
local AxisState
AxisState, rc = mc.mcMpgGetAxis(inst, MachMpgNumberForPendant)
if (AxisState ~= UnmapMPG) then
hAxis_X, rc = mc.mcSignalGetHandle(inst, mc.ISIG_INPUT5)
SelectAxis_X, rc = mc.mcSignalGetState(hAxis_X)
hAxis_Z, rc = mc.mcSignalGetHandle(inst, mc.ISIG_INPUT4)
SelectAxis_Z, rc = mc.mcSignalGetState(hAxis_Z)
-- Now actual axis Selection Switch processing code
if (SelectAxis_X == 1) then
mc.mcMpgSetAxis(inst, MachMpgNumberForPendant, AxisNumber_X) -- Map the MPG to control the X Axis
mc.mcCntlSetLastError(inst, "Pendant Axis X Selected") -- Show a message in the Screen Set
elseif (SelectAxis_Z== 1) then
mc.mcMpgSetAxis(inst, MachMpgNumberForPendant, AxisNumber_Z) -- Map the MPG to control the Z Axis
mc.mcCntlSetLastError(inst, "Pendant Axis Z Selected") -- Show a message in the Screen Set
else
-- This is a problem, because the axis select switch is one or the other
-- We have no high pin - so shut off jogging
mc.mcMpgSetAxis(inst, MachMpgNumberForPendant, UnmapMPG ) -- Unmap the MPG, so it won't control any axes
mc.mcCntlSetLastError(inst, "ABEND - no valid axis selected on control panel!") -- Show a message in the Screen Set
end
else
mc.mcCntlSetLastError(inst, "Changed axis select while jog disabled - IGNORED")
end
end
It's very straightforward. The switch on the control panel that enables jog maps the MPG to the axis when jog is active, and unmaps the MPG when jog is off. The test:
if (AxisState ~= UnmapMPG) then
checks to see if the axis is not unmapped (-1), and if it is unmapped, it falls through to
else
mc.mcCntlSetLastError(inst, "Changed axis select while jog disabled - IGNORED")
end
because an axis change request when jogging is inactive can be safely ignored, and we check the state of the jog axis select switch when we enable jogging.
But here's the weirdness:
I enable jogging.
I switch the axis switch - and it works.
I switch it back - and it works.
I switch it again - and it fails.
It isn't consistent - sometimes it fails on the first switch, sometimes the fifth. But even though jogging is still enabled and the axis is mapped, that test is failing.
Even weirder, I have a button on the control panel for manual spindle on/off (it's a lathe, I use it for tailstock drilling and polishing).
Buttons generate two signals, a PRESS and a RELEASE.
Here is the code:
---------------------------------------------------------------
-- Control Panel Manual Spindle
---------------------------------------------------------------
function InputManualSpindle()
-- Momentary pushbutton, so we get TWO signals with each button press:
-- an "ON" and an "OFF"
-- So check state and ignore the "OFF"
local hSpindleButton
local SpindleButtonState
hSpindleButton, rc = mc.mcSignalGetHandle(inst, mc.ISIG_INPUT8) -- signal 3
SpindleButtonState, rc = mc.mcSignalGetState(hSpindleButton)
if (SpindleButtonState == 1) then
mc.mcCntlSetLastError(inst, "Control Panel Manual Spindle PRESS")
local hsig = mc.mcSignalGetHandle(inst, mc.OSIG_SPINDLEFWD)
local spinstate = mc.mcSignalGetState(hsig)
if (spindstate == 0) then -- If spindle is off, turn it on
mc.mcSignalSetState(hsig, 1)
mc.mcCntlSetLastError(inst, "Control Panel Manual Spindle ON")
else -- Otherwise, turn it off
mc.mcSignalSetState(hsig, 0)
mc.mcCntlSetLastError(inst, "Control Panel Manual Spindle OFF")
end
else
mc.mcCntlSetLastError(inst, "Control Panel Manual Spindle RELEASE")
end
end
That code now only triggers the RELEASE message, even though the Mach4 diagnostics show a distinct PRESS and RELEASE signal (and if I hold the button down, it never generates the release signal)
So the signal script is correctly catching the button press, but it is failing
hSpindleButton, rc = mc.mcSignalGetHandle(inst, mc.ISIG_INPUT8) -- signal 3
SpindleButtonState, rc = mc.mcSignalGetState(hSpindleButton)
if (SpindleButtonState == 1) then
in here.
Whiskey Tango Foxtrot?
-
OK, I have found evidence that what I thought was my reference code for the scripts may not have been the most recent version, in that some signal numbers were wrong, and I have caught a typo in a variable name.
This only underscores my conviction that having the screen load LUA code baked into the screen set where they cannot be accessed separately is a bad design.
It appears that I may have to re-debug my scripts.
-
OK there really is weirdness. not just typos.
This code is now "fixed" (but it isn't):
function InputManualSpindle()
-- Momentary pushbutton, so we get TWO signals with each button press:
-- an "ON" and an "OFF"
-- So check state and ignore the "OFF"
local hSpindleButton
local SpindleButtonState
hSpindleButton, rc = mc.mcSignalGetHandle(inst, mc.ISIG_INPUT3) -- signal 3
SpindleButtonState, rc = mc.mcSignalGetState(hSpindleButton)
if (SpindleButtonState == 1) then
mc.mcCntlSetLastError(inst, "Control Panel Manual Spindle PRESS")
local hsig = mc.mcSignalGetHandle(inst, mc.OSIG_SPINDLEFWD)
local spindstate = mc.mcSignalGetState(hsig)
if (spindstate == 0) then -- If spindle is off, turn it on
mc.mcSignalSetState(hsig, 1)
mc.mcCntlSetLastError(inst, "Control Panel Manual Spindle ON")
else -- Otherwise, turn it off
mc.mcSignalSetState(hsig, 0)
mc.mcCntlSetLastError(inst, "Control Panel Manual Spindle OFF")
end
else
mc.mcCntlSetLastError(inst, "Control Panel Manual Spindle RELEASE")
end
end
In that now it catches the button press and release, it is properly grabbing the current state of mc.OSIG_SPINDLEFWD, and it is setting it to on or off depending on what the initial state was (on if off, off if on).
On the UI, the green "light" that shows if it is on or off is changing appropriately.
What is NOT happening is the spindle relay firing and the spindle starting or stopping.
I'm sure that used to work....
And when I look at the button in the screen editor, it has the action on release as "event{...}" which is not helpful.
-
LOL
This code is copied directly from the LUA scripting manual (https://www.machsupport.com/wp-content/uploads/2014/05/Mach4%20Scripting%20Manual.pdf),
pages 18-19
local inst = mc.mcGetInstance()
local hsig = mc.mcSignalGetHandle(inst, mc.OSIG_SPINDLEFWD)
local spinstate = mc.mcSignalGetState(hsig)
if (spindstate == 0) then
mc.mcSignalSetState(hsig, 1)
else
mc.mcSignalSetState(hsig, 0)
end
It has the exact same typo ("spinstate" vs "spindstate") as I had - so I guess I know where I found the code!
...and it no longer works in V5310...
-
I got some assistance over at Warp 9 and have some fixes:
Manual Spindle Button
function InputManualSpindle()
-- Momentary pushbutton, so we get TWO signals with each button press:
-- an "ON" and an "OFF"
-- So check state and ignore the "OFF"
local hSpindleButton
local SpindleButtonState
hSpindleButton, rc = mc.mcSignalGetHandle(inst, mc.ISIG_INPUT3) -- signal 3
SpindleButtonState, rc = mc.mcSignalGetState(hSpindleButton)
if (SpindleButtonState == 1) then
mc.mcCntlSetLastError(inst, "Control Panel Manual Spindle PRESS")
local hsig = mc.mcSignalGetHandle(inst, mc.OSIG_SPINDLEON) -- This turns on the spindle
local hsig2 = mc.mcSignalGetHandle(inst, mc.OSIG_SPINDLEFWD) -- This turns on the UI button on screen
local spindstate, rc = mc.mcSignalGetState(hsig)
if (spindstate == 0) then -- If spindle is off, turn it on
mc.mcSignalSetState(hsig, 1)
mc.mcSignalSetState(hsig2, 1)
mc.mcCntlSetLastError(inst, "Control Panel Manual Spindle ON")
else -- Otherwise, turn it off
mc.mcSignalSetState(hsig, 0)
mc.mcSignalSetState(hsig2, 0)
mc.mcCntlSetLastError(inst, "Control Panel Manual Spindle OFF")
end
else
mc.mcCntlSetLastError(inst, "Control Panel Manual Spindle RELEASE")
end
end
Jog Axis Select Switch:
function PendantAxisChange()
-- handles
local hAxis_X
local hAxis_Z
local SelectAxis_X
local SelectAxis_Z
local PanelMachMPGNumber = 7 -- setting this here because of suspicions that the "constant" we were using is getting garbage collected by Lua 5.3
-- March 8 2024
-- All of a sudden, following an update, MACH is picking up on the split second when it appears that both lines are HIGH
-- Adding noise reduction to the ESS config had not effect, so I suspect that the switch really does have both lines HIGH
-- as the switch moves across the contacts.
-- LUA does nt appear to have a native DELAY function and I'm not sure about OS dependancies so a simple delay isn't (yet) an option
-- so we need another solution
-- The status of the JOG ON light can be used as a flag. Is this yucky, or brilliant?
local hJogLight
hJogLight, rc = mc.mcSignalGetHandle(inst, mc.OSIG_OUTPUT5)
local JogState, rc = mc.mcSignalGetState(hJogLight)
local AxisState
AxisState, rc = mc.mcMpgGetAxis(inst, PanelMachMPGNumber)
hAxis_X, rc = mc.mcSignalGetHandle(inst, mc.ISIG_INPUT5)
SelectAxis_X, rc = mc.mcSignalGetState(hAxis_X)
hAxis_Z, rc = mc.mcSignalGetHandle(inst, mc.ISIG_INPUT4)
SelectAxis_Z, rc = mc.mcSignalGetState(hAxis_Z)
-- mc.mcCntlSetLastError(inst, "Entered PendantAxisChange()") -- Hoe many times is this thing getting called per switch? The answer is TWO.
if (AxisState == AxisNumber_X) then
-- We started at X, so we must want Z
if (JogState == 1) then -- Make sure jog is active
if (SelectAxis_Z== 1) then
mc.mcMpgSetAxis(inst, PanelMachMPGNumber, AxisNumber_Z) -- Map the MPG to control the Z Axis
mc.mcCntlSetLastError(inst, "Panel Jog Axis Z Selected") -- Show a message in the Screen Set
else
-- Should this fail like this?
-- This traps the second call
-- mc.mcCntlSetLastError(inst, "I think we want Z but the Z line isn't HIGH - ABEND")
end
else
mc.mcCntlSetLastError(inst, "Changed axis select to Z while jog disabled - IGNORED")
end
elseif (AxisState == AxisNumber_Z) then
-- We started at Z, so we must want X
if (JogState == 1) then -- Make sure jog is active
if (SelectAxis_X == 1) then
mc.mcMpgSetAxis(inst, PanelMachMPGNumber, AxisNumber_X) -- Map the MPG to control the X Axis
mc.mcCntlSetLastError(inst, "Panel Jog Axis X Selected") -- Show a message in the Screen Set
else
-- Should this fail like this?
-- mc.mcCntlSetLastError(inst, "I think we want X but the X line isn't HIGH - ABEND")
-- This traps the second call
end
else
-- This never seems to execute
mc.mcCntlSetLastError(inst, "Changed axis select to X while jog disabled - IGNORED")
end
else
-- We somehow have a wrong axis?
-- Actually this triggers when we change the axis switch with jogging disabled
mc.mcCntlSetLastError(inst, "Jog Axis Switch does not recognize previously enabled axis - ABEND")
end
-- Disabled while we try the new regime because of debounce
--if (AxisState ~= -1) then -- Temporarily (?) hardcoded to see if our constant was getting garbage collected in Lua 5.3
--
-- hAxis_X, rc = mc.mcSignalGetHandle(inst, mc.ISIG_INPUT5)
-- SelectAxis_X, rc = mc.mcSignalGetState(hAxis_X)
--
-- hAxis_Z, rc = mc.mcSignalGetHandle(inst, mc.ISIG_INPUT4)
-- SelectAxis_Z, rc = mc.mcSignalGetState(hAxis_Z)
--
-- -- Now actual axis Selection Switch processing code
-- if ((SelectAxis_X == 1) and (SelectAxis_Z== 1)) then
-- This is a problem - the switch is shorted or something
-- mc.mcMpgSetAxis(inst, PanelMachMPGNumber, -1 ) -- Unmap the MPG, so it won't control any axes
-- mc.mcCntlSetLastError(inst, "ABEND - Both control panel axis select lines are HIGH") -- Show a message in the Screen Set
--
-- elseif (SelectAxis_X == 1) then
-- mc.mcMpgSetAxis(inst, PanelMachMPGNumber, AxisNumber_X) -- Map the MPG to control the X Axis
-- mc.mcCntlSetLastError(inst, "Pendant Axis X Selected") -- Show a message in the Screen Set
--
-- elseif (SelectAxis_Z== 1) then
-- mc.mcMpgSetAxis(inst, PanelMachMPGNumber, AxisNumber_Z) -- Map the MPG to control the Z Axis
-- mc.mcCntlSetLastError(inst, "Pendant Axis Z Selected") -- Show a message in the Screen Set
--
-- else
-- -- This is a problem, because the axis select switch is one or the other
-- -- We have no high pin - so shut off jogging
-- mc.mcMpgSetAxis(inst, PanelMachMPGNumber, -1 ) -- Unmap the MPG, so it won't control any axes
-- mc.mcCntlSetLastError(inst, "ABEND -Both control panel axis select lines are LOW") -- Show a message in the Screen Set
-- end
-- else
-- mc.mcCntlSetLastError(inst, "Changed axis select while jog disabled - IGNORED")
-- end
end
-
Now I have these other issues:
- The Cycle Start panel button doesn't work
- The Feed Hold panel button doesn't work
- Tool changes don't work (might be a case of a missing macro file)
- The cycle start UI button is behaving oddly
- Entering in tool offsets from the UI does not change the DRO
- UI jog buttons do not work
- There's an indicated 0.010 wear offset that I cannot clear
- Tool table wear does nothing
- On one homing sequence, the UI put up "Homing Complete" after it homed to X, then homed Z but ignored the home switch, necessitating an EStop. After restarting and jogging off the switch, a second attempt worked fine
...and that's just the issues I found so far.
-
Can you post your profile and screenset including required modules?
I thought tool wear was only enabled on Mach4 Industrial, do you have an industrial licence? I could be wrong though...
Homing is all related to the ESS and the plugin.. does Warp9 have a working plugin for 5310? Their documentation site is still saying they had problems with build 5000 onwards
Thanks
-
> Can you post your profile and screenset including required modules?
Can you describe what files you want for "my profile"?
The screenset is the new wxLathe. The only thing I have changed is I deleted the screen button/light for "spindle reverse" (as my spindle doesn't run backwards) and I have added my Lua code to the screen run script.
> I thought tool wear was only enabled on Mach4 Industrial, do you have an industrial licence? I could be wrong though...
I have a hobby licence. Tool wear may not be implemented, but there is a screen widget for it, and it has a value in it (that I cannot change). Presumably it is being applied, or it would be "0".
> Homing is all related to the ESS and the plugin.. does Warp9 have a working plugin for 5310? Their documentation site is still saying they had problems with build 5000 onwards
They do.
From the Warp 9 Forum:
Here is a link to a plugin that has the proper code to work with the v5000 versions of Mach4. Technically it goes back a little further than that, but some other changes to Mach4 made v5000+ behave badly and that is when it was noticed. I believe it was a timing issue, and v5000+ had improved performance which created the problem. It has to do with how the device reports to Mach that it has stopped moving. Every motion control plugin had issues with this except for the ones that Steve Murphree of Artsoft wrote (of course he knew how it was supposed to work!).
Because I know there are issues with the Mach versions leading up to v5305, I set a cutoff date in the plugin. You can ignore the warning if you want to use an older version such as v5036 (I never used that version). I would use v5305 or later.
https://warp9td.com/files/Plugins/ESS/Mach4/ESS_Mach4_v306.zip
Here is where you can download the latest Mach4 installers:
https://www.machsupport.com/ftp/Mach4/DevlopmentVersions/
Please let me know of any bug reports. I am unsure about Height Control. I will definitely be looking at that closely this week.
As far as I can tell (I have not tested it extensively) this combination of ESS 306 and Mach 4 5310 works fine with mill. But the upgrade from 4498 introduced a new lathe screen set with extensive changes and that is the source of the trouble.
-
If you go to Help>Support>Package Current Profile and upload the file it creates. This will include the screenset, macros, and the machine.ini file
I had a quick look at the tool wear in the default lathe screen. The DRO is set to read only, hence why you can't edit it, also the code in the On Modify script needs updating. There's a bunch of other changes required to the X and Z offset DRO's too. Looks like DRO names were updated but the code is still referencing the old names :(
-
> If you go to Help>Support>Package Current Profile and upload the file it creates. This will include the screenset, macros, and the machine.ini file
OK, will do. I'll post it later today, thanks.
> Looks like DRO names were updated but the code is still referencing the old names
I'll bet something similar is going on with the screen jog buttons too.
-
Here you go.
Thanks again.
-
Here is an updated screen, I've renamed it so it won't overwrite your current screen, you can just load it through the View menu once it's copied to the Screens folder.
This should fix the wear DRO, X and Z tool offset buttons, UI jog buttons, your control panel Cycle Start and Feedhold buttons. I've tried to keep your code the same as much as possible so it's familiar to you but some of it could be optimised. I've tested with the Sim and it looks ok, but always test cautiously on the machine!
I've not changed anything to do with the your pendant stuff. I think it could do with recoding to utilise the signal library to prevent it unnecessarily running functions every time a switch state is changed.
A question regarding your pendant, does the 'Off' setting have it's own signal or are you saying it's considered off when there is no axis selected or speed selected?
Thanks
-
Wow, that was fast. And on a Saturday too!
> but some of it could be optimized.
Oh, no doubt.
My prime concern is that the code never fails is a way that does something undefined or dangerous. Uncommanded movements, movements faster than expected or in the wrong direction, etc.
And you are looking at the remnants of my first generation Lua coding. The lathe control panel was the first Lua I ever wrote, and my understanding of the language and how Mach works has gotten slightly better since then. I have some code for tool-length-probe on toolchange for mill in another thread - a project that got derailed by the lathe shenanigans.
> I think it could do with recoding to utilize the signal library to prevent it unnecessarily running functions every time a switch state is changed.
I'm listening. Where is this documented?
> A question regarding your pendant, does the 'Off' setting have it's own signal or are you saying it's considered off when there is no axis selected or speed selected?
For jog?
The jog section of the panel has 3 controls:
- an MPG handle
- an axis select switch, two positions, SPDT, with lines for each axis (X, Z)
- a rotary select switch, 4 positions, 3 lines, OFF (no lines connected) 0.001 (line 1 connected) 0.010 (line 2 connected) 0.100 (line 3 connected)
The reason why there is no "off line" is because I wanted JOG ENABLE to fail OFF if the panel was unplugged or a line broke
The "so what" there is that the function that handles turning on jogging must handle not just the line going ON (to turn jog active) but also OFF (to turn jog inactive). So the fact that Mach calls the function on state change is a feature here.
Axis select, in retrospect, could have been a single line - Z if OFF, X if ON, but at the time I was going for positive control - the axis was only selected if its select line was HIGH, so a broken or unplugged cable disabled jogging.
You should see the mill control - I've overloaded the MPG handle. There's not just an axis select switch, there's a handle function select switch: JOG - SPINDLE OVERRIDE - FEED OVERRIDE. In jog mode the handle jogs like the lathe. In SPINDLE mode the handle changes the spindle speed up or down, and in FEED mode the handle changes the feed speed up or down. And there are separate lights to indicate if the handle is active in JOG mode, or active in SPEED mode...
Anyway, thanks for the fixes - I'll try them tomorrow.
-
Some quick tests:
1. Wear offset is editable. Check.
2. Tool change works and applies offset. Check.
3. Tool offset is applied and changes DRO. Check.
4. Cycle Start panel button works. Check.
5. Jog buttons on UI work. Not at first. Enabling machine"ungreyed" the panel, but the buttons would not highlight on mouseover. Then they did, and I don't know what triggered that. Incremental step change button works. Speed slider works. Axes work. Button jog mode button does NOT work (always continuous)
Good progress, thanks!
-
This should fix the jog mode selection
-
Verified - thanks!
-
Oho!
The "disable keyboard jogging" button does NOT work!
A bit of a surprise when editing an MCI program!