Now I'm confused as to what you are calling single stepping.  Single Block?

Steve

Sorry, yes, I mean pressing Cycle Start when the Single Block radio button is lit. We call it Single Stepping in our industry.

Well, I don't know why that would affect anything having to do with backlash.  All Mach does is provide the trajectory plan to get from the start position to the end position of the move.  The plan should never change just like the distance between your door and your mailbox never changes.  How you get from your door to your mailbox is the motion controller's job. 

As to Cycle Stop.  I don't like it because it is not recoverable.  My YASNAC control that was on my Matsuura mill had Cycle Start, Reset, Feed Hold, and an e-stop button.  If I wanted to stop the machine and walk away for a bit, I hit feed hold.  On my YASNAC control, Feed Hold was a yellow button.  On most Fanucs, it is a red button but it is labeled "Feed Hold".  I kind of like the red button because most people associate red with stop.  Neither has a Cycle Stop button.  When I converted my mill from YASNAC to Mach 4, it still has no Cycle Stop Button.  Not on the panel and not on the screen.  I believe this is correct for for most milling applications.  I'm not a lathe or grinder guy, so I just don't know.  But a Cycle Stop button has been a Mach feature for nearly 25 years now and people just expect it to be there, for better or worse.  Worse, IMHO.

But anyway, pressing cycle stop USED to be semi-recoverable on Mach 3.  But with Mach 4 and its' MACRO B, better cutter comp, and more advanced Fanuc compatible interpreter, Cycle Stop is just not recoverable.  Especially if you are using cutter comp.  You need to use "Run From Here" to restore the state of the machine to restart.  If you don't use cutter comp or Macro B, you may be able to get away with just pressing Cycle Start.  But your mileage may vary.

Steve

Ok, but on Single Block, I'm getting it doing a phantom move instead of the first X/Y move. Mach4 moves on to the next block, but the DROs shows what actually happened, ie a short random move. It's only when the next Single Block is executed that it actually performs the move, but now it's out of step by one block.
Do you think this is because the ESS isn't processing the whole move? It looks to me like there's some kind of setup move going on to deal with the Backlash Compensation. Unfortunately I won't be able to experiment with any of this until this large job it finished.

I've found by accident that Cycle Stop seems to be recoverable, but I didn't expect it to be. Personally, as long as it doesn't lose count, that's all that matters. I don't see why anyone should expect to be able to continue. You've asked it to stop after all. Personally, I think you'd be justified in setting a flag that prevents you from continuing after a Cycle Stop. You could force the user to restart using the tools provided. Maybe there are some situations where it's easy to recover, and in those situations you wouldn't force a restart.

Cycle Stop takes a long time to respond now, and that's changed too. Is that something that Mach4 is doing, or is this another thing the ESS is doing?

Restarting part way through a program is a bit of an adventure though, I try to avoid doing it. For some reason it always starts at the block before the one you select, so you have to be wary. I'm not sure why it does that.

Rob has an ESS machine at the shop that has backlash that he said he could test with.  You could try disabling the backlash comp on the ESS and see if there is still a strange movement with Single Block. 

I have it on good authority that Cycle Stop will cancel cutter comp and trying to recover from that just by hitting Cycle Start will be disastrous. 

Cycle Stop used to stop things rather abruptly.  And people complained about it which made me want to ask why they were pressing cycles stop in the first place, hence my rant.  So...  I added a setting that basically does a feed hold before the stop.  THAT takes time.  It also made cycle stop more recoverable, unfortunately (for me).    So check your settings on the general tab and untick that setting.  Cycle Stop should be pretty instant that way.  Oh, and abrupt, crude, rude, and obnoxious.  The way it was meant to be.  If that happens quickly, then we know it was the feed hold portion taking so long.  If so, check that the ESS motion buffer isn't exceptionally large, that will affect how long Feed Hold takes.

Typically, with Mach 4 and a decent PC, you can run motion buffers as small as 30 milliseconds, which to us humans, seems instant.  Anything under 100 milliseconds for most people, actually.  But even the people with the fastest sense of time considers 50 milliseconds instant.  Just to give you an idea on where a good buffer depth is.

I have never seen an issue when using Run From Here.  I'm get it tested again though. 

Steve

Running trying that on Rob's machine would be a big help. I've just got a reply from Warp9 and his machine clearly works correctly with backlash compensation during Single Block.

That makes good sense about cutter compensation being cancelled. You can't expect to pick up from that because you don't know the calculated intersections to know where you've come from. Can't you disable the Cycle Start when that situation occurs so they can't do it? You know when Cutter Compensation is turned on. The same goes for any other situation you know it can't recover from. That way you cover your back.

I don't use cutter compensation, the CAM does all of that, and that's probably why I can carry on.

Ok, I'll uncheck that setting for the feed hold, that's not the way I want it to work.

I need a decent size of ESS buffer to stop it hesitating when running at speed. With 1 micron resolution, that's a lot of data. I've noticed it pausing during some moves too, so it seems that something else might be wrong.

I'm beginning to wonder if my install is somehow corrupted. Is there any way to completely purge Mach from the Registry and wipe it totally for a fresh install?

When this big job is out of the way, I'll have a really good look at all of this.

Roger

Roger,

There is nothing in the registry save for the installation directory.  And I doubt you have a corrupted install.  It is way more likely that your Ethernet card is not doing the job. 

A lot of the onboard Ethernet devices are built asymmetrically.  Meaning they are better at downloading than uploading and thus have large receive buffers and small transmit buffers.  Look at the device properties for the Ethernet device and see if you can increase the transmit buffers.  Also, turn off anything that is like "interrupt moderation" or "green Ethernet".  If you can't increase the transmit buffers equal to the receive buffers, get an new Ethernet card.

The resolution of your encoders really doesn't affect the data stream.  The Mach planner divides the trajectory plans into many time slices.  Each time slice has a planned number of steps that have to be executed in that time.  Most Controllers use a time slice (or cycle time) of 1 millisecond.  So a 2 micron resolution might move 1 step in 1 millisecond but a 1 micron resolution may move 2 steps in 1 millisecond.  So it is the resolution of time, not the resolution of position that affects the data stream.  For example, a cycle time of half a millisecond will stream twice the data than that of a cycle tome of 1 millisecond. 

Most motion controllers settle on 1 millisecond cycle times as it is a good all around number and is granular enough that the no faceting is detected at high speeds and is capable enough of running very smooth low speeds.  The ESS uses a 1 millisecond cycle time.  An interesting thing that we can derive from that and your machine's resolution is that your 1 micron resolution allows you to run as slow as 1 micron per millisecond without spreading a step across cycles. 

I have an D2700MUD Atom board that is capable of feeding my Galil at half a millisecond cycle times.  That is twice the data that you are moving with the ESS.  The Galil can actually go as low as one quarter of a millisecond on the cycle time.  But there is a point of diminishing returns.  So how does this little Atom board do it?  Well...  it has a good Ethernet device in it.  The Intel Pro series Ethernet chipsets are a favorite of mine.  The Realteks and Bigfoots, not so much.  My point is not all Ethernet chipsets are created equal. 

All this is to say that any decent PC with a decent Ethernet chipset should be able to feed an ESS without stuttering, even with a very low motion buffer depth.  I routinely run a buffer depth of 30 milliseconds on my Atom/Galil combination.  My loop interval is 10 milliseconds (feedback loop) so that gives the system 3 chances at filling the buffer to its' full depth.  No stutters ever.  That is why I suspect that your Ethernet card is just not doing what you need it too.  Because there are a lot of CRAP Ethernet chipsets in consumer PCs these days.  It is a throughput issue, not a corruption issue.

Steve

I'll certainly check out the settings. However, this is not new hardware, I've been running the same hardware since 2010. That was initially on Mach3 then Mach4 and I've had no issues whatsoever until I upgraded to Mach 4 4.2.0.4612 ESS V270 from Mach 4 V4.2.0.3804 ESS V231

That means this is clearly a software issue, unless by some amazing coincidence I've had a hardware fault at the same time. Of course that can be either a Mach or ESS issue, and I suppose Windows could coincidentally have done something to upset things. You never know what curved ball an update is going to throw you.

Is there a way I can get the old 3804 version back? I did look at the ftp link, but it wouldn't connect me to anything. I'd like to prove definitively that it still works ok with that version so I've got a reference point I can go back to.

Hi Roger,

For 3804 have a look here https://www.pmdx.com/Downloads_Mach4/Mach4_Hobby_Releases/

Nick.

Hi Roger,

For 3804 have a look here https://www.pmdx.com/Downloads_Mach4/Mach4_Hobby_Releases/

Nick.

Thanks Nick, that's great.

I've been in contact with DynaMotion, and they seem disinterested in making a Mach4 plugin. I guess that's because they would rather you use their own KMotionCNC software. Although that looks messy at first glance, it is configurable, so that might be the way forward.

Eureka! I've finally got to the bottom of this bizarre behaviour with Single Stepping and the phantom move.
I downloaded the old version that I was using before, and I spotted that I'd overridden the Custom Velocity and Custom Acceleration units. I'd failed to set those up when I configured V4612 and ESS V270
Filling in those values has fixed the problem. The custom values are much larger than the defaults, so maybe the ESS is tripped up by how long it takes to apply the backlash compensation when the settings are low and the Servos are high resolution and dynamic. Who knows. I'm surprised that it caused such bizarre behaviour.
Anyway, I've fed this back to Warp9, so maybe they can put some bounds on the values you input or make sure that at least it doesn't trip up Single Block.

So hopefully it will now behave itself and I can restore my confidence in the whole system.

What I'd really like to do is to use KFLOP with it, and I'd be delighted with the system. Open loop systems suck. I wonder if it's worth you contacting Dynamotion to see if they can be convinced to make a plugin for Mach4. They've done it for Mach3, so I can't see why they can't do it for Mach4. Their KMotionCNC is not dissimilar to Mach3 in the way they customise the screen. It's a bit clunky, nothing like as nice as Mach4.
Maybe others reading this might be inclined to contact Dynamotion too. The more they get asked, the more likely they are to cave in and give us what we want.