From 89957db3fb1bbcab1f78bc5c271373c2fe79de1d Mon Sep 17 00:00:00 2001 From: luzpaz Date: Sun, 19 Feb 2023 11:31:39 +0000 Subject: [PATCH] Fix various typos Found via `codespell -q 3 -S ./.git,./doc/log -L everytime,tread` --- doc/markdown/interface.md | 6 +++--- doc/markdown/jogging.md | 2 +- doc/markdown/laser_mode.md | 2 +- doc/markdown/settings.md | 2 +- doc/script/fit_nonlinear_spindle.py | 2 +- doc/script/stream.py | 2 +- grbl/config.h | 22 +++++++++++----------- grbl/gcode.c | 4 ++-- grbl/gcode.h | 2 +- grbl/main.c | 2 +- grbl/motion_control.c | 2 +- grbl/planner.c | 2 +- grbl/planner.h | 2 +- grbl/report.c | 2 +- grbl/serial.c | 2 +- grbl/serial.h | 2 +- grbl/spindle_control.c | 2 +- grbl/stepper.c | 2 +- 18 files changed, 31 insertions(+), 31 deletions(-) diff --git a/doc/markdown/interface.md b/doc/markdown/interface.md index e02c32ef..5fec7159 100644 --- a/doc/markdown/interface.md +++ b/doc/markdown/interface.md @@ -16,7 +16,7 @@ Finally, Grbl has **real-time commands** that are invoked by a set of special ch # Writing an Interface for Grbl -The general interface for Grbl has been described above, but what's missing is how to run an entire G-code program on Grbl, when it doesn't seem to have an upload feature. This is where this section fits in. Early on, users fiercely requested for flash drive, external RAM, LCD support, joysticks, or network support so they can upload a g-code program and run it directly on Grbl. The general answer to that is, good ideas, but Grbl doesn't need them. Grbl already has nearly all of the tools and features to reliably communicate with a graphical user interface (GUI) or a seperate host interface that provides all those extra bells and whistles. Grbl's base philosophy is to minimize what Grbl should be doing, because, in the end, Grbl needs to be concentrating on producing clean, reliable motion. That's it. +The general interface for Grbl has been described above, but what's missing is how to run an entire G-code program on Grbl, when it doesn't seem to have an upload feature. This is where this section fits in. Early on, users fiercely requested for flash drive, external RAM, LCD support, joysticks, or network support so they can upload a g-code program and run it directly on Grbl. The general answer to that is, good ideas, but Grbl doesn't need them. Grbl already has nearly all of the tools and features to reliably communicate with a graphical user interface (GUI) or a separate host interface that provides all those extra bells and whistles. Grbl's base philosophy is to minimize what Grbl should be doing, because, in the end, Grbl needs to be concentrating on producing clean, reliable motion. That's it. ## Streaming a G-Code Program to Grbl @@ -134,7 +134,7 @@ Every G-code block sent to Grbl and Grbl `$` system command that is terminated w - If an empty line with only a return is sent to Grbl, it considers it a valid line and will return an `ok` too, except it didn't do anything. -* **`error:X`**: Something went wrong! Grbl did not recognize the command and did not execute anything inside that message. The `X` is given as a numeric error code to tell you exactly what happened. The table below decribes every one of them. +* **`error:X`**: Something went wrong! Grbl did not recognize the command and did not execute anything inside that message. The `X` is given as a numeric error code to tell you exactly what happened. The table below describes every one of them. | ID | Error Code Description | |:-------------:|----| @@ -212,7 +212,7 @@ The start up message always prints upon startup and after a reset. Whenever you Alarm is an emergency state. Something has gone terribly wrong when these occur. Typically, they are caused by limit error when the machine has moved or wants to move outside the machine travel and crash into the ends. They also report problems if Grbl is lost and can't guarantee positioning or a probe command has failed. Once in alarm-mode, Grbl will lock out all g-code functionality and accept only a small set of commands. It may even stop everything and force you to acknowledge the problem until you issue Grbl a reset. While in alarm-mode, the user can override the alarm manually with a specific command, which then re-enables g-code so you can move the machine again. This ensures the user knows about the problem and has taken steps to fix or account for it. -Similar to error messages, all alarm messages are sent as **`ALARM:X`**, where `X` is an alarm code to tell you exacly what caused the alarm. The table below describes the meaning of each alarm code. +Similar to error messages, all alarm messages are sent as **`ALARM:X`**, where `X` is an alarm code to tell you exactly what caused the alarm. The table below describes the meaning of each alarm code. | ID | Alarm Code Description | |:-------------:|----| diff --git a/doc/markdown/jogging.md b/doc/markdown/jogging.md index c20aaee2..5edf4f32 100644 --- a/doc/markdown/jogging.md +++ b/doc/markdown/jogging.md @@ -80,7 +80,7 @@ The time increment `dt` may be defined to whatever value you need. Obviously, yo - `dt > 10ms` - The time it takes Grbl to parse and plan one jog command and receive the next one. Depending on a lot of factors, this can be around 1 to 5 ms. To be conservative, `10ms` is used. Keep in mind that on some systems, this value may still be greater than `10ms` due to round-trip communication latency. -- `dt > v^2 / (2 * a * (N-1))` - The time increment needs to be large enough to ensure the jog feed rate will be acheived. Grbl always plans to a stop over the total distance queued in the planner buffer. This is primarily to ensure the machine will safely stop if a disconnection occurs. This equation simply ensures that `dt` is big enough to satisfy this constraint. +- `dt > v^2 / (2 * a * (N-1))` - The time increment needs to be large enough to ensure the jog feed rate will be achieved. Grbl always plans to a stop over the total distance queued in the planner buffer. This is primarily to ensure the machine will safely stop if a disconnection occurs. This equation simply ensures that `dt` is big enough to satisfy this constraint. - For simplicity, use the max jog feed rate for `v` in mm/sec and the smallest acceleration setting between the jog axes being moved in mm/sec^2. diff --git a/doc/markdown/laser_mode.md b/doc/markdown/laser_mode.md index 4e42ba3b..80f20fc0 100644 --- a/doc/markdown/laser_mode.md +++ b/doc/markdown/laser_mode.md @@ -1,6 +1,6 @@ ## Grbl v1.1 Laser Mode -**_DISCLAIMER: Lasers are extremely dangerous devices. They can instantly cause fires and permanently damage your vision. Please read and understand all related documentation for your laser prior to using it. The Grbl project is not resposible for any damage or issues the firmware may cause, as defined by its GPL license._** +**_DISCLAIMER: Lasers are extremely dangerous devices. They can instantly cause fires and permanently damage your vision. Please read and understand all related documentation for your laser prior to using it. The Grbl project is not responsible for any damage or issues the firmware may cause, as defined by its GPL license._** ---- diff --git a/doc/markdown/settings.md b/doc/markdown/settings.md index 4b54746f..3dff28ee 100644 --- a/doc/markdown/settings.md +++ b/doc/markdown/settings.md @@ -223,7 +223,7 @@ This sets the spindle speed for the minimum 0.02V PWM pin output (0V is disabled #### $32 - Laser mode, boolean -When enabled, Grbl will move continuously through consecutive `G1`, `G2`, or `G3` motion commands when programmed with a `S` spindle speed (laser power). The spindle PWM pin will be updated instantaneously through each motion without stopping. Please read the Grbl laser documentation and your laser device documentation prior to using this mode. Lasers are very dangerous. They can instantly damage your vision permanantly and cause fires. Grbl does not assume any responsibility for any issues the firmware may cause, as defined by its GPL license. +When enabled, Grbl will move continuously through consecutive `G1`, `G2`, or `G3` motion commands when programmed with a `S` spindle speed (laser power). The spindle PWM pin will be updated instantaneously through each motion without stopping. Please read the Grbl laser documentation and your laser device documentation prior to using this mode. Lasers are very dangerous. They can instantly damage your vision permanently and cause fires. Grbl does not assume any responsibility for any issues the firmware may cause, as defined by its GPL license. When disabled, Grbl will operate as it always has, stopping motion with every `S` spindle speed command. This is the default operation of a milling machine to allow a pause to let the spindle change speeds. diff --git a/doc/script/fit_nonlinear_spindle.py b/doc/script/fit_nonlinear_spindle.py index 57ca5f3b..43b62cbd 100644 --- a/doc/script/fit_nonlinear_spindle.py +++ b/doc/script/fit_nonlinear_spindle.py @@ -109,7 +109,7 @@ points 'PWM_pointX' in this script to move where the piecewise line junctions are located along the plot x-axis. It may be desired to tweak the junction points so the model solution is more accurate in the region that the spindle typically running. - Re-run the script and tweak the junction points until you are satified with the model. + Re-run the script and tweak the junction points until you are satisfied with the model. - Record the solution and enter the RPM_POINT and RPM_LINE values into config.h. Set the number of piecewise lines used in this model in config.h. Also set the '$30' and '$31' diff --git a/doc/script/stream.py b/doc/script/stream.py index 4a637ab9..5402265b 100755 --- a/doc/script/stream.py +++ b/doc/script/stream.py @@ -148,7 +148,7 @@ def periodic_timer() : else: print " MSG: \""+grbl_out+"\"" else: - # Send g-code program via a more agressive streaming protocol that forces characters into + # Send g-code program via a more aggressive streaming protocol that forces characters into # Grbl's serial read buffer to ensure Grbl has immediate access to the next g-code command # rather than wait for the call-response serial protocol to finish. This is done by careful # counting of the number of characters sent by the streamer to Grbl and tracking Grbl's diff --git a/grbl/config.h b/grbl/config.h index f48d9586..228f0012 100644 --- a/grbl/config.h +++ b/grbl/config.h @@ -56,7 +56,7 @@ // NOTE: All override realtime commands must be in the extended ASCII character set, starting // at character value 128 (0x80) and up to 255 (0xFF). If the normal set of realtime commands, // such as status reports, feed hold, reset, and cycle start, are moved to the extended set -// space, serial.c's RX ISR will need to be modified to accomodate the change. +// space, serial.c's RX ISR will need to be modified to accommodate the change. // #define CMD_RESET 0x80 // #define CMD_STATUS_REPORT 0x81 // #define CMD_CYCLE_START 0x82 @@ -98,7 +98,7 @@ // cycle, but this requires some pin settings changes in cpu_map.h file. For example, the default homing // cycle can share the Z limit pin with either X or Y limit pins, since they are on different cycles. // By sharing a pin, this frees up a precious IO pin for other purposes. In theory, all axes limit pins -// may be reduced to one pin, if all axes are homed with seperate cycles, or vice versa, all three axes +// may be reduced to one pin, if all axes are homed with separate cycles, or vice versa, all three axes // on separate pin, but homed in one cycle. Also, it should be noted that the function of hard limits // will not be affected by pin sharing. // NOTE: Defaults are set for a traditional 3-axis CNC machine. Z-axis first to clear, followed by X & Y. @@ -278,7 +278,7 @@ // the associated data is refreshed and included in the status report. However, if one of these value // changes, Grbl will automatically include this data in the next status report, regardless of what the // count is at the time. This helps reduce the communication overhead involved with high frequency reporting -// and agressive streaming. There is also a busy and an idle refresh count, which sets up Grbl to send +// and aggressive streaming. There is also a busy and an idle refresh count, which sets up Grbl to send // refreshes more often when its not doing anything important. With a good GUI, this data doesn't need // to be refreshed very often, on the order of a several seconds. // NOTE: WCO refresh must be 2 or greater. OVR refresh must be 1 or greater. @@ -391,7 +391,7 @@ #define MINIMUM_FEED_RATE 1.0 // (mm/min) // Number of arc generation iterations by small angle approximation before exact arc trajectory -// correction with expensive sin() and cos() calcualtions. This parameter maybe decreased if there +// correction with expensive sin() and cos() calculations. This parameter maybe decreased if there // are issues with the accuracy of the arc generations, or increased if arc execution is getting // bogged down by too many trig calculations. #define N_ARC_CORRECTION 12 // Integer (1-255) @@ -452,7 +452,7 @@ // Serial send and receive buffer size. The receive buffer is often used as another streaming // buffer to store incoming blocks to be processed by Grbl when its ready. Most streaming // interfaces will character count and track each block send to each block response. So, -// increase the receive buffer if a deeper receive buffer is needed for streaming and avaiable +// increase the receive buffer if a deeper receive buffer is needed for streaming and available // memory allows. The send buffer primarily handles messages in Grbl. Only increase if large // messages are sent and Grbl begins to stall, waiting to send the rest of the message. // NOTE: Grbl generates an average status report in about 0.5msec, but the serial TX stream at @@ -505,8 +505,8 @@ // Defines the EEPROM data restored upon a settings version change and `$RST=*` command. Whenever the // the settings or other EEPROM data structure changes between Grbl versions, Grbl will automatically // wipe and restore the EEPROM. This macro controls what data is wiped and restored. This is useful -// particularily for OEMs that need to retain certain data. For example, the BUILD_INFO string can be -// written into the Arduino EEPROM via a seperate .INO sketch to contain product data. Altering this +// particularly for OEMs that need to retain certain data. For example, the BUILD_INFO string can be +// written into the Arduino EEPROM via a separate .INO sketch to contain product data. Altering this // macro to not restore the build info EEPROM will ensure this data is retained after firmware upgrades. // NOTE: Uncomment to override defaults in settings.h // #define SETTINGS_RESTORE_ALL (SETTINGS_RESTORE_DEFAULTS | SETTINGS_RESTORE_PARAMETERS | SETTINGS_RESTORE_STARTUP_LINES | SETTINGS_RESTORE_BUILD_INFO) @@ -516,7 +516,7 @@ // to prevent this data from being over-written by a user, when used to store OEM product data. // NOTE: If disabled and to ensure Grbl can never alter the build info line, you'll also need to enable // the SETTING_RESTORE_ALL macro above and remove SETTINGS_RESTORE_BUILD_INFO from the mask. -// NOTE: See the included grblWrite_BuildInfo.ino example file to write this string seperately. +// NOTE: See the included grblWrite_BuildInfo.ino example file to write this string separately. #define ENABLE_BUILD_INFO_WRITE_COMMAND // '$I=' Default enabled. Comment to disable. // AVR processors require all interrupts to be disabled during an EEPROM write. This includes both @@ -525,7 +525,7 @@ // option forces the planner buffer to completely empty whenever the EEPROM is written to prevent // any chance of lost steps. // However, this doesn't prevent issues with lost serial RX data during an EEPROM write, especially -// if a GUI is premptively filling up the serial RX buffer simultaneously. It's highly advised for +// if a GUI is preemptively filling up the serial RX buffer simultaneously. It's highly advised for // GUIs to flag these gcodes (G10,G28.1,G30.1) to always wait for an 'ok' after a block containing // one of these commands before sending more data to eliminate this issue. // NOTE: Most EEPROM write commands are implicitly blocked during a job (all '$' commands). However, @@ -582,7 +582,7 @@ // This option will automatically disable the laser during a feed hold by invoking a spindle stop // override immediately after coming to a stop. However, this also means that the laser still may -// be reenabled by disabling the spindle stop override, if needed. This is purely a safety feature +// be re-enabled by disabling the spindle stop override, if needed. This is purely a safety feature // to ensure the laser doesn't inadvertently remain powered while at a stop and cause a fire. #define DISABLE_LASER_DURING_HOLD // Default enabled. Comment to disable. @@ -669,7 +669,7 @@ // integrate this feature without arguably too much work. // Variable spindle (i.e. laser mode) does NOT work with this shield as configured. While // variable spindle technically can work with this shield, it requires too many changes for -// most user setups to accomodate. It would best be implemented by sharing all limit switches +// most user setups to accommodate. It would best be implemented by sharing all limit switches // on pins D9/D10 (as [X1,Z]/[X2,Y] or [X,Y2]/[Y1,Z]), home each axis independently, and // updating lots of code to ensure everything is running correctly. // #define DUAL_AXIS_CONFIG_CNC_SHIELD_CLONE // Uncomment to select. Comment other configs. diff --git a/grbl/gcode.c b/grbl/gcode.c index 57e31e59..9964280c 100644 --- a/grbl/gcode.c +++ b/grbl/gcode.c @@ -126,7 +126,7 @@ uint8_t gc_execute_line(char *line) // NOTE: Mantissa is multiplied by 100 to catch non-integer command values. This is more // accurate than the NIST gcode requirement of x10 when used for commands, but not quite // accurate enough for value words that require integers to within 0.0001. This should be - // a good enough comprimise and catch most all non-integer errors. To make it compliant, + // a good enough compromise and catch most all non-integer errors. To make it compliant, // we would simply need to change the mantissa to int16, but this add compiled flash space. // Maybe update this later. int_value = trunc(value); @@ -608,7 +608,7 @@ uint8_t gc_execute_line(char *line) case NON_MODAL_GO_HOME_0: // G28 case NON_MODAL_GO_HOME_1: // G30 // [G28/30 Errors]: Cutter compensation is enabled. - // Retreive G28/30 go-home position data (in machine coordinates) from EEPROM + // Retrieve G28/30 go-home position data (in machine coordinates) from EEPROM // NOTE: Store parameter data in IJK values. By rule, they are not in use with this command. if (gc_block.non_modal_command == NON_MODAL_GO_HOME_0) { if (!settings_read_coord_data(SETTING_INDEX_G28,gc_block.values.ijk)) { FAIL(STATUS_SETTING_READ_FAIL); } diff --git a/grbl/gcode.h b/grbl/gcode.h index 6cdc61b4..3bb08894 100644 --- a/grbl/gcode.h +++ b/grbl/gcode.h @@ -49,7 +49,7 @@ // Define command actions for within execution-type modal groups (motion, stopping, non-modal). Used // internally by the parser to know which command to execute. // NOTE: Some macro values are assigned specific values to make g-code state reporting and parsing -// compile a litte smaller. Necessary due to being completely out of flash on the 328p. Although not +// compile a little smaller. Necessary due to being completely out of flash on the 328p. Although not // ideal, just be careful with values that state 'do not alter' and check both report.c and gcode.c // to see how they are used, if you need to alter them. diff --git a/grbl/main.c b/grbl/main.c index 96f2abae..9dec3682 100644 --- a/grbl/main.c +++ b/grbl/main.c @@ -98,7 +98,7 @@ int main(void) plan_sync_position(); gc_sync_position(); - // Print welcome message. Indicates an initialization has occured at power-up or with a reset. + // Print welcome message. Indicates an initialization has occurred at power-up or with a reset. report_init_message(); // Start Grbl main loop. Processes program inputs and executes them. diff --git a/grbl/motion_control.c b/grbl/motion_control.c index 6e11e35c..d43721ba 100644 --- a/grbl/motion_control.c +++ b/grbl/motion_control.c @@ -26,7 +26,7 @@ // unless invert_feed_rate is true. Then the feed_rate means that the motion should be completed in // (1 minute)/feed_rate time. // NOTE: This is the primary gateway to the grbl planner. All line motions, including arc line -// segments, must pass through this routine before being passed to the planner. The seperation of +// segments, must pass through this routine before being passed to the planner. The separation of // mc_line and plan_buffer_line is done primarily to place non-planner-type functions from being // in the planner and to let backlash compensation or canned cycle integration simple and direct. void mc_line(float *target, plan_line_data_t *pl_data) diff --git a/grbl/planner.c b/grbl/planner.c index 49ff7229..6cf627ea 100644 --- a/grbl/planner.c +++ b/grbl/planner.c @@ -476,7 +476,7 @@ uint8_t plan_buffer_line(float *target, plan_line_data_t *pl_data) void plan_sync_position() { // TODO: For motor configurations not in the same coordinate frame as the machine position, - // this function needs to be updated to accomodate the difference. + // this function needs to be updated to accommodate the difference. uint8_t idx; for (idx=0; idx