Blog

Datasources in Genesis64 are defined within the GridWorX64 application to cache data for display and use in the HMI. My experience with datasources has been as a link between a SQL server database and Genesis64. However, while developing an application that contained numerous datasources (40+), I ran into an issue that rendered the application unusable. This blog post describes the issue and a workaround.

The Problem:
Refreshing datasources with a time trigger takes an increasingly long amount of time as more datasources are refreshed with the same trigger. This behavior becomes a significant hindrance when an HMI is used to display and edit data. This is because any changes made by the user to the data are only reflected in the displays when the corresponding datasource is refreshed. In other words, a very high refresh rate is required to ensure that the user sees the change made to the data relatively quickly, but a high refresh rate is not feasible when there are multiple datasources in Genesis64. In some instances, a single data refresh of all datasources took up to 30 seconds; this was unacceptable for our application and would be for most other interfaces too. 

The Workaround:
After a lot of experimentation, manual refreshing of datasources was the method that allowed for the fastest refreshing of data from the user’s perspective. A special datapoint that is provided in Genesis64 (Datasource.@@Refresh) can be written as well in order to manually refresh a particular datasource. This can be achieved by creating a process point or label, tying it to a datasource’s refresh point, and using a script to write to the process point when a button is clicked. 
In our application, any user action that could have potentially changed data in a datasource initiated a manual refresh of that datasource. While this increased development time, it ensured that the user saw the changes that were made within one second.

Learn more about DMC's Iconics programming services.

*Screenshot from Iconics Genesis64 demo.