Stop working and undefined movement if choose SPINDLE_TYPE_DAC

[floggy22]

The controller shows undefined behavior if i use SPINDLE_TYPE_DAC SPINDLE_TYPE_PWM, SPINDLE_TYPE_LASER.

Some times it stops but do not crash, some times it does not react or only move in one direction. In some cases it shows grbl error ID23 or ID33

If i choose SPINDLE_TYPE_NONE it works perfect without any problems. It is only a test maschine, i try it with a nodemcu32 and esp32devkit1. Same result on both controllers.

What version of the firmware are you using? Lastest master 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:2 load:0x3fff0018,len:4 load:0x3fff001c,len:1044 load:0x40078000,len:8896 load:0x40080400,len:5828 entry 0x400806ac

[MSG:Grbl_ESP32 Ver 1.2a Date 20200428] [MSG:Compiled with ESP32 SDK:v3.2.3-14-gd3e562907] [MSG:Using machine:CNC6] [MSG:Axis count 3] [MSG:RMT Steps] [MSG:DAC spindle on Pin:25]

Grbl 1.2a ['$' for help]

Is the problem repeatable? YES

I added my maschine file but it is also repeatable with test_drive.h and set a SPINDLE_TYPE other then NONE. I tested with CNCjs 1.9,22 and with bCNC 0.9.14-dev. I disable all options (wifi, bluethooth., sd card, ...) in config.h in the eyecatch block.

gcode_config_maschine_file.zip

[bdring]

I am not seeing those errors, but I have noticed some synchronization errors. This means the spindle is not turning on/off exactly when it should.

I'll fix that and keep looking at your issue.

[bdring]

I see you have 2 functions on the same pin.

#define Y_STEP_PIN                  GPIO_NUM_33
#define SPINDLE_ENABLE_PIN          GPIO_NUM_33

That needs to be fixed.

Can you send the response to a $+ command? That would help me replicate your setup.

[floggy22]

OK, i fixed it but still an error. I try ugs 2.0beta and get an output. I assume it has something to do with the feedrate. If i use the same gcode without set a spindle type it works.

Which tools do you use for gcode sending? Maybe i need better tools to debug and it is an error in my setup.

$+ output: $+ $0=3 $1=250 $2=0 $3=0 $4=0 $5=1 $6=1 $10=3 $11=0.010 $12=0.002 $13=0 $20=0 $21=0 $22=0 $23=3 $24=200.000 $25=2000.000 $26=250 $27=1.000 $30=25000.000 $31=0.000 $32=0 $33=5000.000 $34=0.000 $35=0.000 $36=100.000 $80=0 $81=0 $82=0 $83=0 $84=0 $90=0.000 $91=0.000 $92=0.000 $93=0.000 $94=0.000 $100=400.000 $101=400.000 $102=400.000 $110=5000.000 $111=5000.000 $112=1800.000 $120=400.000 $121=500.000 $122=600.000 $130=300.000 $131=300.000 $132=300.000 $140=0.250 $141=0.250 $142=0.250 $150=50.000 $151=50.000 $152=50.000 $160=16 $161=16 $162=16 $170=16 $171=16 $172=16 ok

ugs error. [Error] An error was detected while sending 'G01X1.4042Y33.3470': Guru Meditation Error: Core 0 panic'ed (StoreProhibited). Exception was unhandled. Streaming has been paused. [Error] Error while processing response <An error was detected while sending 'G01X1.4042Y33.3470': Guru Meditation Error: Core 0 panic'ed (StoreProhibited). Exception was unhandled. Streaming has been paused.> Core 0 register dump: PC : 0x400d90bb PS : 0x00060d30 A0 : 0x800d6468 A1 : 0x3ffb3e80
A2 : 0x00000000 A3 : 0x3ffc1b1c A4 : 0x3ffc1b64 A5 : 0x3ffc1b6c
A6 : 0x00000002 A7 : 0x3ffc105c A8 : 0x3ffc1bb8 A9 : 0x3ffb3e70
A10 : 0x00000823 A11 : 0x40c04700 A12 : 0x0000000e A13 : 0x0000208e
A14 : 0x7ff00000 A15 : 0x7ff04700 SAR : 0x00000002 EXCCAUSE: 0x0000001d
EXCVADDR: 0x00000020 LBEG : 0x40002390 LEND : 0x4000239f LCOUNT : 0x00000000
Backtrace: 0x400d90bb:0x3ffb3e80 0x400d6465:0x3ffb3ef0 0x400d649b:0x3ffb3f10 0x400d69c3:0x3ffb3f40 0x400d972b:0x3ffb3f60 0x400d5626:0x3ffb3f80 0x400d7c85:0x3ffb3fa0 0x400d7e1a:0x3ffb3fc0 0x4008a145:0x3ffb3fe0 Rebooting...

[bdring]

Thanks, I can run your file with your machine definition and settings. I do not get an error, but I am seeing a parsing error that causes bad values to get into the gcode.

