Hello Guest it is September 21, 2019, 04:57:23 PM

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

Galil / Re: DMC-2143 time out
« on: November 04, 2015, 04:12:40 PM »
For some reason, I quit getting forum notifications.  Sorry about that.  :(

Most people that run the Galil are using it so they can drive servos.  So you are in a VERY small group.  :(


Galil / Re: Galil controller compatability (what works with the plugin)
« on: November 04, 2015, 04:05:36 PM »
I'm setting up a Bridgeport mill with a Galil 4080 connected to 30A20ac Advance Motion Control. I will use -10/+10 vdc control between the 4080 and the 30a20ac. The 30a20ac has inputs to inhibit direction that can be used to prevent going in the wrong direction when backing off a limit. Should I hook them up, or will the software take care of this? The drive motor has a CFW-08 Weg drive, I can control it with -10/+10 vdc also, or order a serial rs485 card. What option would work best with my setup? I'm leaning toward the -10/+10vdc to the 4080 because it has extra axis and I will be putting an encoder on the spindle at some point. (After Mach 4 gets rigid tapping) How difficult will it be to use the i/o on the 4080? I have the option to use i/o on pokeys 56E that my PoNET kbd48CNC keyboard is connected to, if the Galil plug-in doesn't support extended i/o. Could I get the Galil plug-in to try out, who would I speak with?

If you use the Galil limit inputs, the Galil will take care of it.  Otherwise, I would hook the drive signals up.  I use both on my machine.  Never hurts to be safe.

I would use +-10v.

IO, both general and extended, are easily used through the plugin.

The plugin for Mach 3 is available on the plugins download section of the website.  The M4 plugin has not been released yet.  :(


Galil / Re: Galil controller compatability (what works with the plugin)
« on: November 04, 2015, 04:01:41 PM »
Hi I am a little confused. I have a 2240 with Ethernet, the manual says it has contour mode. Will it work with the Mach 4 plugin when its released? Or should I just go with Mach 3 & the existing plugin, If so how well would it work?

Yes, it does indeed have contour mode.  However, it does not have a contour buffer large enough to run contour mode over the Ethernet.  It's only one slot deep!  This, in effect, makes it impossible to use Contour mode on these controllers.


Galil / Re: buy Mach4 yet? for a Galil DMC 2133?
« on: November 04, 2015, 03:56:04 PM »
Unfortunately, the M4 Galil plugin is still in Alpha stage.  Estimated time out now is the end of the year.  But that could change.


Galil / Re: Controlling a SuperPID w/ Galil 1842 and Mach3
« on: November 04, 2015, 03:53:56 PM »
Unfortunately, it is not possible to run a PWM spindle with the Galil plugin.


Mach4 General Discussion / Re: Showing selected axis
« on: November 03, 2015, 07:48:51 PM »
It works fine.  In 2788, the way MPGs are handled internally is different.  Now there is the concept of encoders that plugins can "export".  And there is a new tab on the Mach config labeled "MPG" of all things.  :)  In that tab, the user can associate a Mach MPG (12 to choose from) to an encoder from any device.  %max vel and %max accel are there as well as reversing the direction. 

For many of you, if you had script based setup of the MPGs, then that stuff will need to go away.

The shuttle plugin exports 1 encoder.  The center wheel.  Additional button functions were added to allow the MPG axis selection as well.  One thing to note is that MPGs are separate than regular jogs.  The MPG axis can be selected independently of the jog axis.  Currently, there is not a way to select both the MPG axis AND the jog axis with one button function.  Not sure how to handle that at the moment. 

My setup is as follows:

MPG#1 -> /Shuttle0/InnerWheelCount, 1 count per detent, accel% 25, velocity% 35, reversed.

The first 4 buttons in the top row of the shuttle pro are:
1.  MPG1 Select X
2.  MPG1 Select Y
3.  MPG1 Select Z
4.  MPG1 Select A

The MPG increment is the current jog increment by default. 

So all I do is press one of my 4 buttons to select the desired axis and start dialing away on the wheel.  And it works really well.  I wish the detents were a little more noticeable on the shuttle, but it is what it is...

MPG#0 is configured to another MPG, so that is why I used MPG#1 for the shuttle.


Mach4 General Discussion / Re: Mach 4 Bug Reports
« on: July 27, 2015, 01:37:43 AM »
Make a copy of the Mach4Mill profile and use it instead.  That way, your settings do not get overwritten.

Mach4 General Discussion / Re: Mach4 Executing Gcode from LUA
« on: July 01, 2015, 02:55:51 PM »
For macro scripts (not screen or buttons scripts), The M code functions are available in the calling M code.

if state == 1 then


Mach4 General Discussion / Re: No Script Engine Found for ...
« on: June 03, 2015, 11:01:08 PM »
Enable the mcLua plugin. 


Mach4 General Discussion / Re: need a little bit of help
« on: June 02, 2015, 11:18:50 PM »
Terry...  There is nothing in the core that is LUA.  The core has no knowledge of LUA.  The GUI has LUA.  And the macros can be scripted in LUA via the mcLua plugin.  When the core executes a macro script, all it does is hand it off to a plugin.  If someone wrote a VB script plugin, the scripts could be in VB.  If someone wrote a GUI, then they could use VB in that GUI. 

GUI --|  (LUA for the screen)
        Core ---|
                  Plugins. (LUA for the macro scripts)

The GUI is the HMI (Human Machine Interface).  It is where the rubber meets the road for the operator.  How the interface operates is up to the user/operator/integrator.  The Core is like an operating system.  In fact, I used to write operating systems so the Core modeled very closely to that of an operating system kernel.  It's sole purpose in life is to provide services to the application layer (GUI) and to interface with hardware via the plugins.  The plugins could be considered something analogous to operating system device drivers.  The core can be extended via plugins too.  This provides future flexibility. 

The LUA scripting uses the EXACT same API that we use in C++.  It IS the API.  It controls the core.  Not the other way around.  When you hit the Cycle start button, mc.mcCntlCycleStart() is used to tell the core to start executing.  So please tell me how LUA that controls the core should be controlled by the core?  How could the core ever have dominion over what the M code script wants to tell the core to do?  What if the core just said no?  That would be useless.  Your arguments are circular.

What keeps you from messing up when writing G code?  What protects you from yourself?  If you tell the spindle to plunge through your workpiece or the the table, what do you expect to happen?  It is up to you to write a good G ode program.  It is also up to you to write a good script program. 

One of the needs that kept popping up for Mach 3 was increased flexibility.  Therefore, that was a design goal for Mach 4.  I'll say it again.  There is nothing wrong with it.  There is no design flaw.  You can use it.  Or not.  Your choice.  You will be waiting a very long time for someone to make a system like you are wanting.  Maybe forever.

And waiting for what?  You make the machine do what you want ONE time.  Then, you use it!  I am an operator.  I did this very stuff on my very own machine.  It wasn't hard.  And I haven't touched it since I did all of the screen and scripts.  Not once!  All I do is go downstairs, turn the machine on, and run parts.  The machine is working for me, as you like to say.  The same way every time.  Just like I want it to.