Description
Controller Board
Grbl_ESP CNC Controller 4 Axis External Drivers V2.0
https://github.com/bdring/4_Axis_External_Driver
Help From Board Vendor
-
YesNoNot Applicable
Machine Description
Chinese CNC6040 with original control board and 0.8kw VFD spindle.
FluidNC step/dir outputs are connected to the parallel port input of that control board.
The same configuration has been running with grbl for years without issues.
Stepper drivers are included in the control board (TB6560AH)
Limit switches are NO directly connected to the “4 Axis External Drivers” pcb.
NowForever VDF connected to RS485 port of the board.
No sd card inserted into the slot.
Board running at 24V (yes i made sure the buck converter and input cap can handle that, double and triple checked the schematic to make sure i wouldn’t fry anything by doing that)
Input Circuits
NO switches connected to the isolated inputs of the "4 Axis External Drivers V2.0" board. Just a wire and a switch.
Configuration file
Config file:
name: "CNC 6040"
board: "Grbl_ESP32 4 Axis External Drives V2.0"
start:
must_home: true
deactivate_parking: true
check_limits: true
control:
feed_hold_pin: NO_PIN
cycle_start_pin: NO_PIN
stepping:
engine: RMT
idle_ms: 250
dir_delay_us: 1
pulse_us: 2
disable_delay_us: 1
axes:
shared_stepper_disable_pin: gpio.13:low
shared_stepper_reset_pin: NO_PIN
x:
steps_per_mm: 320
max_rate_mm_per_min: 800
acceleration_mm_per_sec2: 15
max_travel_mm: 397
soft_limits: true
homing:
cycle: 2
allow_single_axis: true
positive_direction: true
mpos_mm: 0
seek_mm_per_min: 800.000
feed_mm_per_min: 25.000
settle_ms: 250
seek_scaler: 1.100
feed_scaler: 1.100
motor0:
limit_pos_pin: gpio.34:low
hard_limits: true
pulloff_mm: 1
standard_stepper:
direction_pin: gpio.2
step_pin: gpio.0
motor1:
null_motor:
y:
steps_per_mm: 320
max_rate_mm_per_min: 800
acceleration_mm_per_sec2: 15
max_travel_mm: 583
soft_limits: true
homing:
cycle: 2
allow_single_axis: true
positive_direction: false
mpos_mm: 0
seek_mm_per_min: 800.000
feed_mm_per_min: 25.000
settle_ms: 250
seek_scaler: 1.100
feed_scaler: 1.100
motor0:
limit_neg_pin: gpio.35:low
hard_limits: true
pulloff_mm: 1
standard_stepper:
direction_pin: gpio.15:low
step_pin: gpio.26
motor1:
null_motor:
z:
steps_per_mm: 320
max_rate_mm_per_min: 800
acceleration_mm_per_sec2: 25
max_travel_mm: 73
soft_limits: true
homing:
cycle: 1
allow_single_axis: true
positive_direction: true
mpos_mm: 0
seek_mm_per_min: 600.000
feed_mm_per_min: 25.000
settle_ms: 250
seek_scaler: 1.100
feed_scaler: 1.100
motor0:
limit_pos_pin: gpio.36:low
hard_limits: true
pulloff_mm: 1
standard_stepper:
direction_pin: gpio.33:low
step_pin: gpio.27
motor1:
null_motor:
spi:
miso_pin: gpio.19
mosi_pin: gpio.23
sck_pin: gpio.18
sdcard:
cs_pin: gpio.5
card_detect_pin: NO_PIN
coolant:
flood_pin: NO_PIN
mist_pin: gpio.21
probe:
pin: gpio.32:low:pu
check_mode_start: true
NowForever:
uart:
txd_pin: gpio.17
rxd_pin: gpio.4
rts_pin: gpio.16
baud: 9600
mode: 8N1
modbus_id: 1
tool_num: 0
speed_map: 0=0% 24000=100%
Output of $CD:
board: Grbl_ESP32 4 Axis External Drives V2.0
name: CNC 6040
meta:
stepping:
engine: RMT
idle_ms: 250
pulse_us: 2
dir_delay_us: 1
disable_delay_us: 1
segments: 12
axes:
shared_stepper_disable_pin: gpio.13:low
shared_stepper_reset_pin: NO_PIN
x:
steps_per_mm: 320.000
max_rate_mm_per_min: 800.000
acceleration_mm_per_sec2: 15.000
max_travel_mm: 397.000
soft_limits: true
homing:
cycle: 2
allow_single_axis: true
positive_direction: true
mpos_mm: 0.000
feed_mm_per_min: 25.000
seek_mm_per_min: 800.000
settle_ms: 250
seek_scaler: 1.100
feed_scaler: 1.100
motor0:
limit_neg_pin: NO_PIN
limit_pos_pin: gpio.34:low
limit_all_pin: NO_PIN
hard_limits: true
pulloff_mm: 1.000
standard_stepper:
step_pin: gpio.0
direction_pin: gpio.2
disable_pin: NO_PIN
motor1:
limit_neg_pin: NO_PIN
limit_pos_pin: NO_PIN
limit_all_pin: NO_PIN
hard_limits: false
pulloff_mm: 1.000
null_motor:
y:
steps_per_mm: 320.000
max_rate_mm_per_min: 800.000
acceleration_mm_per_sec2: 15.000
max_travel_mm: 583.000
soft_limits: true
homing:
cycle: 2
allow_single_axis: true
positive_direction: false
mpos_mm: 0.000
feed_mm_per_min: 25.000
seek_mm_per_min: 800.000
settle_ms: 250
seek_scaler: 1.100
feed_scaler: 1.100
motor0:
limit_neg_pin: gpio.35:low
limit_pos_pin: NO_PIN
limit_all_pin: NO_PIN
hard_limits: true
pulloff_mm: 1.000
standard_stepper:
step_pin: gpio.26
direction_pin: gpio.15:low
disable_pin: NO_PIN
motor1:
limit_neg_pin: NO_PIN
limit_pos_pin: NO_PIN
limit_all_pin: NO_PIN
hard_limits: false
pulloff_mm: 1.000
null_motor:
z:
steps_per_mm: 320.000
max_rate_mm_per_min: 800.000
acceleration_mm_per_sec2: 25.000
max_travel_mm: 73.000
soft_limits: true
homing:
cycle: 1
allow_single_axis: true
positive_direction: true
mpos_mm: 0.000
feed_mm_per_min: 25.000
seek_mm_per_min: 600.000
settle_ms: 250
seek_scaler: 1.100
feed_scaler: 1.100
motor0:
limit_neg_pin: NO_PIN
limit_pos_pin: gpio.36:low
limit_all_pin: NO_PIN
hard_limits: true
pulloff_mm: 1.000
standard_stepper:
step_pin: gpio.27
direction_pin: gpio.33:low
disable_pin: NO_PIN
motor1:
limit_neg_pin: NO_PIN
limit_pos_pin: NO_PIN
limit_all_pin: NO_PIN
hard_limits: false
pulloff_mm: 1.000
null_motor:
kinematics:
Cartesian:
spi:
miso_pin: gpio.19
mosi_pin: gpio.23
sck_pin: gpio.18
sdcard:
cs_pin: gpio.5
card_detect_pin: NO_PIN
control:
safety_door_pin: NO_PIN
reset_pin: NO_PIN
feed_hold_pin: NO_PIN
cycle_start_pin: NO_PIN
macro0_pin: NO_PIN
macro1_pin: NO_PIN
macro2_pin: NO_PIN
macro3_pin: NO_PIN
coolant:
flood_pin: NO_PIN
mist_pin: gpio.21
delay_ms: 0
probe:
pin: gpio.32:low:pu
check_mode_start: true
macros:
startup_line0:
startup_line1:
macro0:
macro1:
macro2:
macro3:
start:
must_home: true
deactivate_parking: true
check_limits: true
parking:
enable: false
axis: Z
target_mpos_mm: -5.000
rate_mm_per_min: 800.000
pullout_distance_mm: 5.000
pullout_rate_mm_per_min: 250.000
user_outputs:
analog0_pin: NO_PIN
analog1_pin: NO_PIN
analog2_pin: NO_PIN
analog3_pin: NO_PIN
analog0_hz: 5000
analog1_hz: 5000
analog2_hz: 5000
analog3_hz: 5000
digital0_pin: NO_PIN
digital1_pin: NO_PIN
digital2_pin: NO_PIN
digital3_pin: NO_PIN
arc_tolerance_mm: 0.002
junction_deviation_mm: 0.010
verbose_errors: false
report_inches: false
enable_parking_override_control: false
use_line_numbers: false
planner_blocks: 16
NowForever:
uart:
txd_pin: gpio.17
rxd_pin: gpio.4
rts_pin: gpio.16
cts_pin: NO_PIN
baud: 9600
mode: 8N1
modbus_id: 1
tool_num: 0
speed_map: 0=0.000% 24000=100.000%
off_on_alarm: false
Startup Messages
Will add proper boot messages tomorrow. For now only without being plugged into the board and with no VFD connected. (that's why its complaining about the limits and the VFD)
Resetting MCU
ets Jun 8 2016 00:22:57
rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0030,len:1184
load:0x40078000,len:12812
load:0x40080400,len:3032
entry 0x400805e4
[MSG:INFO: FluidNC v3.6.2]
[MSG:INFO: Compiled with ESP32 SDK:v4.4.1-1-gb8050b365e]
[MSG:INFO: Local filesystem type is spiffs]
[MSG:INFO: Configuration file:config.yaml]
[MSG:DBG: Running after-parse tasks]
[MSG:DBG: Checking configuration]
[MSG:INFO: Machine CNC 6040]
[MSG:INFO: Board Grbl_ESP32 4 Axis External Drives V2.0]
[MSG:INFO: SPI SCK:gpio.18 MOSI:gpio.23 MISO:gpio.19]
[MSG:INFO: SD Card cs_pin:gpio.5 detect:NO_PIN]
[MSG:INFO: Stepping:RMT Pulse:2us Dsbl Delay:1us Dir Delay:1us Idle Delay:250ms]
[MSG:INFO: Axis count 3]
[MSG:INFO: Shared stepper disable gpio.13:low]
[MSG:INFO: Axis X (-397.000,0.000)]
[MSG:INFO: Motor0]
[MSG:INFO: standard_stepper Step:gpio.0 Dir:gpio.2 Disable:NO_PIN]
[MSG:INFO: X Pos Limit gpio.34:low]
[MSG:DBG: Updating X Pos Limit]
[MSG:DBG: X Pos Limit 1]
[MSG:INFO: Motor1]
[MSG:INFO: Axis Y (0.000,583.000)]
[MSG:INFO: Motor0]
[MSG:INFO: standard_stepper Step:gpio.26 Dir:gpio.15:low Disable:NO_PIN]
[MSG:INFO: Y Neg Limit gpio.35:low]
[MSG:DBG: Updating Y Neg Limit]
[MSG:DBG: Y Neg Limit 1]
[MSG:INFO: Motor1]
[MSG:INFO: Axis Z (-73.000,0.000)]
[MSG:INFO: Motor0]
[MSG:INFO: standard_stepper Step:gpio.27 Dir:gpio.33:low Disable:NO_PIN]
[MSG:INFO: Z Pos Limit gpio.36:low]
[MSG:DBG: Updating Z Pos Limit]
[MSG:DBG: Z Pos Limit 1]
[MSG:INFO: Motor1]
[MSG:INFO: Kinematic system: Cartesian]
[MSG:INFO: NowForever Spindle Uart Tx:gpio.17 Rx:gpio.4 RTS:gpio.16 Baud:9600]
[MSG:INFO: Using spindle NowForever]
[MSG:INFO: Mist coolant gpio.21]
[MSG:INFO: Probe Pin: gpio.32:low:pu]
[MSG:INFO: WiFi is disabled]
[MSG:DBG: VFD setState:0 SpindleSpeed:0]
[MSG:DBG: RPM:0 mapped to device units:1073423424]
Grbl 3.6 [FluidNC v3.6.2 (wifi) '$' for help]
[MSG:INFO: Check limits]
[MSG:INFO: '$H'|'$X' to unlock]
[MSG:INFO: VFD RS485 Unresponsive]
User Interface Software
Universal Gcode Platform 20220917
What happened?
Sometimes axis just randomly “shift” while executing gcode.
In this example the X axis shifted towards +X about 2mm.
Other times the Z axis was shifting towards -Z an unknown amount.
This causes parts of the cuts to be misaligned with the rest or travel moves to intersect with the part.
The attached pictures show the result (was repeatable 3x) vs the expected part (ugs preview and camotics simulation)
The misaligned features so far were only “G2” commands as far as i could tell (not 1000% sure though).
Also not sure if that’s related or not but after aborting the execution of that file i remember having issues with homing. Some axis would still report an alarm even though as far as i could tell none of the limit switches were triggered. Motor movement while homing a second time was also erratic.
GCode file in question:
Generated using Version: 0.21.30193 (Git) AppImage and grbl post processor with the following options:
–no-show-editor –translate_drill
Other Information
Earlier the same day i cut 3 parts without issues (that included G2 spiral path codes as well, lots of them in fact) without issues.
The fourth part failed with the issues described above (didnt notice that yet).
After a few hours of the machine and host pc being completely powered down (plugs pulled) i tried to cut the part in the picture.
Rebooted and power cycled the machine after the first failure without any effect.
Metadata
Assignees
No one assigned
Labels
Projects
No projects
Milestone
No milestone
Relationships
None yet
Development
No branches or pull requests
Participants
![[gnea/grbl-Mega Issue#1] $ command extentions](https://www.grblhal.com/wp-content/themes/gitphp/timthumb.php?src=https://www.grblhal.com/wp-content/themes/gitphp/assets/img/pic/7.jpg&h=110&w=185&q=90&zc=1&ct=1)
![[gnea/grbl-Mega Issue#2] Better interrupt priorities](https://www.grblhal.com/wp-content/themes/gitphp/timthumb.php?src=https://www.grblhal.com/wp-content/themes/gitphp/assets/img/pic/3.jpg&h=110&w=185&q=90&zc=1&ct=1)
![[gnea/grbl-Mega Issue#3] ATMega16U2 virtual com port on ATMega2560](https://www.grblhal.com/wp-content/themes/gitphp/timthumb.php?src=https://www.grblhal.com/wp-content/themes/gitphp/assets/img/pic/9.jpg&h=110&w=185&q=90&zc=1&ct=1)
![[gnea/grbl-Mega Issue#4] Real-time adjustable feedrates](https://www.grblhal.com/wp-content/themes/gitphp/timthumb.php?src=https://www.grblhal.com/wp-content/themes/gitphp/assets/img/pic/4.jpg&h=110&w=185&q=90&zc=1&ct=1)
Activity
MitchBradley commented on Oct 15, 2022
The first thing that jumps out at me is the pulse_us value. That is very short for an optocoupled input, especially if it is being driven from 3.3V instead of 5V. But even if it is a direct input to the TB6560AH chip, it is still way out of spec for the TB6560’s CLK (their name for STEP) input. According to https://toshiba.semicon-storage.com/info/docget.jsp?did=11252&prodName=TB6560AHQ :
That gives the shortest pulse that is tested in production as 30 us, and maybe you can go down to 10 us with a different value for the oscillator capacitor. Even at 10 us, a 2 us pulse is badly out of spec. It appears that the TB6560 needs about 40 cycles of the oscillator to reliably recognize a step pulse on the CLK input. At the standard oscillator frequency of 130 kHz, a 2 us pulse is less than 1/4 of an OSC clock.
Your max step rate is 320 steps/mm * 800 mm/min / 60 sec/min = 4267 steps/sec, or 234 us/step. At that rate there is no need for a short pulse.
I suspect that the reason it works with grbl-mega is because grbl-mega is either configured for a longer pulse, or maybe it cannot even make shorter pulses. I have seen references that suggest it is limited to about about 30 khz pulsing.
So the first thing I would try, if you are willing to try anything, is to increase pulse_us to say 40 (after upgrading to 3.6.3).
This analysis, of course, is not guaranteed to be the solution to your problem, but it does explain all of the symptoms. If the driver is missing pulses because they are too short for it to register them, the motion is definitely going to be erratic. The funky limit behavior is very likely to be fixed by 3.6.3.
bdring commented on Oct 15, 2022
What is your $0 (Step pulse time, microseconds) setting in Grbl. I think the default is 10.
The FluidNC default is 4. You have it at 2.
LukasGossmann commented on Oct 15, 2022
Oh damn it didn’t even occur to me that the driver might not support 2µs pulses since that is more or less the standard value everything uses i guess. I vaguely remember setting that value to 2 because using anything higher caused some other weird issues with step pulse generation (I looked at the outputs with an oscilloscope since the motors were just making weird noises)
I’ll try setting the value to 10µs and see what the step generation does in this version.
Also turns out grbl-Mega uses 10µs pulses (which is the max FluidNC supports) by default which is also what it is configured to in my setup. Still a bit under spec i guess but apparently good enough to never come up as an issue.
The input to the opto isolator of the parallel port is driven at 5V though as the 4 axis external driver pcb has some buffer ics on it.
bdring commented on Oct 15, 2022
I think our min is 0. We should look at both limits.
LukasGossmann commented on Oct 15, 2022
Yeah min is 0 according to the documentation (thats where i got the 10 from too)
bdring commented on Oct 15, 2022
Anything that uses the TB6560 is about as low end as it gets. I would try 10 and lower your expectations on speed to about 33KHz.
LukasGossmann commented on Oct 15, 2022
Those drivers werent really my pick… thats just what was included in the control box of that machine
bdring commented on Oct 15, 2022
TB6600 was supposed to replace those almost a decade ago.
MitchBradley commented on Oct 15, 2022
If you want to conform to the datasheet I would consider going above 10. Especially if there are optocouplers, which will further interfere with the signal timing.
MitchBradley commented on Oct 15, 2022
Oh, you are right. 10 is the max. Maybe we should increase that.
bdring commented on Oct 15, 2022
I think 10 might work. A lot of Grbl users have had success with the default.
LukasGossmann commented on Oct 15, 2022
I just hooked it up to the scope and it looks like 10 works just fine now even though i dont see the 10us pulses i am expecting. Kinda weird that i remember it not working entirely when i first configured it that way…. Whatever that was its fine now.
Oh and quick question. From the scope traces it looks like FluidNC does dynamically shorten and lengthen the step low and high duration’s depending on the speed that is needed. Is that true ?
I just took the 2µs config and moved the X axis with G0 X20 F800 and only got pulses of 80µs low and 160µs high while at max speed (not accelerating or decelerating). This stays the same even if i i bump the speed in the config and in the G0 up to 1500mm/min…..
If the timings are really like that (or my sleepy brain is messing something up…) that would mean i was inadvertently running the drivers well within spec even though the config says otherwise…
MitchBradley commented on Oct 15, 2022
I will do some scope traces. The way it is supposed to work is that the pulse high time (or low depending on polarity) is constant and the only thing that changes with step rate is the inactive time.
LukasGossmann commented on Oct 15, 2022
That sounds like what i would have expected too.
Just changed the config to 4µs pulses and now got 320µs high and 80µs low so the high duration did double as expected. (again at F1500)
The inactive time (low in my case) does lengthen as it should, the high duration always stays at a constant 80µs though.
Oh also in case it matters that is still on 3.6.2!
MitchBradley commented on Oct 15, 2022
Please please please switch to 3.6.3. It might not change this behavior but back-testing with old code is a pain.
9 remaining items
DEST1981 commented on Oct 16, 2022
I used Candle_1.2.15b to move the tool. Maybe this is the problem?
Speed really stops increasing after a certain level. And the distance traveled by the tool also decreases.
MitchBradley commented on Oct 16, 2022
@DEST1981 There is an important reason why we ask you to start a new issue, even if your problem seems similar to another ticket. The reason is that we need complete information about each specific setup in order to think clearly about a problem and to reproduce it if necessary. Subtle details about controller hardware, configurations, senders, test conditions, etc. often are the key to the diagnosis. When people do “metoo” on a ticket, it makes it hard for us to keep track of what info in the ticket pertains to what user. That causes us to waste time trying to sort out what is what, and we often make mistakes as a result. So if you want the attention of the developers, you will need to play by our rules and make your own ticket. If you pile onto someone else’s ticket, we cannot help you, and it impacts our ability and willingness to engage with the original ticket, because of the confusion factor. If there is commonality between tickets, we will pick that up and factor it into our analysis. But we really really really need separation so we can keep track of exact configurations and system rollups.
DEST1981 commented on Oct 16, 2022
Yes, of course I did.
MitchBradley commented on Oct 16, 2022
There is something strange about GPIO initialization. I can reproduce your results with longer than normal pulses, but only some of the time. Sometimes after a CTRL-R reset, the pulses are the correct length; other times, they are much too long.
added a commit that references this issue on Oct 16, 2022
Fix #668 – erratic step pulse widths in RMT mode
MitchBradley commented on Oct 16, 2022
I think that 26a2b9f fixes it. With that patch, I can no longer repro the problem; pulses are always the correct length.
ModuloFS commented on Oct 16, 2022
This sound like the behaviour of my controller, described in issue #667
MitchBradley commented on Oct 17, 2022
Please try this https://github.com/bdring/FluidNC/releases/tag/v3.6.4-pre1
LukasGossmann commented on Oct 18, 2022
Looks good so far
Did some testing with the scope hooked up and wasn’t seeing any weird long pulses or the incorrect idle level anymore. Ill do some testing with it connected to the CNC on the weekend and report back if the shifting of the gcode is also gone or if that still persists.
Thanks for the quick and very in depth help and the fix
@ModuloFS Your step signal looks the same as what i was seeing. Try the v3.6.4-pre1 and see if it works for you too.
added
on Oct 18, 2022
closed this as completedon Oct 18, 2022
ModuloFS commented on Oct 21, 2022
First tests with v3.6.4-pre1 showed no problems with homing so far and signal levels seems correct too!
added a commit that references this issue on Oct 26, 2022
Merge pull request #673 from bdring/Fix668
mentioned this on Feb 20
mentioned this on May 7