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
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?
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 …
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.
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
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.
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.
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)