Hi All, Just started using my OozNest (SPAM) 1010 for which I am using the BlackBox controller. Everything seems to be working correctly apart from 'Continuous' jogging. Most of the time this works correctly, but just once in a while the continuous jogging gets stuck. This happens mostly on the Y-axis but has also happened with the Z-axis once. What happens is, I jog the Y-axis in continuous, but when I release the jog button the axis continues to jog. To cancel it I click the opposite jog direction button and sanity is restored. I will try and diagnose this further, but due to it's seemingly random nature, I'm not sure how long this would take. From what I can recall, it seems to occur when doing a longer jog rather than just nudging the axes around. Just wondered if anyone else has found this?
Very old bug. Dont click too fast or use Incremental See Keyboard Jog Bug · Issue #73 · OpenBuilds/OpenBuilds-CONTROL
Thanks for the reply. I am currently using the mouse to control the jog movements, I might try using the keyboard instead to see if this solves it. I'll post a reply if I manage to find out more.
Bug applies to both. Clicking too fast or pressing keyboard too fast between moves. We are still unsure of the root cause of the bug, but working a little slower, or switching to Incremental mode, both resolves it
Just a quick progress update. I tested the build 1.0.256 this afternoon and found that I couldn't repeat the sticking jog problem with this version. I noted that when releasing the mouse button / key and quickly clicking it again to continue the jog results in no jog, which, for me is preferable to the jog sticking. I am doing some tramming / tuning of the setup tomorrow, so will test this further, but these early results seem favourable. Thank you for the prompt solution .
Had a good day yesterday, got everything trammed up and cut the first 3D part which performed very well. I did have one occurrence of the Y-axis jog not releasing, but was focussing on other things so don't recall what steps lead up to this occurring. I'll attempt to do some more testing of this next time. Are there any log files created by the BlackBox unit?
Just the Serial Log tab in CONTROL. I had to switch gears last week, will try revisiting this bug next week - sorry!
There's no apology required. I really appreciate that you are on the case and am sure that it will get resolved. If there is any testing that you would like me to do I am happy to assist. I am planning on running / testing the OpenBuilds Control on a Raspberry Pi so can (hopefully) test it with this also if this would help?
1.0.257 should be coming down with automatic updates later on today I changed the behaviour just a little more, instead of just checking that we are not in JOG already, before sending the jog message, we are now checking that you are indeed Idle before sending the new move. That ensures a) that there aren't extra jog commands in the queue that can cause a runaway, and b) as it wait for the machine to come to a stop, we can more accurately calculate the allowed move distance that won't hit soft-limits Give it a go, hopefully another step further Full changelog here: OpenBuilds/OpenBuilds-CONTROL
That all seems logical. I'm hoping to get down to the machine tomorrow so will give it a go and will let you know the results. Thanks again for your prompt help
I managed to get down to the machine today, cutting a sign for a friend. I did have two jog runaways, both on the Y-axis. I couldn't reliably repeat the problem......... However, I did find that pressing any of the mouse buttons (left / right / wheel) initiates the jog which wasn't what I was expecting. Is this intended behaviour? I would have expected that the left mouse button would be the primary for this? I will keep exploring this issue and will report back with any relevant findings.
Fixed in an upcoming version though that would not be the cause of the runaway When you are getting the runaway condition: - Using mouse or keyboard? - If its mouse, any chance you are moving the cursor off the button before releasing? That's the only failure I could replicate so far in new version, moving off the button before releasing the mouse means the MouseUp event is caught by some other element than the button. I have testing code in an upcoming version that catches the mouseUp event in the whole window and "if" a jog is running, sends cancel. So just keep an eye out on the version you are on, maybe that is what is what was happening to you?
I am mostly using the mouse for jogging and the runaway has only occurred (for me) when using the mouse. I will test the 'mouse button release' event when I next get a chance. I haven't intentionally done this but it is possible that this may be something that I am inadvertantly doing.
Sounds plausable then - looking at the machine one can easily drift off the button - if thats what causes the runaways, the fix is going to be easy
I am just testing the problem now and can confirm that your diagnosis of the problem is spot on. When I click the jog button using the mouse and move the cursor away from the button before releasing it, the jog continues until the button is clicked again
Fantastic! (; that's maybe part of why it took so long to find the issue - when we test - its those little human nature things that doesn't show up so easily. I really appreciate all your help on the testing side 1.0.262/3 somewhere around there (couple internal testing versions in between) is scheduled for release around/just after this weekend - I've included the fix
It's my pleasure. Thanks for finding a quick resolution. I wasn't too worried about an X/Y axis runaway because these are easy to catch.....it was a Z-axis runaway which was my main concern.
Just a quick update, I've tested the latest secret build version today and the jog problem when using the mouse is solved
Glad its sorted finally Will publicly release the fix soon (just waiting on some unrelated internal release info)
Sorry to wake up an old thread, but I still experience this mouse problem, and I'm on the latest release.. Is the fix public yet?
Is this a wireless mouse? I have had weird button sticking problems with 2 different wireless mice, a Microsoft and a Genius, absolutely no problems with a wired mouse. In fact I still get the sticking problem with the Microsoft wireless mouse on this PC, especially noticable when playing CS:GO when the gun keeps firing after I release the button. This is not a physical button issue but rather a mouse software issue where it does not release unless the mouse is moving in just the right way.
I had wireless mice & keyboard issues for a while... either the mouse/keys wouldn't work, or they'd work, then stick, and it was because of some sort of electrical interference with the wireless dongle. I solved it by plugging a 6" USB extension into the computer, then the dongle into the extension. I haven't had a single issue since then. Likely not related, but mentioning just in case...
