Schneider Unity Pro XL copy data to/from DDT

[bevanweiss]

Hi all,

I'm sure this is a stupidly simple question, but I'm really struggling to find any EFB or similar to do this.

I want to map a block of data (like an array of INT) into an instance of a DDT.

The reason I want to do this is, I have an existing M340 rack (actually three racks linked with rack expansion cables) which is being migrated to an M580. Since the M580 won't fit in this rack the client has INSISTED that we use a single PRA module to link these three racks into the M580.
I've tried to convince them that a CRA is the 'right' way to do it, but no traction on that.

Anyway, I have a nice pair of DDTs (one for IN, one for OUT) configured in the PRA, with all of the appropriate data mapped into it, and it's nicely located at readable memory addresses.
In the DTM Browser of the master, I'm aware of how to create transactions etc. Although here it appears I'm unable to use any DDT as part of this mapping, restricted to only elementary types. So an array of INTs seems like the best system here... but then I still want to map this back into my nice DDTs, so that it's more obvious that data at the PRA end aligns with data at the M580 end (without remembering that DATA_RX[402].4 = Rack2.Slot10.Channel15.ERR)
And obviously manually mapping each data item sounds really rubbish to me

Help please

 

[Saffa]

Are your nice DDT elements all ints? Or a mix of bools, ints etc?

If all elements are the same type then you could just give them the array and the DDT the same %MW address.

But if you have some bools in the DDT that would be related to bits in a word, then that won't work - bools in a UDT require 8 bits to store. That's in an M340, but i think M580 is the same.

As painful as it sounds you might need to copy element to element.

I do this for data in and out of RTUs that can only read sequentially addressed blocks of INTs, and I do all the code in ST using the := operator and a few type conversions. Its actually really easy to build the code in something like excel first using string concatenation functions. Especially if you have your DDT already built - just export it, open it up in Notepad and with a bit of copy / paste you can have it in excel in no time.

 

[Lare]

Linking via %MW is possible, but then all variables needs to be same type as Saffa pointed.
Also as it is indirect addressing, it isn't allways clear how data is transferred if Unity pro is not everyday tool



I posted example of transferring ints to DDT several years ago.

Types don't need to be exactly same, but you need to take care of bools extracted to int variables.
http://plctalk.net/qanda/showthread.php?p=776365




Whit extract block it is also possible to transfer differently sized parts, so you can construct your int and bytes and bool to different extract blocks, but from / to same DDT-type.


But as I understanded, you have allready M340 CPU on old racks. Why you want use CRA then. You can repogram old M340 to transfer IOs only to %M and %MW areas and then read/write TCP modbus from M580 to M340.


PRA-module would also function same manner.


Also, isn't it possible to add M580 via Xway cable to old M340 racks?
Xway can be 36meters long on M580, and M580 support 0, 4 or 8 local (xway) racks. (max local racks depends of CPU type)

 

[Lare]

Here is example of different sized parts transfer to DDT.


It would be more readable if you construct DFB-blocks for different transfer types.

 

[bevanweiss]

Are your nice DDT elements all ints? Or a mix of bools, ints etc?

If all elements are the same type then you could just give them the array and the DDT the same %MW address.

But if you have some bools in the DDT that would be related to bits in a word, then that won't work - bools in a UDT require 8 bits to store. That's in an M340, but i think M580 is the same.

The DDT elements are a mix of types.

The issue with the %MW aspect is that DTM Browser created variables DO NOT allow to be located in the M580 (which seems to differ from the M340 behaviour). So it's not possible to just use %MW assignment to map things over.

 

[bevanweiss]

Whit extract block it is also possible to transfer differently sized parts, so you can construct your int and bytes and bool to different extract blocks, but from / to same DDT-type.

I did see the EXTRACT EFB, but it seemed pretty confusing to me. It looked like when dealing with DDTs you have to choose an arbitrary 'division' (as the length) and then the offset and transfer size would be in units of this.

But as I understanded, you have allready M340 CPU on old racks. Why you want use CRA then. You can repogram old M340 to transfer IOs only to %M and %MW areas and then read/write TCP modbus from M580 to M340.


PRA-module would also function same manner.

I wanted to use a CRA to take advantage of the media redundancy, which the client is also demanding. Doing this with PRA/NOE seems like a real kludge.

The DTM browser can't access %M, so best to not use them

Also, isn't it possible to add M580 via Xway cable to old M340 racks?
Xway can be 36meters long on M580, and M580 support 0, 4 or 8 local (xway) racks. (max local racks depends of CPU type)

[/QUOTE]
This is something that I had not thought of... I really like this idea.
Then I could just do topological mapping of the existing modules and all that would need to change is they would get a +1 on the rack offset.
Given there is less communications etc, the customer 'should' like it.
But will see.
Thanks for the info

 

