Lots of new settings

[bdring]

A suggestions to add the $33 setting (spindle PWM frequency) from grbl-LPC snowballed into a bunch of stuff. I had been holding back on adding to the settings. Once I decided to change them, I added several others to match grbl_LPC. I also added setting that apply to SPI (Trinamic) motors.

This represents about 8 hours of work and testing. It impacted a lot of files, so I hope all still works right. I compiled all cpu maps and put several of them on the oscilloscope and logic analyzer

Several new $$ settings have been added....

• $33 PWM frequency. This allows you to change the base frequency of the PWM signal. The default is 5000.0
• $34 Spindle off duty in percent default is 0.0
• $35 Spindle min speed duty in percent. Default is 0.0
• $36 Spindle max speed duty in percent Default is 100.0
• $140 (thru $145 depending on axis count) This is used to set the run current on SPI (Trinamic) stepper motors. It is a float value in amps. Default is 0.25
• $150 (thru $155 depending on axis count) This is used to set the hold current on SPI (Trinamic) stepper motors. It is a float value in percent, Default is 33
• $160 (thru $165 depending on axis count) This is used to set the microstepping level on SPI (Trinamic) stepper motors. The default is 16

Some senders cannot handle any changes to things like this. some even hard crash. To head off a bunch of support issues, #define SHOW_EXTENDED_SETTINGS has been added and commented out by default. This means you will not see the new ones, by default. You can still set them, but they will not display when you send $$. You can enable the reporting of all setting by uncommenting #define SHOW_EXTENDED_SETTINGS

The default values for the $$ settings work quite a bit different now. Default values are used the first time to start Grbl or if you send $RST=$ (to restore them). Now the generic default definitions check to see if they are defined somewhere else before being defined (in defaults.h). This allows you to to put your own defaults in a cpu_map. You only need to define the ones that are important or different for your machine. The reset will be the default defaults in defaults.h.

I still need to verify a few things to make sure there are no edge case issues with the Trinamic stuff. After that it will be pushed to the devt branch. Display of the new settings are not in the WebUI yet.

[hedon77]

A great solution. It works well for me and solves previous problems. THX

[ghost]

Could you also add a setting for stallguard threshold in a future release? I'm designing a board to put in a laser cutter that will use TMC5160 stepper drivers and stallguard for the endstops. Currently I hard code the stallguard value, but a setting would be much better. Thanks!

[bdring]

I have $170 - $175 as stallguard on my current project. You still need to code the mode and thresholds, but I added a cleaner way to do that.

[bdring]

@Dan018

I also use $179 (0 or 1) to put the controller into a stallguard tuning mode. It will display real time stallguard and TSTEP values to help you find the best speed and stallguard value to use for sensorless end stops.

[ghost]

To the uninitiated how would I get $170 - $175 to be recognised as StallGuard thresholds?

Presumably I would have to edit grbl_trinamic.cpp to include something like

TRINAMIC_A.sg_stall_value($170)

where $170 is the value stored by the $170 setting. How you call the setting (i.e. what I would put inside the brackets) is what I don't know.

[bdring]

The Trinamic drivers have so many options, there is no easy way to set them up via cpu_map options alone. For Stallguard to work, you also need to setup speed thresholds. Many people will also probably want to exit stallguard mode and go back to the quietest modes. So you will have to add some code on your own.

The Wallbot branch has all the new features. Look at the machine_trinamic_setup() function. This allows you to add your own machine specific trinamic options without touching the main code.

There are also a number of other features implemented in wallbot.cpp. It has a method to live tune stallguard and ways to implement custom homing.

I do not get a lot of time to work on the wallbot project, due to contract jobs with higher priority, so I don't know when those features will make it into the main branch.

[xnaron]

I've got my esc spindle control working. Thanks for adding these new parameters. One thing I do notice is that when I home an axis my esc loses the PWM signal (or invalid not sure as I haven't checked it on the logic analyzer). This causes my esc to beep until I turn it on and off again (S1000 M3 followed by S0 M3).

[bdring]

@xnaron I'll check the code. Homing is a special case and might be turning the PWM off. I'll look at the code when I get home from vacation late next week.

FYI: On my ESC, I only need to do max /min PWM once. After power cycling, I do not need to do it again.

[bdring]

@xnaron

Can you put #define SHOW_EXTENDED_SETTINGS in your CPU_MAP, recompile and load the new firmware.

Then send $$ to get all the settings. Paste $33 through $36 in a reply to this issue.

[xnaron]

Thank you. Yes I used the extended settings to get it working.

$33=50.000 $34=3.500 $35=3.500 $36=10.000

I picked the values above from the comments you had in the cpu_map.h code. I noticed another case yesterday where the esc started to beep again was during auto bed levelling in BCNC. I was doing a 36 point bed level for a pcb routing operation. After it stopped moving the esc stopped beeping. However the spindle does stay on after turning it on with S1000 M3 when I run the gcode to isolate the traces.

[bdring]

OK, Thanks.

Those setting look right. I can't see any obvious reasons the PWM is stopping. Can you paste all of your $$ settings.

I'll have to test on real hardware when I get home.

[xnaron]

Sure.

$0=3 $1=255 $2=0 $3=0 $4=0 $5=0 $6=0 $10=3 $11=0.010 $12=0.002 $13=0 $20=0 $21=1 $22=1 $23=0 $24=4000.000 $25=4000.000 $26=250 $27=1.000 $30=1000.000 $31=0.000 $32=0 $33=50.000 $34=3.500 $35=3.500 $36=10.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=321.400 $101=321.400 $102=100.000 $110=10000.000 $111=10000.000 $112=200.000 $120=500.000 $121=500.000 $122=200.000 $130=170.000 $131=260.000 $132=20.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

[bdring]

@xnaron I found a typo in the code. It results in a PWM pulse below the minimum. This could cause the resetting. I need to do some more testing to check all the modes to make sure the pulse does not turn off in ESC type operations.

[bdring]

@xnaron I found another issue and I think everything works now. I think the errors crept in when the $$ settings were added. I'll push the code tomorrow into Devt, then master

[xnaron]

thank you

[bdring]

Changes pushed to Devt Branch.

[xnaron]

Thanks will test this week.