I know what you mean about not having anything useful to work from. I converted my decent sized Denford Mill in 2008 and it's done amazing work.
However, Mach is flaky in my opinion. When you get something that works, don't touch anything. Updrading to the latest build of Mach4 is proving to be a nightmare. Basic things you'd think were set in stone, such as Single Stepping have been messed up. The bizarre thing is that it momentarily worked correctly, and now it's gone back to being wrong.

Anyway, this is what I've done to get it to this imperfect but just usable state...

1) Set up my I/O and configuration from scratch in the new default Mach4Mill profile.
2) Copied the profile to make a new version I can experiment with
3) Installed my screen set
4) Checked to see what works and what doesn't

The results are as follows...

1) Single Stepping is still wrong, it lags behind the actual moves by one step. However, if I go back to the Mach4Mill default profile it works correctly, however there is a definite lag between the digits changing on the DRO and the table moving, and I've not noticed that before.
2) It no longer throws an error report on exiting Mach4
3) It no longer loses the input pin configurations for the limit switches and e-stop
4) Mach4 doesn't seem to crash after showing the Warp V270 splash screen which it's always done.
5) Jogging the A-Axis is almost right now, but not quite. There's still a rounding error in Mach4 that means if you have precisely 1 output step when you click the jog for that amount, it doesn't ouput a step. Instead, it ignores the first step and then outputs two the next time.
In other words, my 4-th axis has 100 Counts per unit and if I jog it using the 0.01 increment, it only increments by 0.02 after I've jogged twice.
Clearly this situation is going to be the same if it's any other axis, so this needs looking into.

I need to make another point about Mach4 that is in direct contradition to everything I've ever read. And that's about dedicating a computer to Mach4. This is utter nonsense, you absolutely DON'T need to do that if you have an ESS. I've been running this way for over 5 years with both Mach3 and Mach4 and have NEVER had an issue.
I stream music, post process huge path files, and browse the internet completely at will. I create complex 3D models and watch YouTube. This is a non issue, despite what you're told. Maybe if you're using a Parallel Port then it's a problem, but as soon as you're using an ESS then it isn't. It's just another process that Windows 10 is perfectly capable of handling. I'm running a 3GHz quad core with 8GB of memory, so it's hardly an amazing computer.

It's massively more convenient to have all of the files you generate on the same PC, with the same screen used for showing Drawings, entertainment and running the machine. I guess nobody tries this because they're scared off by the bad advice.

thanks for the update

jogging updates you say I jog 0.01no movement but when I jog 0.01 x2 it moves 0.02 ( mm I think ) I suspect that the resolution of your stepper motor ( sorry I assume )if that's what you use is to course and the cannot resolve the small movement

glad things are a bit better

as to the pc if it works for you all well and good use it that way , as for me I will stick to what works for me

one question if I may be so bold is in previous comments you mention " pressing the stop button and or single step button" I take it these are actual buttons on a control panel not icons on the screen

if they are are they scripted in Lua in the screen or PMC ladder , if its in the screen set there maybe some lag when it processes your input

g31 now will not execute, getting: Capping Z Minimum to 0.0000 based on parameter 1801.  I have changed #1801 to -2.000

g91 g31 z1 f2 works
but g91 g31 z-1 f2 gives the above error message.

TIA

RT

I have AC Servos, not stepper motors, and they respond to every pulse. I'll double check tomorrow, but I'm sure Mach4 isn't outputting individual pulses, else it would increment the count by 0.01 each time I click the jog button right? It makes no sense that the DRO would output every other pulse. I think it's a software rounding issue.

What works for my PC will work for everyone with an ESS and a half decent computer. Don't let the fear factory dictate what system you can have. It works, so why not take advantage of multi tasking your PC?

You're quite right, these are on screen buttons clicked with the mouse.

So the main outstanding problem I have is with Single Stepping. This behaved briefly but now it's back to lagging the moves by one step. In other words, everything executes as expected until the moment it's supposed to make the first physical move. The system fails to move when the block is executed, or does some random tiny move. When Cycle Start is pressed again (on screen button) the previous block finally gets executed. This continues until the last block where it's confused because it's reached the end of the program as far as the highlighted block is concerned, but it hasn't gone there yet.  Executing the last block causes it to go to the position but also executed the M5M30. The highlighed block skips back when it does this as it tries to get back in sync.

