Made PWM frequency changable by $33 setting#4
Conversation
|
@chamnit Are you OK reserving $33 for PWM frequency? @cprezzi @chamnit If the frequency is configurable, then we should probably make the other parameters configurable also. We'd need to reserve config numbers for replacements of:
These, together with the existing rpm_min and rpm_max settings would allow full PWM tuning without recompiling. |
|
It's annoying that different K40's have different steps-per-mm. |
|
@tbfleming : I'll follow your lead on this one. $32+ settings were intended to be reserved for spindle/laser settings anyway. I'm ok with everything proposed so far, except PWM period should probably be expressed in frequency. The values are easier to understand as Hz, rather than micro- or milli-seconds. I was also thinking about making PWM frequency something that can be altered in g-code in the future as an override. This would make it possible for LW to tailor tool paths for different operations that require different frequencies and let users quickly test materials. Thinking that this would be a scalar of the PWM frequency setting like the other overrides. |
That's what @cprezzi did :)
That would rock! |
|
@tbfleming If we are thinking about additional $settings, what about the PWM pin? This could cancel the need for multiple compiled versions. |
|
@cprezzi : FYI, I'm planning on making just about everything I can a setting. However, I'm struggling to understand why the PWM pin would need one and how it could change. |
|
@chamnit Smoothieboard provides a set of pins to choose from, so different users end up hooking their laser control to different pins. I've been providing .bin files for the two most common choices. |
|
@chamnit There are multiple "smoothie compatible" (LPC1769) boards out there, but not all use the same pin for the Spindle/Laser PWM. It's also depending if the user likes to use the heatbed mosfet output (like for K40 lasers), or a logic level pin (like for diode laser engravers). Mosfet is additionally inverted (pull down). |
|
@chamnit For your info: Today I have implemented a 4. axes (A) into my fork (see https://github.com/cprezzi/grbl-LPC/tree/more-axis). Does it make sence that I do a PR (just for grbl_LPC), or do you plan to add more axis anyway? |
|
@tbfleming In that branch, I have also moved all the default settings and pin mappings to cpu_map.h and defaults.h, so the board and machine can be set by two simple #define in config.h ;) |
|
@cprezzi @tbfleming : Ok. Makes sense. However, this is something board specific, rather than a generalized setting. I think it'll create some problems with some of the assumptions I made with the new Grbl HAL. There is no separate set of tools to create these types of settings and make sure they get initialized. Not a big deal, but something I should get installed before public release. Perhaps we need to declare a set of |
|
@cprezzi : I'll add a 4th axis in the next major release. But, I can't say when that will be, because I have a upcoming NASA project. I'm developing a new Mars solar array farm concept pretty much solo. It's going to eat up a huge chunk of my time and energy for the rest of the year, starting in June. However, I'll find the time somehow, as I always do. So, feel free to do what you need to do. I can always use your code or pull from it when it comes time. |
|
@chamnit I always knew you are the guy for rocket science ;) Good luck! 👍 |
|
I added $33-$36 for spindle control. My laser isn't set up right now and I had to return the borrowed oscope, so I can't test it. I pointed users to @cprezzi's branch for releases since that branch is moving faster. |
|
Would it help to make @cprezzi a collaborator for this branch? |
|
@chamnit yes please |
|
Thanks @chamnit @tbfleming ! |
Added a description to each option, including the option codes (ordered by $key).
Thanks for the helpful code comments!
…1.27 on the sbase board
Add additional docker info to help new users
changes to allow probing on pin 1.27
Based on code provided by Jim Fong for Cohesion3D
Add open drain configuration per axis
uint8_t overflows the 32 bit status register
Fix for safety door, feed hold and cycle start bits.
Correct 32bit mask for probe invert. Probe Physically Open $6=0 <Alarm|WPos:0.000,0.000,0.000,0.000|FS:0,0|Pn:ZA|WCO:0.000,0.000,0.000,0.000> Probe is not triggered $6=1 <Alarm|WPos:0.000,0.000,0.000,0.000|FS:0,0|Pn:PZA|Ov:100,100,100> Probe is triggered Probe Physically Closed $6=0 <Alarm|WPos:0.000,0.000,0.000,0.000|FS:0,0|Pn:ZA|WCO:0.000,0.000,0.000,0.000> Probe is not triggered $6=1 <Alarm|WPos:0.000,0.000,0.000,0.000|FS:0,0|Pn:PZA|Ov:100,100,100> Probe is triggered
Fix for issue #49 (probe invert mask 8 bit instead of 32)
Corrected wrong digipot wiper mapping for MKS SBASE boards.
Correcting back to former wiper registers
7 participants
I have made the PWM frequency changable through the $33 param, so laser engraver users can easily experiment with that param.
Default frequency is set to 5'000Hz (=200us PWM period), which is a good mix for grayscale engraving and cutting.
Higher frequencies (like 20'000Hz) tend to cut deeper with less burning and lower frequencies (like 2'500Hz) could deliver slightliy better grayscale representation. The effect depends on many factors like the laser power supply, material, focus, feed...