Merge pull request #2816 from luzpaz/typos-src

Fix typos in src subdirectory

Author: andypugh

src/emc/usr_intf/emcrsh.cc

@@ -3039,7 +3039,7 @@ int sockMain()
         if (client_sockfd < 0) exit(0);
         // count connected clients
         sessions++;
-        // enforce limited amount of clients that can connect simultaniously
+        // enforce limited amount of clients that can connect simultaneously
         if ((maxSessions == -1) || (sessions <= maxSessions)) {
             pthread_t *thrd;
             connectionRecType *context;

src/emc/usr_intf/gmoccapy/gmoccapy.py

@@ -5783,7 +5783,7 @@ def _make_hal_pins(self):
         pin = self.halcomp.newpin("ignore-limits", hal.HAL_BIT, hal.HAL_IN)
         hal_glib.GPin(pin).connect("value_changed", self._ignore_limits)
 
-        # make pins to set optinal stops and block delete
+        # make pins to set optional stops and block delete
         pin = self.halcomp.newpin("optional-stop", hal.HAL_BIT, hal.HAL_IN)
         hal_glib.GPin(pin).connect("value_changed", self._optional_blocks)
         pin = self.halcomp.newpin("blockdelete", hal.HAL_BIT, hal.HAL_IN)

src/emc/usr_intf/gscreen/gscreen.py

@@ -493,7 +493,7 @@ def add_handler(method, f):
 
 # ok here is the Gscreen class
 # there are also three other files:
-# mdi.py for mdi commands (which include non-obvious mdi commands done in maual mode)
+# mdi.py for mdi commands (which include non-obvious mdi commands done in manual mode)
 # preference.py for keeping track of stored user preferences
 # emc_interface.py which does most of the commands and status of linuxcnc
 # keep in mind some of the gladeVCP widgets send-commands-to/monitor linuxcnc also
@@ -564,7 +564,7 @@ def __init__(self):
             self.xml = Gtk.Builder()
             self.xml.set_translation_domain(domain) # for locale translations
             self.xml.add_from_file(xmlname)
-            # this is a fix for themeing - it sets the widgets style name to
+            # this is a fix for theming - it sets the widgets style name to
             # the widget id name. You can over ride it later with:
             # self.widgets.<OBJECT NAME>.set_name('<STYLE NAME>')
             for o in self.xml.get_objects():

src/emc/usr_intf/pncconf/ADDING_A_MESA_CARD.md

@@ -4,7 +4,7 @@ This document describes how to add a new Mesa card to the pncconf utility.
 # Concepts
 There are various types of Mesa cards that this configuration utility supports.  Generally speaking, they need to be run with a specific firmware that configures the FPGA on the card to behave in a certain way with respect to the I/O of the card.  In some cases this firmware is installed at runtime by LinuxCNC and in other cases it is loaded on the boards manually via some other process.  In order for pncconf to be able to properly generate a configuration, it must know both the Mesa I/O card(s) you are configuring, as well as the firmware installed on those cards.  In the case of the real time drivers (for example the `hm2_pci` driver), the pinout from message will be written to the `dmesg` facility on LinuxCNC startup.  In the case of the upsace drivers (for example the `hm2_eth` driver), the pinouts are written to the `stdout` of the LinuxCNC process and so you can see the pinout by starting LinuxCNC from a command prompt.
 
-Individual firmware images allow additional configuration, via the driver, to specify for instance the specific number of stepgens, pwmgens and encoders your specific machine requires.  The remaining I/O is typically configured as GPIO.  For example, a `7i93` card, can be configiured with an `SVST4_4d` firmware, which allows up to 4 steppers, 4 encoders, and 4 pwmgens.  Using pncconf you can configure fewer of each of those, and the remainder will be configured as GPIO.  Because things like stepgens, pwmgens, and encoders are allocated in the firmware in a particular order, typically you have to align the wiring of the machine to respect these limitations.  This is a limitation of how the Mesa firmware is handled, not pncconf.
+Individual firmware images allow additional configuration, via the driver, to specify for instance the specific number of stepgens, pwmgens and encoders your specific machine requires.  The remaining I/O is typically configured as GPIO.  For example, a `7i93` card, can be configured with an `SVST4_4d` firmware, which allows up to 4 steppers, 4 encoders, and 4 pwmgens.  Using pncconf you can configure fewer of each of those, and the remainder will be configured as GPIO.  Because things like stepgens, pwmgens, and encoders are allocated in the firmware in a particular order, typically you have to align the wiring of the machine to respect these limitations.  This is a limitation of how the Mesa firmware is handled, not pncconf.
 
 To add a board to pncconf, you must create a list data structure within the `private_data.py` `MESA_INTERNAL_FIRMWAREDATA` list variable that specifies the details of the card.  There will be an entry in that data structure for each combination of card and firmware that you wish to have as configuration options.
 
@@ -42,7 +42,7 @@ The expected data elements of the list are described programmatically in the `pr
 
 The remainder of the data structure consists of list entries specifying the individual I/O pins of the card in order of how they will be allocated by the firmware.  For instance the first six pins are used to provision two encoders with a,b and index connections: `[S.ENCB,1],[S.ENCA,1],[S.ENCB,0],[S.ENCA,0],[S.ENCI,1],[S.ENCI,0]`.  The next two pins are two pwmgens: `[S.PWMP,1],[S.PWMP,0]`.  The order of these pins is not arbitrary, and must match what the specific firmware on the card is expecting.  This information is supplied from Mesa in the form of pin files, typically shipped with the firmware files.  In our case there are 48 entries because there are 48 I/O pins.
 
-Allocation of the order of I/O pins to connectors is done at the Mesa hardware level and in our case the Mesa manual for the `7i93` specifies `CONECTOR P2 I/O 0..23` and `CONNECTOR P1 I/O 24..47`.
+Allocation of the order of I/O pins to connectors is done at the Mesa hardware level and in our case the Mesa manual for the `7i93` specifies `CONNECTOR P2 I/O 0..23` and `CONNECTOR P1 I/O 24..47`.
 
 If logical number < 100 => GPIO can be changed to GPIOO or GPIOD at the start of linuxcnc, load time if you prefer (or run time)
 If logical number > 100 => GPIO can NOT be changed to GPIOO or GPIOD at the start of linuxcnc, load time (always input or always output)

src/emc/usr_intf/stepconf/pages.py

@@ -587,7 +587,7 @@ def on_halui_btnDel_clicked(self, *args):
             index = 1
             self.w.lstStore1.set_value(treeiter, 0, index)
             index = index +1
-            # Cicle lstStore1 to update index
+            # Cycle lstStore1 to update index
             while treeiter != None:
                 treeiter = self.w.lstStore1.iter_next(treeiter)
                 if treeiter != None:

src/hal/components/bldc.comp

@@ -281,7 +281,7 @@ If this input is used then the rotor will need to be homed before the motor can
 
 \\fBi\\fR Use the index of an incremental encoder as a home reference.
 
-\\fBf\\fR Use a 4-bit Gray-scale patttern to determine rotor alignment.
+\\fBf\\fR Use a 4-bit Gray-scale pattern to determine rotor alignment.
 This scheme is only used on the Fanuc "Red Cap" motors.
 This mode could be used to control one of these motors using a non-Fanuc drive.
 

src/hal/components/carousel.comp

@@ -74,7 +74,7 @@ Once the decel-time has expired the carousel will, if it was moving forwards, re
 to the position marker, off of the arker and then bak on to the FWD edge. If moving in reverse
 it will continue off the marker and then reverse slowly on to the FWD edge.
 This algnment is only possible with a motor-vel controlled bidirectional carousel,
-Other combinations will be acepted but probably won't have the desired behaviour.
+Other combinations will be accepted but probably won't have the desired behaviour.
 Some tuning will be needed of align-dc and decel-time to achieve reliable operation.
 
 In the unusual case that the index and pulse signals do not align it is

src/hal/components/laserpower.comp

@@ -8,7 +8,7 @@ pin in bit enabled "True when laser output enabled";
 pin in bit raster_mode "false for vector mode, true for raster mode";
 pin in float raster_power "Requested power level during raster operations";
 
-pin in float vector_power "Requested power level during vector operatons";
+pin in float vector_power "Requested power level during vector operations";
 pin in float distance_to_go "Distance to go of current move";
 
 pin out float power "Current power level command";

src/hal/components/raster.comp

@@ -6,7 +6,7 @@ pin in bit   run      "starts the raster";
 
 pin out bit enabled = 0      "When a valid raster program is running.";
 pin out float output = -1    "current output level command";
-pin out bit fault = 0        "If error has occured";
+pin out bit fault = 0        "If error has occurred";
 pin out signed fault_code = 0 "Code of fault";
 pin out signed state = 0    "current state";
 pin out float program_position = 0.0 "base position of program at run start";
@@ -20,27 +20,27 @@ pin out float previous_pixel_value = -1.0 "previously loaded pixel value";
 pin out signed current_pixel_index = -1 "currently loaded pixel index";
 pin out float fraction = 0.0;
 
-description """The raster componenet converts a single raster program line to laser output.
+description """The raster component converts a single raster program line to laser output.
                The position pin is slaved to the axis that the raster line maps too. 
                The raster program must be programmed for each raster line that is to be executed.
                The port must be programmed prior to a raster line being executed.
 
                A python component RasterProgrammer (lib/python/RasterProgrammer.py) is provided to ease programming of the raster component.
-               congifs/sim/axis/laser shows an example of how these pieces could be integrated for a functional laser engraver config.
+               configs/sim/axis/laser shows an example of how these pieces could be integrated for a functional laser engraver config.
 
                A program line format is as follows:
                {program_offset};{bits_per_pixel};{pixels_per_unit};{number_of_ pixels};{pixel_data ....}
 
-               program_offset: a float. It indicates the start position of the raster line relative to the current axis postion. 
-                  A negative program_offset indicates that the raster sweeps from positive to negatve
+               program_offset: a float. It indicates the start position of the raster line relative to the current axis position. 
+                  A negative program_offset indicates that the raster sweeps from positive to negative
                   A zero or positive program_offset indicates that the raster sweeps from negative to positive direction
 
                bits_per_pixel: an integer. It indicates the precision of a pixel value and consequently the number of bytes consumed per pixel value.
                   A bits per pixel of 4 takes 1 character (0-F) and scales out from from 0.0 to 1.0 (0 being 0 and E being 1.0). F corresponds to off or -1.0
                   A bits per pixel of 8 takes 2 characters per pixel, 12 takes 3 characters per pixel etc...
 
                pixels_per_unit: a float that represents the size of a pixel in machine units. 
-                   1 would correspond to 1 pixel per machine unit, 100 would corrsepond to 100 pixels per machine unit.
+                   1 would correspond to 1 pixel per machine unit, 100 would correspond to 100 pixels per machine unit.
 
                number_of_pixels: an integer that indicates the length of the raster line in pixels.
                           The length of the rasterline in machine units would be number_of_pixels / pixels_per_unit
@@ -69,7 +69,7 @@ include "hal/components/raster.h";
 enum {
     ERROR_NONE           = 0, //no error at the moment
     ERROR_INVALID_OFFSET = 1, //offset must be a float
-    ERROR_INVALID_BPP    = 2, //bpp must be between 4-32 and divisable by 4
+    ERROR_INVALID_BPP    = 2, //bpp must be between 4-32 and divisible by 4
     ERROR_INVALID_PPU    = 3, //ppu must be greater than 0
     ERROR_INVALID_COUNT  = 4, //count must be a float > 0
     ERROR_BADPIXELDATA   = 5, //pixel data does not match begin statement

src/hal/drivers/hal_gm.c

@@ -1840,7 +1840,7 @@ RS485(void *arg, long period)
 	  {
 	    if((device-> RS485_mgr.ID[2*i]) != ((temp_u32 >> 8) & 0xff)) 
             {
-              //RS485 module falled off, error
+              //RS485 module fell off, error
               if(failed == 0) //Msg only first time, do not put 100 error msg
               {
                 failed=1;
@@ -1854,7 +1854,7 @@ RS485(void *arg, long period)
 	  {
 	    if((device-> RS485_mgr.ID[2*i+1]) != ((temp_u32 & 0xff000000)>>24))
             {
-              //RS485 module falled off, error
+              //RS485 module fell off, error
               if(failed == 0) //Msg only first time, do not put 100 error msg
               {
                 failed=1;