- Software
- IQANdesign
-
Ideas
0
Language memory usage in non-display masters
It appears that text and translations thereof are stored locally on the master controller on which it is declared, even if the master in itself has no means of displaying it (e.g. on an MCx as opposed to an MDx).
Couldn't the text instead be stored on the master display(s) on which the text is actually shown, to reduce the flash memory usage on controllers that do not have a display? Depending on your implementation, I guess such a modification also has the potential to reduce the Master/Diagnostics bus load.
Text can easily occupy hundreds of KB, which is a substantial part of the MCx flash memory.
Thanks!
Customer support service by UserEcho
That is correct, the language translations are stored together with the channels.
Channel texts not require the use of a master display, the text are available also when connecting with IQANrun/IQANgo.
What you could do only send a selection of texts to the system is to tick the option for send language dialog.
Thanks for your reply Gustav,
Is the option to only send a selection of languages available also in IQANrun?
Just a thought. Assuming a multi-master system with at least one non-optional device with an abundance of flash memory (e.g. an MD4), couldn't it technically be possible to store static application data not needed at run-time (such as strings from comments, channel descriptions, measure group names and items, adjust group names and items, and even channel names) on the device(s) with an abundance of memory (e.g. the MD4)? IQANrun and IQANgo would fetch the data from that device (e.g. the MD4) but would present it as inherent to the other devices.
Of course, in the event that the device where the data is stored is not available, IQANrun and IQANgo would not be able to fetch the data, but this could be worked around by opening a copy of the application in IQANrun/IQANgo before connecting.
The send language option is available in IQANrun 2-6. It is currently missing in IQANrun 7 (and IQANgo), but should be added to version 7 as well.
I don't believe the send language options feature has been so widely used up until now, probably due to controller flash memory not being the limiting factor for most applications.
If it is becoming more used, maybe it should be incorporated in the script action for send project as well.
Redesigning the system so that texts for channels one module is retrieved from another module would be very complex. But a possible application solution could be to move channels that have lots of texts (IMSG/CMSG for example) to the display application and send the values across.