OK, well my turn for random (in fact, very random) Error 10 message. Two month old 4x4 AltMill been working flawlessly until the last project. I understand that this is in general an E-Stop error. I’ll be spending some time today trying to hunt this down but a couple quick questions. First, should I be looking anywhere other than the E-Stop button (wiring, etc. ) and, second, is the E-Stop button from a standard SLB interchangeable with the E-Stop on the SLB-EXT. I have an SLB that I can scavenge the E-Stop from if that is an option. Thanks
yes and yes (with 99.9% certainty)
To give more suggestions on 1, we need more detail
Most likely an issue with the inductive sensors (i.e. not set properly), or you are exceeding the limits of the machine.
For #1, the z sensor is especially a frequent issue for users who have set the sensor too far back.
For #2, this can happen during a project if your gcode has movements that exceeded the limits. For example, if you are using a long clearing bit (which requires your spindle to be higher up) and you have a safe height that will move the spindle even higher. This could trigger an Alarm 10.
But as Jens has said, more info is required. If you are able to consistently home your machine, then I’d say it is a scenario closer to #2.
Thanks for the responses. I guess I would have to say that having successfully run hundreds of individual toolpaths since setting up my AltMill and prior to the onset of this seemingly random occurrence of the Number 10 errors I’m pretty sure this is not an issues with inductive sensors being set improperly. The most recent toolpath in which I had the problem repeat three times was a laser etching toolpath with no Z movements that was confined to a small area of the bigger project well within the X and Y limits. As such I have a difficult time reconciling the recurring problems to either an improperly set sensor or a limits issue. I guess I would also ask why a limits issue would throw a number 10 error and not a number 1 or 2 error. All of the documentation I have seen indicates that a 10 error is an issue with the E-Stop being asserted either intentionally or through some sort of fault.
Please verify that nuts holding the sensors are still tight. Not that I think that this is causing your problem but it only takes a minute and I have had one of my axis sensor nuts loosen up.
1 Like
@martindg I can’t answer your specific questions but I am currently running a multi-step job over several days and all of a sudden, for a new toolpath, I started getting alarm 10. I wasn’t sure what caused it but homing resolved the issue. It wasn’t because of any limits.
You’re probably right about Alarm 2 vs 10. I get both frequently enough that I don’t really pay attention to them. But the problem is usually limits-related or fixed by homing.
Are you getting this random error before you run the toolpath or is it occurring in the middle of the job?
There are both Alarm and Error codes. It seems to me that some responses are about Alarm 10 (soft limit related) while you said Error 10 (e-stop related). I just got mixed up on the two recently in another thread.
EDIT: I flipped them again in my head but this thread still mentions both so we should clarify which one you had/have!
Alarm 10 : E-stop asserted. Clear and reset. Untwist your E-stop.
Error 10: Homing not enabled. Soft limits cannot be enabled without homing also enabled.
1 Like
Yeah I guess I missed that there are both Alarm codes and Error codes that share numbers. Seems like a very confusing way to do this. I think that the console message was Alarm 10 and not Error 10 but I guess I’ll have to fire the machine up and look at the log to see what it says…..
So, looking at the Alarms pane on the Stats page it clearly shows Alarm 10. SO i’m pretty sure this is a E-stop related issue?
As an aside, I notice that the Alarms pane shows only 4 alarms over the last few three days. I would think there should be more alarms listed in this pane over a longer period of time. I don’t believe that I have intentionally cleared the Alarm listing so how far back should the list go and is there an alternative log file someplace that would have amore extensive Alarm history?
So update for anyone interested…before Christmas I went through the full troubleshooting steps provided by Sienci Support for this type of issue. The results suggested that there was a possible issue with the power connection port on the SLB for the cable that was connected to the Y1 mother. I reseated all the cables and ran a short project and it seemed to work without the Error 10/Y1 motor error stoppage. I was cautiosly optimistic that the problem was solved but I then shut down for the holidays. Back in the shop yesterday running a new order (3D carve with laser etching on top of the carved area) and sure enough the stoppage occured again - same Y1 error message with a report that the E-Stop had been asserted even though iot hadn’t). This occured during the laser etching run and what happens is the motors halt all movement on the alarm but the cuttting tool is not stopped. IN this case it was a laser etching so as the laser did not turn off I burned a nice hole into the project. After some ridiculous toolpathing gymnastics I was able to salvage the project. Unfortunateloy I have a second order that involves a much larger 5 hour 3D carve with a 3 hour laser etching over the carve, My machine is 3 months old but I am at a point where I do not believe that it is reliable enough to undertake this project. Frustration is turning over to anger.
As I went back and reviewed the exchange with support what I was told was that if the problem occurred again they were going to ask me to disconnect everything from the SLB, remove the board from the housing and take pictures of the solder joints and send it to them so they could try to determine whether there was a compromise of any of the solder connection on the motor power supply ports. I got back in touch with support late yesterday and as of yet have heard nothing back from them. Frustration turning more over to anger. A 3 month old machine in which their own trouble shooting process points to an issue with the SLB and instead of simply providing a replacement SLB they want me to tear it apart to see if there is an issue (that may or may not be obvious from a photo) with the manufacturing process of the board itself. Needless to say I’m not too keen on this plan. I need to get back to work and not continue going round and round while they resist doing the right thing. As such, I simply ordered a replacement SLB-EXT in the hopes that this will get me back up and running. Thus, as support is seemingly not willing to make this right on a 3 month old machine I’m out an additional $200 to try to get back up and running.
A year ago I converted my old OneFinity by adding an SLB and a gControl computer. I was extremely happy with this setup. So much so that I upgraded to a 4x4 AltMill. Now, I have a $3500 machine that is unreliable and I’m spending additional money to try to get it functional. Sorry for the rant, for what its worth, but as mentioned my frustration is definitety turning over to anger. I suppose there’s a good chance someone will tell me why my take is incorrect
@martindg I’m certainly not going to tell you that your take is incorrect.
However, one thing that you’ve said puzzles me. You said that, when all movement stopped, the laser continued to fire, ruining the piece. In laser mode, this should not happen - ever. When the machine stops moving in X and Y, or when the machine is doing G0 fast moves, the laser should be off.
I know that the last thing that you need is to look for more issues, but you really should look at this one.
I am surprised that Sienci did not offer a replacement controller. I had a controller issue and it was surprisingly straight forward to have a replacement sent out.
I would suggest that, especially if the new controller fixes things, you contact support and request that you return the dud controller for a full refund of what the replacement cost (including freight)
I run the laser in the laser mode ($31) so when all is working correctly the laser fires only during ‘cutting’ moves and not during rapids. It stops when the toolpath ends (M5) so all is working as it should. The fact that the laser doesn’t stop (and the spindle doesn’t when I’m in spindle mode) with this error situation is part of the problem. Of course, this shouldn’t be occurring but it is so I need this as part of the problem resolution
Thanks Jens. I’m a bit surprised that I’m having this issue. I hope they do right and issue my refund but I guess we’ll see.
@martindg It’s likely just a typo, but laser mode is $32. In laser mode, the value is 1.
1 Like
Try running that troublesome program after changing the Junction deviation setting.
On the console type: $11=0.005 then hit the run button….. or navigate to config: more settings: Junction deviation and change the value to 0.005 and save settings.
Power cycle the SLB off then on, Home the machine and let her rip! that setting change will reduce the jerkiness of the axis during small tight direction change moves. It will add about a minute more of run time to a previous 15 minute cycle time program