S7-1500 moving variables from one DB to another

ojz0r

Member
Join Date
Feb 2009
Location
127.0.0.1
Posts
435
Hello all,


I have a problem that seems to be hard to solve.
In an upgrade project from an old Sattcon 200 PLC to a S7-1500 the client requested to keep their SCADA system as is (IFIX).
So the tags between the PLC and IFIX is the same in the IFIX end, and addressed in a new DB in the S7-1500. This was rather easy to do until we tried connecting it to the new IFIX driver to S7. The S7A driver for IFIX only allow to read the first 1023 bytes in the DB, in which we have ~2700 bytes. So we need to split this DB into three separate DB's - the problem is that the everything is addressed to the one DB and when trying to cut and paste into new DB's it does not re-address these tags to the new DB in the logic.


Has anyone ever had to do something similar that have a good, not too time consuming, way of doing this?
 
Suggestions:

1. Create 3 data types that contain the data split into each group less than 1023 bytes.
In the 1st DB add 3 STRUCTs, each defined by its respective data type.
Setup 3 DBs for Ifix, each one with only 1 STRUCT defined by one of the data types.
Now you can easily copy the data like this:
"Ifix_db1".data_type_1 := "Common_db".data_type_1 ;
"Ifix_db2".data_type_2 := "Common_db".data_type_2 ;
"Ifix_db3".data_type_3 := "Common_db".data_type_3 ;

2. With serialize/deserialize you can copy basically from anything to anything (see example 2):
https://support.industry.siemens.com/cs/ww/en/view/42603881
 
That seems like a crazy communications driver limitation. Does IFIX have the option of using OPC UA? If so you can use the OPC UA server on the PLC and call it good (license required, but probably cheaper than time lost figuring out how data is shuffled around, and then watching everyone else who touches the project in the future scratch their head).
 
Suggestions:

1. Create 3 data types that contain the data split into each group less than 1023 bytes.
In the 1st DB add 3 STRUCTs, each defined by its respective data type.
Setup 3 DBs for Ifix, each one with only 1 STRUCT defined by one of the data types.
Now you can easily copy the data like this:
"Ifix_db1".data_type_1 := "Common_db".data_type_1 ;
"Ifix_db2".data_type_2 := "Common_db".data_type_2 ;
"Ifix_db3".data_type_3 := "Common_db".data_type_3 ;

2. With serialize/deserialize you can copy basically from anything to anything (see example 2):
https://support.industry.siemens.com/cs/ww/en/view/42603881


I like the struct solution, very neat.
However im not sure it will work as the communication is bidirectional.


That seems like a crazy communications driver limitation. Does IFIX have the option of using OPC UA? If so you can use the OPC UA server on the PLC and call it good (license required, but probably cheaper than time lost figuring out how data is shuffled around, and then watching everyone else who touches the project in the future scratch their head).


Yes very limiting.
We belive there might be a bug in the "S7A" driver (its 3rd party). There was an option to use an offset, but at first it was not working. But when we started from scratch again we managed to create three "blocks" in the S7A IFIX driver with different offsets to cover all addresses.


So the imidiate problem is solved, but the original question is still: How can one move (bidirectional) variables from one DB to another while still retaining its connection to the new DB? Maybe this is undoable?
 
I like the struct solution, very neat.
However im not sure it will work as the communication is bidirectional.





Yes very limiting.
We belive there might be a bug in the "S7A" driver (its 3rd party). There was an option to use an offset, but at first it was not working. But when we started from scratch again we managed to create three "blocks" in the S7A IFIX driver with different offsets to cover all addresses.


So the imidiate problem is solved, but the original question is still: How can one move (bidirectional) variables from one DB to another while still retaining its connection to the new DB? Maybe this is undoable?

The 1500 has the concept of pointers for flexible data access, but not hard links between tags/DBs.

Hypothetically, you could do it if you manage the HMI data transfer, where the data is copied into the HMI transfer area before the HMI reads, and then copied out again any time the HMI writes. It probably requires the HMI to be aware of the coordination, although whether it could be done with scripts or needed to be in the driver I couldn't say. At best it sounds super duper messy.

I'm glad you found a workaround.
 
Rename your DB to AAA
Copy/paste AAA and rename it to BBB + assign new DB number

Copy/paste AAA and rename it to CCC + assign new DB number

Delete the last third of the tags from AAA
Compile the program
Where it fails, replace AAA with BBB


Delete the last half of the tags left in AAA
Compile the program
Where it fails, replace AAA with CCC


Trim BBB,CCC down to remove the tags no longer used.
 
Would it be possible to use IGS instead? Last I used iFix they were throwing all protocols in IGS unlike previous times when you'd license protocol.


Unfortunately S7A is the driver the client already have on site.


Rename your DB to AAA
Copy/paste AAA and rename it to BBB + assign new DB number

Copy/paste AAA and rename it to CCC + assign new DB number

Delete the last third of the tags from AAA
Compile the program
Where it fails, replace AAA with BBB


Delete the last half of the tags left in AAA
Compile the program
Where it fails, replace AAA with CCC


Trim BBB,CCC down to remove the tags no longer used.


Hm this might work, provided TIA doesn't change all the DB names in the logic. We did a quick test before posting this thread but we only tried with 2 steps (like AAA, BBB) without luck, maybe the third step is the magic one.
I will test this solution (for fun) when i get back into the office.
 
What do you mean by 'without luck'?


It worked for me.


Sorry. What i meant was that we did do a test similar to this, but not identical, without success. I will try your method when i get some time back in the office to experiment with this.
 

Similar Topics

HI DURING MY LAST VISIT TO ONE OF THE SITE ,MY PLC WAS RECEVING SOME OF THE INPUTS FROM DCS SIDE,BUT SINCE DCS ENGINEERS WERE NOT AVAILABLE I...
Replies
2
Views
4,673
Hi all Trying to remotely connect to a TIA Portal PLC. I can ping it without a problem but can't get my software to connect. I've opened port...
Replies
8
Views
281
Been fighting all morning with a stubborn HMI. It just won´t connect with the plc. attaching from settings. Have i missed anything? Both plc and...
Replies
5
Views
235
Hi there, Maybe I am overthinking this issue, but here is what I have going on. I have a program running for a water valve on a DI system. We...
Replies
4
Views
429
Hello, I am programming in S7-1500, V17. I have some blocks from a drive manufacturer that are not compiling and giving me an error "Invalid...
Replies
2
Views
273
Back
Top Bottom