uCNC using RAMPS and 4 axis freezes on negative direction

[mvackel]

I'm using the Mega/Ramps 1.4 board with the ReprapDiscount Full Graphic Smart Controller.
It works normally with 3 axis and limits, but when I add the 4th axis, Axis A, the Jog control using the display makes the board and display to stop ONLY when moving in the negative axis direction, on any axis.

If connected to the UGS platform, it recognizes the 4th axis and displays the "A-" and "A+" jog buttons, but after the first jog command on any axis, in the negative direction, the board also freezes without any interaction with the Reprap controller.

The positive axis direction on any axis is working (X+, Y+, Z+, A+) but any jog command on the negative direction (X-, etc) on any axis stops the board.

[Paciente8159]

Thanks I will investigate.

[Paciente8159]

Just one question. Do you have software limits enabled?

[mvackel]

I've tested both. Same behavior.
Also, even with software limits enabled, you can jog any axis in the positive direction many times (say, 1mm each time), but after this, just one click in the button to go in the negative direction freezes the board.

[Paciente8159]

I tested with the virtual emulator and all worked as expected.
Also tested with an ESP32 board and was also working correctly with UGS.

I'll will try later with an AVR board.

I also recommend you try resetting all your settings via $RST=* and then re-configuring your board. If you enabled extended commands don't forget to do a $SS to permanently store the information in the EEPROM

[Paciente8159]

Just finished testing. At first I seemed to be kind of stalled. I mean the board was working fine with UGS. The screen was just not updating.
But then after pressing the cables tighter behind the screen all started working normally.
Tested with the latest UGS.

Ok. I thought that uploading a new firmware would overwrite all old data. How can I erase everything to load the new settings with the new compiled firmware?
This can probably explain why I was stuck in the logo display in the previous thread - and could only be solved burning a new bootloader.

Usually rewriting the firmware is enough. If settings have some invalid data or the CRC does not match the default values are loaded. But the CRC is not a silver bullet and sometimes can return the correct CRC sum even though the settings are not what you desire. You can end up with an axis that as a value of 0 stored in the steps/mm and when you command it to run...well it wont be able to get very far.

I recommend do an EEPROM cleaning if you reflash the firmware and your settings structure as changed (for example when adding or removing axis).

To do a settings clear and restore all default values send a $RST=* command.
If you extended commands options enabled then do a $SS command to save your new settings to the EEPROM.

Here the compiled firmware.
firmware.zip

I build using web config tool and used these settings:
ucnc_ramps_config_json.txt

One note. With 4 Axis the screen does seem to be getting a little sluggish. But I guess AVR is struggling to get everything updated.
Maybe by reducing the refresh rate of the screen might improve things a bit. (I forgot to add that option in the web config but there is and option for that).

By default the screen refresh rate is once every second.
You can change that by adding this line:

// change refresh rate to 2s
#define GRAPHIC_DISPLAY_REFRESH 2000

[Paciente8159]

Just note that the firmware file I sent has issue #494. This was patched in the master branch.

[mvackel]

The generated files using your json worked as expected.
I compared the generated files with the ones that caused the problem and found that I had enabled "Enable S curve acceleration". Just commenting the line
#define ENABLE_S_CURVE_ACCELERATION
in cnc_hal_overrides.h fixed the problem.

So, it seems that "Enable S-curve acceleration" is causing the freezing problem on negative jog commands. I've also tested with 3 axis and this seems to be working. The problem seems to be with 4-axis AND "Enable S-curve acceleration".

I do not need to enable S-curve acceleration, so I will keep it disabled. Maybe you should confirm if that is really a bug.

I'll test this again with 5 axis - that's my final goal, by now.

Thank you.

[Paciente8159]

Thanks for this. I will give it a try and try to reproduce the issue.

[Paciente8159]

I was not able to reproduce the issue. Even with S-Curve enabled jogging to negative regions was not a problem.
Tried this using master branch with virtual emulator, STM32 Bluepill and AVR Mega/RAMPS.

How are you compiling this? VSCode or Arduino IDE?

If you are using VSCode next time try this before compiling:
Open the CLI

on the terminal type this command:
pio pkg update -e ramps14

This will update all compilation tools and dependencies for the project ramps environment.