Comments on ScreenMaker 5.11

Kevin

ScreenMaker provides me with a good solution for allowing the operator to view process data while the Rapid program is running.

I would also like to use it as a sophisticated replacement for the functions of TPErase, TPReadFK, TPReadNum, TPShow & TPWrite.

I need to display different screens dependant on options selected by the operator in previous screens. I therefore need a method of assigning conditional actions to ScreenMaker objects; or if I do the logic in Rapid, a method of displaying any screen from Rapid (not just the Main screen). Also I need to be able to close the Main screen either from Rapid or via an action.

As a work-around I have looked at trying to control the 'enabled' and 'visible' properties of objects from Rapid, so that I can change the displayed objects in a screen depending on previously selected options.

I can bind the 'enabled' property to a controller object, so can control this property from Rapid. However, I can only bind the 'visible' property to an application variable which I cannot control from Rapid.

I understand that ScreenMaker is intended to build stand-alone applications for the FlexPendant, but think that a less restrictive interface to Rapid would greatly increase its usefullness. I hope that a future release might address some of these issues.

Regards,

Kevin

carlosmtz2000

Hi Kevin,

 

Thanks for your input. It is really valuable.

 

Regarding the connectivity to the Visible property, you can add use the ActionTrigger component, which allows you to listen to a change in a RAPID variable. Inside its Change event, you can modify the value of the application variable, which will modify the Visible property to which this varialble is connected. One of the requirements of this solution is that the default value of the Visible property must be set to TRUE in order to start the binding mechanism.

 

One of the limitations we set-up for this ScreenMaker version is that there is not script or expression editor.  We believe that if the user starts thinking about IF, while and more complex condition, it is a good canditate to use RAB ...

 

 

Kevin

Hi Carlos,

Thanks for your reply.

I will try the ActionTrigger method, which should give me a partial solution.

The overall experience of developing in Rapid+ScreenMaker for IRC5+FlexPendant is that for some of the time we are able to present the operator with a nice modern GUI interface (ScreenMaker), but then we have to use the TP**** instructions, which is a little like having to use a DOS box to achieve something in a Windows program on a PC. The UIMsgBox instruction is of limited use as we are restricted to a few standard button types.

I would rather handle the logic in Rapid than use the RAB route, and I feel that the UAS issue raised in a separate post (here) will have to be addressed at some stage.

For me an ideal solution would be for there to be two classes of ScreenMaker project ...

1. The existing one with tree-like screen structure and the project appearing in the ABB menu for direct access by the operator at any time.

2. A new one, with the project fully controlled from Rapid, not displayed in the ABB menu and without a restrictive tree structure for screen display. There would have to be some way of bypassing the UAS for actions requested from these screens: perhaps there could be separate UAS grants for this class of ScreenMaker project.

This obviously goes beyond the design and implementation of ScreenMaker. Perhaps you would kindly ensure that my suggestions are drawn to the attention of those responsible for the overall concept of the IRC5 user interface.

Regards,

Kevin

Steve_Murphy

Hello Kevin,

 

There are other issues other than UAS that arise if RAPID is to control the ScreenMaker screens.  One of the most significant ones is that the RAPID code becomes dependent on the screens defined in ScreenMaker.  If the ScreenMaker dll is not loaded, or when the screen names are changed, the RAPID program can no longer raise or lower a screen and hard-to-debug runtime errors occur.

 

Following this, one might consider a scenario where a RAPID program could look-up or discover which screens are currently loaded in the FlexPendant and available for presentation.  But this is questionable given the added complexity and does not solve the issues of ScreenMaker and RAPID dependency.

 

In the discussions preceeding ScreenMaker there were discussions on not only driving the user interface from RAPID, but also using RAPID to define the screens and objects in the screen as well.  The analysis showed that there are an equal number of limitations with this approach as well and the decision was made to release ScreenMaker with the current screens concept.

 

Kind Regards,

 

  Steve

 

Kevin

Hi Steve,

Thanks for your reply.

Dependancy between Rapid code and ScreenMaker screens seems a worthwhile price to pay if it allows Rapid to exploit the full capabilities of the FlexPendant GUI. The intention is after all that the code and screens are to work together.

When I have tried to execute UIShow with incorrect parameters or with the ScreenMaker project not deployed, the resulting error messages have made it fairly obvious where the problem lies.

I appreciate your explanation for the current limitations of ScreenMaker, but still hope that future development will result in a mechanism for versatile integration of GUI screens with Rapid.

Regards,

Kevin

Steve_Murphy

Hello Kevin,

 

The scenario that I am worried about is more in the line of when the user has 40 different screens (has been done today in ScreenMaker) and then has RAPID code that shows these screens during RAPID execution, the RAPID code will then contain references to 40 screens and given that somebody may rename a screen, the RAPID will run perfectly fine until someday in the future when the right combination of events and buttons occur, and suddenly RAPID is trying to show Screen 27 and it is not there.  Then the error message comes up and production stops, or the original author of the ScreenMaker program and/or RAPID program must be found.

 

This is why compilers are important as are all compile-time or installation-time checks that a program is complete with all references.  This is also why web-sites have so many missing links, nothing can be checked until the page is shown and the link is activated, then the missing link is discovered.  There are companies that provide special crawlers to search company sites for the missing links.

 

In addition, this brings up the issue of the entire 'project' of what shall be deployed or downloaded to the controller.  ScreenMaker applications are dependent upon the RAPID and I/O configurations and the dependency is one-way.  But, if RAPID was to become dependent upon ScreenMaker (via a screen name reference) then we would have to provide better tools not only to detect such dependencies, but also keep the ScreenMaker application more tightly coupled to the RAPID application.   This is under conceptual discussion but would be more critical with such a design.

 

Kind Regards,

 

  Steve

 

Kevin

Discussions relevant to this topic have become spread over two threads.

See also: ScreenMaker / RAB / UAS issue

Regards,

Kevin