Reading unlocated Variables in Modicon

I am working on rading variables from a M340 application into WonderWare with DASMBTCP DAS Server.
My issue is that I want to read the unlocated variables that are linked to the Magellis touchpanel.
These variables are addressed as %UV.
It seems that the syntax is something like this:
%UV(XX).YYYY.ZZ.255.(Data type).824371125.
Where
XX = seems to be data type?
YYYY = Address
ZZ = number of bits
(Data Type) = REAL, BOOL, TIME, INT etc.
the trailing numberseems to be the same throughout the program and may be the build number or some such.
My question is since everything has to be i nmemory somewhere can these values be read vis Modbus?
I know that the Unity Pro will produce the file for the Magellis and Vijeo to exchange data, but I really don't want to introduce OFS into my system if I can avoid it.
Does anyone have an idea about the syntax and addressing?

Thanks

Why not just locate the variables? I know it's a bit of work now but it'll save you a lot of headache later on. If you hard code those variables into Wonderware and do a full rebuild of the PLC program there is a chance those addresses could change.

Either use OFS and link it to a XVM file, or if you want to avoid that and use your built in IO servers for Intouch then locate your variables

Saffa said:

Why not just locate the variables? I know it's a bit of work now but it'll save you a lot of headache later on. If you hard code those variables into Wonderware and do a full rebuild of the PLC program there is a chance those addresses could change.

Either use OFS and link it to a XVM file, or if you want to avoid that and use your built in IO servers for Intouch then locate your variables

Click to expand...

Of curse I can locate the variables, but that opens up other problems.
The problem is that if you change the program then the Unity Pro recalculates the table for the unlocated variables and you have toload this new table into the Vijeo project and rebuild the system or the PLC and the Magellis will not talk
I am trying to get around this without OFS which still requires using the Data Dictionary and reloading the Magellis program.
Also the PLC (M340) needs to have the firmware upgraded for the data dictionary to work with it.
This application is for a lime slurry make up and silo system that is required 24/7 and I would like to migrate it over to all Wonderware at some time and this would be an interim step.
If I bring it into our Wonderware application then I would not have to worry about the D^%$ Magellis crapping out and reloading the program in the replacement. Along with the fact that the old units are no longer available.

Isn't there data dictionary setting without firmware update.
Enabling it should do the trick and you don't need to update also magelis after every plc modification

http://www.plctalk.net/qanda/showthread.php?t=91129

That's the whole point of locating the variables. Program change. ..no problem. Other than a bit of work initially I see no other down sides?

I do this with all our remote M340s. Sometimes i need to tweak the programs remotely over slow radio links and i don't want to have to update the HMIs each

Saffa said:

That's the whole point of locating the variables. Program change. ..no problem. Other than a bit of work initially I see no other down sides?

I do this with all our remote M340s. Sometimes i need to tweak the programs remotely over slow radio links and i don't want to have to update the HMIs each

Click to expand...

Are you using Magellis panels programmed with Vijeo?
Also with Unity Pro the data dictionary will not work with the current firmware so before I can generate the dictionary I need to upgrade the firmware.
If it were not for the compatibility between the M340 and the Magellis panel the locating of the variables would not be a problem either.

redbarron55 said:

Are you using Magellis panels programmed with Vijeo?
.

Click to expand...

Yes. I am using latest firmware though, and the STU panels. I generally build my application, locate my HMI variables in a block of %MW, export variable list then import into Vijeo. That's just to build the variables initially.

But i generally don't touch them much once they're first created.

I think redbarron misunderstood you saffa.
What saffa meant with "locating the variables" is to give them physical addresses.
Memory shouldnt be a problem

Yes I agree he is correct< but after the application is loaded if changes are made in the variables then the application will have to be exported to Vijeo and rebuilt.
Perhaps the thing to do is exactly all of that to expose the variables to Wonderware, I wanted to avoid all of that and there is plenty of memory as stated.
While this is being done the Magellis will not communicate with the PLC. (the exported memory map will not be correct and the HMI will not connect until the Vijeo designer builds the map to track those pesky variables.
If the original programmer has located those pesky variables in %MW locations it would be easier.
Part of the problem is the DFB XXX.out etc. variables .
Since everything has t be in memory those pesky numbers are somewhere, I just have to be able to figure out where they are and I can lie to the WonderWare DASMBTCP server to pull them out.

What i would be cautious of is that those locations may change after a full build. So if you do figure them out and build your Intouch tag db using those locations, there's no way to know they will stay that way indefinitely.

You can locate UDT types in memory as well. It can get a bit inefficient depending on how your sub types are organised though.

So if the only problem is firmware version that you can't use data dictionary. Why you just don't buy new CPU and download project with data dictionary setted on on PLC settings. Change PLC and panel will work. (or update firmware of original CPU)

Data dictionary (Tools → Project Settings → General)

Dictionary of symbolized variables with their characteristics (address, type,...) in the PLC memory.
If this setting is enabled, all symbolized variables of the application are embedded in the PLC memory and any client (SCADA using OFS, HMI, embedded Web server...) can then animate or modify those variables. By default, the settings are disabled.
The Data dictionary is generated at build time. This block is updated only if it is needed during an online modification.
NOTE: Comments of the variables are not stored.

The 3 following properties improve the performances of the Data dictionary online build:

• When checking Preload on Build Changes, download of data dictionary reflecting the change of variable definition will be performed before applying the real change of the application in the PLC. The PLC client tools will then be able to learn new changes of data.
• The Effective Build Changes Time Out (sec) is the time (1..240 s) that Unity Pro will wait between the download of the new data dictionary and the real online application change, the down counting of the time out will be displayed in the progress bar during the Build Changes operation.
• Checking the Only HMI variables and identifying the HMI variables necessary in the Data Property table improves online build performances and memory usage of the PLC. This setting means that the data dictionary will embed only variables or DFB/EFB instances that have the HMI attribute set.