[Grbl_Esp32 Issue#469] Problem with USE_RMT_STEPS feature

#1 – karoria 于 2020-07-05

I had also problems with using RMT steps and since then I keep them disabled and got good results. I don’t know much technicalities concerning to this issue but I suspect it changes something which relates to how “time” is measured. Hence the velocity, acceleration, etc. can be affected a lot.

I have made an aluminium pattern “using RMT steps” as well as “not using RMT steps” (two different jobs). Using RMT steps has spoiled my job, so after roughing, I have not finished it. From the photographs below, the unfinished ones are machined “using RMT steps” and finished ones are without using RMT steps which are OK.

When I faced this problem, I got to the problem root after 7 days of continuous troubleshooting! which included checking of coupling slippage, drive parameters (I use easy servos), checking step and direction signals in DSO, checking for noise issues and what not! Then I found the villain is “#USERMTSTEPS”

It was with an old (some 5 months back) firmware. Bart has clearly mentioned that it is an experimental feature, so was off in the config.h, but I noticed it was uncommented in some other file which was not supposed to be edited. I commented that define and problem solved!

Developers @bdring @MitchBradley please throw some light on this practical finding.

!RMT-OFF-1
!RMT-OFF-2
!RMT-OFF-3
!RMT-ON-1
!RMT-ON-2
!RMT-OFF-4
!RMT-ON-3

#2 – karoria 于 2020-07-05

I don’t know whether it is clear from photos, but the portait (vertical) photographs are of the NOT OK job. You can see the Y axis dragged first in positive direction to some height and then to negative direction. Same was in X but at a lower extent (approx half then Y). All the landscape images are of OK job which is finished. The OK job is almost symmetrical in side slope in X and Y both axis.

#3 – MitchBradley 于 2020-07-05

Let’s not make the same mistake as last time and fail to get all the system information in the ticket. We need to know:

Exactly which firmware version (“the latest” is not enough because there are multiple branches. Furthermore, if anybody looks back at this ticket, it will be troublesome for them to figure out what “the latest” meant at a given time).
Which machine definition file and any modifications to it.
Any modifications to any other files such as config.h, defaults.h, or any .cpp files
The values of all the settings.
Details about the board you are using. If it is one of Bart’s boards, supply the name and version and tell us how any jumpers are set. If it another board, perhaps one of your own design, show the schematic and jumper settings.
The types of drivers and motors, and driver settings if there are any (like on external drivers).
Photo of the machine so we can see the mechanical design.
Pitch of screws or timing belts, and pulley sizes.
A GCode file that exhibits the problem and best guess as to which line was executing at the time.
Which GCode sender was being used with the problem occurred, with console logging info if that is available.
The startup lines that Grbl issues after reboot.