Messages

1

Mach4 General Discussion / Re: Mach4 Installed but not launching

« on: January 13, 2018, 11:40:49 PM »

A bit late, but...  While PMDX doesn't sell the PMDX-422 any more, the plug-in still supports it, and will continue to support it for the foreseeable future.

2

Mach4 General Discussion / Re: Jogging and DRO errors

« on: January 13, 2018, 11:25:43 PM »

My X and Y are set to 1/8 and my Z is set to 1/4. MY X and Y are on a belt and my Z is on a screw.

This doesn't make sense.  Your X and Y axes are set the 1/8 steps per inch (or mm)??  When you go to the Configure->Mach menu, click on the "Motors" tab and select "Motor0", what does the "Counts per unit" say?  Likewise the other motors.

For "very small" jog increments, if you don't get any motion it means that the jog increment is smaller than one step as entered in the "count per unit" field referenced above.  For example, if you have 100 counts per inch, each step pulse will move 0.01 inches.  If you set the jog increment to 0.0001 inches and try to do an incremental jog, you will get no motion until you jog 5 times (I think the PMDX plug-in rounds fractional motion up starting at 1/2 of a step).  And then every 10 incremental jogs.

Likewise, if you set the "counts per unit" to 400, each step will be 2.5 thousandths of an inch.  If you start at zero and command a move to 0.008 you will actually end up at 0.00075 because that is as close as you can get with that step size.  If the DRO is displaying 3 fractional digits, it will round up (I think) and show 0.008.  If the DRO shows 4 fractional digits it will show the full 0.0075.

What is the message "Attempt transition from "Jogging" on event "Stop Jog" Controller.cpp:1379" indicate? Where can I find a listing of all the error messages?

This is not an error message.  It simply says that the Mach4 core is attempting to change out of the "jogging" state, because it received a "stop jog" event (i.e. the motion planner told the core that it was done generating the motion).

3

Mach4 General Discussion / Re: Version 2 has no tenths jog increment

« on: January 18, 2017, 10:32:28 PM »

What is your steps/inch setting in the motor config tab?

4

Mach4 General Discussion / Re: VistaCNC Pendant - Running out of luck...

« on: December 16, 2016, 12:23:36 AM »

I'm new to the forum searching for answers and have discovered my issue to be the same as Pete's.  I'm curious to know if Bob's instructions to Pete resolved the issue??  I'm interested in providing a test-bed to provide input to learn how Mach4 and the VistaCNC P1A issues can be resolved.

My instructions to Pete were to gather information to try and figure out what was going on.  As best i can remember Pete never ran the tests as he discovered an incompatibility between the SmartBOB and his breakout board.

If you want to try collecting the data, send me your Machine.ini file. See item (1) in my previous post on finding the correct Machine.ini file.  Please email it to me at bob at my domain below.  I'll update it and send it back for you to use in the test.

Bob

5

Mach4 General Discussion / Re: *** PROBING SCREEN ? ***

« on: November 30, 2016, 09:39:34 PM »

Probing is controlled by your motion controller.

Not entirely, unlike homing which *is* entirely controlled by the motion controller.  When Mach4 executes a G31 command, it tells the motion controller to prepare for a probe move (i.e. "arm" the probe input).  The Mach4 motion planner then generates the motion data for the G31 move just like it does for G0 and G1 motion.  It is then up to the motion controller to detect the probe strike, record the current position, halt motion, tell Mach4 that the probe triggered, and discard the rest of the motion data that may have already been buffered.

That said, the probing screens in the newer Mach4 releases do a LOT of work in Lua scripts before and after the individual G31 calls.  If the probe strikes during any of those moves (usually G0 or G1 motion), there isn't anything to stop the motion.  Unless your motion controller has a feature called "probe safety", which halts *any* motion if it sees the probe input go active.

Who's "fault" it is depends on whether the original poster's probe crash happened during the actual G31 motion or during some of the G0/G1 motion that the scripts generate on the fly.

Bob

6

Mach4 General Discussion / Re: Home offset

« on: November 05, 2016, 10:08:01 PM »

I can't speak to the 2nd issue of the X and Y "home in place" and the home cycle not completing.  Try opening the Mach4 log window (Diagnostics->Logger, and then click the "play" button to enable it) and then try the home sequence.  See what it says.

As for the Z axis - the homing movement is supposed to leave the axis at (or very near) the home switch.  So the action you describe is correct.  If you want the axis moved somewhere else before the other axes start homing you will need to edit the homing script that is built into the Mach4 screen sets.  This is from memory so I may not have all the details exactly correct.  You can search the forums for info on editing the screen set and finding the "load scree"n" script that I mention below.