[Lare]

This is something that I had not thought of... I really like this idea.
Then I could just do topological mapping of the existing modules and all that would need to change is they would get a +1 on the rack offset.
Given there is less communications etc, the customer 'should' like it.
But will see.
Thanks for the info

Then you would only need correct M580 CPU type.
look manual from page 67


https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=3&ved=2ahUKEwiNuYzHpfvnAhVjyaYKHVyiAtIQFjACegQIBRAB&url=https%3A%2F%2Fmedia.distributordatasolutions.com%2Fschneider%2F2018q1%2F8b857fcc58888b0b497b68131a8550c8304fbeeb.pdf&usg=AOvVaw3CKnKUUiMuS38XVL33TcUQ


1020 = 4XBUS, 0RIO racks (CRA)
2040 = 4XBUS, 8RIO racks
3020 = 8XBUS, 0RIO
3040 = 8XBUS, 16RIO




p.s



Xbus lenght limit is 30m meters for M340 / M580 series, not 36m as I writed before.


https://www.google.com/url?sa=t&rct...IO0000002626&usg=AOvVaw1p4ofEvJZGhfdzNgvDcY7B
page 44.

 

[bevanweiss]

Xbus lenght limit is 30m meters for M340 / M580 series, not 36m as I writed before.
page 44.

Yep, I already knew 36m wasn't the right number... but I was mistaken that I thought it was 30m for the total bus length. It's 100m for the total bus length, and 30m per bus cable. Which means it'll easily fit.

I think that Schneider having so much segregation of capability within the M580 range is silly (i.e. only x40 units can do RIO drops, the x20 units can only do DIO). These kind of things should only be for big series changes, like between M340 or M580. But to hamper the M580 processors in such a way is silly.

The extended rack solution is really a winner I believe. It would be cheaper than the PRA/NOE or CRA version, and it provides some more IO slots (since the existing M340&NOE can be removed) on top of the cost saving.
Plus the flexibility of having all of the IO data presented (rather than trying to squeeze it all through a DIO connection).

 

[tragically1969]

I think that Schneider having so much segregation of capability within the M580 range is silly (i.e. only x40 units can do RIO drops, the x20 units can only do DIO). These kind of things should only be for big series changes, like between M340 or M580. But to hamper the M580 processors in such a way is silly.

I agree, it's confusing the way the limitations are described too.

It's OK once you have your head around it but would be easier if there was a Xref somewhere, but with little knowledge its very easy to end up with the wrong processor, also the CRA modules can be easily messed up as some are dedicated to X80 but not eX80 and have different capabilities and I/O limitations.

I tend to use EcoStruxure Plant Builder now to check builds before we order anything, its actually a pretty good tool.

 

[Lare]

Yep, I already knew 36m wasn't the right number... but I was mistaken that I thought it was 30m for the total bus length. It's 100m for the total bus length, and 30m per bus cable. Which means it'll easily fit.

I think that Schneider having so much segregation of capability within the M580 range is silly (i.e. only x40 units can do RIO drops, the x20 units can only do DIO). These kind of things should only be for big series changes, like between M340 or M580. But to hamper the M580 processors in such a way is silly.

The extended rack solution is really a winner I believe. It would be cheaper than the PRA/NOE or CRA version, and it provides some more IO slots (since the existing M340&NOE can be removed) on top of the cost saving.
Plus the flexibility of having all of the IO data presented (rather than trying to squeeze it all through a DIO connection).

How I undestands from manal it is 30m meters is overall for XBE1000 xbus cards.


"NOTE: In the daisy chain, the maximum cumulative length of X bus cables is 30 m (98,42 ft)."


100m meters was for older P57 platform, which had Xbus connectors directly on racks.


I agree, that Schneider have too much too choose.


Cheaper PRA module, which is actuallu CPU with ethernet, but without USB-connection and first you need to configure DHCP from master CPU, before you can connect first time.


Then CPU, with ethernet and USB, which you can also program for only IO transfer (instead of PRA-module, and it cost little bit more.


Then CRA module, but wait, you need select right CPU also.
And for M580 you need ethernet rack for main rack and all rest racks have to be without ethernet cabalicity.


But for M340 you need to use only Xbus racks, which are allmost similar than ethernet models.


(Well it is possible nowadays to use ethernet racks only, but before wrong rack halted CPU.)




Still thinking that it easier to order parts to Schneider than with Siemens ET200SP

 

[Lare]

provides some more IO slots (since the existing M340&NOE can be removed) on top of the cost saving.
Plus the flexibility of having all of the IO data presented (rather than trying to squeeze it all through a DIO connection).

if you remove M340 CPU and NOE-card, then M580 CPU should go to old track directly as it is 2 slot wide?