Interstitial Firmware Releases

Software Maslow Firmware
524

hmm, that movement behavior is odd
unfortunantly the logs don’t show restoring the data in the UI, you would need to attach a USB cable to gather the logs (there is another fix in to try and address that problem)

the machine not being locked when it comes back on is correct. The lock is because it doesn’t know it’s belt lengths, so it needs to be sure not to try and move. Since we know the belt lengths, we don’t need to start in alarm mode.

can you try running gcode? (even without a bit) to see if that sag is just while it’s jogging?

@bar is there any chance that it’s relaxing tension when it goes idle? I have not seen anything like that, but I’m working on a horizontal frame, and the little bit of movement shown may not show up for me? but it’s not something in the area this fix touches

525

Ok on the logs. How do I get them with the usb. I’m using windows 10. I can find it as debug device I think it is. But after that??

526

bday wrote:

Ok on the logs. How do I get them with the usb. I¢m using windows 10. I can
find it as debug device I think it is. But after that??

the zip file for a release includes a program fluidterm.sh that you should be
able to use to read the logs, or you can use a terminal program like putty to
connect to the port and capture the logs.

David Lang

527

This looks like the servos powering off between moves to me which lets things relax a little. It won’t happen while cutting.

Do you see the same behavior before powering off and having the belt position saved? Does the tension in the belts seem the same as before?

It is a sign that the tension in the belts is really high which might be a sign that something loaded differently than it was saved

528

It did not do the hop and relax movement prior to power off the first time. It does it before and after every time now but prior to the first power off after uploading the firmware change and doing the initial RET thing it moved normally and smoothly when jogging. The tension feels the same to me before and after including the first time. I have not tried to run a file yet but will tomorrow hopefully. I’ll report any issues. Thanks for the help.

1 Like
529

I was having problems with a new build not being able to calibrate, so I have been going back to try and find the problem (my changes should not have affected that area) and I am trying the head of the Maslow-Main trees (both firmware and UI) and I’m having even more grief. I seem to be getting stuck at the very beginning of calibration. I added debugging log messages and they show I’m not getting very far

@bar are things working for your?

[MSG:INFO: Requesting state change from Belts Extended to Calibrating]
[MSG:INFO: Calibration starting in HORIZONTAL orientation mode]
[MSG:INFO: Setting z-stop position]
[MSG:INFO: Center coordinates updated in MaslowKinematics: X=385.043 Y=383.770]
[MSG:INFO: Machine Position found as X: -16.198 Y: -46.177]
[MSG:INFO: Setting motor positions from hardware readings:]
[MSG:INFO: TL: 412.019 TR: 415.411 BL: 412.878 BR: 410.108]
[MSG:INFO: Succeeded]
[MSG:INFO: Current state: 6]
[MSG:DBG: Starting Calibration loop at Waypoint:0 With pointcount:16 measurement in progress:1]
[MSG:DBG: taking measurement]
[MSG:DBG: takeing a measurement at 0]
[MSG:DBG: Starting Calibration loop at Waypoint:0 With pointcount:16 measurement in progress:1]
[MSG:DBG: taking measurement]
[MSG:DBG: takeing a measurement at 0]
1 Like
530

Maslow-Main is working normally for me right now

531

Bar wrote:

Maslow-Main is working normally for me right now

puzzling. could you try the firmware I posted with the new algorithm (try it
first with the default legacy algorithm)

I was seeing all the calculations complete, then when it invoked calibrate for
the final time it would hang, so a problem on the firmware side. so I started
switching to different firmware and mostly started having it run into grief on
waypoint 0

I’ll load a fresh maslow.yaml file and try again in case there is something odd
there.

David Lang

1 Like
532

new maslow.yaml file didn’t work. @bar, can you post your working files (firmware and ui)

I’m almost to the point of swapping the board in sheer frustration

1 Like
533

I just ran through a calibration which worked except that

  1. The grid was offset up and to the left (not centered on the work area)

  2. The machine crashed as soon as I tried to jog

I think that we’ll need to go through all the pull requests that we merged and figure out which one is breaking things.

I can’t stress enough how important testing before merging things is. It’s a lot easier to test before the main branch is broken than after because now we have to go through an re-test everything instead of just one branch :confused:

The issue must be something after this branch forked off because I was testing there without these issues last week

To me this feels like two separate issues. The crash seems like it’s caused by trying to save the belt lengths. I’m not sure what is causing the grid to be offset.

It looks like one of these is the culprit:

534

Bar wrote:

I just ran through a calibration which worked except that

  1. The grid was offset up and to the left (not centered on the work area)

  2. The machine crashed as soon as I tried to jog