It is similar to this issue with the ESP32. I will figure out what is wrong and why the problem is happening to me again.

Sorry for the issues.

[bdring]

I am still trying having trouble with your files. Can you tell me the program you are using to create the gcode? Do you have a source file for the artwork, so I can try it in my cam programs.

The (StoreProhibited) error generally means the ESP32 is trying to store something in memory in a place it is not allowed to. This can happen with out of bound arrays or objects that are null.

You could help by compiling and uploading the firmware using the Arduino IDE and plugging the backtrace information into the exception decoder. The exception decoder will give to the exact line that caused the problem and where the function was called from.

You need to install the exception decoder. There are instructions here I cannot do it from my end, because it has to work the exact file from your compile. Also, while I am getting odd behavior, I do not get any crashes.

[floggy22]

For this file i use https://www.estlcam.de/. I have other files created with fusion 360 and the same problem. The source file can be found at https://svgsilh.com/image/2023449.html. The error did not occures when set spindle_type_none. If i use my maschine with version

define GRBL_VERSION "1.1f"

define GRBL_VERSION_BUILD "20200115"

everything runs smoothly with the same file. Other versions i did not try. Need some time to setup Arduino IDE.

By the way i like what you are doing. It is a great software!!

[floggy22]

If have make a screencast and put the logfile at the end. Maybe this helps.

screencast.zip log.txt

Result of the stack trace:

Decoding stack results 0x400d9157: st_prep_buffer() at C:\Users\flogg\AppData\Local\Temp\arduino_build_341637\sketch\stepper.cpp line 1321 0x400d6501: protocol_exec_rt_system() at C:\Users\flogg\AppData\Local\Temp\arduino_build_341637\sketch\protocol.cpp line 513 0x400d6537: protocol_execute_realtime() at C:\Users\flogg\AppData\Local\Temp\arduino_build_341637\sketch\protocol.cpp line 248 0x400d6a5f: protocol_buffer_synchronize() at C:\Users\flogg\AppData\Local\Temp\arduino_build_341637\sketch\protocol.cpp line 217 0x400d981b: sys_io_control(unsigned char, bool) at C:\Users\flogg\AppData\Local\Temp\arduino_build_341637\sketch\system.cpp line 551 0x400d56c2: mc_reset() at C:\Users\flogg\AppData\Local\Temp\arduino_build_341637\sketch\motion_control.cpp line 430 0x400d7d21: execute_realtime_command(unsigned char, unsigned char) at C:\Users\flogg\AppData\Local\Temp\arduino_build_341637\sketch\serial.cpp line 205 0x400d7eb6: serialCheckTask(void*) at C:\Users\flogg\AppData\Local\Temp\arduino_build_341637\sketch\serial.cpp line 134 0x4008a145: vPortTaskWrapper at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/freertos/port.c line 143

[MitchBradley]

The stack trace is very helpful. I see a possible problem already.

[MitchBradley]

Here is something to try: In stepper.c, change line 1321 from:

pl_block->millimeters = mm_remaining;

to

if (pl_block) pl_block->millimeters = mm_remaining;

[floggy22]

It changed behavior. The controller did not crash any more but will be very slow. It seems something blocks communication.

[MitchBradley]

Okay that is a good clue. There is a race condition in the code. I will have to map the entire behavior of that section of the code to understand the proper fix.

[BlueOrangeLive]

Hello I have similar problems so I also used the gcode file from floggy22. When I compile with SPINDLE_TYPE_PWM or SPINDLE_TYPE_LASER, the process stops in the middle or an axis travels to the limit switches. The connection then leaves. If I compile with SPINDLE_TYPE_NONE then the gcode file runs through to the end. Tested five times. mfg Jürgen

[bdring]

The master branch has been reverted to a working version. We are working to fix the spindle class version.

[bdring]

I think we found the problem, The ESP32 is very sensitive to floating point data types with interrupts. Grbl uses a floating value for the spindle speed. Typically people don't use spindle speeds with decimal points. We have switched the type to integer, but may move to a fixed point value, like milli-rpms in the future (100.005 RPM). The ultimate resolution is still dependent on the PWM signal, which is about 13bits at 5,000Hz.

I am not sure why the spindle classes raised this issue, because it was always floating point. There was probably a stability issue waiting to pop up.

The code is in the SpindleClass2 branch. I am still doing extensive testing, commenting and refactoring. I hope to merge it back in a few days.

Thank for for patience on this issue.

[floggy22]

I did a first test and it works. Tomorrow i try to test more. Great work!!

[bdring]

I have only fully tested None, PWM, Laser & BESC.

VFD looks good too, but I could improve the speed of communication.

Need to test Relay and DAC.

[floggy22]

I do some more test for DAC. I found, that the max output is by around "m3 s160". My spindle max value is 25000. The controll value is only between 0 and 160.

[bdring]

The DAC spindle should be working now.

[floggy22]

Thank you. My tests are done without an error.