I’m heading on vacation and want to take the SLB along with me to get familiarized with it and do some testing without stepper drivers connected. What settings should I change to eliminate the “MSG:Warning: Motor Error on X Axis!” ALARM 10 I’m seeing at power up?
I’d like to be allowed to make “ghost” stepper moves without drivers connected. Is this possible? What settings do I have to change?
Thank you
@wiremonkey just to remind me, you’ve got the SLB EXT from the AltMill right?
Yes, the SLB EXT.
Thanks!
Are you getting this alarm with the motor plugged in or unplugged? From my end it seems like you should be able to unplug everything and run the board just fine with the Power supply and USB
I have an alarm 10 that I can’t clear. Nothing connected to board but the e-stop unit and power.
Tried flashing to SLB_EST_B5.0.11.hex using gsender and got error, put board in dfu mode. I issued $dfu and tried again. No luck.
Ah, OK. This brings me back to my other question. How can I clear the alarm when I have nothing connected to the board? I’m in a bit of a catch 22 unless I connect up all the steppers, limit switchs, etc? Unless you have a way that I can clear this alarm 10?
I’m thinking that if homing and hard limits are disabled I wouldn’t be getting alarm 10 upon connection?
Sorry, I know I’m proposing something unusual. I’m sure most folks would have already connected the SLB up to their mill…
I think the only way around having to hook everything up would be to create a hex file with homing and hard limits turned off, and whatever else might trigger this alarm, and use STM Cube Programmer to flash.
When you power on the board, are you pressing in the E-stop, unpressing it, then clicking the ‘Unlock’ button in gSender? For the SLB EXT you need to follow this process every time for safety purposes
Just to note, reflashing might still not address the issue since the Firmware settings can be stored separately in EEPROM - so unless you fully wipe the board before flashing then settings may still remain. Otherwise what you’re talking about could work, but in this case I don’t think there’s any hardware you have set up or settings configured that should be locking your machine out of regular operation
By the way, what you’re asking to do is completely doable - at our office we all have SLBs and LongBoards at our desks with just power supply and E-stop hooked up and that’s what we use to help people troubleshoot simple problems without being next to a whole machine. It’s definitely much more rare for other board users to do this setup but it’s still done on occasion
OK, so here’s what I’ve learned after a few hours of playing around with a Teensy 4.1, SLB, gsender and bCNC. on an Ubuntu PC.
- With bCNC and SLB combo, when I change a setting via console and $ command, settings remain after a power cycle. Nice! You should look into why this doesn’t work in gsender.
- I was able to invert all pins so that there were no input errors by setting $14=73. Nice!
- I was able to connect to Teensy, load a hex file and no alarm.
- I cannot clear Alarm 10 on SLB no matter what I do: with e-stop depressed, let up, disconnected, nothing changes.
I’d love to see settings list for your people using a power only SLB for phone support. There is something that I’m missing in the settings and now that I can use bCNC to permanently change things…
Perhaps there’s more here that I’m missing:
- SLB should be able to unlock by power on → press E-stop → Unpress → click red unlock button in gSender
- The settings we use for testing at the desk is the exact same as what’s shipped by default with all boards, no other modifications required. All these values appear in gSenders Firmware tool when you select the AltMill profile on the dropdown list, you can also find them all here gsender/src/app/containers/Firmware/eepromFiles/Altmill.js at master · Sienci-Labs/gsender · GitHub
- I’m not sure how you got a value of $14=73 unless that’s a typo since the default values for $14 should be =14 and the max value it should have if everything is inverted is 31
- I don’t think I understand where the Teensy factors into this testing
Happy to keep working with you as I can, I know you’re trying to prep this on time for a trip and this is certainly a unique puzzle
Hi Chris, No luck unlocking. I found $14=73 in a forum somewhere. I’ll try 31. I’m not sure I understand how to calculate the bits…
I was using the Teensy as a control. In other words, I’m able to operate the Teensy via gsender as a test, no alarms, nothing connected. I cannot seem to achieve this with the SLB. In fact, I’d love to just do a fresh wipe of firmware, but I can’t. I’ve tried using STM 32, but no dfu mode is possible, even after powering up with boot pins shorted. gsender won’t allow me to update firmware. I suppose it’s possible there is an issue with my linux config and that USB port or the driver?
That could be the case… are you following the guide here? Firmware & Flashing - SuperLongBoard
It could be more risky if the driver isn’t working, but while connected over STM you could click the button to do a “Full Chip Erase” before then loading the full firmware back in
I see now, you’re using the Teensy as a point to test against. I mean worst case scenario if nothing else we can ship a new board out to you, which is probably what you’ve already heard on the ticket you sent in. I can’t think of any other obvious things to check and once they start to become less obvious solving issues over email gets easier since we can send back and forth videos and diagnostics files.
For reference, the way the bits calculation works is binary to decimal conversion (by the way this applies to any other SLB or LongBoard setting):
- For $14 there are 5 items to invert: Reset, Feed hold, Cycle start, Safety door, and E-stop
- Those are listed in order of the bits they use, so reset uses the first bit, Feed hold the second, etc.
- Binary bits to decimal convert in order: 1, 2, 4, 8, 16, 32, 64, etc.
- All this in mind, if you look at the default setting of bits you’ve got bit number 2, 3, and 4 turned on which would convert to 2 + 4 + 8 = 14
- If you wanted them all inverted, then you’d want them all turned on which would be 1 + 2 + 4 + 8 + 16 = 31
Though my explanation of this concept is technically wrong, I think it’s the best way to communicate how it works so let me know if that helps 
OK! I finally got it. I decided to connect the SLB to a computer running windows 10. I installed STM32 programmer and put the SLB in DFU mode by shorting the BOOT pins on startup. It took a few tried to get STM32 to connect. Then I programmed the SLB with firmware version, 5.0.5. Finally, a blue light on the SLB and it is no longer locked and alarmed out.
For the life of me, I don’t know what the issue was. Maybe the firmware was corrupted?
Anyway, we’ll mark this as solved. I hope this helps someone if they have the same issue.
Phew!
Whew! I’m so glad we’ve passed this plateau! Hard to say what could’ve happened. If you’ve got the board to run the AltMill I’d advise that you load up the 5.0.11 firmware when you go to use it since the 5.0.5 is only supposed to work properly for the regular SLB.
I can’t speak to where things went wrong since it seems like perhaps STM’s flasher or maybe Linux USB driver or something was off and preventing proper flashing? I’m also still interested to why you were finding that bCNC could change firmware while alarmed, meanwhile gSender couldn’t since that seems odd to me.
Forward momentum is amazing 
Yeah,
So strange that I could change settings in bCNC, but not in gsender. Again, it was alarmed out, with alarm 10, nothing I could do to unlock it, even cycling e-stop, etc. I thought I was going crazy until I finally got the firmware reloaded and was able to unlock it after an e-stop cycle.
I see, I’ll load up 5.0.11 now and see if we’re still in the green. Also, I’ll see if I can flash from gsender in Linux. If I drop down the menu in firmware and choose Altmill 48x48, this will load 5.0.11?
Yes, I think something is fishy with Ubuntu. When I try to flash using gsender, I get the following.
OK, I finally was able to flash firmware via gsender from Ubuntu box. It was definitely a USB rights issue, which I don’t fully understand. My Linux knowledge is lacking.
Here is the website I found: LIBUSB_ERROR_ACCESS · Issue #302 · node-usb/node-usb · GitHub
And here are the steps from that page that I followed to get it to work. There are still errors when flashing, but it does flash!
Step 1: Identify the USB Device
- Plug in the USB device.
- Open a terminal and list all connected USB devices:
lsusb
- Note the vendor ID and product ID of the USB device. The output will look something like this:
Bus 001 Device 002: ID 1234:5678 Sample USB Device
Here, 1234 is the vendor ID and 5678 is the product ID.
Step 2: Create a udev Rule
- Create a new
udevrule file in the/etc/udev/rules.d/directory. You can name it something like99-usb.rules:
sudo nano /etc/udev/rules.d/99-usb.rules
Add the following line to the file, replacing 1234 with your vendor ID and 5678 with your product ID:
SUBSYSTEM=="usb", ATTR{idVendor}=="1234", ATTR{idProduct}=="5678", MODE="0660", GROUP="plugdev"
- This rule sets the permissions of the device to
0660and assigns it to theplugdevgroup.
Step 3: Add Your User to the plugdev Group
- Add your user to the
plugdevgroup:
sudo usermod -aG plugdev $USER
- Log out and log back in to apply the group changes.
Step 4: Reload udev Rules
- Reload the
udevrules to apply the changes:
sudo udevadm control --reload-rules sudo udevadm trigger
Step 5: Verify Permissions
- Unplug and replug the USB device.
- Check the device permissions to ensure they have been set correctly:
ls -l /dev/bus/usb/001/002
- The exact path may vary; adjust it according to your system.
After completing these steps, your user should have access to the USB device without needing sudo. If you still encounter issues, make sure that no other kernel drivers are conflicting with the device access.
I hope this helps someone who is trying to use the SLB on an UBUNTU box. If anyone has more info, please chime in.
1 Like
OK, and finally I was able to flash firmware in UBUNTU with no errors from gsender after issuing the following in terminal:
sudo chmod -R 777 /dev/bus/usb/
I don’t know if this would have worked without doing the previous steps or not.
1 Like
@wiremonkey amazing that you linked through this process and managed to get it all working!
If you have a moment, could you read through the new section I added to the resources regarding this issue and let me know if there’s anything important I missed? Hopefully if anyone else runs into the same issue they can either report the instructions as incomplete or verify that they worked for them as well