I think that we’ll need to go through all the pull requests that we merged and figure out which one is breaking things.

I can’t stress enough how important testing before merging things is. It’s a lot easier to test before the main branch is broken than after because now we have to go through an re-test everything instead of just one branch :confused:

for the record, I have been testing every PR as I went along (or if I couldn’t,
I have stated so in the PR)

The issue must be something after this branch forked off because I was testing there without these issues last week

GitHub - BarbourSmith/FluidNC at Move-generation-of-calibration-grid

To me this feels like two separate issues. The crash seems like it’s caused by trying to save the belt lengths. I’m not sure what is causing the grid to be offset.

I did just find that there is a timing bug that could cause the BR belt to not
be saved correctly when fully retracted. I haven’t tested it yet

It looks like one of these is the culprit:

Fix belt positions not saved after retract-all and calibration completion by Copilot · Pull Request #411 · BarbourSmith/FluidNC · GitHub

this is related to belt saving above, but what I was seeing was a problem of the
belts being wrong when fully retracted, preventing me from being able to extend
belts, not something that could cause the problem you were seeing

Fix ISO C++ compile warnings in Calibration.h by Copilot · Pull Request #413 · BarbourSmith/FluidNC · GitHub

I think this is the most likely, it cleared the warning, but I may not have done
a full calibration after it.

improve compile time warning when not compiling a tagged version by davidelang · Pull Request #422 · BarbourSmith/FluidNC · GitHub

This is just a compile time warning, no affect on the resulting code

David Lang

535

@dlang @bar good news. I did run a few cut files back to back after the power off and on thing. The hop and relax is there when jogging but running a file all is normal. Also did a release tension to put a bit in and the apply tension worked well. As a side note @bar the Maslow bits are amazing. I bought both the single and double flute but have only run the double so far. Quietest bit I’ve ever run and my router now is at its lowest setting with good chips and working with speeds. Again the power off and on change seems to be working well for me. I’ve run through that cycle numerous times now without an issue other than that hop when jogging. Thanks for all you guys do this fix was a big one for me.

1 Like
536

state of patches, @bar is looking at merging what’s ready today and then testing everything for several days to a week before the release.

there are a LOT of changes this time

Here is a review of every PR that exists in both repos.

UI

tested with full calibration

not critical, cleanup to make it easier to see future bugs that are introduced.

not critical, but this makes it easy for people who may have a large outdoor frame and a small indoor frame (like I setup for my local hackerspace)

The new logic is MUCH faster (finishes faster than the current algorthm gets the first 100 tried) and it seems to handle the 2x6 grid we start with better than the existing config.

It’s not ready to switch to it entirely, and with the work I did in the last few days researching if we can also figure out the z offsets during calibration,
it’s not going to be the long term solution as is.

It would be nice to make people able to test it and report if it helps (it seems fit my frame better)

so possibly helpful, definantly a dead end.

can’t merge until there are tagged versions in the UI repo, so will wait at least one more release

Firmware

early days, no testing, may also want a ‘probing’ state

seems like a worthwhile thing, but you had a question, so it doesn’t seem ready to merge yet.

Not something for before the next release. we still have a bunch of variables around from before you setup the new state system. they can be cleaned up to simplify the code and remove landmines that will slow future development

one fixes a race condition that after retracting, the belt lengths may be saved before the command to make the belt lengths 0 takes effect. this can cause a nasty surprise when it thinks a belt lenght is wildly wrong (belt tangle type problem as the machine tries to move based on what it thinks the belt length is). I think we either need to add this fix or remove saving the belts while reatracted.

the other accepts a small amount of encoder shift (currently 0.5mm) while the belts are retracted. If this fails, the user has to retract before they can extend, annoying but no risk)

it’s not optional now, and we can add it immediately after this release. So I would say don’t push it into this release.

not for this release

you found one, I found another atari-zero found more and tested them.

This fixes bugs that can lead to broken belts. should be included

currently, if the measurements differ by too much, it reports it and retries. I am not sure if it retries forever or only retries once

I took two stabs at this

  1. try to retry three times
  2. if there is only one outlier, ignore it and use the rest

these may be ones to just close and revisit later.

It started as an effort to track down ‘sits and spools’, which is looking like a crash to be caught by the watchdog. But copilot identified an error condition that is not handled.

I don’t know how to test error conditions like this

in any case NOT something for this release

the next startup it would try again.

this avoids that problem by downloading both of them first.

I think these may be one of those ‘copilot broke so I made a new issue’ orphans as I believe the functionality was merged.

but not something for this release

  • there are a whole lot of PRs (from both of us) about auto-grid sizing. At this point I think they should all be closed and we revisit the ideas along with the new algorithms

Process

not related to a release

