[Grbl_Esp32 Issue#318] RMT_STEPS mem_block_num and step invert

未分类 bolang 4个月前 (10-14) 54次浏览

Issue #318 | 状态: 已关闭 | 作者: khnrchs | 创建时间: 2020-01-18

标签: bug


What version of the firmware are you using?
Git commit cc78ba3afa65deaa809b5f6f59f85237cd10d13b (Last for Devt)

Is the problem repeatable?
Yes

Under what conditions does the bug occur?
When the step pins should be inverted – setting $2

The value of “memblocknum` in `rmtconfigt` should be 1. A memory block can hold 64 items. When specify a number of 2 the memory block of the next channel is used. Not really a big issue as per channel less than 64 items required. It only matters when the last channel is used - channel 7 can only have `memblocknum` value of 1. The definition of `XBRMTCHANNEL` and `YBRMTCHANNEL` is missing, should be channel 6 and 7.

The step invert isn't correctly masked and should have a shift for the axis number:
`C++
rmtConfig.txconfig.idlelevel = bitistrue(settings.stepinvertmask, 1<AXIS) ? RMTIDLELEVELHIGH : RMTIDLELEVELLOW;
`
The
`STEPPULSEDELAY` doesn't respect the step invert, inverted pins have no delay but an extended pulse width. Inverted pins will have an initial tick (with random direction) when the steppers are enabled in function `stwakeup()`. When use RMT the the setp outbits must be set to 0 (this was already mention in issue #302 )

`C++
#ifdef USERMTSTEPS
// Initialize stepper output; invert is done in RMT cycle
st.step_outbits = 0;
#else
// Initialize stepper output bits to ensure first ISR call does not step.
st.stepoutbits = stepportinvertmask;
#endif


评论 (2)

#1 – terjeio 于 2020-01-18

I guess am partly to blame for this, at least the memblocknum wrongly set to 2, see issue #115. Note that rmtfilltxitems(...) call should be changed to rmtfilltxitems(rmtConfig.channel, &rmtItem[0], 2, 0); as well if I understand the docs correctly. It may not matter if the RMT RAM block is cleared per default, but better be safe.

Step pulse delay works correctly for inverted signals when I look at the output from my version on a scope – and I can’t immediately see any reason for why this should behave differently.

Since I do not have a compatible toolchain set up I am not able to test this version, sorry about that.


#2 – khnrchs 于 2020-01-19

You are right, the pulse delay works correctly. I’m sorry for this.
Seems, I mixed this up with the invert not properly masked.


原始Issue: https://github.com/bdring/Grbl_Esp32/issues/318

喜欢 (0)