Hi @lamaus, I looked into this in our internal RnD support environments for 23R1 and 24R1 and the event is available in both environments. But I also got some technical help to get a quick look at this, but the answer I got wasn't as clear as expected."Normally, events are registered in the 'Event.ins' file of that component, but I can't find this anywhere in the current codebase for 24R1. Even when checking into the App8 codebase where the PCM component was there, still couldn't find a place where this is registered.The event seems to only be used in the Pm Calendar Generation schedule. That usage code is still there. So the guess is either this was added to a previous release manually and remains in upgrade environments and/or this is always added by a user as needed."Please add a support task for this to RnD if you want to keep track of this, otherwise we plan to investigate internally how to handle this for release 24R2.Best RegardsPelle
Hi, the design of the PM Programs is as you describe it. I agree that it would provide a clearly greater added value if the programs could be configured in a better way.The administrative work required today of having to create separate PM Programs for each combination of Item class and work task template would be significantly reduced if PM actions were only generated for valid combinations.I would suggest that you post this as an Idea here in the Community as a suggestion for improvement so that it can be taken into consideration. Best RegardsPelle
Hi,When looking at the Tool/Equipment page I saw this field,. I have never used it and is not sure how it’s intended to be used. When reading the field description it sounds like something that could be worth looking at? RegardsPelle
Hi NK,As mentioned the Replaced By functionality is built into the PM generation routine and can by that only be used between different PM Actions within same generation. Below you can find a small example how the replacement functionality is built up to work. It's possible to do a setup that PM '2' replaces PM '1' if they both are part of same generation. It' also possible to do a setup in several steps, i.e. that PM '3' replaces PM '2' and also that PM '2' replaces PM '1' if they are part of same generation. This setup in several steps will then also include the scenario that PM 'C' replaces PM 'A'. Example:• (Weekly) - PM1 = Once a week • (Monthly) - PM2 = Once every 4 week• (Yearly) - PM3 = Once every 52 weekThis would end up in a situation that if several of these PMs is to be generated same week, only one will be generated.• For a week where only PM1 is planned for generation , only PM1 will be generated.• For a week where only PM2 is planned for generation, only PM2 will be gen
Hi,I'm afraid I simplified reality a bit in my answer and I'm sorry for that.The conditions you define on your PM Actions are all linked to a parameter+test point which in turn was previously defined on the object for the PM Action.To always get all this generated at the same time, all your PM Actions must then have the same object and the condition line (parameter+test point) must be set up the same on these PM Actions.This is unfortunately not the case in your example as you have different objects on the PM Actions for Comp and Inst.However this could possibly be solved by inheriting measured values from the object you have on the COMP side to the object you have on the INST side and thus make the measured values follow each other and thus get generation of them at the same time.Unfortunately the functionality for inheriting measured values from one object to another is not part of the standard functionality in APP10.Currently this functionality is only available as part of the
Hi,There can be a possibility to solve things by using the Replacements and PM Group ID functionality and not have any PM connections.But there are some things to consider if you want to run it like this.When using replacements you need to do the planning of the PMs in a way that for example the part of the PM to be replaced (PM10) need to be added as a part of the replacing PM (PM11).This mean if PM10 contain of work ‘A’ and you sometimes want to replace PM10 with PM11, the work for PM11 will be planned as ‘A’+’B’ where ‘A’ is from the replaced PM10 and ‘B’ is the additional work. Replacement in one level: Scen 1 – PM11 replacing PM10PM10 - Small job - (A) PM11 - Medium job - (A+B) Hours PM10 PM11 2000 X 4000 (X) X 6000 X 8000 (X) X 10000 X 12000 (X) X *X = PM generated**(X) = PM replaced and not generated If wanted yo
Hi, The statuses can just be changed in one direction from preliminary -> active -> obsolete. Once a pm action has been set to status obsolete, it will stay in this status and cannot be set to active again.Easiest way is to create a new revision from the obsolete revision that you have. Best RegardsPelle
Hi @mdeanton, A change introduced to APP10 was that the work task concept was introduced so that the work task became the driving part and the work order only a holder for work tasks.At same time, it was changed so that the maintenance plan now is updated when the actual maintenance work (linked to the work tasks) actually has been completed. I.e. no longer when the work order (that only is a holder for the work tasks) has been reported and completed. When running a PM with Performed Date Based = Yes or Performed Value Based = Yes, the maintenance plan will be adjusted based on the date on which the last work task connected to the PM was set to status Work Done.There are four columns in the maintenance plan related to this:Last Work Task Completed Last Work Task Completion Date Last Work Task Step Completed Last Work Task Step Completion DatePlease also see an extract from the user documentation below. Best RegardsPelle
Hi @Anders Jansson,In version APP10 the Route PM Actions was removed and instead two new ways was introduced as replacement, ‘Group’ and ‘Merge’.The 'Group' concept is more advanced than the old Route handling and the 'Merge' concept is more simple than the old Route handling. 'Group'Used by adding a value in 'PM Group ID' but no 'Merge' flag set. The 'Group' concept is to be seen as the main option for the old route handling if you have use for more advanced "route" handling. All Work List lines from one or more PM Actions will become Work Tasks on the generated Work Order. The execution will be done on Work Task level. For PM Actions using 'Group' you will get the exact costs reported back into the Actual Equipment Object on the Work Task. 'Merge'Used by adding a value in 'PM Group ID' and the 'Merge' flag set. The 'Merge' concept is only to be used for simpler actions that you want to perform as a part of a list together with other similar simpler tasks as a checklist. As example f
As an addition to my earlier answer.if you want the PMs to be connected to each other every third time when both are generated, my proposal is to solve this by using PM Group ID on the PMs to get both generated as separate work tasks into same WO.Best RegardsPelle
Hi,When working with PM structures the top PM will be the master and all underlying PMs connected will inherit the generation details. As in your example PM ‘Y’ will inherit the details from PM ‘X’ and by that also be generated each time when running the event. This is the basic idea with creating a PM structure, that the identical structure will be created on the WO side. However as I see it you can get what you want without connecting your PMs into a PM structure.When you enter the event data into your PMs you just enter as follows.PM ‘X’ - Event = <event name> , Start = 1, Interval = 1 PM ‘Y’ Event = <event name> , Start = 1, Interval = 3Now when running your event generation for event <event name> you will get PM ’X’ generated each time and PM ‘Y’ every third time. Best RegardsPelle
Hi,OK then I don’t have much ideas.Just few things that you can check, but I’m not sure they will help.You run Performed Value Based = Yes on the Condition line. This will require an ongoing WO to be finished before generating a new. (However in you example this would rather have impact on the parent PM than on the child PMs). Second thing to check is the the configuration of the Object Level used for the objects used on the child PMs. If this Object Level allows creation of WOs. This configuration can be found in Equipment/Equipment Basic Data/Object Levels.RegardsPelle
Hi,There is no possibility in STD to inherit a meter value from one object into another object in the facility. To get things working you need to define a PM for the parent pump and then also one PM for each of the components you want to connect. For the parent pump PM you add a condition line for the working hours.For the component PMs you add no condition lines at all.For the parent pump PM select RMB Connections and add each of the component PMs as connected PMs in the table.See to that all PMs are activated.Add measurements for the pump object on your parent pump PM until you get a Generation Value that will lead to a WO generation.Run Condition generation.Now it should end up in a WO structure generated that reflect how the PMs was connected into a structure. RegardsPelle
Hi,I even think there is a possibility to enter a negative number into ‘PM Inventory Part Demand Horizon (Days)’ field to also remove material demands back in time. But I have not tested it myself to see what consequences it might have.
Hi,I think the material demand from PM Action is decided and created from these rules.From date for the material demand lines are created from the higher value of either:‘Valid From’ date in PM Action/General tab. The System date.To date for the material demand lines are created up to the least value of either:‘Valid To’ date in PM Action/General tab. ‘PM_PLAN_HORIZON’ defined in Application Base Setup/System Setup/System Definitions/Object Property tab The date you get by adding the number of days in ‘PM Inventory Part Demand Horizon (Days)’ field in Site/Maintenance tab to the current System date. According to this, the easiest for you will probably be to decrease the value in ‘PM Inventory Part Demand Horizon (Days)’ field to shorten down the days forward the material demands will be set. Otherwise the way to go is probably to either set the PM Action to Generatable = ‘No’ or the relevant Maintenance Plan lines to Generatable = ‘No’. If you are going to set the entire PM Actions to
Hi,After you on the PM have entered a Condition line for a certain Testpoint/Parameter, either of type Accumulate (with a Start Value and Interval) or type Limit (with Min Value and/or Max Value), you can start adding measurements for this Testpoint/Parameter combination.As long as you have not exceeded the level for your Accumulated line according to specified startvalue/interval nothing will happen. I.e. this will not be part of any condition generation.Same goes for a Limit line that not have exceeded the specified limits for min/max value. I.e. this will not be part of any condition generation.At the moment you enter a measurement that exceed the specified startvalue/interval (Accumulated) or min/max value (Limit), then you will get this measured value into the Generation Value field.It’s this Generation Value that is set for this Condition line on the PM that is the trigger used for generation of a WO when running the Condition generation.
Hi,What you request is the functionality named as ‘Performed Value Based’ that is available on the PM condition line in STD from App9 and forward, and by that it’s not available in App8.The Performed Value Based functionality is built up to be used in a similar way for condition PMs as Performed Date Based functionality for calendar based PMs. Help texts from APP9:Performed Value BasedDisplays whether or not the maintenance plan is to be moved forward in time, based on the actual completion date of the last work order that was generated from the PM action. The final value of the forecast measurement is calculated from the average use of the equipment multiply by the date difference of the planned and completion date of the work order. This is valid only for the Accumulated type parameters.Performed Date Based:Displays whether or not the maintenance plan is to be adjusted in time, based on the actual completion date of the last work order that was generated from the PM action. Notice th
Hi, I’m aware of that this answer is a bit late for the original question but still hope it can be of use for someone.Below you can find some information of the thinking behind some ways of grouping together several PMs into same WO.Regarding merge criteria there might have been one or two more criterion added to the list. Mechanisms for putting PM Actions together into same Work OrderIn App10 when introducing Work Task concept in Service & Asset a lot of work was also done in the PM area. One thing among other was to remove the earlier way of distinguishing between Separate PM Actions and Route PM Actions, to just have PM Actions. On the other hand, then different mechanisms were introduced to be able to get more than one PM Action into same Work Order after generation. In this way it become more flexible how to build up Work Orders from one or more PM Actions. PM Group IDBy using same PM Group ID, the PM Actions will be grouped together and the Work List lines on the PM Actions
Yes when introducing Work Task Templates as a replacement for Standard Jobs in APPS10, the LOV for Part Nowas rebuilt to include both inventory parts and purchase parts.
Hi,As a complement to the answer given by Dilini. Execution Time will only follow into the WO from a PM Action during generation when you have a 1:1 relationship, i.e. when you generate one single PM Action into a WO. When using the functionality of grouping or merging several PM Actions into same WO, no execution time will everbe set on the generated WO.
Hi, Equipment Object Navigator window was part of an extension for APP8 and was then taken into STD in APP9. Best RegardsPelle
Hi,I once solved this by creating a custom menu in Separate PM Actions ovw window. It was used for a support task but you can probably use this description as a base.RegardsPelle Work Steps to create a Custom Menu in Separate PM Actions overview window Logon into the environment as an Application Owner (IFSAPP) or another user that have privileges to create custom menus. Open Separate PM Actions overview. Select RMB Properties. Check the ‘Include Custom Items’ box and click OK. Select RMB Custom Objects / Menus / Create New and fill in the following information. Description: ‘Regenerate PM Plan’ Action Type: ‘PL/SQL Block’ Menu Text: ‘Regenerate Plan’ Action Parameters / PL/SQL Block: ‘&AO.PM_Action_API.Refresh_Plan__(&PM_NO,&PM_REVISION);’ Presentation Object: ‘tbwPM’ Translations: ‘en-English Regenerate Plan’ (or another line for the language wanted) Save the information. Open Separate PM Actions overview and see that you have a new RMB option Regenerate Plan.
Already have an account? Login
No account yet? Create an account
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.
Sorry, we're still checking this file's contents to make sure it's safe to download. Please try again in a few minutes.
Sorry, our virus scanner detected that this file isn't safe to download.