currently stuck, not sure why.

this is to try and change the instructions to copilot so that it will always
check for trailiing whitespace and dead code before it decides a commit is good enough

sometimes copilot seems to compile code a few times to check it, but I’ve also had times when it just plain broke the code and it took several rounds to get it to fix it’s compile errors.

not sure how to move it forward

537

partial list of things merged in this release

commit e7c45b5f7fc1f233f44cde2caafcaf8ad73b3cde

Fix belt positions not saved after retract-all and calibration completion

commit 467999ece885e3cf93c48e2204063a7a82883dc2

Fix ISO C++ compile warnings in Calibration.h

commit f26edfe0a03f8cc8a21f475b0005a0f1c781dbea

Enable soft limits

commit 2c2f1471d02b5904182c36219030e979c35c19e2

Prevent telnet negotiation from triggering system reset

commit 6b098858c6d12c97e4e2bd03264b7f69d615e243

Disable build attempts on review requests to fix permission failures

commit 8a3f24adc12488d69ba5a64f87e38c990ca11513

Fix automatic builds to report proper version tags using git describe

commit 31493c4b95b63c171a6a5c1c0b486d1d358f9f9f

Fix frame size validation to prevent machine damage from out-of-bounds dimensions

commit 45b938b3bc6a35c6059900b3a509f7d47b0955e3

Extend startup log capture until first websocket connection for $SS command

commit 269efa24e49476b2311d71652fb3b714ed8f8018

Fix: Prevent duplicate spoilboard and work thickness log messages

commit c30a9ae708eeb9c64504dff754b85a2d05e50abe

Save and restore belt positions and machine state across power cycles (based on PR #366)

commit 66400e1ecae6afe6b5dae390a225f695bbdb036a

Add workflow to automatically assign issue authors to PRs

commit 18fab563c81381c871490f9b51346e62d645fd1a

Fix calibration grid inconsistency when running calibration back-to-back

commit f28cf385bbd4695d8abd8bfdb16ec7db3cf35d54

Fix AutoUpdate HTTP redirect support, implement semantic version comparison, enhance firmware installation safety, and comprehensively refactor code for GitHub API and releases

commit 6bf855de3ea905687ebe20e03ab4d7f7755d0615

Fix Z-axis motor mapping issue for probe movement in Maslow CNC

commit 2bc9f999fb4b7307aca108e4a1e878497601fd2f

Improve firmware packaging in maslowbot build action to include folder structure and README

commit 11be43d0a8d7f7962c39d340414d3fed914e738c

Add fixedZ configuration parameter to MaslowKinematics for arms that don't move with Z
1 Like
538

I took the maslow that I have been testing inside with retraction current in the 900-1100 range on a small frame out to the hackerspace where there were concrete anchors.

extend/apply tension did not result in ready-to-cut (center point deviation >12mm) so I tried doing several calibrations.

one the first one, it calibrated up and to the left, and kept moving up, sometimes not retracting one belt, sometimes not retracting another belt (not retracting at all, no movement)

I upped the current during the calibration, seemed to help for a bit, then belts woudln’t move again

I increased current to 1800 and tried calibration again with the new calculations, it got ‘does not converge’ from the data

I tried a third time with maslow-classic algorithm and the bottom left belt not only didn’t retract, it extended, with the maslow pulling on the other three belts until the anchor snapped and the belt tension threw the 4" 3/8 bolt about 8 feet and the anchor 30 feet

I’ll post logs tomorrow (just from the UI unfortunantly)

I’ll have to 3d print the anchor again

539

Ouch.

540

here are the logs from my work yesterday
hsl-outside-calibration-bad-Maslow-serial.log (45.7 KB)
hsl-outside-find-anchors2.log (11.2 KB)
hsl-outside-calibration-bad-broke-anchor.log (13.1 KB)

541

1.13 UI was tagged correctly, but the 1.13 firmware wasn’t

Index.html Version: v1.13
[MSG:INFO: Firmware Version: v1.13-6-g13c33c4c]

there were 6 commits between the tag and the tree that was built for the release, you can remove the existing tag (git tag v1.13 -d) and then apply it again to the tip of the tree.

1 Like
542

I think we need to fix something in the build system because I created the tag right before running the build, but I couldn’t get it to not add the suffix. I tried a couple times and then gave up because I didn’t want to delay

543

Here is a release of the latest dev version which fixes some bugs with parsing the .yaml file as discussed here.

firmware.bin (1.9 MB)

I can’t give firmware versions names like 1.13.1 anymore so we’ll have to come up with a new way to distinguish them

First run very inaccurate
Help with troubleshooting (unsure how to label this, yet to get it to cut)
Maslowkinematics unavailable