Slb testing mode?

SuperLongBoard šŸ“–Docs
1

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

2

@wiremonkey just to remind me, youā€™ve got the SLB EXT from the AltMill right?

4

Yes, the SLB EXT.
Thanks!

5

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

6

I have an alarm 10 that I canā€™t clear. Nothing connected to board but the e-stop unit and power.

7

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.

8

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.

9

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

10

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ā€¦

11

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

12

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?

13

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
    image
    image776Ɨ186 21.8 KB
  • 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 :+1:

14

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!

15

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 :muscle:

16

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.

Screenshot-1
Screenshot-11039Ɨ752 55.8 KB

17

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

  1. Plug in the USB device.
  2. Open a terminal and list all connected USB devices:

lsusb

  1. 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

  1. Create a new udev rule file in the /etc/udev/rules.d/ directory. You can name it something like 99-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"
  1. This rule sets the permissions of the device to 0660 and assigns it to the plugdev group.

Step 3: Add Your User to the plugdev Group

  1. Add your user to the plugdev group:

sudo usermod -aG plugdev $USER

  1. Log out and log back in to apply the group changes.

Step 4: Reload udev Rules

  1. Reload the udev rules to apply the changes:

sudo udevadm control --reload-rules sudo udevadm trigger

Step 5: Verify Permissions

  1. Unplug and replug the USB device.
  2. Check the device permissions to ensure they have been set correctly:

ls -l /dev/bus/usb/001/002

  1. 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
18

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
19

@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