Locking Steering and Spring Travel

A description of MotionSolve .xml statements needed to lock steering and spring travel.

When computing the characteristics like lateral force steer compliance, the steering needs to be held fixed. However, when computing the steering at the wheel centers due to a torque at the steering wheel, the steering wheel must be allowed to rotate. Similarly, when computing the suspension ride rate, the suspension springs must be free to deflect, however when computing the steer motion at the wheel centers to determine the kingpin axis, the spring motion is be locked to remove the change in kingpin direction due to spring motion. While locking the steering and spring travel may be done by activating a motion, performing an analysis, and then deactivating the motion, the compliance matrix for a suspension can be manipulated numerically to lock (remove) specific degrees of freedom without performing expensive, additional analysis steps.

To Facilitate locking, the model needs to contain information about what and where to lock and pass it to the subroutines. These are passed by calling the corresponding user subroutines “REGISTER_TRAVEL_LOCK” and “REGISTER_STEERING_LOCK”. These user subroutines are using the STRING_READ API, which allows, that the functions are called once at the beginning of the simulation. The information will be registered internally and available to retrieved by the routines, that compute steer axis or the instant axis due to wheel travel. The idea of the locking is, that it can be viewed as a modelling aspect, that is defined in the steering system and spring systems only and no information is forwarded to the testrig on the modelling level by using attachments. Note, that the Reference_String element has been used in a way, that differs from its designed purpose. The original purpose of the API is to provide a string, which is required in the model, but generated in the user subroutine. In the locking mechanism, the API is used to transport information from the model to the user subroutine. The string, that is returned from the subroutine is not used in the model.

Steering Lock

The steering lock can be defined in the solver model, by adding a string of type USER. On the solver level, this looks like:

<Reference_String
    id = "325001"
    label = "SolverString-LockRegistration"
    usrsub_dll_name = "msautoutils"
    usrsub_param_string = "USER( 0, 32500100 )"
    usrsub_fnc_name = "REGISTER_STEERING_LOCK"
  />

In this example, the user subroutine is called with two arguments. The first argument “0”, is the version of the array. Only version 0 is supported currently. The second argument is the solver id, of a Reference_Array. The array has five elements, as defined below:


Index	Name	Assumed Type	Restrictions	Example	Purpose
0	Axle ID	unsigned int		0	Provides a link to the axle id, that is used in the requests. This is usually 0 for the front axle and 1 for the rear axle. The implementation will accept any integer value and uses this value to assign the lock to an axle. When requesting scrub radius on axle with ID == 1, then a lock with Axle ID == 0 will not be used, but a lock with Axle ID == 1 will be used, if present.
1	Full varname	int/string-id		ss_strg_jt_fullvar.id	Identify the steering joint in model hierarchy or messaging.
2	Marker 1 ID	int/marker-id		spr.i.id	Provides location and body to lock, if #4 is positive. Provides direction to lock from z-axis, if #3 is not given (-1) and #4 is positive. Provides reference point for direction, if #3 is defined (second marker).
3	Marker 2 ID	int/marker-id		spr.j.id	Provides location and body to lock, if #4 is negative. Provides second point for direction, if defined (second marker).
4	Lock Mode	int	{-6; -5; … -1; 1; 2; … 6}	3	An integer value, that provides the information, which axis to use for locking, if #3 is not defined and whether or not to swap Marker 1 and 2. A negative value requests, that Marker 2 is used to provide location and parent body to lock. Since in 2 marker case, direction is defined as line passing through markers, only “-1” is a valid value. A positive value requests, that Marker 1 is used to provide location and parent body to lock. In this case, the absolute value is only relevant, if Marker 2 is not defined. In this case, 1 requests, that X axis translation is locked on Marker 1. 5 requests, that y axis rotation is locked on Marker 1. 1: translation - x 2: translation - y 3: translation - z 4: rotation - x 5: rotation - y 6: rotation - z In the current implementation, only 3, 6 and -1 are supported values.

Travel Lock

The travel lock is defined in a similar way.

<Reference_String
    id = "310002"
    label = "SolverString-LockRegistration-right"
    usrsub_dll_name = "msautoutils"
    usrsub_param_string = "USER( 0, 31000200 )"
    usrsub_fnc_name = "REGISTER_TRAVEL_LOCK"
  />

The call itself is using a different entry point and a different array. The array is of size 6. It contains the same information as the steering lock, but in addition to that, also passes the side to lock.


Index	Name	Assumed Type	Restrictions	Example	Purpose
0	Axle Index	unsigned int		0	Provides a link to the axle id, that is used in the requests. This is usually 0 for the front axle and 1 for the rear axle. The implementation will accept any integer value and uses this value to assign the lock to an axle. When requesting scrub radius on axle with ID == 1, then a lock with Axle ID == 0 will not be used, but a lock with Axle ID == 1 will be used, if present.
1	Full varname	int/marker-id		ss_lock_ent_fullvar_l.id	Identify the spring in the model hierarchy or messaging.
2	Side	unsigned int	{0;1}	0	This information is not used in the current implementation. It provides the information, which spring lock is on which side on the vehicle. Should a future implementation require to lock only one side of the suspension, this information will be useful.
3	Marker 1 ID	int/marker-id		spr.i.id	Provides location and body to lock, if #4 is positive. Provides direction to lock from z-axis, if #3 is not given (-1) and #4 is positive. Provides reference point for direction, if #3 is defined (second marker).
4	Marker 2 ID	int/marker-id		spr.j.id	Provides location and body to lock, if #4 is negative. Provides second point for direction, if defined (second marker).
5	Lock Mode	int	{-6; -5; … -1; 1; 2; … 6}	-1	An integer value, that provides the information, which axis to use for locking, if #3 is not defined and whether or not to swap Marker 1 and 2. A negative value requests, that Marker 2 is used to provide location and parent body to lock. Since in 2 marker case, direction is defined as line passing through markers, only “-1” is a valid value. A positive value requests, that Marker 1 is used to provide location and parent body to lock. In this case, the absolute value is only relevant, if Marker 2 is not defined. In this case, 1 requests, that X axis translation is locked on Marker 1. 5 requests, that y axis rotation is locked on Marker 1. 1: translation - x 2: translation - y 3: translation - z 4: rotation - x 5: rotation - y 6: rotation - z In the current implementation, only 3, 6 and -1 are supported values.

The models generated from Assembly Wizard, contain locking subsystems for spring and steering, that automatically encode user selections, such as markers and directions into a lock mode. These also provide a good example to define all other values.