Someone else has commented that this is a problem that they just live with, but that's crazy. It worked just fine for years with Mach 4 V4.2.0.3804 ESS V231, so something has been messed up somewhere inbetween.

It looks to me like some other process is being executed when the first commanded move takes place, causing the change in the DROs. I have no idea what this move is, it doesn't equate to the backlash compensation values.

g31 now will not execute, getting: Capping Z Minimum to 0.0000 based on parameter 1801.  I have changed #1801 to -2.000

g91 g31 z1 f2 works
but g91 g31 z-1 f2 gives the above error message.

TIA

RT

Tested this with pokeys57cnc and Sim.  With old and new wx4 screen sets.  Same results.  What does the error message indicate?

Ok, this has nothing to do with g31.  Went to surface a block with incremental (g91) moves and got the same message.  There is a setting somewhere that this new build has defaulted to.

g0x0y0
m98 p1234 L1
m30

o1234
g91
g1 f5   z-.005
g1 f15 x-5
g1 f5   z-.005
g1 f15 x5
g90
m99


RT

Very strange behavior.  Changed the tool length for tool1 from 0 to 1.  Ran fine.  Changed it to .25, ran as expected.  Changed it to .001. ran as expected.  Changed it back to 0 and it ran as expected.  Since no tool had been defined is the tool table empty?

RT

Tracked this down to something within the profile I am using.  I have a laptop that I use for development and another one for actual cutting.  If I start with a clean profile it runs as expected.  This profile was from a previous build and has few screen modifications.  I assumed that you could continue to use your old profiles.  When I packaged the cutting machines profile and put on the laptop it would not work there either so somewhere there is a missing setting or a bad setting.  Soft limits are not enabled but it wont let the z axis below zero. I have no idea how to tracking it down.

FWIW, in this profile there is a file called parameters.ini.  In it there is an entry for 1801 -
[1801]
Desc=OEM parameter 1801
Type=2
Value=0

If I change it to NIL all is well.
I have know idea how or when this gets changed. Wizard/Post Processor?  Anyone know?

RT

I have AC Servos, not stepper motors, and they respond to every pulse. I'll double check tomorrow, but I'm sure Mach4 isn't outputting individual pulses, else it would increment the count by 0.01 each time I click the jog button right? It makes no sense that the DRO would output every other pulse. I think it's a software rounding issue.


So the main outstanding problem I have is with Single Stepping. This behaved briefly but now it's back to lagging the moves by one step. In other words, everything executes as expected until the moment it's supposed to make the first physical move. The system fails to move when the block is executed, or does some random tiny move. When Cycle Start is pressed again (on screen button) the previous block finally gets executed. This continues until the last block where it's confused because it's reached the end of the program as far as the highlighted block is concerned, but it hasn't gone there yet.  Executing the last block causes it to go to the position but also executed the M5M30. The highlighed block skips back when it does this as it tries to get back in sync.

Someone else has commented that this is a problem that they just live with, but that's crazy. It worked just fine for years with Mach 4 V4.2.0.3804 ESS V231, so something has been messed up somewhere inbetween.

It looks to me like some other process is being executed when the first commanded move takes place, causing the change in the DROs. I have no idea what this move is, it doesn't equate to the backlash compensation values.

On this first point, I've just checked and the single jog move of 0.01 when the steps/unit is 100 doesn't output each individual step. I know this because my AC Servo amplifiers have a digital readout on them that shows the counts received. That shows zero when I jog the first time, and then instantly two when the next step is made. So it follows the DRO, which is exactly what you would expect.

On the more important issue of the Single Stepping being one step behind, and showing troubling behaviour on the first step that's being ignored, I've attached the screen set that I'm working with.
The bizarre thing is that this morning, it's behaving itself! I have no idea what's going on, but there's definitely something flaky in the code. I'll see if I can put my finger on it when I see this being wrong again, which it surely will be.