Public scope channel in external function
Not sure if this is exactly a bug, but it is annoying nonetheless.
In IQAN Design 5.03 or prior, it was possible to make Global Scope Variables inside Library blocks. So made a whole bunch of libraries, using that feature. Works all fine, until IQAN 5.04 or 6+, where these Global Scope variables cannot be accessed anymore.
We "fixed" this for some machines by changing the libraries, turning global scope vars into Function Group outputs and doing some re-wiring of the blocks. But many of the older software versions didn't have this change.
Now as long as you open these older versions with IQAN 5.03, everything is ok. But open them with 5.04 or newer (accidentally), and the file is basically broken once it is saved.
Can Global Scope Variables inside Libraries return in newer versions of IQAN 5 or 6?
Customer support service by UserEcho
Just to avoid confusion for other readers of this post, I changed the title of this post from "Global Scope Variables inside Libraries" to instead say public scope channels. There are no global variables in IQAN applications, a variable that you can write to is always local to a Qcode expression.
What you meant was of course channels with public scope, when used in the main project these can be read in any function group in in the application. Except from within instances of external function groups.
A problem in that existed in versions 5.00 to 5.03 was that it was possible to have a public scope channel in the main application, with the same name as a channel inside the external function. Qcode expressions in the external function that were referring to the channel with the ambiguous name would start out that referred to the name in the external. The conflicting name was only detected when re-parsing the all expressions in the entire project.
This was solved in 5.04.
At the same time, we took the opportunity to also limit the scope of channels in external files, to have a more well defined interface when bringing these in to the main project.
There is some more discussion on this here: