Erratic Z motion Jogging though Mach 3

[bhauser]

Hi,

I have been using mach3 through the plugin for a few years now. I'm currently running v4.35f, and it seemed very stable up until recently. The new issue that I'm running across is that the Z axis Jogging will randomly fail to stop when the keys are released, causing the Z axis to either fully retract or crash into whatever unlucky thing is beneath it at the time. It seems very random, but If I had to estimate I'd say it occurs once every 20 or so key presses. It's interesting to note that I haven't seen this issue with X/Y jogging. I don't think it's the keyboard because both the page up and page down keys are affected and I haven't been able to reproduce this in other applications.

One other issue to note is that I recently had my spindle warmup gcode program freeze and lock up. It only happened once, but it coincides with the Z axis issue and I have never seen happen before. Where should I start debugging this problem? Part of me suspects that after years for faithful service the board is failing. Another part of me suspects that windows update really is out to get me.

Thanks,

Brian

[TomKerekes]

Hi Brian,

I'm not sure why that would be. Our Plugin provides JogOn and JogOff functions that Mach3 calls. That is the problem with Mach3 they don't allow us to see or debug their code. I don't know if you are familiar with Visual Studio, if so I'd be willing to release our Plugin source code if you think that might help figure it out.

Nothing changed?

Does the motion ever stop? It could be that Windows is "freezing" so Mach3 never makes the call to stop in a timely manner.

Have you tried a different PC?

[bhauser]

Thanks Tom,

The motion does stop sometimes. Usually when it happens I'll hit the up down keys a bunch of times, but I'm not certain that actually does anything useful... It's just me panicking. Sometimes the Z axis travels only while the key is pressed (works properly), sometimes it travels 2 or three inches then stops before hitting anything, and sometimes it goes for broke and continues until something else stops it and the axis disables.

I have a high degree of confidence that the only thing that changed on the machine were changed by windows update. The machine was sitting around for about a year. Last month I powered it up to rework some parts and it worked great. I was very, very, behind on my windows updates so I allowed the system to update and shut it down.

Flash forward to a few days ago when I power it up to make some parts and run into this Z axis problem. I also thought that windows was freezing so I replaced the USB wifi dongle which I suspected was dying due to connectivity problems. Replacing the dongle fixed the connectivity but not the Z axis issue. now that I think about it, I'm a bit suspicious that it only happens on the Z axis, are page up/down special in some way? I might try re-mapping those keys in Mach 3 to see if the problem follows.

I'm familiar with visual studio, but I think that you're probably right and this is a windows issue. Before I try debugging the code that works for everybody else without issue (big clue right there) I think it might be smart to replace some of the other devices on the USB (channel?) that might be dying and causing issues. I also think I need to go through the windows event log and see if anything is crashing and re-starting.

I'll look into this a bit more and let you know if I solve the issue. I'll also try to jog the Z axis in Kmotion CNC to see if I can reproduce it there (which would be odd, but worth a try anyway). If all else fails, I may have to bite the bullet and figure out how to switch away from Mach... It will be a bit painful to get up and running again with different software, but I would like my machine to stop eating tool setters... it's not good for it's diet.

Before I start doing the deep dive on this, Is there a good way to test the communication between the PC and the controller? It might be useful to ping the board every X milliseconds and see if there are any communications issues like latency or just plain dropouts.



Thanks again,

Brian

[TomKerekes]

Hi Brian,

That all sounds reasonable.

The PC should be communicating and requesting status from KFLOP at a rate of ~10 times per second. However on rare occasions the PC/Windows/USB may freeze for a second or so. There is a counter (StatusRequestCounter) that KFLOP increments each status request. This can be used to check for gaps in communication. See the WatchdogStatusRequests.c example.

[bhauser]

Thanks Tom,

I'll look at the sample program and try to remember how to use the setup tools (it's been a while!). Keeping my fingers crossed that this is not too rough to debug. I think a jog dial might be a prudent thing to get up and running. I remember this being a posibility, Am I remembering right?

Thanks,

Brian

[TomKerekes]

I suppose you are what is normally referred to as an MPG. Yes with an MPG connected directly to KFLOP there aren't any communication/PC/Windows delays. It is completely deterministic. See here.

[bhauser]

Hi Tom,

So I modified WatchdogStatusRequests.c to give me a warning when ALIVE is false with a timeout of 250ms. It appears that the problem isn't caused by poor communication as this was never triggered. When I set it to 100ms tr triggered fairly often. I looked at the event log and saw nothing of interest. I also tried the Z jog in Kmotion CNC and much to my surprise, it DID do the same thing. It's interesting to note that sometimes motion was delayed (up to a second) when pressing the Z axis keys... which is behavior I didn't see in mach. I'm not certain if the keyboard could be at fault here, but I'm tempted to replace it just to make certain.

One other item of note, windows is running in test mode for unsigned drivers. when I take windows out of test mode the kmotion board isn't detected. Any chance this is related?

It's been a long while since I looked at the Kmotion board schematic. Does it have a 5V output that can supply 150ma for an MPG?

Thanks,
Brian

[TomKerekes]

Hi Brian,

One other item of note, windows is running in test mode for unsigned drivers. when I take windows out of test mode the kmotion board isn't detected. Any chance this is related?

You shouldn't need to run in Test Mode. What Version of Windows are you using? Try removing the drivers (including software) and updating to the Drivers from the 4.35h Release.

It's been a long while since I looked at the Kmotion board schematic. Does it have a 5V output that can supply 150ma for an MPG?

Yes you should be able to pull 150ma of +5V from KFLOP Connectors JP4, JP6, or JP7.

[bhauser]

Thanks Tom,

The machine is running windows 10 pro. I'll disable test mode, install 4.35h and try again soon. I have no idea why this PC was in test mode, it's not like I'm using it for driver development.

In preparation for the MPG, I was looking at the IO list for my Kflop and noticed that I'm a bit short on inputs. Can I use the j15 Isolated inputs on my Kanalog to run the MPG? Will they be fast enough, or do I need to use the Axis 4 encoder input?

Assuming the Isolated inputs will work, it looks like I can just supply 5v to the MPG and just connect directly to J15 without any level conversion of current limiting circuits, which makes this much (much) more likely to happen.

There are 8 opto inputs but 11 potential outputs from the MPG, so I plan on mapping them as follows:

chA+ IN0
chB+ IN1
X IN2 note, XYZ can all be low in the off position
Y IN3
Z IN4
4th Axis IN5 Not strictly necessary, but there is a very small chance I might use a 4th axis
X10 IN6 .001"
X100 IN7 .01"

X1 N/C this is assumed if both X10 and X100 are low so .0001" is the default
chA- N/C I'm surprised that this MPG has TTL level output but has a chA-. maybe it' just there for compatibility with differential inputs?
chB- N/C Hopefully safe to ignore.

does this make sense, or am I asking for problems by making X1 a default to preserve the option for a 4th axis?

Thanks,

Brian

[bhauser]

Hi Tom,

I installed 4.35h, but it appears that windows is unhappy with the driver if it's not in test mode. I've attached some images of the issue when out of test mode. I can also confirm that it is not the keyboard causing this issue. I may try replacing my USB hub next.

Thanks,

Brian