Something I noted during this test as well, the problematic arm (bottom left), would be slightly loose when I go to extend it if it is not the first belt that I extend.
I think somehow extending the other belts is causing some kind of friction between the arms that the encoder on the bottom left arm sees and then relaxes the motor. I would expect the encoder to be able to account for this, but maybe my understanding of the system or problem is flawed
Not related to this issue See Interstitial Releases for an interim fix. Won’t fix the belt issue.
Not consistent.
From this I would suggest a loose magnet is probable. If you are pulling that arm apart, also check how easy it is to move the spool on both halves of the arm. If it is not easy, then sand the relevant surfaces until it is. You can also apply a silicon lubricant.
gotcha, I’ll pull it apart again and add some glue to the magnet, thanks Ian!
where do I find the Interstitial Releases?
This is what you’re looking for
What if we make it so that $BRO etc will ignore those. I like that it has to be a manual command
This is unfortunately a bug that slipped into 1.18. We added a watchdog which will shut the machine down if anything interrupts the processor for too long, but it seems like saving the settings can take too long and trigger the warning.
Maybe we should add a warning not to use 1.18 until we can get it fixed. What do you think @dlang and @ian_ab ?
@bar see
Bar wrote:
What if we make it so that $BRO etc will ignore those. I like that it has to be a manual command
the $BRO etc commands are very limited compared to what I think we really want.
they both don’t do enough, and have no safety, a bad combination
I’m thinking of something like
belts tr extend 100 tl comply 100
not just ‘pulse the motor for X ms’ like the current commands do
David Lang
Bar wrote:
This is unfortunately a bug that slipped into 1.18. We added a watchdog which will shut the machine down if anything interrupts the processor for too long, but it seems like saving the settings can take too long and trigger the warning.
Maybe we should add a warning not to use 1.18 until we can get it fixed. What do you think @dlang and @ian_ab ?
sending out a warning is a good idea, but until people use it and find where we
have gotchas like this, we won’t ever know when we will be able to remove the
warning
how about releasting a 1.18.1 that changes the watchdog to something longer so
it’s less likely to trigger?
David Lang
@bar is there some way we can force the maslowbot to build on the latest version? That is, with all approved changes incorporated. At the moment it keeps building on whatever Maslow-Main was in effect when the new pull request was initiated, which means it’s not testing against the current situation. Each little change is done in its own bubble.
Ian Abbott wrote:
@bar is there some way we can force the maslowbot to build on the latest
version? That is, with all approved changes incorporated. At the moment it
keeps building on whatever Maslow-Main was in effect when the new pull request
was initiated, which means it’s not testing against the current situation.
Each little change is done in its own bubble.
I’ve tried it, the copilot cannot rebase to the current master.
what I have done is at the end of a messy PR, I ask it for instructions to give
to re-create the PR (without the problems) and then feed that in as a new issue.
David Lang
Yeah I don’t know a good way to make it build the main branch. What I’ve been doing is to create a new issue which asks the AI to make a pull request with “one small white space change for testing” which basically means it will add a blank space to the end of a line or something to make a change which basically doesn’t matter and then I’ll ask the bot to build there.
It’s not the cleanest system, maybe we should come up with something better.
Bar wrote:
Yeah I don’t know a good way to make it build the main branch. What I’ve been doing is to create a new issue which asks the AI to make a pull request with “one small white space change for testing” which basically means it will add a blank space to the end of a line or something to make a change which basically doesn’t matter and then I’ll ask the bot to build there.
ahh, what we need to do is to split off a set of nightly builds, and every night
have a bot compile and upload the latest firmware.
We just need to not have it show up in the main releases section.
I know that other projects have release, nightly, and release candidate
categories of builds.
David Lang
I like that idea a lot. I wonder if there is a way to automate it.
Bar wrote:
I like that idea a lot. I wonder if there is a way to automate it.
There is, many projects do it.
google search
how to configure automated nightly builds in github
returns:
AI Overview
To configure automated nightly builds in GitHub, you primarily use GitHub
Actions and the schedule event with a cron expression. This process involves
creating a YAML workflow file that defines when the build should run and what
steps to execute.
Step 1: Create a GitHub Actions Workflow File
Navigate to your repository on GitHub.
Go to the Actions tab.
Click on New workflow.
Choose to set up a workflow yourself by clicking set up a workflow yourself (or
a similar link at the top of the suggested templates). This opens a new file
editor for a YAML file in the .github/workflows/ directory.
Name the file something descriptive, like nightly-build.yml
Step 2: Define the Schedule Trigger
In your YAML file, use the on:schedule: block with a cron expression to specify
the nightly frequency.
name: Deploy Nightly
on:
schedule:
# Run every night at 2 AM UTC
- cron: ‘0 2 * * *’
workflow_dispatch:
The cron: ‘0 2 * * *’ expression schedules the workflow to run at 2:00 AM
Coordinated Universal Time (UTC) every day. You can adjust the cron expression
to your preferred time and frequency.
Step 3: Define the Build Job
Below the on: block, define the jobs: section. This section outlines the steps
for your build process. The specific steps will depend on your project’s
language and requirements (e.g., Node.js, Python, Docker).
jobs:
nightly-build:
runs-on: ubuntu-latest # or windows-latest, macOS-latest, depending on your
needs
steps:
- name: Check out repository code
uses: actions/checkout@v4
# Add steps here to build your project (e.g., install dependencies,
compile, test)
- name: Install dependencies
run: npm ci
- name: Build project
run: npm run build
# Add steps to upload the build as an artifact or release asset (optional
but recommended)
- name: Upload artifacts
uses: actions/upload-artifact@v4
with:
name: nightly-build-assets
path: ./dist # adjust ‘dist’ to your build output directory
Step 4: Commit and Monitor
Commit the new YAML file to your repository’s main branch.
The workflow will automatically run at the scheduled time. You can monitor the
progress and view logs in the Actions tab of your repository.
Optional: Create a Nightly Release
Many nightly build setups also create a “pre-release” on GitHub to easily access
the latest build artifacts. You can use a GitHub Marketplace action, such as
Deploy Nightly, to automate this part of the process.