fix paramter/parameter typos all over

configs/apps/gladevcp/mdi-command-example/speed.ui

@@ -22,7 +22,7 @@
         <child>
           <object class="HAL_Button" id="hal_button1">
             <property name="label" translatable="yes">  Pass speed as
-paramter in MDI
+parameter in MDI
     command</property>
             <property name="visible">True</property>
             <property name="can_focus">True</property>

configs/sim/axis/remap/manual-toolchange-with-tool-length-switch/nc_subroutines/restore.ngc

@@ -1,4 +1,4 @@
-; restore metric/inch absolute/relative, feed as per paramter values
+; restore metric/inch absolute/relative, feed as per parameter values
 ; call as 'O<restore> call [originalmetric] [originalabs] [originalfeed]
 ;
 O<restore> sub

configs/sim/gmoccapy/python/stdglue.py

@@ -117,7 +117,7 @@ _compat = {
     emccanon.CANON_PLANE_VW : (("u","r"),_xyz,"VW"),
     emccanon.CANON_PLANE_UW : (("v","r"),_xyz,"UW")}           
 
-# extract and pass parameters from current block, merged with extra paramters on a continuation line
+# extract and pass parameters from current block, merged with extra parameters on a continuation line
 # keep tjose parameters across invocations
 # export the parameters into the oword procedure
 def cycle_prolog(self,**words):

docs/man/man9/hostmot2.9

@@ -578,7 +578,7 @@ a Fanuc Aa64 encoder. The pins created are:
  hm2_XXiX.N.fanuc.MM.crc                 The CRC checksum. Currently HAL has no way to use this
  hm2_XiXX.N.fanuc.MM.encoder.count       Encoder counts
  hm2_XiXX.N.fanuc.MM.encoder.index\-enable Simulated index. Set by counts\-per\-rev parameter
- hm2_XiXX.N.fanuc.MM.encoder.position    Counts scaled by the ...scale paramter
+ hm2_XiXX.N.fanuc.MM.encoder.position    Counts scaled by the ...scale parameter
  hm2_XiXX.N.fanuc.MM.encoder.rawcounts   Raw counts, unaffected by reset or index
  hm2_XiXX.N.fanuc.MM.encoder.reset       If high/true then counts and position = 0
  hm2_XiXX.N.fanuc.MM.valid               Indicates that the absolute position is valid

docs/src/gcode/m-code.txt

@@ -483,7 +483,7 @@ Note that in particular, the motion mode (G1 etc) is NOT restored.
  * executing within a G-code subroutine. The state saved with 'M70'
  within a subroutine behaves exactly like a local named parameter - it
  can be referred to only within this subroutine invocation with an
- 'M72' and when the subroutine exits, the paramter goes away.
+ 'M72' and when the subroutine exits, the parameter goes away.
 
 A recursive invocation of a subroutine introduces a new call level.
 

docs/src/gcode/o-code.txt

@@ -295,7 +295,7 @@ o123 endsub [3 * 4]
 A subroutine return value is stored in the '#<_value>'
 <<gcode:predefined-named-parameters, predefined named parameter>> , and
 the '#<_value_returned>' predefined parameter is set to 1, to indicate
-a value was returned. Both paramters are global, and are cleared just
+a value was returned. Both parameters are global, and are cleared just
 before the next subroutine call.
 
 // vim: set syntax=asciidoc:

docs/src/remap/remap.txt

@@ -1811,7 +1811,7 @@ These wrap a NGC procedure so it can act as a cycle, meaning the
 motion code is retained after finishing execution. If the next line
 just contains parameter words (e.g. new X,Y values), the code is
 executed again with the new parameter words merged into the set of the
-paramters given in the first invocation.
+parameters given in the first invocation.
 
 These routines are designed to work in conjunction with an
 <<_the_argspec_parameter,`argspec=<words>` parameter>>. While this is
@@ -2406,7 +2406,7 @@ results.
 
 .Interpreter action on a Tx command
 
-All the interpreter does is evaluate the toolnumber paramter, looks up
+All the interpreter does is evaluate the toolnumber parameter, looks up
 its corresponding pocket, remembers it in the `selected_pocket`
 variable for later, and  queues a canon command
 (SELECT_POCKET). See 'Interp::convert_tool_select' in 'src/emc/rs274/interp_execute.cc'.

