Messages

361

Mach4 General Discussion / Re: New to jogging/ non g-code moves

« on: February 02, 2020, 01:52:30 PM »

You can't jog a coordinated axis from an M code.  Period.  Because the machine is in automatic mode when running G code.  Jogging coordinated axes is only possible in manual mode.  Determining what the return code is would tell you this.  We know it is not MERROR_NOERROR.  But what is the return code exactly?  If you had looked at it, you would have seen that it is -18 (MERROR_NOT_NOW).  Meaning you cannot jog now. 

To RT's point, the return codes are numbers like -18.  As such, it is hard to know what they mean unless you have memorized them.  This is why mc.mcCntlGetErrorString() exists. 

Code: [Select]

function m91002()
local inst = mc.mcGetInstance()
rc = mc.mcJogIncStart(inst, 0, -.2)
if rc ~= mc.MERROR_NOERROR then
local rcText = mcCntlGetErrorString(inst, rc)
-- wx.wxMessageBox("failure") -- you have to be careful with message boxes in scripts!!!! 
-- Better to use mc.mcCntlSetLastError().
mc.mcCntlSetLastError(inst, "m91002(): " .. rcText)
end
end

Notice the comment about wxMessageBox().  You can paint yourself into a corner really quickly using wxMessageBox() in macro scripts.  It is best not to use them.  You should use mcCntlSetLastError() or mcCntlLog() (requires the log window to be up) instead. 

Steve

362

Mach4 General Discussion / Re: mach 4 machine coordinates not showing

« on: January 19, 2020, 06:52:36 PM »

It sounds like you need to install Galil's latest GDK.  Make sure GCAPS is running.

363

Mach4 General Discussion / Re: Mach4 + Plasma MACRO ALARM Help

« on: January 19, 2020, 06:51:31 PM »

Well... when you don't give a lot of information, people tend to stay silent.  What Mach build are you running and with what motion controller?  Did you build the machine?  What kind of motors and how are they hooked up?  What did you do between when it was working to now?  Etc...  Update something? 

Steve

364

Mach4 General Discussion / Re: Mechanical speed ranges in Mach4

« on: January 15, 2020, 07:31:21 PM »

Hi,
you've seen Smurph's recommendation about using lowercase in Gcode......is there any reason you ignore his advice?

Craig

I think there is a misunderstanding.  You don't have to call the m40.mcs macro script with lower case in G code.  But you do have to make the macro script filename lower case.  And the function name in the script should be lower case as well.

The first thing the interpreter does is lower case everything.  So if you had a line wit "M40" on it, when the interpreter processed that line it would do:

1. M40 -> m40  (lower case the M40 to m40)
2. Look for m40.mcs (notice the lower case filename).
3. Look for function m40() in the m40.mcs file (notice the lower case function name).

Steve

365

Mach4 General Discussion / Re: how use mcToolGetData with api

« on: January 13, 2020, 11:28:30 PM »

Yes.  11000 is the base number for the system variables where the tool information is stored.  We use a Funuc tool offset memory type C layout.  11000 + tool is the location in the system variables.  You could also use:

mcCntlGetPoundVar(inst, 11000 + tool, val);  // This really should be called mcCntlGetSystemVar()

This means that tool height information is also available to G code. 

Here is a handy dandy system variable memory layout chart for future reference:  http://www.machinetoolhelp.com/Applications/macro/system_variables.html

Steve

366

Mach4 Plugins / Re: Galil plugin compatibility

« on: January 13, 2020, 10:42:00 PM »

The machine was originally going to use the CNCBrain but that project stalled before the linear encoder part was completed.
My SureServo AC Servo system can use analogue inputs, so the Galil system ought to work. However, it's very expensive and frankly they didn't seem that keen to help. There didn't seem to be anyone with experience of the system so it was too risky to follow up on.
I'm using closed loop on the leadscrew using step/direction at present with backlash compensation, but it's nowhere near are good as a linear scale would be.

Galil support probably won't spend much time with you until you buy a controller.  But their pre-sales should be able to answer any questions you may have on what is needed to accomplish what you want.  I have NEVER gotten someone from Galil that wasn't able to answer a question or be able to put me in contact with someone who could.  And I have been working with them for nearly 30 years now.  If you need to talk to an applications engineer, Vincent Nagel is one of the app engineers that I use and he's on the ball, for sure.   

Is it expensive?  That is relative.  On a typical CNC machine, say like if my Matsuura MC500 were a new production machine, the Galil controller would be about 5% (or less!) of the total cost of the machine.  A DMC4153 ($1695.00) is a good controller for a VMC.  That allows for XYZA, and analog spindle control.  For an industrial motion controller, that's a steal!!!  Have you ever priced a Delta Tau?  Again, expensive is relative and the Galil might be more controller than your machine needs.  But if you are taking about dual feedback, and let's be honest, you are no longer playing in the hobby realm of motion controllers. 

Also, Galil has a plethora of information on their website like application notes and white papers.  Here is the whitepaper describing dual velocity loops:  http://www.galilmc.com/download/whitepapers/wp_advanced_control_techniques_for_real_world_drivetrains.pdf

