I have run into an odd issue and am wondering if it’s me or if it’s gSender (ver 1.5.3)
I was doing a lot of surfacing of stock today. I had set up for 0.5 mm depth to a maximum of 5 mm. The idea was to run the job until the entire surface was at the same height and then hit the stop key to interrupt the surfacing operation.
Of course when you click on ‘stop’, the machine stops and faults out. You are supposed to unlock it by clicking on the lock notice (I don’t have the screen in front of me so I can’t be more specific)
Anyway, today about half of the unlock operations didn’t go as planned - the mill would not unlock. I had one instance where it took about 5 minutes before the machine became responsive again (lots of hitting the unlock button on the screen)
It’s only mildly annoying if I have to click a couple of times but today I was very close to restarting the computer because it just wouldn’t unlock the mill …. it eventually did.
Anyway, I am curious if other people had this experience?
Did some more surfacing this morning and one run required more than 10 (I stopped counting) clicks on the unlock button. I eventually gave up and did another quick task. When I came back the mill was unlocked. I am now thinking that maybe the computer is just exceedingly slow especially considering that there is a noticeable lag between hitting a key and the mill doing the task. This is mostly based on jogging - it probably takes about 3/4 of a second to move the gantry after hitting a jog key.
Later on today I am going to reboot the computer to see if this is maybe windoze doing it’s windoze thing (I hate Microcrap)
@Jens, what CNC are you having this issue on? For machines running the SLB-EXT like the AltMill and LongMill Closed Loop kit the unlocking procedure takes longer due to a physical switch that has to latch in the electronics box so I’m curious if that’s what you’re seeing
I have an Altmill. No, the delay has nothing to do with any physical switch that might take half a second to latch. I have had many issues with the system going to ‘LaLa’ land. Recovering from an error condition is one of the issues but there are others.
I have a gControl computer running gSender 1.5.3 to control the Altmill. BTW, I have not upgraded to the various versions of gSender because things were working well enough (relatively speaking) and because it’s VERY annoying having to remember how to enable screen blanking every time gSender is upgraded (this is a hint/upgrade request). Anyway, to give an example of the delay issues I run into, I was working with the mill yesterday and it required numerous files to be loaded. Maybe 10 or so files were involved. In three cases I would click on ‘load file’, the directory listing would come up, I would double click on the file desired and nothing happened. clicking on the file again or clicking on ‘open’ would freeze the screen. In these cases it takes (in one instance) about 50 (!!!) seconds for the locked up directory window to go away and the file to show up in the visualizer. When I say ‘freeze’ in these situations, it’s not really a freeze as I can still move the mouse cursor but gSender was non-responsive otherwise.
I have gotten used to the issue of the system going on ‘vacation’ in many different situations. Error conditions are more variable in terms of how long it takes to recover but loading a file is pretty consistent about the time it takes for things to unlock. In all instances, a good portion of the operations happen without lockup (maybe 80% as a wild guess).
I have a feeling that the issue of the mill shooting well past it’s desired movement (ie when stepping the spindle down to set Z zero) is also related to whatever is causing these delays. I no longer try stepping down the spindle towards my Auto Zero plate - instead I set up the plate to locate the x and y position in the appropriate location, remove the Auto Zero plate, step down the spindle to a position that put’s it into the range required for probing, I re-install the Auto Zero plate and then proceed with probing. I have lost a few mills / drills when a 0.5 mm step turns into a 25 mm (or so it seems) step. If the Auto Zero plate is not present, the tool just buries itself in the work piece or spoil board but if the plate is present and I have a small tool mounted, the tool will get destroyed.
Sorry if this all sounds like a ‘war and peace’ kind of novel but it is very frustrating and it happens intermittently. I have no idea if it is related to gControl or gSender or possibly Windoze. I intend to upgrade gSender to 1.6.0 when released to see if that changes anything and if it doesn’t I will try a different computer. Beyond that I will just have to put up with things as I can’t say to you ‘here is the issue’ - if you can’t see it you can’t fix it.
I have read many of the problems you have and feel bad for you every time I see you have written another psalm to your book of rants. Every time I run into a minor problem with my setup, I will sit at my machine, read a psalm from the book of Jens and thank the all-cncer that I am the fortunate one (even though i am not a senators son.)
I do often speculate that your setup is relying on hardware that was never intended to be used as a cnc controller in the first place but especially, that it was never intended to be on all the time. Think of it, the gcontrol is a pc/tablet intended to be used in a restaurant for costumers to order food on. (At least, that is what I remember was said about it in a blog post somewhere.) That aint no high end machine, because you need no high end machine for that purpose. It does not surprise me that running a glorified pizza menu for days, weeks and months in a row has it running into weird problems. It is not a high end server rack running software that has a maintenance cycle to clean up memory and flash buildups. Heck, even my cctv recorder has a reboot cycle every week to make sure it does not run into problems, and that thing is intended to run 24/7. (And does not run the dreaded windoze you hate so much but a dedicated os, prolly based on linux.)
I speculate that if you, as an experiment, shut down the gcontrol after use and restart it when needed, you might find your problems starting to disappear. I know you don’t want it like that, but it’s an experiment that takes no further investment to generate data. If you are suddenly finding yourself having a machine that works without or with less hickups then when you keep it on, you can focus on investing into a known direction. Hardware that is intended to handle what you are asking of it.
Just my pizza slice with pepperoni and mozzarella.
I believe you are correct re this being a restaurant POS terminal … but then it’s been said that gSender is not resource intensive (and I upgraded the memory just in case).
I feel another psalm is coming down the line …
I agree that an occasional reboot is a good thing on a windoze box and even occasionally on a Linux box. Where I disagree is in the suggestion that my issues are possibly reboot related.
The reason I disagree is that in every case I can remember where a reboot was required, the problem was a “it’s broken, let’s reboot type problem”. It’s never a situation where everything works fine, then things go south only to return to normal a little while later. While I am typing this it does however occur to me there is one critical thing that is different in my setup - the gControl computer is blocked from going out to the internet. Only local traffic is allowed to retrieve .nc files for cutting. It is normal for a computer to appear locked up if it attempts to grab some data from the internet and can’t do so only to time out after a short while. I had never thought about this before and this is something I can try to investigate by looking at my server logs. It would be reasonable for example to suggest that windoze tries to report to the mothership on a regular basis and, if the conditions are just right, it sits there waiting for an answer. It would not show up if the computer just sits there idling and it’s unlikely to show up while gControl or gSender are running a file because there is a certain amount of cutting data that is buffered.
A quick look at the logs confirm that the gControl/windoze computer does actually try and talk to the internet on an extremely frequent basis. I can easily see windoze sensing that it is connected to a network and trying to talk to the mothership. This would not happen if there is no network connection. Heck, since when I grab a .nc file it comes from a server computer, maybe that wireless link has to retry several times. An interesting test would be to transfer ,nc files via USB stick and shut down the ethernet link to the network.
Anyway, this opens up a whole new can of worms that need to be investigated …
As a side note, I find it repulsive to have a pizza with just sauce, cheese and pepperoni. My taste calls for the kitchen sink!
@Jens I’m looking forward to the results of your network tests. It would not surprise me if it was partly responsible for the issues you are having. I wonder if gSender makes internet calls as well.
I’m really starting to dislike Windows. Windows 10 was sort of ok but I really hate Windows 11 Home edition, and that for a multitude of reasons. And I’m not a big Apple fan either. My next computer might just be Linux. At least the gControl came with Windows 11 IOT.
Although the loading of files problem is intermittent, I am optimistic that I have found the problem. Grabbing the files off a local USB stick seems to be much snappier and in my brief loading tests I had no issues!
The hesitation of clearing errors is still there to some degree but I didn’t test that issue thoroughly enough.
As a side comment, it is also quite possible that, since I was using WIFI for connectivity for grabbing files, that my signal level was marginal and thus requiring re-loads from the OS. My next test, if I get around to it, will be to set up a hard line to the gControl computer to see what happens if I grab files that way. Maybe it was all about the WIFI . I would also like t point out that getting a directory listing prior to loading a file always worked (suggesting that the WIFI signal should have been strong enough)
Soooo … loaded some more files onto my USB stick, went to the mill and noticed that the status had changed to ‘disconnected’. Click on ‘Connect’ and I see two ports - USB and ethernet. I click on ethernet, and gSender responds with a new ‘connect’ prompt while the status is still ‘disconnected’. I click on connect again but this time I choose the USB port. GSender behaves as if it was connected but the center top status bar still shows ‘Disconnected’.
I tried re-loading gSender - no change.
Tried rebooting gControl - no change.
Power cycled the SLB-EXT - system came back on line.
Our clan is the first and only clan occupying this house so there is no chance of some restless spirit roaming around …
BTW, this has happened before but thankfully it is fairly rare.
I can confirm that the issue of loading a cut file seems definitely fixed by hosting the file locally (USB drive) I have run around 30 (give or take) tool paths (separate files) today without a hiccup.
I can also confirm that the occasional issues with clearing alarm/error conditions still exists. Hopefully 1.6.0 will fix that once it gets released.
