6 Replies Latest reply on Sep 22, 2014 1:07 PM by steve_ssh

    Triggering out of context


      I have a solution called machine.fmp12 with a single table MACHINE with a single field MACHINE::id. The machine could be On / Off, so I should add another field MACHINE:status with a boolean value 0: machine off and 1: machine on.


      However instead of adding that second field I need to have the status of the machine into another solution called status.fmp12 with a single table STATUS, with three fields:


      • STATUS::id
      • STATUS::id_machine
      • STATUS::value


      The status.fmp12 is shared, so I can use it in the graph of machine.fmp12 and set the relationship between MACHINE and STATUS.


      The user is working from machine.fmp12 in a layout based on MACHINE. In that layout I have placed the STATUS::value, so the user can see if the machine is On / Off. During the normal work the STATUS:.value is updated according to the information received from hardware sensor (via PLC and OPC Server,...etc).


      What I need is to trigger a script on the context of layout based on MACHINE when the STATUS:.value changes.


      Is that feasible?




        • 1. Re: Triggering out of context

          Not exactly (since this is a related field and therefore not local data). However, you could run an OnTimer script that checks the status field on some frequency.

          • 2. Re: Triggering out of context

            Hello Rafael and Mike,


            There is a possible technique for this sort of thing that I've not seen discussed much.  I don't know if there's a good reason for that that I've missed or not.


            I'm hoping that by mentioning it here we might be able to evaluate it as a potential solution for Rafael's system, as well as for other scenarios where this comes up from time to time, e.g. sending a message from one FM client/user to another.



            The gist of it:


            1) Make use of a calculation that FMP will be constantly monitoring for changes


                This will take the place of our using an OnTimer script to constantly watch for a status change.


                A nice example of a constantly monitored calculation is the Hide Object When calculation in v.13.


                Even changes to non-local data referenced via relationship within the hide calculation trigger a re-evaluation by the FM calc engine.


                This gives us our hook to "wake up", evaluate our condition, and conditionally trigger a script.





            2) Make use of either a plugin or a WebViewer to trigger a script via the FM calculation engine.


                In non-FmGo scenarios, I would tend towards a plugin (e.g. BaseElements, ScriptMaster), because I feel that it would more robustly survive OS updates than a WebViewer


                In an FmGo scenario, the WebViewer becomes the only means that I currently see to trigger our script





            3) In the calculation that FMP monitors, include a check for the condition change that concerns our system, and, when we see that the condtion has changed, we trigger the script using the plugin/webviewer.


                This can be accompished with a calc that incorporates some condition checking, and which conditionally evaluates a statement that triggers the plugin/webviewer.



            * I'll attach an archive of sample files to illustrate this idea. *








            The advantage that I see to this technique is that it can eliminate the need for an OnTimer script.





            The big disadvantage that I see to this technique is that it requires a modification to each layout that one might have open when monitoring for a trigger.


            I have tried to see if I could work around the multiple layout modification drawback by triggering off of a calc embedded into a custom menuset, e.g. "Enable Menu When", but my initial attempts at this have not been successful.


            It may be that the custom menu calcs are not constantly monitored by FM, but are only revaluated on a Window change.  This would make sense to me.






            Last Comments:


            In Rafael's case, we are checking for a change to a specific related record, though in other scenarios, we might simply be triggering off of a single record table which maintains a single status value.


            Though the implementation details of these would differ, the same underlying technique of triggering from a constantly monitored calculation could apply.


            I would not argue that this techniqe is better than or worse than an OnTimer approach, but rather I see it as a possible alternative that we might consider as something that we might keep in our toolbox.



            Kind & best regards,









            Message was edited by: steve_ssh  Made one small change to the WV example in archive.  Uploaded new attachment: 20140902

            • 3. Re: Triggering out of context

              Hello Mike,


              I've tried the OnTimer script and it solves my problem.




              • 4. Re: Triggering out of context

                Hello Steve,


                I found your approach very interesting, since it opens alternative ways to solve the problem. I would probably stay with the OnTimer script step solution, but you show a very creative way to leverage the use of the constant monitoring calculations, which I had not realize their existence... Thanks for you detailed sample files which I will keep them in my toolbox from now on.




                • 5. Re: Triggering out of context

                  Steve is a never-ending source of wonderfully clever solutions.  

                  • 6. Re: Triggering out of context

                    @Mike and Rafael:  Thank you both for the positive words which brightened my day.


                    Rafael:  Glad you got a good solution working!


                    Very best to you both,