Had an interesting event today. I was in the process of setting Z using the paper method. I needed a few more steps down clicking on the mouse. There were a few steps that didn’t step … I thought that the mouse click had not registered for whatever reason. I clicked a few more steps and all of a sudden the mill decided to burry the bit in the spoil board.
I have expressed on many occasions that the mill goes to lala land on occasion being slow to react or not reacting at all for a few seconds (and sometimes requiring 30 seconds or more to catch up). Today’s experience seems to indicate that, rather than interpreting quick mouse clicks as a request to flip into continuous mode, it simply doesn’t respond (in a timely manner) to some commands. The commands are queued though. Unfortunately doing many small steps is mostly a Z kinda’ thing which is why this is where the problem is most obvious. So, a few down steps are queued and when gSender is good and ready it executes those queued steps which than buries the bit.
BTW, I was clicking the mouse relatively slow because of previous bit burying experiences so there was no way that anything could have been interpreted as a command to go to continuous movement.
The take-away: watch the z axis like a hawk and verify that each and ever click of the mouse causes a step. If the mill doesn’t step, wait ten seconds (ie an eternity) to see if the step was queued and just not executed yet.
Just so I understand, is this an issue with gSender or the firmware on the controller board?
This problem in my opinon is a huge problem. I hope that Scienci would kindly find a solution to the mouse, xbox controller, etc runaway issue. It is very unsafe, and more than a few stories on these forums are from this issue. You are probably right that it is queuing the commands and then running them later which is not good at all.
My sister called me yesterday because she was having computer issues. Applications weren’t responding all that well and web sites were opening at random. I suspected malware but investigated further. As I was moving my mouse over the browser, multiple tabs opened up with the same web site. Ok, I said to myself, maybe she’s got sticky keys or mouse button. I disconnected the mouse and all her problems went away. Got her a new mouse and computer has been running smoothly since. I’ll note that she was having issues even when not pressing the mouse buttons. But if it was stuck, it would still send a command when the focus was on a URL in the browser.
My point, you ask. Maybe a hardware issue with an input device is sending multiple commands to gSender (as has been suggested). Swapping out or removing these devices is easy and not too expensive.
I will test your theory but I do not think this is what is happening.
First, it’s happening to a lot of people - similar failures happening to multiple people is unlikely.
Second, what are the chances of a mouse sending multiple click events precisely after steps were missed but not at other times?
Last, the issue with gSender ‘freezing’ for a few seconds is well known (at least by me).
Very plausible hypothesis Jens. Maybe next time, in stead of waiting the eternity, counter the hiccup with a click-up, to prevent multiple cued downward movements to happen. If it was an unregistered click, you at least don’t have to wait and can continue stepping?
No?
I will try to remember …
@Jens I wasn’t necessarily implying that you are having a mouse issue. It was more an observation on an issue I thought was caused by something (malware) which was actually caused by something I wouldn’t have normally considered ( the mouse).
Don’t forget that the touch screen is an input device too.
It would be worthwhile to grab the content of the console when this happens. Or the diagnostics file. Someone (Sienci) might be able to tell if multiple z down commands are being issued.
I use the touch screen as well but very sparingly. While it works, I wouldn’t call it exactly reliable and it is difficult to use it while your attention is on the bit. My finger wanders unless I am looking at the screen. I can operate the mouse while concentrating on the bit. Having said that, I can probably use the keyboard without having to look at it.
It’s been a long time since I’ve had the runaway problem. It’s also been a long time since I used Windows. Just last night I stumbled across this quick read about how input handling is messed up on Windows.
Maybe related maybe not, IDK if your running Windows.
He’s one of the biggest fans of windown I know on this forum.
No.. not a typo.
I had the same problem and fixed it by watching an IDC YouTube video. There is a setting in the gsender config area which will fix this problem. Unfortunately I am not by my CNC to tell you which setting needs adjusting. I will respond with the info when I get back home.
+1. I had this problem probably the second time I used my new setup. Clicked the z-down button a few times, nothing… then the bit crashed into the piece top. Fortunately I was hovering (since this was a new setup) and I quickly hit the kill switch. Hasn’t happened again, but I’ve experienced this same issue.
You are talking about the delay before gSender switches into continuous movement mode. While this is an important setting, this was not the issue for me. I had already increased the delay time.