Multiple feature requests

[dlang]

Several items that I want to bring up for discussion

1. make a topic here that subscribes to the github activity (this would make it so that when issues are filed on github, they show up here). it would be fantastic if it was possible for this to be a two-way connection, but even a read-only topic would be useful. It could be either a single topic, or a category with each issue/pr as a separate topic. Since github can send emails, and the forum can post from emails, this should be a fairly straightforward thing to do as a one-way, single topic feed.
2. add a sanity check and warning if the total Z offset (z offset + wasteboard + workpiece) is <0 (i.e. the belt would pull up)
3. make it possible to go from the ‘extending belts’ state to start calibration or apply tension. People should only need to pull out the belts far enough to hook up to the frame, not a longer distance just because that was in the config
4. I did some testing and learned that you can have multiple yaml files on the system and switch between them (in the fluidnc tab there is a config value “ConfigFilename”)
   1. make sure that when you save parameters in the settings, you save them to the file specified in this variable, not to “maslow.yaml”
   2. make this a pulldown option that offers all .yaml files on the system rather than having to type in the value (potentially, this would be something exposed in the maslow tab)

[Jonathan_Dion]

The point 4 seems great ! But we actually need to restart the Maslow ( and extend the belts again… ) so switching between .yaml will need a reboot or is it possible to adjust “on the fly” ?

[dlang]

Jonathan Dion wrote:

The point 4 seems great ! But we actually need to restart the Maslow ( and
extend the belts again… ) so switching between .yaml will need a reboot or is
it possible to adjust “on the fly” ?

I don’t know. There is a button to reload the config items, so that would make
it seem like it can be done on the fly.

