Omron CX-Programmer Address Management

[Hann]

Is there an efficient tool to manage and validate CX-Programmer addressing.

Requirements:
- Highlight Duplicate Address allocation
- Compact/Defrag address range to avoid wasting memory space.

Note:
- Any FINS addressing will have to be reconfigured
- This approach assumes symbol use rather than direct addressing in the logic.

 

[BITS N BYTES]

Within project:-
Select View > Cross Reference Report
Select "Duplicate usage over programs"
Select Generate.

 

[Hann]

Thanks for letting me know that exists!

 

[BobB]

The addressing also has I, Q, W etcetera numbers so you do not have to fiddle about with bloody symbols - I program by numbers. Attached is the options box - 'Show Address After Name' is turned on. Pic 2 shows the result.

 

[parky]

I agree with Bob, Not many systems can use symbols only like RW, some platforms if you use symbol addressing only (do not allocate the symbol to a physical address) then it cannot be read by an HMI or Scada system.
I believe some platforms can by producing an area to store the symbols, this gives the physical address for the communications.
Many systems currently availlable still use fixed memory areas like Word addresses, at compile time any symbolic only tags are allocated to physical addresses, this is usually an area reserved for the compiler so can be different on each compile, I do not know CX but take the slightly older Mitsubish system.
part of the word area is reserved for symbolic addressing so what happens is that any tags that are declared as absolute would be in the "D" area from D0000 to D7999, the reserved area is D9000 to D9999 (don't take this as gospel because the area can be changed in settings) so if you create a tag called My_Int_Var & use a physical address it could be "My_Int_Var, D100"
A symbolic only address could be "My_Int_1_Var" would not have a physical address but when compiled could be any of the D9000 to D9999.
Unless the platform has some way of storing these in some form of symbolic table that points to physical address an HMI or scada could not access it.
Platforms with physical addressing you don't need to worry about compressing or defragging as these exist anyway, as far as duplicates a cross reference can find them.
Unlike Siemens data areas are fixed, in Siemens Datablocks are downloaded to the memory so the amount & size are how you configure them the larger or more you have the more memory is used.
So on platforms that do have fixed addressing space makes no difference on how many tags you have it does not impact on scan time, only those used in the program contributes to the scan time (well sort of).
The things that do impact are communications, try to make data that is written to or from an HMI or scada system are not fragmented i.e. keep these tags in groups, this means less transactions for example if you have a large chunk of say integers being read by an HMI then it could be one coms transaction, if the data is split over a large data area i.e. say D100, D105, D200 etc. then it would either have to transmit a large amount with some unused tags or a larger number of transactions of small amounts, as communications have an overhead i.e. strt, address, checksums etc. transmitting 10 individual addresses takes more bytes i.e. 10 transactions with 20 bytes each compared to one transaction of 30 bytes + overhead for tags that are continuous.
I suspect most PLC systems will move away from physical address space in favour of symbolic as that is part of the IEC format this helps in code that is transferable form one platform to another.

 

[BobB]

Omron new PLCs are auto allocation - in other words IEC and symbols. Programming is way too slow - searching for symbols is a PITA! That being said it is powerful but slow for mine. CX-P is my favourite programming software by far - and I use many. Emerson (GE) is next but no programmable function keys. Click is quick and easy also. Siemens and Schneider are a long way down the list. Clunky.

 

[quailflowerpot]

Within project:-
Select View > Cross Reference Report tunnel rush
Select "Duplicate usage over programs"
Select Generate.

That's great. Your sharing is really helpful

 

[parky]

I personally like FBD, much better, just drop a function without having to move cursor to where you want to place it, use symbols only if used within the same program or function no need to bother with physical addresses unless exposed to other blocks or external i.e. HMI/Scada etc. No need to wory about power/common lines

 

[Hann]

You all have made some excellent points:

@parky
- I am only aware of the FINS driver on Kepware that requires direct addressing, so I agree that auto allocation is out.
- I still have to develop an HMI standard for Omron, and I wasn't sure if a byte packing feature existed on this platform, I will raise it as a new post.
- As Far as I know there are no function block features in CX-Programmer

@BBob
- I have stumbled across, those settings and they are very useful.

@BITS N BYTES
- I have briefly played with the feature but I am not quite sure it fully solves my problem. Data Types use multiple words of data. The report shows each element of the data type's usage. This seems like it will need some post processing to draw attention to an error rather than scanning through the whole document manually.

 

[parky]

It's standard & obvious, never really know how the coms are done on any HMI but there is no doubt that keeping tags in banks rather than spread is obvious, any communication driver would have difficulty if the tags being read/written to were spread too widely appart, I bet most drivers only request data from visible objects on the HMI screen or if needed like logging, this cuts down the amount of data, probably if you have gaps in addressing of a few addresses then the driver probably includes some not used but discards them i.e. only those needing updating are processed. It probably does not matter on a small system where there is not many tags on the HMI or are spread over many screens (assuming it only updates tags that are visible at that time or logging or alarms etc.). So it makes sense where possible to group your tags used in the HMI as best as possible. I tend to make all buttons that drive a bit in the PLC in one area, same as alarms always contiguous, just like you would a recipe.