Interstitial Firmware Releases

I agree that that is probably a tuning issue with the arm being told to move faster than it can actually move.

I think that these are probably the settings that we care most about for a, b, c, and d axis:

But there could be other settings that I haven’t discovered the importance of yet.

Let me know if you discover anything new! I’m going to be exploring those settings too.

1 Like

Could I strongly recommend that you switch your IDE to cursor - it is based on VS Code. I haven’t tried yet whether it is happy with the platform.io plugin, so you may still need to switch back and forth.

It is extremely good AI integration, there is a free plan. I’ve been using it for several projects including the latest GCodeClean fix

Cursor - The AI Code Editor

1 Like

Is it that much better than copilot?

A looot better - although I still use copilot in vscode

1 Like

Where can I find a copy of this code. Flying blind making changes without knowing how the code works. Thanks for all the awesome work.

Those settings are all in the maslow.yaml file, but the full source code is here:

Let me know if you want help finding any particular parts of it

1 Like

Stoked on this! Does this update mean we’ll be able to account for stretch in each belt without some crazy trigonometry?

2 Likes

Interestingly yes I think that it will!

2 Likes

I haven’t done any experiments with AI generating code, I have only conceptual knowledge of the process. I would be interested in hearing a real world experience how you had to go about leveraging existing code and feeding AI to generate whole new 4axis code base.

Now that AI has the new base code do you suspect it will speed future development and improvements like Kyles suggestion on belt stretch factor?

Dano

1 Like

The AI is quite good at executing on actually writing the code if you can give it a clear understanding of what you want, but sometimes having the good understanding of exactly what you want is the hard part.

Overall I’ve found it to be super impressive. It for sure handles a lot of the most painful and tedious parts of programming.

For wrapping my head around what I should be telling the AI, this just came out, and I found it super useful, filled in a lot of gaps for me. There is some programmer jargon in here, but not much …

4 Likes

This seems to be working as expected. I’ve bumped up the max feedrate per-axis and seems to be working well.

maslow.yaml (6.5 KB)

This made it a lot better, I have noticed TL & BR belts went slack when transitioning, although not much, and tightened when M4 reached it’s destination.
I have noticed a couple of problems:
Setting home does not work, it appears to have worked but subsequent clicking on home goes to random places.
The X,Y & Z values do not update while nc commands are running and values appear to be randomised. Changing Z values is not reflected accurately when up/down arrows are pressed.
Not quite ready for general release yet.
Suggestions:
Interstitial releases have a distinct release number, so its apparent if it is loaded by inexperienced users.
Is it possible to put both version numbers in the log file so we can identify disparities quickly.
Users be requested to add a log file when requesting help where possible.

Please disregard this

I worked out I had reloaded the software to Interstitial Release on one machine, updated the maslow.yaml file with the new values, then moved to my laptop to run some tests. The laptop was configured with V1.07 so although jobs ran correctly it did not get the data it expected to update the X,Y & Z values or set the home. After a power reset and reload of the web page the machine reported correctly. Haven’t tried homing since realising this so well test that tomorrow

Still get TL and BR getting loose when doing a G0 move, haven’t noticed with simulated cut. Haven’t done a cut with this version yet.

Can not set Z until after Apply Tension. Fans start and Z value changes but no movement on Z axis. This will be a problem if job fails with Router bit stuck in job.

Were these particularly big or diagonal moves? I was seeing something similar on main doing big diagonal moves - I worked around it by turning down max speed.

With mine, it almost felt like the trailing arm spooled out too quick, because it did go taut at the end of it made it that far. Was that the same behaviour you saw?

With per-arm-calcs I am assuming we can handle it better - I’ve not dug into the new code yet though :thinking:

I noticed when I was doing an angled move both up-left and down-right. On the last one it errored out with a 15mm error. I had done several simulated cuts of circles and squares with no problems. I was when I tried to use G0 commands to move a metre or so diagonally that it fially failed. When it didn’t fail on large moves the BR & TL belts were loose and then tightened when it reached its destination. Belts also loosened when used the home button and the Maslow had to move diagonally back approx. a metre.

Yes, similar effect.

Dave wrote:

With mine, it almost felt like the trailing arm spooled out too quick, because it did go taut at the end of it made it that far. Was that the same behaviour you saw?

That is exactly what to expect when the motors aren’t keeping up, it can’t pull
hard enough to get you where you should be, but the trailing arm is able to feed
out faster as it’s not under load.

David Lang

1 Like

Ian Abbott wrote:

I noticed when I was doing an angled move both up-left and down-right. On the
last one it errored out with a 15mm error.
< ,
I was when I tried to use G0 commands
to move a metre or so diagonally that it fially failed. When it didn’t fail on
large moves the BR & TL belts were loose and then tightened when it reached
its destination. Belts also loosened when used the home button and the Maslow
had to move diagonally back approx. a metre.

this is caused by telling it to move faster than it can (and the 15mm error is
when it gets off enough for it to notice). slowing down the feed rate should
solve it (you need to turn down the max feed rate to help with the G0 moves)

David Lang

1 Like

Great! This was the first thing on my todo list for today so I’m glad to hear that :grinning_face:

I think that this is exactly correct. We just need to tune the maximum feedrate for each arm a bit I think.