nc_files/remap_lib/python-stdglue/stdglue.py

@@ -298,7 +298,7 @@ _compat = {
     emccanon.CANON_PLANE_VW : (("u","r"),_xyz,"VW"),
     emccanon.CANON_PLANE_UW : (("v","r"),_xyz,"UW")}           
 
-# extract and pass parameters from current block, merged with extra paramters on a continuation line
+# extract and pass parameters from current block, merged with extra parameters on a continuation line
 # keep tjose parameters across invocations
 # export the parameters into the oword procedure
 def cycle_prolog(self,**words):

src/emc/rs274ngc/interp_internal.hh

@@ -538,7 +538,7 @@ enum retopts { RET_NONE, RET_DOUBLE, RET_INT, RET_YIELD, RET_STOPITERATION, RET_
 
 typedef block *block_pointer;
 
-// parameters will go to a std::map<const char *,paramter_value_pointer>
+// parameters will go to a std::map<const char *,parameter_value_pointer>
 typedef struct parameter_value_struct {
     double value;
     unsigned attr;

src/hal/hal.h

@@ -476,7 +476,7 @@ extern int hal_unlink(const char *pin_name);
     'name' is the name of the new parameter.  It must be no longer than
     .HAL_NAME_LEN.  If there is already a parameter with the same
     name the call will fail.
-    'dir' is the parameter direction.  HAL_RO paramters are read only from
+    'dir' is the parameter direction.  HAL_RO parameters are read only from
     outside, and are written to by the component itself, typically to provide a
     view "into" the component for testing or troubleshooting.  HAL_RW
     parameters are writable from outside and also sometimes modified by the
@@ -531,7 +531,7 @@ extern int hal_param_s32_newf(hal_param_dir_t dir,
     functions above.
     'type' is the hal type of the new parameter - the type of data
     that will be stored in the parameter.
-    'dir' is the parameter direction.  HAL_RO paramters are read only from
+    'dir' is the parameter direction.  HAL_RO parameters are read only from
     outside, and are written to by the component itself, typically to provide a
     view "into" the component for testing or troubleshooting.  HAL_RW
     parameters are writable from outside and also sometimes modified by the

src/hal/user_comps/huanyang-vfd/hy_comm.h

@@ -115,7 +115,7 @@ typedef struct _hycomm_param_t {
 typedef struct _hycomm_data_t {
 	unsigned char slave;			/* slave address */
 	unsigned char function;			/* function code */
-	unsigned char parameter;		/* PDxxx paramter */
+	unsigned char parameter;		/* PDxxx parameter */
 	int data;						/* Data to send */
 	unsigned char ret_length;		/* length of data returned from slave */
 	unsigned char ret_parameter;	/* parameter returned from slave */

src/hal/user_comps/vfs11_vfd/vfs11_vfd.c

@@ -68,13 +68,13 @@
  * VFS-11 parameters:
  *
  * There are dozens of parameters. Some can be stored permanently in EEPROM (setup parameters),
- * some in RAM (operating paramters), and some can be stored both in EEPROM and RAM. The manual
+ * some in RAM (operating parameters), and some can be stored both in EEPROM and RAM. The manual
  * is a bit unclear which parameters are RAM/EEPROM/both.
  *
  * There are two communication protocols to talk to the VF-S11, a proprietary but documented
  * "Toshiba Inverter Protocol" (TIP), and a simple Modbus subset. TIP can set EEPROM and RAM
  * parameters and hence can be used for initial inverter configuration. Modbus control can only
- * set operating paramters in RAM. So any setup parameters which you'd like to change (like,
+ * set operating parameters in RAM. So any setup parameters which you'd like to change (like,
  * e.g. maximum output frequency) need to be set up differently, either through the operating
  * panel, or through a Windows program supplied by Toshiba named PCS001Z.
  *

src/rtapi/uspace_rtapi_app.cc

@@ -151,7 +151,7 @@ static int do_comp_args(void *module, vector<string> args) {
 	remove_quotes(s);
         size_t idx = s.find('=');
         if(idx == string::npos) {
-            rtapi_print_msg(RTAPI_MSG_ERR, "Invalid paramter `%s'\n",
+            rtapi_print_msg(RTAPI_MSG_ERR, "Invalid parameter `%s'\n",
                     s.c_str());
             return -1;
         }