Non-continuous jog movement

[mvackel]

(uCNC 1.7.4 using Mega/RAMPS 1.4 5-axis)

After initial boot, the jog movement is not continuous on any axis, moving in noticeable steps. For instance, if you jog to move 5 millimeter (using UGS or the controller), the motor move in about 20 steps and not continuously. The axes are all configured for 400 steps/mm.

In UGS, if you send a Soft Reset command, all axis start moving continuously, fixing the problem.

If you go to the controller (Reprapdiscount full graphic smart display) and issue a jog command from there on any axis, the jerky movement returns and is again observed issuing the command by UGS.

Any way to correct this?

[Paciente8159]

The button motion is also made to cancel jog motion. Maybe this is causing issues.
For example if you send a jog command and then press the button mid jog it should stop it I think. I got to review the code to be sure.

[Paciente8159]

About the making the jog motion more continuous there is a change that can be made.
Currently the system menu only accepted one jog command at time.
I will modify that to allow chaining multiple jog commands like it's possible to to with UGS.

About the problems of jog consistency I will still test that to see if I can replicate the problem by using both the display and UGS at the same time.

[Paciente8159]

#501 should allow multiple JOG commands to be chained via the display controller.
The issue of the very slow JOG happened once while using the display but I was not unable to determine the source. (I'm still investigating).
After I sent a JOG cancel command the JOG it started to work ok again.

[Paciente8159]

One question?

Does this issue affects only jog? What about normal motions or running a gcode file?

I do get some kind of jagged motion but it seems to me that this is being caused by the idle screen refresh rate.

The idle screen refresh takes some processing time that leads the planner/interpolator buffer to get starved and to constantly accel/deaccel as new motion data is feed.
This should also manifest on normal gcode execution too.

EDIT

Try to add this line to your cnc_hal_override.h file and see if it improves the issue
#define SYSTEM_MENU_REDRAW_IDLE_MS 2000

[mvackel]

I tried issuing G0 and G1 and the movement is jagged. I don't know on a program because the movement is usually mixed with many other commands.
I tried to add the line you suggested and the movement is MUCH better, but still interrupted, apparently in intervals of 2 seconds.

[Paciente8159]

Then (that confirms my observation) the issue is the toll the screen update takes in the main loop. The motion planner is being starved by the time it takes to draw the full screen.
I'm reading thought the u8g2 to try to improve the update speed of the screen or even do partial updates.

I'll give you some feedback when I come up with an improved module.

[Paciente8159]

I believe this fixes the issue.
Paciente8159/uCNC-modules#33

All u8g2 function call take along time to execute and if too many of them are called without calling the main loop the planner gets empty and the motion gets jagged.
This also enforces that the main loop is called while communicating with the LCD.

After making these modifications the motion seems to be uniform even navigating inside system menus.

Please let me know if you find any issue.

[mvackel]

The movement is fixed using both: the display and UGS. Great!

I'm not sure if this is just after this modification, but the jog control using the display's rotary encoder got very unresponsive and/or erratic again. I have to command (turn the encoder) about 10 times to get just one or two responses and some of them in the wrong direction. If I rotate the encoder VERY slowly (so that the movement occurs before each "click"), it works, but sometimes in the wrong direction. The menu item navigation is ok, as you mentioned - as is the change of numeric values, like "Settings/Axis/X-accel".

Should I open another discussion about this?

[Paciente8159]

I think we can continue tracking the issue here

[Paciente8159]

And clarifying. The issue you are experiencing is also a bit a of a consequence of the modification.
I'll explain what is happening.

The encoder reading and screen refresh are part of the main loop, since they are hooked via extension events.
The problem I found is that the redrawing of the screen was taking too long to perform and would lead to the step interpolator getting empty and causing a jagged motion.

This forced me to recall the main loop again (several times and from several places) from the module to keep feeding the interpolator and motion planner.

To prevent the "inception problem" and to blow up the stack, once inside graphic display code the code as to prevent calling it self.

This also affect the amount of times the encoder is read.
I have a new idea how to cope with this and will try to test this later today.

I will pull the encoder reading outside and add an accumulator that will count the number of pulses and direction.
It will then execute the use action based on the accumulated value instead of the pulse reading at that moment.

This should hopefully improve wrong direction (it will not fixed it completely but hopefully improve it), and will also help by acting as a buffer of the user action in between screen refreshing frames.

I'll let you know if it works and when it's done.