But since my purpose for wanting this is for switching between one frame outside
(concrete anchors), and one inside (~30" square from 2x4 and 3d prints), having
to restart when switching config files is not significant, it just needs to be
done before doing the extend for the new frame.

what other reasons can you think of for switching between config files?

David Lang

[Adam_Schreiber]

@dlang

make it possible to go from the ‘extending belts’ state to start calibration or apply tension. People should only need to pull out the belts far enough to hook up to the frame, not a longer distance just because that was in the config

If it does this, it might be worth prompting the user to update the value and displaying the current extension distances or offering to do so when changing the modes.

[Adam_Schreiber]

@dlang

what other reasons can you think of for switching between config files?

I would think this would also be useful when troubleshooting and switching back to a “known good” yaml or when upgrading and wanting to try the new version. It might even be worth starting to version the yaml distributed with the firmware and looking for the new one in the upgraded firmware.

[bar]

I think that these are great ideas. I am going to work on implementing these on Tuesday.

[Adam_Schreiber]

I also thought it would be advantageous to check if z position is set to z zero before beginning calibration and offering to move the z axis to z zero.

[dlang]

sadam wrote:

I also thought it would be advantageous to check if z position is set to z
zero before beginning calibration and offering to move the z axis to z zero.

Currently, the calibration routine defines Z Zero as whereever you are when you
start calibrtion.

if we had stall detection turned on, going down until we stall would be a good
idea, even if we don’t use stall detection normally (stall detection depends on
back EMF and so EM interference, like from the router, can confuse it, but when
starting calibration, it’s not turned on)

that would be a rather big change, but I think it would be worth it

David Lang

[dlang]

@bar also look at trick captive portal tests by davidelang · Pull Request #277 · BarbourSmith/FluidNC · GitHub that I hope will fix the ‘need to login to the network’ and related issues

I haven’t yet figured out (again) how to compile the firmware, but the AI feedback gives me confidence that it’s correct (it not only understood the code, but it validated that the responses were correct for the each of the client OSs)

[bar]

Check out the instructions here under the platformIO section: FluidNC Installation | Wiki.js

Although to be honest I think those directions are pretty much useless and over complicated. Basically AFIK the steps are:

1. Install Visual Studio Code
2. Install the PlatformIO app inside VS code
3. Open the project in VS Code
4. Press this button:

That will compile and upload the code to the machine over wifi.

If you have a chance to try that and run into any issues let me know!

[dlang]

Bar wrote:

1. Install Visual Studio Code

just visual studio code? not full visual studio? (that was confusing me)

I will try this later tonight.

David Lang

[bar]

Yeah, I think that we just need VS Code

[dlang]

the compile failed with

home/dlang/.platformio/packages/toolchain-xtensa-esp32s3/bin/../lib/gcc/xtensa-esp32s3-elf/8.4.0/../../../../xtensa-esp32s3-elf/bin/ld:
.pio/build/wifi_s3/src/src/Machine/MachineConfig.cpp.o:/home/dlang/git/FluidNC/FluidNC/src/Machine/../Maslow/Maslow.h:31:
multiple definition of nvs'; .pio/build/wifi_s3/src/src/FileStream.cpp.o:/home/dlang/git/FluidNC/FluidNC/src/./Maslow/Maslow.h:31: first defined here /home/dlang/.platformio/packages/toolchain-xtensa-esp32s3/bin/../lib/gcc/xtensa-esp32s3-elf/8.4.0/../../../../xtensa-esp32s3-elf/bin/ld: .pio/build/wifi_s3/src/src/Maslow/Maslow.cpp.o:/home/dlang/git/FluidNC/FluidNC/src/Maslow/Maslow.h:31: multiple definition of nvs’;
.pio/build/wifi_s3/src/src/FileStream.cpp.o:/home/dlang/git/FluidNC/FluidNC/src/./Maslow/Maslow.h:31:
first defined here
/home/dlang/.platformio/packages/toolchain-xtensa-esp32s3/bin/../lib/gcc/xtensa-esp32s3-elf/8.4.0/../../../../xtensa-esp32s3-elf/bin/ld:
.pio/build/wifi_s3/src/src/Maslow/MotorUnit.cpp.o:/home/dlang/git/FluidNC/FluidNC/src/Maslow/Maslow.h:31:
multiple definition of nvs'; .pio/build/wifi_s3/src/src/FileStream.cpp.o:/home/dlang/git/FluidNC/FluidNC/src/./Maslow/Maslow.h:31: first defined here /home/dlang/.platformio/packages/toolchain-xtensa-esp32s3/bin/../lib/gcc/xtensa-esp32s3-elf/8.4.0/../../../../xtensa-esp32s3-elf/bin/ld: .pio/build/wifi_s3/src/src/ProcessSettings.cpp.o:/home/dlang/git/FluidNC/FluidNC/src/Maslow/Maslow.h:31: multiple definition of nvs’;
.pio/build/wifi_s3/src/src/FileStream.cpp.o:/home/dlang/git/FluidNC/FluidNC/src/./Maslow/Maslow.h:31:
first defined here
/home/dlang/.platformio/packages/toolchain-xtensa-esp32s3/bin/../lib/gcc/xtensa-esp32s3-elf/8.4.0/../../../../xtensa-esp32s3-elf/bin/ld:
.pio/build/wifi_s3/src/src/Protocol.cpp.o:/home/dlang/git/FluidNC/FluidNC/src/./Maslow/Maslow.h:31:
multiple definition of `nvs’;
.pio/build/wifi_s3/src/src/FileStream.cpp.o:/home/dlang/git/FluidNC/FluidNC/src/./Maslow/Maslow.h:31:
first defined here

these are unrelated to my chanages

David Lang

[dlang]

note that I get the same result when I compile Maslow-Main

searching for info on this, it looks like the definition
const char * nvs = “Maslow”;

cannot be in a header that is included into many files.

the variable could be defined here

const char * nvs;

but the assignment would need to happen elsewhere.

David Lang

[bar]

Hmmm this is happening when compiling with that arrow button which should compile and upload with platform io?

[dlang]

Bar wrote:

Hmmm this is happening when compiling with that arrow button which should
compile and upload with platform io?

correct, I have no way to upload from the code app, but it’s failing on the
linking stage, both for Maslow-Main and my branch.

David Lang

[bar]

I have a computer that I’ve never set up the build process on before, I’ll try to set it up there today and see what I can learn

[dlang]

Bar wrote:

I have a computer that I¢ve never set up the build process on before, I¢ll try
to set it up there today and see what I can learn

I found the problem, I was not as up-to-date as I thought I was. got to the
current version and it now compiles and links. but I now get repeated copies of
this set of warnings

In file included from FluidNC/src/Maslow/Maslow.h:8,
from FluidNC/src/ProcessSettings.cpp:26:
FluidNC/src/Maslow/Calibration.h:175:85: warning: ISO C++ forbids converting a
string constant to ‘char*’ [-Wwrite-strings]
{ CALIBRATION_COMPUTING, “Calibration Computing” } };

FluidNC/src/Maslow/Calibration.h:175:85: warning: ISO C++ forbids converting a
string constant to ‘char*’ [-Wwrite-strings]
FluidNC/src/Maslow/Calibration.h:175:85: warning: ISO C++ forbids converting a
string constant to ‘char*’ [-Wwrite-strings]
FluidNC/src/Maslow/Calibration.h:175:85: warning: ISO C++ forbids converting a
string constant to ‘char*’ [-Wwrite-strings]
FluidNC/src/Maslow/Calibration.h:175:85: warning: ISO C++ forbids converting a
string constant to ‘char*’ [-Wwrite-strings]
FluidNC/src/Maslow/Calibration.h:175:85: warning: ISO C++ forbids converting a
string constant to ‘char*’ [-Wwrite-strings]
FluidNC/src/Maslow/Calibration.h:175:85: warning: ISO C++ forbids converting a
string constant to ‘char*’ [-Wwrite-strings]
FluidNC/src/Maslow/Calibration.h:175:85: warning: ISO C++ forbids converting a
string constant to ‘char*’ [-Wwrite-strings]
FluidNC/src/Maslow/Calibration.h:175:85: warning: ISO C++ forbids converting a
string constant to ‘char*’ [-Wwrite-strings]
FluidNC/src/Maslow/Calibration.h:175:85: warning: ISO C++ forbids converting a
string constant to ‘char*’ [-Wwrite-strings]

David Lang

[dlang]

the other part of the development question is what options I have to use a 4.0
board without the rest of the maslow to test on.

There should be a way to define fake motors, things that move exactly as
instructed, producing the proper encoder changes, etc without requirng actual
motors

or an option to use the old 4.0 enocders with magnets glued to the end of the
motor shafts in some 3d printed frame to hold things in place.

These don’t eliminate the need for real testing on real frames and real cutting,
but they allow for a lot of testing of UI and network functions that are
independent of the real-world movement problems.

David Lang

[bar]

Excellent! I also get those warnings so I think they are safe to ignore.

I’ve also been playing around with the idea of having a fake machine to simulate some things and maybe even having a hardware in the loop testing routine which could automate some of the testing process, but I haven’t found a way to do it which truly simulates the machine well enough.

I think it is a really cool idea though!