Question

Technical Characteristics on Type Designation

Chriswharton22
Rank
Userlevel 3
Badge +7

Hi All, 

 

When associating a Technical Class to a Type designation within Service and Maintenance, I was sure that the values for the attributes on the class could be independent from each other.

As a simple scenario, lets say we have two motors, and we have a characteristic that captures the colour of the motor connected to the technical class.  The class is connected to the Type Designation within Functional/Serial object. 

I would expect from prior experience that we can capture the colour of two independent objects which have the same Type Designation. 

  • Motor A;  Type Designation: Motor,  Motor Colour: Red
  • Motor B;  Type Designation: Motor,  Motor Colour: Blue

Both items are motors and have the ability to record values against the attributes defined in the class. 

 

What I am seeing in IFS APPS 10 UPD8 is that the attributes are no longer independent from each other.  If I change Motor A to be red, then all motors in the system are now red. 

 

I know that we can attach a technical class to an object directly through the requirements or technical data tabs, however that relies on the user remembering to add this data and doesn’t populate based on the object type itself. 

 

Is anyone able to validate this scenario on a different IFS environment? require to have type designation driven technical class with different values per object.  I wouldnt want to create multiple technical classes as there would be too much variation. 

Chris
This topic has been closed for comments

2 replies

Mayura Wasantha
Rank
Userlevel 6
Badge +15

Hi,

It has been the same behavior even in previous versions of IFS Applications. As for your request,  I tested this against some APP9 versions, where the same results is produced. Here we need to understand the functional expectation of “Type Designation” . Type designation is used for the central registration of design/article data which is same all over for given Design Part/Article.

On the other hand, the  “Requirements” is used to define different flavors of the actual object. In your example the Color.

I hope this will be helpful.

Regards

Mayura

/ mayura
T
Rank
Userlevel 2
Badge +5

Hi,

It has been the same behavior even in previous versions of IFS Applications. As for your request,  I tested this against some APP9 versions, where the same results is produced. Here we need to understand the functional expectation of “Type Designation” . Type designation is used for the central registration of design/article data which is same all over for given Design Part/Article.

On the other hand, the  “Requirements” is used to define different flavors of the actual object. In your example the Color.

I hope this will be helpful.

Regards

Mayura

Stealing the topic a little..

As per my understanding setting the technical class to object type, should inherit the technical class characteristics to objects with that  type. However I have not been able to make that work - it only works when creating new object from scratch (Apps9) or not at all (2021 R1).

Basically what we require at the moment is that the empty required characteristic fields would be available to any object with certain object type (let say servo motor) to give users the blank canvas to fill certain informations to the object, such as color, firmware, cable connector type etc. Each motor  have own unique settings and need to be filled separately, but the selected technical class with required (empty) charactericstics would be added automatically even to existing ones.

Terms & ConditionsCookie settings