Messages

2641

General Mach Discussion / Re: Mirror probing

« on: April 14, 2019, 06:38:09 PM »

Hi Don,

If I probe the centerline, then probe again .020” off center and so on I can use that as my step over and convert the z+ z-?  What am I missing?

That is the essential idea....you are not missing anything.
Most CAD/CAM programs have a function that converts a set of points, or point cloud, to a Gcode toolpath. It is still
the same idea but is automated to produce the Gcode. You could for instance probe at 0.02 stepovers but to get the
accuracy you might decide to mill at 0.005 stepovers, the CAD/CAM program allows that.

Carig

2642

General Mach Discussion / Re: Mill or Turn?

« on: April 14, 2019, 06:33:17 PM »

Hi,
at the current time Mach4 does not do Mill-Turn per se. It, like Mach3, has a multiaxis Lathe profile to allow milling
ops on a lathe and also A, B, C axes and Out-of-Band axes (up to 6) for turning ops on a mill. It accommodates CSS.

This is from Smurph:

You are welcome for the new stuff.  It is my pleasure.  Stuff I have in mind for the future is 3rd order planner, tie the multiple instances together for true multi-path capabilities (Screw machines, Mill/Turns, etc..), and kinematics.

So the intention is that Mach4 have multiple instances for genuine Mill-Turns. When is the next question.

Craig

2643

General Mach Discussion / Re: Mirror probing

« on: April 14, 2019, 05:53:44 PM »

Hi,
yes that would work but you can omit the casting step.

If you probe the barrel with a matching probe, save the data, then the ball mill can follow the path from the previously
stored data.

Craig

2644

Mach4 General Discussion / Re: Is it possible to call one GCODE file from another?

« on: April 14, 2019, 05:41:19 PM »

Hi,
not directly.

Gcode does not have a required instruction to call another file.
The M98 call however calls a subroutine. The subroutine code must be included in the currently loaded file.
That would mean that each job that you wanted to have this particular op included would have to have a copy
of the code to do the op. That would mean also that if you wanted to change the parameters of the op you would have
to change it in each and every Gcode job which used it. Not ideal.

May I suggest that instead of maing a separate Gcode file BoltHole.NC that you instead have the code included in a macro,
m150 say. Note that the macro code is stored in the macros folder of your profile and therefore any of your Gcode jobs
running under your profile can call m150 at will. Additionally if you wanted to change the parameters of the countersink
you need only change if in one file, namely m150.mcs

You could have multiple macros for different ops.
m150     countersink 1/4 cap head
m151     countersink 5/16 cap head
m152     countersink 3/8 cap head
etc.

Then in your main Gcode job CutPart.NC and you wanted to countersink for a quarter cap head at the current
location you would put a line m150.

Presumably the machine would have to do an m6 to get another tool or drill. Thus it would on entry need to save
the current location, THEN do the m6, THEN return to the saved location, THEN drill the countersink, THEN do another
m6 to restore the original tool, THEN return to the saved location, THEN m150 can return to CutPart.NC .

Craig

2645

Mach4 General Discussion / Re: Mach4 cnc program min/max values

« on: April 14, 2019, 05:14:09 PM »

Hi,
easy, I added a toggle button to the DRO block. With ToolLegthComp ON (green and blinking) tool length
is compensated, ie subtracted from zOffset. Note the button is connected to Output#63

Then in the PLC script tests the state of Output#63 and compensate or not as the case may be.

Code: [Select]

--*****************************************************************************
local zOffset=mc.mcCntlGetOffset(inst,mc.Z_AXIS,mc.MC_OFFSET_FIXTURE)
local toolCompHandle=mc.mcSignalGetHandle(inst,mc.OSIG_OUTPUT63)
local toolComp=mc.mcSignalGetState(toolCompHandle)
local toolNum=mc.mcToolGetCurrent(inst)
local toolLength=mc.mcToolGetData(inst,mc.MTOOL_MILL_HEIGHT,toolNum)
if (toolComp==0) then
zOffset=zOffset-toolLength
end
local workZMaxHandle=mc.mcRegGetHandle(inst,'core/inst/PathZmax')
local workZMax=mc.mcRegGetValue(workZMaxHandle)-zOffset
local workZMaxHandle=mc.mcRegGetHandle(inst,'iRegs0/workZMax')
mc.mcRegSetValue(workZMaxHandle,workZMax)
local workZMinHandle=mc.mcRegGetHandle(inst,'core/inst/PathZmin')
local workZMin=mc.mcRegGetValue(workZMinHandle)-zOffset
local workZMinHandle=mc.mcRegGetHandle(inst,'iRegs0/workZMin')
mc.mcRegSetValue(workZMinHandle,workZMin)
--**********************************************************************************
Note that I don't use tool lengths so it may be that the compensation is applied wrongly, ie negatively whereas
your expectation is for positive compensation. Please test it before use.

