Adress offset for user-defined datatypes CJ2M

[nednor 0]

Hi there,

I am starting to discover the user-defined datatype in CX-Programmer, but I have one issue with it. I can't get the addresses I want to use. e.g. I create a type called "valve" with the members  "open", "close" and "limit". Now I have to define the memory area for it, but if I chose CIO 3200 CX-Programmer assumes I want all the members to be in adjacent addresses. I would want "open" to be in CIO 3300 and "limit" to be in CIO 3200 for instance. Is there a way to specify an offset? I have tried the brackets ( [] ) behind the address in a rung, but that seemed not to compute very well.

Is there a way around this?

 

 

[IO_Rack 178]

If you are using the Data Types, I'm not sure why you would be concerned with the addresses but if you want this offset, It'll have to done in the Data Type Structure. Insert a member to take up the space.

[automase 0]

First off, making a valve data type is a great idea, especially if you've got many valves to program. This will keep them all consistent. But as IO_Rack said it shouldn't really matter where they are addressed. I see what your trying to do in that you want to declare your valve variable in the CIO memory area (It looks like this would be where your physical IO signals are coming in from? Can't remember the exacts but I recall CIO 3000's being for remote devices), BUT this would definitely be considered average practice.

What you should do is make your valve data type as you did with just 3 bits. This fits nicely into 1 word of memory with 13 bits spare if you want to expand your datatype to include things like '.Fault', '.Interlocked', '.Auto', '.Manual', etc. So then say you have 100 valves. I'd personally declare my valve variables as something like:

Name: Valve_001 (Pad the variable name with zero's as searching through the variable tables will be much easier, so you don't get Valve1, Valve10 & Valve100 appearing next to each other when trying to sort them)
Type: Valve
Address: W1 (The state of your valve is determined by IO in real time so no need to have the variables in retained memory, I only do when I've got say 500 valves and the W area isn't big enough)

Then all the way up to Valve 100.

Name: Valve_100
Type: Valve
Address: W100

Now what you can do is have a section in the program that is for mapping the IO from the CIO area, to your valve variables, and vise-versa for any Outputs. This should be one of the very first sections of code.

If you're not short on memory in you're program there's no need to conserve it. Also the increased cycle time is negligible if you're using this for valves that take perhaps half a second to open anyway.

 

[nednor 0]

Thanks for the answers! The valves were just an example. Recent I was at a plant with 40-something VFDs on a fieldbus, and each and every one of them had their respective status bits and words declared individually. The manual for the inverter suggested using structs and showed an example from Rslogix. I didn't get to try this with Omron. 

I see the point of mapping the IO to another area. It doesn't make a practical difference for the projects I deal with anyway with increased cycle time.