Hello Guest it is September 23, 2020, 09:07:32 AM

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - smurph

111
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

112
Mach4 General Discussion / Re: Mechanical speed ranges in Mach4
« on: January 13, 2020, 04:14:08 PM »
Typically, spindle speed ranges are in the M40-M46 range of M codes.  These M codes are just general as not all machines will have multiple speed spindles.  Some may have 2, 3, 4 or more.   The Machine Tool Builder (you) will have to implement them because of the differing methods of control and number of ranges implemented are too varied to have canned M codes for this purpose. 

Code: [Select]
function m40()
local inst = mc.mcGetInstance("Spindle range 0")
local rc
local currentRange
currentRange, rc = mc.mcSpindleGetCurrentRange(inst)
if (currentRange == 0) then
return -- nothing to do!
end
-- Do the machine dependent range change control.
--
-- End machine dependent range change control

-- Next, tell Mach what rage we are now in IF the above is successful. 
mc.mcSpindleSetRage(inst, 0)
end

if (mc.mcInEditor() == 1) then
    m40()
end

Rinse and repeat for all of your spindle speed ranges. 

Steve

113
Mach4 General Discussion / Re: mach 4 reverse motor direction
« on: January 07, 2020, 02:02:47 AM »
Yes, the new plugin is a different version.  It is newer. 

You will probably have to install the latest GDK from Galil.  It will install the GCAPS service.  You must be running a 64 bit version of windows to use the latest Galil drivers in the GDK.

You do not need to reinstall Mach.  We are just dealing with the plugin at the moment. 

Steve

114
Mach4 General Discussion / Re: mach 4 reverse motor direction
« on: January 06, 2020, 08:28:20 PM »
Well...  the dog ate my homework.  And so on and so forth.  :(  You will need to get the latest Galil plugin to make the motor reverse check box in the motor tuning tab to affect the motor direction. 

https://www.machsupport.com/ftp/Mach4/Plugins/Galil/mcGalil.zip

Steve

115
Mach4 General Discussion / Re: M0 (M00) Issue
« on: January 06, 2020, 08:22:09 PM »
Wasn't there something in the change log about loading g code with M0's...I think it was > v4300?

Damn straight there was! 

"Core: Prevent lock when loading a G code file with M0 in it." 

I wrote that.  I fixed the bug.  And I didn't remember it!!!  My brain is definitely fried. 

So a release from the FTP dev area will fix you up.  Get one later than 4310 just to be sure. 

Back to the lower case stuff.  It is perfectly fine to program your G code in upper case.  Just be aware that the G code interpreter reads a line and the first thing it does is lower case everything.  This is just so we don't have to test for 'G' and 'g', etc..  So internally, everything is lower case.  This means that when programing M code macro scripts the filenames needs to be lower case and the function names inside the file also need to be lower case.  That is what Craig was reffering to.

BTW, You only need to program M code macro scripts if you need something special. 

Steve

116
Mach4 General Discussion / Re: M0 (M00) Issue
« on: January 05, 2020, 10:04:29 PM »
Yeah, I can't duplicate this either using build 4360 here internally.  Perhaps you can post the G code that exhibited the issue? 

Steve

117
Make sure you are starting the C# application with the correct working directory (where Mach4core.dll resides). 

As far as non English strings is concerned, strings must be passed to the API as char * in C, but you can pass UTF8 strings in that parameter as well.  So don't convert from UTF8 to ASCII before passing the string but instead cast the UTF8 string to a char *.  I pretty much hate anything that is CLR from Microsoft so I have no idea how to do that in c#.

Steve

118
Mach4 General Discussion / Re: Motion Device Grounding
« on: January 03, 2020, 02:07:04 AM »
Floating isn't bad.  Also, there is ZERO risk in ground loops if you don't create them.  And when I say ground loop, I mean a loop between devices/components.  Say like a motion controller, the PC, and a VFD. 

Let's see if I can do some ASCII art for the win here...  :)
Good (D is for device):

D   D   D
\    |    /
     |
     G

Bad:
D - D - D         D - D - D
|                      \    |    /
|               or         |
G                          G

Steve

119
Mach4 General Discussion / Re: real position
« on: January 03, 2020, 01:58:11 AM »
I run analog servos with real position feedback with a Galil and Mach 4.

It all depends of where the control loop is closed.  Hint: It is NEVER closed on the PC with Mach.  In my case, the Galil is where the loop is closed.  Servo drives that take step/dir input close the loop in the drive itself.  If the loop is closed in the drive or the controller, it NEVER needs to be closed on the PC. 

The loop is closed on the PC for systems like Linux CNC because Linux CNC is running the real-time processes and the hardware motion boards are pretty much passive I/O devices.

So if you want industrial style feedback with motor position error monitoring with runaway alarms, get an industrial controller. 

We also have auxiliary position feedback where the DROs will display the feedback from an encoder but the planner runs the motors with step/dir.  But that is far beyond the hobby realm that is discussed on this forum.   We are taking Mach 4 Industrial level of support to get that going. 

Steve

120
Mach4 Plugins / Re: Galil plugin compatibility
« on: December 29, 2019, 07:09:54 PM »
If you are using step/dir to drive your AC servos, then what are the linear scales for?  The control loop should be closed in the servo drive and not need any scale feedback for a traditional PID control loop. 

If you are wanting backlash compensation with dual feedback, then you really can't do that with digital (step/dir) control on the servo drive, even on a Galil.  It would need to be analog control with the control loop closed on the controller.  The Galil can close the loop with dual position feedback using analog control, but it may require special firmware. 

Some servo drives allow for dual feedback but I do not remember any model or brands right off the bat.  Just that they do exist.  If your servo drives will not allow this, then we are talking about getting new servo drives instead of a new motion controller. 

Steve