Manually Building SuperLongBoard STM32F412

[siganberg]

Since the SuperLongBoard is not yet available in Web Builder, I'm trying to build firmware for the LongBoard32, but I can't seem to get it working, and I keep encountering errors.

So far, I have created an entry in the platformio.ini file:

[env:f412vg_SLB]
board = genericSTM32F412VG
custom_prog_version = SLB
board_build.ldscript = STM32F412VGTX_FLASH.ld
build_flags = ${common.build_flags} 
  -D BOARD_LONGBOARD32=1
  -D SLB_EEPROM_ENABLE=1
  -D SIENCI_LASER_PWM=1
  -D SDCARD_ENABLE=2 
  -D _VOLUMES=1  
lib_deps = ${common.lib_deps}
  FatFs
  eeprom
lib_extra_dirs = ${common.lib_extra_dirs}  
upload_protocol = stlink

I also added an entry in driver.json:

  {
      "name": "Longboard32",
      "symbol": "BOARD_LONGBOARD32",
      "URL": "https://github.com/Sienci-Labs/SuperLongBoard",
      "MAP": "boards/longboard32_map.h",
      "caps": {
        "axes": 5,
        "auto_square": 2,
        "digital_in": 3,
        "digital_out": 4,
        "eeprom": -2,
        "fram": 0,
        "i2c": 1,
        "sdcard": 1,
        "keypad": 1,
        "pio_board": "genericSTM32F412VG",
        "ldscript": "STM32F412VGTX_FLASH.ld"
      },
      "symbols": {
          "STM32F446xx": "",
          "HAS_BOOTLOADER": ""
      }

I copied the genericSTM32F412VG.json file to the root folder. This file can be found here: (https://github.com/Sienci-Labs/sienciHAL/blob/SLB_Bringup_Dev/genericSTM32F412VG.json).

Then, I executed the following command:

pio run -e f412vg_SLB

I started with fewer plugins to have a successful build, but I keep getting errors after fixing one issue. Before going down the rabbit hole of trying to fix all the errors, I figured I'd ask if anyone has already had a successful build.

The reason I am building this is that the core of the Sienci grblHAL firmware is not up to date.

[terjeio]

Here is the platformio.ini I use to build the latest version with VSCode/PlatformIO:
Note that this build has not been verified yet!

platformio.zip

[siganberg]

Do you have the extra scripts?

extra_scripts = 
    pre:extra_script.py
    post:extra_script.py

[siganberg]

Not sure if the script is important but if I take it out, I'm getting this errors:

[terjeio]

Do you have the extra scripts?

It is found here.

Not sure if the script is important but if I take it out, I'm getting this errors:

Do you have the latest grblHAL version?

[siganberg]

The core? Yes

I manage to have successful compilation by disabling the the following. Will adding Sienci custom plugins and looking to fix those 2 flags.

 -D EVENTOUT_ENABLE=0
  -D RGB_LED_ENABLE=0

Thanks a lot for the help, really appreciate it.

[terjeio]

Will adding Sienci custom plugins and looking to fix those 2 flags.

Do a recursive pull to get the latest submodules instead, recently a new one was added for the two you disabled.

[siganberg]

Do a recursive pull to get the latest submodules instead, recently a new one was added for the two you disabled.

I already did a recursive pull but I'm still getting errors with those two flags turned ON. For now, I've kept them OFF. I'm also just adding the custom Sienci plugins they included, such as boot_entry, rgb, and probing. Anything that matches with the repo, I left as is and pulled the latest changes.

I loaded the firmware for the SLB. The issue is that the motors are not getting power after I performed a firmware reset. Restoring the SienciHal firmware brings the stepper motors back online. Before resetting, the motors had a slightly high-pitched sound when moving. I'm not sure if this is caused by the settings for the TMC2660. Setting number don't much, they are off by 1 whey I compare with SienciHal.

[terjeio]

Boot entry is part of the base driver so not needed, basic RGB support is also, with a core defined API. I have not looked into the probing plugin yet. There should be a plugins folder with the eventout and rgb plugins:

If not download and add it manually - making it generally available is still work in progress.

I loaded the firmware for the SLB. The issue is that the motors are not getting power after I performed a firmware reset.

What is your $4 setting? And M122 output?

Setting number don't much, they are off by 1 whey I compare with SienciHal.

Some SienciHal setting numbers were added without requesting them from me and they were already assigned for other purposes. So those had to change. Reloading SienciHal settings into grblHAL is thus a bad idea.

[siganberg]

Pulling the Plugins fixed the two issue with enabling EVENTOUT_ENABLE and RGB_LED_ENABLE. It's not currently added on this repo.

There is another flag STATUS_LIGHT_ENABLE which is on the rgb plugins of sienci so If take it off I also need to turn that off. Already remove the boot_entry as you suggested.

Some SienciHal setting numbers were added without requesting them from me and they were already assigned for other purposes. So those had to change. Reloading SienciHal settings into grblHAL is thus a bad idea.

I agree, that's why I'm trying to switch. :D

[siganberg]

Here's my test result.

• Homing doesn't work and freeze the board, need hard power cycle.
• Jogging doesn't update the coordinates.
• Hitting e-stop doesn't show any ALARM. Reconnecting the board then shows the ALARM 10. Resetting e-stop doesn't work or unlocking the machine ($X). Require hard reboot to continue.
• typing in the console doesn't show any response like getting value of ${parameter} or $$.

What works so far:

• Jog dial works.
• Spindle (modbus)

I'm using gSender since I don't have any other grblHal sender to try on macos.

Attaching diagnostic file from gSender which has all the firmware paramenters.

diagnostics_10-15-2024_09-53-05.pdf

[terjeio]

Homing doesn't work and freeze the board, need hard power cycle.

This has now been fixed.

The rest I am not so sure about, can you connect with a terminal and try some commands from that?
FYI I do not have a SLB with me where I am now so cannot test myself, other drivers I do have access to works as they should so you may have wait a bit for the rest to be resolved.

[siganberg]

Great! I will test it tomorrow. Will provide feedback.

IMHO, Sienci should send you one for the great work you been doing. 👍

[terjeio]

IMHO, Sienci should send you one for the great work you been doing.

I have one at home, but I am away for 3 more weeks...

[siganberg]

Try the latest. I initially still got problem with the homing so decided to do RST and start from scratch the it works. So far everything is working except for the tool set routine with my RapidChangeATC.

When I touches the tool setter, it stop and freeze the board.
https://youtu.be/h3W3Max4_Ig?si=RnjEP9GS6LAyygQp&t=58

Macro used for tool change for reference: https://github.com/greilick-industries/rcatc-scripts-grblhal/blob/main/macros/TC.macro

This one is working with sienciHal but has some other minor issue.

[terjeio]

If I run the the tool setter macro (g65p231) directly on a STM32F7xx dev board it completes correctly - so this might be an issue with the SLB. If you try to probe the toolsetter manually does it still crash?

[terjeio]

FYI I have commited some fixes to expression handling that may help if it is a hang, not a crash.

[siganberg]

Thanks @terjeio . Sorry, I haven’t had a chance to test this build—I've been busy working on my AutoDustBoot.

I heard that Chris from Sienci is working with you to integrate SienciHAL back into the grblHAL stack. Do you have any idea when this might happen or when the web configurator will be available for the SLB? I keep encountering random parsing errors with SienciHAL.

If this isn’t happening anytime soon, I might start looking into compiling my own firmware again. :D

[siganberg]

I found some time to test the latest and build it successfully, but I can't get it to work. I can connect to the device, but I'm not getting any response from the board.

[terjeio]

Odd, it is working for me. Perhaps I should make a binary available for you to try?

The SLB will be made available in the Web Builder when Chris gives the green light for adding it, hopefully soon.

[siganberg]

So this STM32F4xx repository works out of the box for you without any changes (except maybe the platform.io configuration and the Python script)?

Yeah, send me your binary so I can try it. My current SLB also has an EEPROM issue; it won’t even work with the stock SienciHAL firmware unless I compile their version with EEPROM disabled and just use the SD card. I’ll test your binary on the replacement board once it arrives.

Meanwhile, could you also send me your latest platformio.ini that works? I’d like to compare it with mine and see what’s different.

Many thanks!

[terjeio]

So this STM32F4xx repository works out of the box for you without any changes (except maybe the platform.io configuration and the Python script)?

Yes, except the Python script has not been changed. I develop with STM32CubeIDE so the build options are not the same as with PlatformIO, however the provided build is made with PlatformIO and with EEPROM disabled. Also be aware that I only bench test with one motor connected so is to be considered as alpha quality for now.

Note that some setting numbers are different, either erase the flash before programming or reset settings to default with $RST=*.

The binary/.ini can be downloaded from here, I'll keep the link active for a short while.

[siganberg]

Thanks I'll try and report back. 👍

[siganberg]

I tested both the binary and the latest compiled code using the provided platform.ini file with consistent result:

Here are the results of my testing:

• I can connect to the machine, but I am only able to execute jog commands.
• Executing the home command causes the board to hang, requiring a power cycle to recover.
• In gSender, sending ${xx} in the MDI produces no response. The same issue occurs in ioSender unless the "Verbose" checkbox is enabled.

[terjeio]

I can connect to the machine, but I am only able to execute jog commands.

I can run gcode programs, can you post a file that does not for you?
In ioSender are there any blocks (lines) that are flagget "ok" when you start a program?

Executing the home command causes the board to hang, requiring a power cycle to recover.

I am not able to test this since I do not have a machine connected. And since the step/dir signals are not available I cannot check with my machine simulator.

In gSender, sending ${xx} in the MDI produces no response. The same issue occurs in ioSender unless the "Verbose" checkbox is enabled.

In ioSender this is per design, a number of responses are only acted upon and not reported to the console. If you want to interact directly with the controller use a terminal program such as puTTY.

[siganberg]

I can run gcode programs, can you post a file that does not for you?
In ioSender are there any blocks (lines) that are flagget "ok" when you start a program?

I never got a chance to run any g-code program since I can't even home the machine on startup.

In ioSender this is per design, a number of responses are only acted upon and not reported to the console. If you want to interact directly with the controller use a terminal program such as puTTY.

This works on their sienciHal firmware. For gSender, upon connection, it issues $$ to retrieve all the settings, reads the response, populates the firmware settings in the UI, and enables all the UI buttons. Without this, gSender will continue to show as disconnected.

On MDI, I also issue M6T{x} for tool change, and I usually get response Ok. The main reason I want to switch to stock STM32F4xx firmware is because I kept getting G-code errors sometimes on sienciHal.

[terjeio]

Try this, at least it errors out for me.

For gSender, upon connection, it issues $$ to retrieve all the settings, reads the response, populates the firmware settings in the UI, and enables all the UI buttons.

ioSender does this too, but does not report the $$ output to the console unless Verbose is checked..

[terjeio]

The fix has now been commited.

[siganberg]

Here's the new result of the new build.

• Connecting to the board I'll get printout in the terminal of all the settings which populate also the User Interface firmware settings of the gSender, but can only modify one value at time, then I need to disconnect and connect again. Typing any command in the terminal doesn't give me any effect or any response, like $$ command or $X to unlock the machine when e-stop is triggered and release.
• Homing start moving but start crash on the limit even though the homing sensor are triggering. Need to hit the e-stop to avoid damanging the motor.

[terjeio]

My guess is that gSender is confused by the $spindles command output and acts weirdly after. If so gSender should use $spindlesh instead for a machine readable version of the output as discussed here.

If you trigger the limit switches manually does the Signals LEDs in ioSender change state? I have a pending commit where they do.

[terjeio]

My guess is that gSender is confused by the $spindles command output and acts weirdly after.

I have now confirmed that this is the reason...

[terjeio]

New patched binary uploaded. It has Siencis customized version of the $spindles output. There may be other issues present as well since jog distances changes to NaN on connect or when sending $I from the console.
Note that I will not add their customization so the binary is just for testing.

[siganberg]

If you trigger the limit switches manually does the Signals LEDs in ioSender change state? I have a pending commit where they do.

I might need to reflash the firmware and retry again with ioSender. I put back the sienceHal as need to run some project right now. Although the sienceHal is usesable, it's annoying getting random invalid g-code error.

I have now confirmed that this is the reason...

Is this something fixable? So this is the reason of MDI interaction eractic on gSender? Or this something that need fixing on the gSender side?

[siganberg]

New patched binary uploaded. It has Siencis customized version of the $spindles output. There may be other issues present as well since jog distances changes to NaN on connect or when sending $I from the console. Note that I will not add their customization so the binary is just for testing.

Is it possible to get the hex version so I don't need to reinstall the STM programmer and I can do it on the gSender? gSender only accept .hex.

Or better yet, just push a separate branch that I can pull and compile myself. And from here we can just continue working on this branch, whatever fix we do or testing.

[terjeio]

Is this something fixable?

Yes.

So this is the reason of MDI interaction eractic on gSender?

Yes it seems so, at least gSender behaves better when I add the customization.

Or this something that need fixing on the gSender side?

Yes, IMO it is better if gSender works with "standard" grblHAL controllers. There is even a comment in the gSender code that they should switch to the machine readable output from $spindlesh...

[terjeio]

Is it possible to get the hex version so I don't need to reinstall the STM programmer and I can do it on the gSender? gSender only accept .hex.

Now available in the download.

Or better yet, just push a separate branch that I can pull and compile myself. And from here we can just continue working on this branch, whatever fix we do or testing.

I have a settings revision nearly ready to commit so creating a branch that includes all the changed drivers and submodules will be far too much work. However, the customization is just these lines, so you may add them manually if you wish.

[siganberg]

Awesome! I will test it and report back.

[siganberg]

All the issue mentioned before are fix but here are the new issues.

Shows stopper issue:

• Probing doesn’t work and hangs the board after it touches the probe/tool setter
  https://youtu.be/KWiwDztz-8g?si=coCrCNNnD5NXUhf1a

Annoyances issues:

• Hitting e-stop and release it doesn’t recover, need hard power cycle.
• Still keep getting this error randomly. If issue jog, then do it again for the same command, the error is not appearing anymore. This is actually the problem with sienceHal too that I’m trying to test if it’s resolve.



[terjeio]

Probe hang is on me, due to the many inputs in the SLB. Fixed in this hex.

E-stop works for me, both in ioSender and gSender (1.4.10). gSender is a bit slow on responding to unlocking sometimes.

The random error is likely a gSender bug? Related to jog distances getting reset to NaN? No such issue with ioSender.
BTW I get the same random errors connected to a MSP432 controller.

[siganberg]

The probe is working now, so my tool setter too, since they are just series together. I need to reboot first before it starts working.

The e-stop unlocking works, but it doesn't return the stepper motor's power back and needs a power cycle. Just scroll on the 4:12 timeline for this issue: https://youtu.be/fsx9jLBmbsY?si=qr9HB4-m_kwMJsn2&t=253

[terjeio]

The e-stop unlocking works, but it doesn't return the stepper motor's power back and needs a power cycle.

Oops, I missed that one. Power is cut to the motors on e-stop so the stepper drivers loose their configuration.
This hex reinits them after the e-stop is cleared.

[siganberg]

Thanks. Will test it tomorrow.

Can I get code changes for it? I'm keeping my fork updated with these fixes.

[terjeio]

Code changes just committed.
You'll have to change -D DEFAULT_SPINDLE=0 to -D DEFAULT_SPINDLE=11 in platformio.ini to get the correct spindle.

[siganberg]

Good new. Everything works now.

With the new version, it fixes my problem too when doing just unloading tool and also tool measurement. Before these give me bunch of errors.

There is a minor issue I keep getting, this might be on the gSender side. If I issue a invalid command let say M61T1 (it supposed to be M61Q1) for telling the firmware what current tool is loaded, it give's me invalid g-code error which should be right but any succedding valid g-code command will still throw invalid g-code until I do some jogging.

[terjeio]

... any succedding valid g-code command will still throw invalid g-code until I do some jogging.

This is a safety feature in grblHAL, when an error is returned it will be returned for all subsequent g-code commands until a blank line or a $ system command is sent. Legacy Grbl will just continue executing commands.
Sadly gSender does not allow sending blank lines, neither do so automatically after an error when a new command is sent from the MDI. IMO gSender should at least allow sending blank lines - they do no harm.

[siganberg]

Ahh make sense. Will check on the gSender side.