I am not expecting a solution to the following but thought I would post it here as a matter of record ….
Today I was running a lengthy surfacing operation. The operation finished fine and gSender seemed to be ready for it’s next command. I needed the gantry to go to the far left corner to free up the work I had just finished. I hit the button to move the gantry but nothing happened. I hit the button a few more times but no joy. I decided to do some brushing off the surface of the mill table when all of a sudden, after maybe 30-60 seconds the mill came alive and the gantry went were I had previously commanded it to go.
My first reaction when the mill didn’t respond to the move command was that the weird freezing of the computer was back (it hadn’t done it in a while and I thought that 1.5.3 had fixed the issue). I had fully intended to reboot the computer after I had finished my house cleaning.
I am now wondering if my earlier problems were also caused by this delay issue but I just didn’t wait long enough for the computer to catch up (or finish twiddling it’s thumbs). Since I didn’t expect the computer to come back from LaLa land, I didn’t pay too much attention to things but there is a good chance it behaved as it did when the problem first came up - the cursor moves as it should but there is no reaction to any click event in the gSender screen. Previously the main screen was still accepting input so it was only gSender that appeared frozen.
Anyway, the nature of this thing is so intermittent and weird that I suspect that the issue will only be found by accident.
You might not expect a solution, and you’re prolly right on not getting one.. here. But this weird thing you have going is not something I would brush off as a meh. (And I pretty much "Meh” at anything the universe throws at me.)
Delays in movement with a unit as powerfull as an Altmill (or any other unit) that take that much time to implement become down right dangerous and should be researched and eliminated.
@Jens I would tend to agree with @Spamming_Eddie . What if, after nothing is responding to the commands you send, you stick your hand or other body part anywhere inside the mill, it suddenly starts moving at high speed?
That’s a potentially serious accident right there.
If you have a spare, the easiest thing to try would be to simply swap out the computer. Depending on the OS, that might be the next logical step anyways. Windows 10 will soon be out of support.
@Jens OK, thanks. I imagine that you know this as it has come up many times here, but be sure that all power saving settings in windows related to USB are turned OFF. Things can get freaky when Windows is allowed to play with the power going to USB ports.
Thank you for mentioning the power settings but the issue is definitively not related.
The gControl is configured as it was when shipped from Sienci with the exception that screen blanking has been enabled so I can leave the computer on 24/7 and not burn in the screen. It only affects blanking and is not a situation were windoze shuts down the USB port.
As mentioned, gControl had just finished a job, appeared to be ready for input (ie I believe the status was ‘idle’), the screen was not blanked. At the time, gSender did not appear to accept input. It appeared to be crashed (or, as it turned out, it apparently was busy contemplating life and accepted the input and put it in the queue for stuff to do)
I will keep my eye out for the next time there is a substantial delay to see if I can glean more details.
Not that this is the cause of your problems but is there any reason you are not connected with Ethernet? Eth has better error detection than USB. And since your gControl is likely near you SLB, all you need is a cat5/6 cable between the two.
FWIW, I did this to myself while tuning the RCATC toolchange macro to work with the AutoDustBoot. Somehow, my brain and fingers weren’t communicating with my eyes, and what I thought was a short pause
G4 P0.100 ; 100mS DWELL
got entered on the web tool as
G4 P100 ; 1m40s DWELL
(Of course, I didn’t have those useful comments in my macro code!)
Whenever I initiated a toolchange (M6T#), the Altmill would start the toolchange, then freeze. Nothing I did in the MDI seemed to do anything, the movement controls on the screen didn’t do anything…
… until almost 2 minutes had passed, at which time @#%^$&^$*& the machine sprang to life and, well, it is good that the E-Stop button worked!
The 2nd time I tried debugging this, I noticed the STOP button on the screen was lit up - and pressing it aborted the overlong DWELL command.
I don’t have a clue as to if or where a malformed DWELL might be getting inserted in the surfacing sub program created by gSender, but the behavior sure sounds like what I did to myself.
If you are using windows check if virus checker was running as I’ve had issues with Gsender and then found out the virus checker was running I now turn virus checker off until finished. It might not be the problem but I would check anyway. Good luck
I was having this issue Jens and of coarse right away i down loaded a bunch of apps/programs when i got my machine and and g-sender. Well lots of of them started automatically when it started. using up a bunch of the little bit of ram we got with it. i Upgraded my memory and have not had a issue since. By no means am i a expert but gave it a try and it worked for me.
I was actually wondering if RAM could be an issue. The reason I didn’t upgrade is because all I have running on the gControl is gSender and that is it. It’s also isolated from the outside internet to prevent any ‘upgrades’. I do have an internet connection to allow access to a shared drive where my CAM program deposits files.
Since Sienci pushes the idea that gSender is very light weight, I decided that a RAM upgrade couldn’t possibly be an issue. Funny thing though - I actually have a RAM module on hand. It was installed in my first gControl which was replaced fairly early on and was never installed in the replacement.
I will go ahead and install the upgrade to see if it makes a difference.
While I am at it, I should really research how to disable the virus checker that causes the ridiculously long startup time.
As it turns out, turning off the antivirus system saves about 10 seconds (out of 30 sec) on the initial startup of gSender. It does not change the startup time if gSender was closed and then opened again.
Although it is an improvement, it’s nothing worth writing home about and not worth the concern of having switched defender off completely.
Funny thing is, startup time has been as fast as 5 seconds and as slow as 20 seconds on the second startup of gSender.
Just for the luls of it (its weekend, lets do weird stuff) what happens when you.. like… turn off the device let it rest for a beer and turn it back on.
I leave my tablet (not windows, mind you) on for months at a time without fresh starts.. untill it just cant cope anymore and even shutting off is something it can’t fully comprehend anymore.
At that time it has slowed down like thick sirop trying to stream up a mountain.
Windows might not fare much better, after weeks or months constant up time.
I tried that when the problem first showed up (first thing I did actually) but it did not resolve the issue.
I have not yet tested to see if the delay after running a job has improved. That is a bit of a subjective call and there isn’t a hard and fast “yep, it’s much better” kind of test.