Standard dual loop is included with the controller, I believe.  Check with Galil to be sure.  If you want the advanced dual loop stuff, then there will be an NRE (one time engineering fee) for special firmware. 

Steve

367

Mach4 General Discussion / Re: how use mcToolGetData with api

« on: January 13, 2020, 08:01:14 PM »

The second argument isn't a string.  It is an integer.  Also, you will get a response from the API in the return code.  Either that or it will crash from a bad API call.  Here is the proper description of the API call:

[DllImport("Mach4Core.dll", CallingConvention = CallingConvention.StdCall)]
   [return: MarshalAs(UnmanagedType.I4)]
   public static extern int mcToolGetData(
      [param: MarshalAs(UnmanagedType.I4)]  int mInst,
      [param: MarshalAs(UnmanagedType.I4)]  int Type,
      [param: MarshalAs(UnmanagedType.I4)]  int toolnum,
      [param: MarshalAs(UnmanagedType.R8), In(), Out()] ref double value);

double height = 0.0;
int toolnum = 1;
int debug = mcToolGetData(0, MTOOL_MILL_HEIGHT, toolNum, height);

MTOOL_MILL_HEIGHT is a constant that resolves to 11000.

All of this is in our SDK and this is FAR beyond the scope of this forum.  Unfortunately, you need to sign a nondisclosure agreement to gain access to the SDK.  Contact Todd Monto at our office to get that started. 

Steve

368

Mach4 General Discussion / Re: Mechanical speed ranges in Mach4

« on: January 13, 2020, 07:49:34 PM »

1) Why are you calling the macro m50?  M40-M46 are the typical M codes used for spindle speed ranges. 
2) When you create an M code macro script, use lower case names for both the file AND the function inside it. 

"m50.mcs" is correct, while "M50.mcs" is not correct for a file name.

function m50()
...
end

is correct and

function M50()
...
end

is NOT correct. 

The FIRST thing you should do is take the example someone gives you and try it like it is.  And there is no guarantee that script people throw up on the forum will work because a lot of the time the people trying to help are putting "the general idea" up to help you on your way.  The rest is an exercise for the user (you).    But anyway, try it like the example was and get things working.  THEN you can start renaming the macro script and function inside it.

When working with the script in the editor, it is always a good idea to try and compile it.  Because compiling it in the editor will show you is there are any syntax errors.  It could be as simple as a misspelled function call from a typo in the example. 

So in summary, if a script is "being ignored", it is most likely because of:

1. Not using lower case names for functions and file names. 
2. Not checking for syntax errors by compiling the macro script first. 

Steve

369

Mach4 General Discussion / Re: Cycle G83 in the Lathe version creates a collision

« on: January 13, 2020, 05:20:33 PM »

Build 4369 addresses the G83 issue. 

G84 is regular right hand tapping meant to be used with a floating tap holder.  G84.2 (RH) and G84.3 (LH) are the rigid tapping variants. 

G84 and G74 can be turned into rigid tapping cycles by issuing a M29 prior to the call to G84 or G74.  G80 is the antidote to M29, so after a G80, M29 will need to again be called before G84 or G74 to rigid tap.

G84/G74 should be supported by all motion controllers because there are no real time requirements.  You will need a floating tap holder.  Rigid tapping, on the other hand, does have to be supported by the motion controller.  Not all motion controllers support rigid tapping (and possibly lathe threading), so it is prudent to check with the manufacturer of the controller to make sure it is supported if you need that feature. 

Steve

370

Mach4 General Discussion / Re: Tool Change macro M56 and T0101 etc. problem

« on: January 13, 2020, 05:05:44 PM »

M6 is indeed the standard tool change M code.  It is machine dependent and therefore the machine tool builder (you) have to write one.    M56 is not something that is standard to my knowledge and I do not know why it would be needed.

The T code, selected the tool.  depending on the tool change settings and the type of tool changer on the machine, it can be used to preload the next tool or select the next tool.  For lathes, the common case is the T on the M6 line is the "tool to use".

M6 T0101

This could be written T0101 M6, but by convention, the syntax of M6 T0101 is used.  Basically, T0101 sets the tool to use (selects the next tool) and M6 makes it happen.  No action happens with T0101 by itself.

Now, if preloading tools is needed.  You can write a t.mcs macro and put it in the macro folder.  This will make T0101 actually perform an action, depending on what you put in the script. 
Here is a sample t.msc file:

Code: [Select]

function t(tool)
inst = mc.mcGetInstance();
local msg = "Tool Changer Retrieving tool #" ..  tostring(tool)
mc.mcCntlSetLastError(inst, msg);
-- make tool changer preload the tool
end

if (mc.mcInEditor() == 1) then
    t(1);
end

But tool preloading is only for tool changers that support it.  Like I said, most lathes don't handle tool changes this way. 

T0101  (preload the tool 1)
M6 T0202 (makes tool 1 active and preloads tool 2)
; gcode
; gcode
; gcode
; gcode
; gcode
M6 T0101 (makes tool 2 active and preloads tool 1)
; gcode
; gcode
; gcode
; gcode
; gcode
M6 (makes tool 1 active)

Steve