Hello Guest it is September 23, 2020, 09:42:27 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

Mach4 General Discussion / Re: Mach 4 Bug Reports
« on: December 11, 2014, 02:23:30 PM »
When the timing signal is triggered the 0 motor which I have set to the x-axis
will start and move in a +direction until it hits the limit or you hit e-stop.

You have an old signal mapping setup in your profile.  Edit the machine.ini file for the profile and delete all of the [Signal#] mappings.  You will then have to re-map your signals.  :(


Mach4 General Discussion / Re: Needing help with screens
« on: December 10, 2014, 01:49:38 PM »
In a M code script, one that will be run from a G code file, it is best to use mc.mcCntlExecuteGcode() mc.mcCntlGcodeExecute() or mc.mcCntlExecuteGcodeWait() instead of mc.mcCntlMdiExecute().  MdiExecute will only run if the machine is in the idle state.  

mc.mcCntlExecuteGcode() mc.mcCntlGcodeExecute() will not wait for the G code to complete.  It is there so that button scripts can fire off code like the Goto Zero button uses.  You don't really want to wait on G code in a button script as it will freeze the GUI until it completes.  The act of executing the G code changes the machine state and you can use the state to lock out buttons to keep things from happening while the G code is running to completion.  mc.mcCntlExecuteGcode() mc.mcCntlGcodeExecute() will call MdiExecute() if the machine is in the idles state.  This is a good choice to use in button scripts.  

mc.mcCntlExecuteGcodeWait() does as it implies.  It will actually run G code while a file is running, so it is the best thing to use for M code scripts.  Again, mc.mcCntlExecuteGcodeWait() will call MdiExecute() if the machine is in the idles state.  Not so good for button scripts.  


Mach4 General Discussion / Re: Mach 4 Feature Request
« on: December 07, 2014, 07:15:13 PM »

I just looked at it.  The data is getting out to the plugins fine no matter what the movement type (rapid vs. feed).  So maybe it is a plugin issue?


Mach4 General Discussion / Re: Mach 4 Feature Request
« on: December 07, 2014, 04:25:18 PM »
I'll look at it and see.  It is supposed to be for feed moves only in the EMC definition.  But I also included rapid moves.  I thought it would be more flexible that way.  So it is at least nice to see that part of it working.  :)

Try a feed move/M62 combo first and see if it is a first case wins thing.


Mach4 General Discussion / Re: Mach 4 Feature Request
« on: December 05, 2014, 03:13:45 PM »
Hi Steve,

Many thanks for dedicating the M62 / M63 commands, it is much appreciated.

Could  you please give me a clue as to how I turn ON / OFF an Output using the M62 / M63 commands. Obviously it is pretty simple but so far it alludes me.



M62 P0

will set the output that is mapped to the Output #0 signal at the first movement after the M62.

So... this requires that a plugin output of some sort is mapped to the Output #0 signal.  That that is the first order of business that has to be taken care of.

Here is a simple example of the G code to drive it:

M62 P0 (turn on the output mapped to Output #0 signal at the next move)
M62 P1 (turn on the output mapped to Output #1 signal at the next move)
G01 X1 F30 (outputs 0 and 1 will activate at the beginning of this move)
M63 P0 (turn off the output mapped to Output #0 signal at the next move)
M63 P1 (turn off the output mapped to Output #1 signal at the next move)
G01 X1 (outputs off)

It is important to note that Mach is not turning the output signal on at any time.  It only uses the output signal to find the mapped plugin output.  The motion controller then turns this output on as a function of the movement.  This has implications as now something outside of Mach is really controlling the output.  Thus Mach will not know that the output is set because it is not the process that is actually setting it unless the motion plugin TELLS mach that the output it set.  Some do...  Some don't...

So the best thing to do is write G code that puts the output back into it's original state (as in the example above).

And to shad71's concerns, we plan on implementing something like "M66 Wait on Input" that will allow waiting on things like torch arc signals.

There is no THC on/off function.  You can create buttons do do whatever you desire.  These buttons would typically set outputs.  And do not that eventually we will have a separate interpreter for plasma machine that will be more tailored to their use.  For right now, we are concentrating on Mill and Lathe.  However, the Mill interpreter will support MOST of the things plasma machine need.


Mach4 General Discussion / Re: Mach 4 Feature Request
« on: December 05, 2014, 12:34:55 PM »
Terry, you can make a page and put the whole tool table on it, if desired.  And the same goes for the Fixtures.  Mach Motion did something similar.  It could be a LUA Wizard type of thing or just something DRO based.  Tabbing...  Probably not going to happen like you want.  The order of control creation has a lot to do with it, so you can kind of control your own destiny a bit there.  But then there is Z level which dictates that some controls be created before others.  It's a Windows thing and it is what it is.

sahd71, you can use any input for ArcOk, put a button on any screen for THC On/Off you desire, and control outputs with M62/M63 with no pause in motion.  M62 and M63 will work in the same manner as Linux CNC (replacing M10 and M11 in Mach 3).

daniellyall, the key mapper can be used to create any number off custom inputs that can be used in the PLC script to perform any action available in the API.  Not as simple as just connecting a key to a stock action, but it isn't THAT much harder to do.  The sky really is the limit.

The tools are there.  You guys can pretty much customize anything to your liking. 


Mach4 General Discussion / Re: Screen Set Ideas
« on: December 04, 2014, 10:54:45 PM »
I'm liking that too!

Galil / Re: Galil 2123 with AMP-20520 lathe Z axis DRO not working
« on: November 25, 2014, 01:59:31 PM »
I have no idea at this point.  The comms to the Galil look good.  It may be a Mach setup issue now.  Make sure that in Mach's general settings that there is nothing set for Z is 2.5D.  Look at ANY setting pertaining to Z for that matter.

I have not ever tried Mach Lathe, so I would not know much about how to set it up.


Galil / Re: Galil controller compatability (what works with the plugin)
« on: November 23, 2014, 04:46:54 PM »
DMC-2142 is an Econo controller with the old style 100 pin connectors on it.  Are you sure it is a 2142?  Or is it a 2143?  Both can only use Linear mode motion control.   The newer controllers use Contour mode.  Strictly speaking, the 21x2/3 controllers will work.  But they are getting long in the tooth.  And the Mach 4 plugin has not been tested with them as yet.

There is a working Galil plugin for Mach 4 for Ethernet controllers only at this point.  It is not ready for prime time yet and has really only been tested on the newer controllers.  Thus it has not been released.  And I'm not sure when it will be released at this point as we are concentrating on Mach 4 primarily at this time.  Right now, Mach Motion, Kenny Crouch and myself are the only ones that have machines running Mach 4 with Galil.  And we are using 4000 series controllers. 

We will be building a machine at the shop with a 21x3 controller in the coming months, so that should shore up the support for the older Ethernet controllers.  But that is not high priority at this time.  :(

Also, the Galil plugin will be a supported plugin for Mach 4.  And that means it will most likely be licensed much like Darwin is.  The price of Mach 4 alone is not going to cover the cost of the Galil plugin development and maintenance. 


Galil / Re: Galil controller compatability (what works with the plugin)
« on: November 18, 2014, 04:35:37 PM »
I cannot write instructions for setting up bused based cards for which I don't have.  :(

The Galil plugin for Mach4 uses the Galil Tools/Galil Suites API library called LibGalil.  It will work with the driver provided by Tools or Suites.  But not Smart Term.  Smart Term is dead and will only work on Windows XP.

If you are shooting for Mach4, then:

1. Don't use Windows XP.
2. Don't use bus based cards. 

Currently, we are supporting XP for Mach 4.  But for how long?  The safe bet is not long at all.  And bus based cards...  I don't have any of them.  I can't test them and I won't be able to support them.  IF it works, then great.  If not, then I will be of no help.  :(

The Ethernet Galils do not require ANY drivers and thus do not require any special setup other than setting up the IP address.  You can load Galil Tool/Suites and immediately communicate with them with no driver install and reboot.  This is the future.  There is no going back to the bus based controllers for Galil.  They have not nor do I believe they will ever produce a PCIe controller.

So that is the writing on the wall, unfortunately. 

The Galils differ greatly on how the data record is obtained.  The Ethernet controllers can "stream" a data record to the PC and this is what we have chosen to use in programming the Mach4/Galil plugin.  The PCI cards have to be polled.  And since I don't have a PCI card, I cannot test this polling of the data record.  So there is absolutely no guarantee that your PCI card will ever work with the Mach4/Galil plugin.  So please don't invest a ton of time and money into the setup you have for Mach 4.  It should work fine for Mach 3 though.