In the recent Mach4 builds (2914 and 3206) in the wx4 screen sets, the "Ref All Home" button runs a Lua script called RefAllHome().  That script is located in the "load screen" script in the screen set (or is it "screen load", I don't remember).  RefAllHome() does something like this (in build 3206 at least):

      Deref all axis
      HomeAllAxis

You will have to change this to something like this:

      DerefAllAxis()
      HomeAxis( inst, Z_AXIS )
      issue command to move Z axis to zero
      HomeAxis( inst, X_AXIS )
      HomeAxis( inst, Y_AXIS )

For the exact syntax and names of these functions, there is a help file names Mach4CoreAPI.chm in the Mach4Hobby\Docs directory.  Sorry to be so non-exact, but I am not at a PC with Mach4 on it.

Bob

7

Mach4 General Discussion / Re: MACH4 LUA scripts disappear after upgrading to new version

« on: October 25, 2016, 10:00:59 PM »

Thanks that is what I did wrong.  I always copy the ini file but that did not save all the LUA code put in WX.  I need to figure that part out as well.

I also forgot about free-standing macros (for example, if you have an M6 tool change macro), these live in the YourProfileName/Macros directory.  Likewise, tool tables and fixture tables have their own subdirectories in the profile.  I mention this just to emphasize that you don't just need to copy/save individual files, or Lua code out of the screen set, but the entire profile.

Bob

8

Mach4 General Discussion / Re: MACH4 LUA scripts disappear after upgrading to new version

« on: October 25, 2016, 09:34:10 PM »

Please please PLEASE... do not save your changes in the standard Mach4 profiles (i.e. Mach4Mill, Mach4Lathe, Mach4Router, etc.).  As you have found out, they WILL get overwritten when you install a different Mach4 version.  Open the Mach4 Loader, select the profile then click on the "Copy Profile" button.

Likewise, if you have any custom changes to the screen set (custom buttons or Lua code), copy the screen set to some other name.  I'm not in front of a PC with Mach4 at the moment, but from the screen editor I think it is something obvious like "File->Save As" (or *some* menu then "save as").

Bob

9

Mach4 General Discussion / Re: input as a dro display (not closed loop),

« on: September 22, 2016, 09:32:36 PM »

im using mach 4 with ess, i have put a dro display on my screen and it works but the counts are not correct . but i do not know how to scale or zero it i need to know how and where to put a script eg dro## value = ess encoder divided by 2000

I would *guess* that the DRO is showing raw encoder counts, but that is just a guess as I don't know how the ESS plug-in handles encoders.  The Lua code to scale the encoder value should probably go in the PLC script so that it runs periodically (search these forums if you don't know where that is).   There are lots of messages about how to do things in scripts so there are probably examples or reading registers and writing to DROs.  Check in the "Mach4 Toolbox" sub-forum.

How to do this with an ESS I have no idea.  Someone here might chime in, or you could/should try posting on the Warp9 support forums.

regarding mpg,never use it as encoder input as it causes the axis to look at it for closing the loop giving crazy movement

Mach4 does not have *any* closed-loop control capability built in to the core.  What *will* happen if you map an encoder to an MPG is that the Mach4 core will attempt to translate changes in encoder counts to jog motion for the currently selected jog axis.  Depending on the MPG configuration parameters that jog motion can be quite erratic.  And as I mentioned earlier, should the encoder wrap from max count to zero it will queue up a whole bunch of motion.

Bob

10

Mach4 General Discussion / Re: input as a dro display (not closed loop),

« on: September 22, 2016, 02:51:50 PM »

If the motion device (or I/O device) supports encoder interfaces, then the plug-in for that device will register one or more encoder devices with Mach4.  It does this by creating a Mach4 register of type "encoder".  That register can then be mapped to a DRO, and/or mapped to an MPG (this is what the Mach4 config "MPG" tab is for).  You can also write Lua scripts to read (and sometimes write) that encoder register to do whatever custom thing you want.  Note that you should only map an encoder to an MPG if you want to use that encoder to jog the machine.  If you want to do anything else with the encoder (like, for example, create a Lua script to allow it to change the feed rate override), DO NOT map it to an MPG.

You can find out what registers your device plug-in provides by going to the "Diagnostics" menu and selecting "RegFile" (presuming that you have the "RegFile" plug-in enabled).  That will show you all of the plug-ins.  If you click on the "+" next to the plug-in to expand it, you will see all the registers that the plug-in exposes to Mach4.

A word of caution when mapping an encoder to an MPG.  By default, if there is an MPG defined, Mach4 will use that to jog the "current" axis (determined by calls to mc.mcMpgSetAxis(), and set to the X axis by default on startup).  Whenever Mach4 is enabled, changes in the encoder count will cause motion based on the change in encoder counts.  If the encoder is configured to reset it's count to zero once per revolution, that will cause *LOTS* of motion as Mach4 will see the count go from, say, 99 to 0 for a 100 count encoder.  That looks like a huge jog request.  Likewise, if you change the encoder value via a DRO while Mach4 is enabled, that will also cause Mach4 to try and jog the current axis.

The plug-in determines whether to allow DRO edits to actually change the encoder count.  I had to explicitly add code to the PMDX-SmartBOB plug-in to allow that feature.  I have no idea if any other plug-ins provide this functionality.  Likewise I also added code to prevent changes to the encoder count from the DRO if the encoder is mapped to an MPG *AND* if Mach4 is enabled (see caution above). 

Bob