Craig

2646

Mach4 General Discussion / Re: Mach4 cnc program min/max values

« on: April 13, 2019, 10:32:41 PM »

Hi,
a little experimentation shows that variable MaxMin is not affected by g92, Head offset, Work Offset or Tool Offset.
If you wish those to be included then the calculation will need those additional terms.

Craig

2647

Mach4 General Discussion / Re: Mach4 cnc program min/max values

« on: April 13, 2019, 10:04:26 PM »

Hi,
the code I posted calculates the work coordinate maximum as the machine coordinate maximum minus the current
axis offset. The line of code that does the calculation is:

local MaxMin=mc.mcRegGetValue(regHandle)-zOffset

And the variable zOffset is defined:

zOffset=mc.mcCntlGetOffset(inst,mc.Z_AXIS,mc.MC_OFFSET_FIXTURE)

But note that the zOffset variable does not include tool offset. I'm less sure about g92 and head offsets.
I guess the way is to experiment by substituting values into the Z axis machine diagnostics page and see what happens
to the output. My inclination is for the ZMax and ZMin be in work coordinates but WITHOUT any tool length offset.
That may or may not make sense to you. If it does not then by all means substract the current tool length from
MaxMin variable as you desire.

This is Machs great strength, you can modify it to suit your expectation.

Craig

2648

Mach4 General Discussion / Re: Weird spindle problem

« on: April 13, 2019, 08:05:40 PM »

Hi,
I agree, I do not suspect physical corruption of the drive but some competing process like the download
maybe, or some unintended consequence of something that you did.

I've had the same problem when I've managed to screw up, and had to use WindowsTaskManager to shut
Mach components down. Whether the current settings are flushed to the .ini file is not easy to determine or
predict. In some cases the normal flush seems to occur but in other circumstances it does not.

Craig

2649

Mach4 General Discussion / Re: Mach4 cnc program min/max values

« on: April 13, 2019, 07:57:45 PM »

Hi,
because the PLC script runs every 50ms (default) the code needs to be pretty quick and slick otherwise
it will block the rest of Mach.

For this reason the code I posted is pretty lean but at the same time detailed enough to make it readable.

Note these lines:

local workZMaxHandle=mc.mcRegGetHandle(inst,'core/inst/PathZmax')
local workZMax=mc.mcRegGetValue(workZMaxHandle)-zOffset
local workZMaxHandle=mc.mcRegGetHandle(inst,'iRegs0/workZMax')

Note that I have redefined the variable workZMaxHandle, first I used it to address the core register PathZmax
and then redefined it to address the instance register iRegs0/workZMax. I did this so the one variable is reused.
Note that I did it a second time with workZMinHandle. On the one hand it reduces the number of variables
that Lua has to keep a track of but on the other hand can be confusing for someone else to read.

If I were writing this code for myself I would streamline it even further, albeit at the expense of readability.

Code: [Select]

local zOffset=mc.mcCntlGetOffset(inst,mc.Z_AXIS,mc.MC_OFFSET_FIXTURE)
local regHandle=mc.mcRegGetHandle(inst,'core/inst/PathZmax')
local MaxMin=mc.mcRegGetValue(regHandle)-zOffset
regHandle=mc.mcRegGetHandle(inst,'iRegs0/workZMax')
mc.mcRegSetValue(regHandle,MaxMin)
regHandle=mc.mcRegGetHandle(inst,'core/inst/PathZmin')
MaxMin=mc.mcRegGetValue(regHandle)-zOffset
regHandle=mc.mcRegGetHandle(inst,'iRegs0/workZMin')
mc.mcRegSetValue(regHandle,MaxMin)
Here I reduced the number of variables to three, zOffset, regHandle, and MaxMin, with the last two being recycled at need.
Not as readable but will run a little faster.

Craig

2650

Mach4 General Discussion / Re: Weird spindle problem

« on: April 13, 2019, 07:34:30 PM »

Hi,
a lot of questions there, and next to no bloody answers here!

My understanding is that if and/or when you make any alterations to your profile the changes are recorded
in the .ini file. Note that does not include scripts. Thus if in a Mach session you wrote a small script in the PLC script
for instance, then the script would be saved in the PLC script, which is in turn part of the GUI chunk, which is in turn
part of your screen set, which in turn is nominated in your profile.

When you close Mach changes that you have made during the session get flushed to the .ini file.

I would guess that in your last session you did something which was flushed to the file and affected Machs behavior
the next time you started up.

I'm not 100% but I believe there is a mechanism to lock the .ini file to prevent accidental corruption. I'm unsure how
specific it is.

Craig