Step7 UDT and DB will not move

I have some data in a FB.

Said data is visible in the FB's DB.

I would like to have this data in a UDT and then move it to another location periodicaly as an archive of sorts.

I have done it nicely in a slightly different situation and I would like to do it with the UDT.

All the data are reals.

All the data are in the same FB.

All the data are contiguos.

There are 7 real numbers in a FB. I want to save them at regular intervals.

I can do it with just one variable, but I want them all together. I thought I could address a UDT in a DB and just move it with FC20 and FC90. But it just doesn't work.



I want those first 7 variables moved into DB85 as repeated UDTs.

The new one would come in at the top and the oldest would vanish off the end.

FC90 is perfect, but it doesn't like me or the UDTs or both.

Can't even get FC20 to do it.

Declare a temp variable of type udt in the temp area. Copy the 7 variables into the temp area udt using 7 moves. Use the temp area udt as the source for the archiving.

Hi Dahnuguy

A UDT is not just any arbitrary group of contiguous data. You can't just spontaneously decide "Oh, it would be convenient to grab these 7 REALs in one clutch and do something with them." Well, actually you can do that, but not with a UDT.
A UDT is just what it says - it defines a type of data, not the actual instances themselves. If you do wish to use a UDT for this you have two preparation steps. One is to define and name the UDT itself, the second is to declare and name the instance of it. Then you can use the instance exactly as L D[AR2,P#0.0] suggested.

Another alternative might be to create a pointer to these 7 REALS? Define the starting address of the data, plus the length, and then move it to the appropriate destination. No intermediate UDT required.

Typical S7, eh? You know what you want to do, and it offers two alternatives, neither of which fit your expectations!

Just another tip. You should use UDTs in DB 85. Did you manually type all of those values in? If you use UDTs, you would be able to at least symbolically address the destination area. And then by coalescing the values to a temp udt in your FB as Lar2 says, you could define the source symbolically as well.

S7Guy said:

Just another tip. You should use UDTs in DB 85. Did you manually type all of those values in? If you use UDTs, you would be able to at least symbolically address the destination area. And then by coalescing the values to a temp udt in your FB as Lar2 says, you could define the source symbolically as well.

Click to expand...

Yes Db85 is UDTs , just looks this way because of the view selected. I displayed it this way as I thought it would convey the idea better.

L D[AR2 said:

Declare a temp variable of type udt in the temp area. Copy the 7 variables into the temp area udt using 7 moves. Use the temp area udt as the source for the archiving.

Click to expand...

I did something very similar , but used the STAT area.

As I thought it over I see why using the temp area would work differently. Using the temp area would auto clear the old data.

Nice touch.

Ken M said:

Hi Dahnuguy

A UDT is not just any arbitrary group of contiguous data. You can't just spontaneously decide "Oh, it would be convenient to grab these 7 REALs in one clutch and do something with them." Well, actually you can do that, but not with a UDT.

Click to expand...

That is exactly what I would like to do in several places.

Ken M said:

A UDT is just what it says - it defines a type of data, not the actual instances themselves.

Click to expand...

AHHHHHHHHH! OK I need the type as the container or structure of the data and then I need the actual data that is in said container.

Ken M said:

If you do wish to use a UDT for this you have two preparation steps. One is to define and name the UDT itself, the second is to declare and name the instance of it.

Click to expand...

Instance of a UDT??????? Now there is a layer I had not anticipated, but I suspected something like this as I was having difficulty with the implimentation. I am trying not to get something that just appears to work. Like with the compares of INT and REALs.

Ken M said:

Then you can use the instance exactly as L D[AR2,P#0.0] suggested.

Another alternative might be to create a pointer to these 7 REALS? Define the starting address of the data, plus the length, and then move it to the appropriate destination. No intermediate UDT required.

Click to expand...

The data could be in different locations a block move would need them to be contiguous...............so I rearanged the FB "INOUT"s so they would be contiguous and then used a block move. Still had problems.

Ken M said:

Typical S7, eh? You know what you want to do, and it offers two alternatives, neither of which fit your expectations!

Click to expand...

Yes I am finding that I must unlearn what I thought knew.........

Like learning Karate and then KungFu...........or trying to levitate an X-wing fighter out of a swamp.


Oh , I will look to see if I can nail down how to name an instance of a UDT. Just in case I don't find it............How would one do such a thing?

The instance of a UDT just makes sense now............of course it would have to be this way! You could use that UDT all over the place............obvious...........not sure how I missed that.


Thanks,

dahnuguy said:

Yes Db85 is UDTs , just looks this way because of the view selected. I displayed it this way as I thought it would convey the idea better.

Click to expand...

Ok, I see what you did. In the future, try using arrays of udts. Then you won't have to manually type in each udt instance name. You could enter an array of 100 udts, and they would be named something like Converyor[1].Start, Conveyor[2].Start, etc.

S7Guy said:

Ok, I see what you did. In the future, try using arrays of udts. Then you won't have to manually type in each udt instance name. You could enter an array of 100 udts, and they would be named something like Converyor[1].Start, Conveyor[2].Start, etc.

Click to expand...

I did not know you could make an array of UDTs .that's neat.

When I read the array discription, it saya all the data in the array has to be the same type. And most of my UDTs are of mixed type. I thought this would cause a problem.

From the other angle though all the UDTs would be the same.

I am going back over the array discription, I went over it breifly the first time around as it did not look usfull for what I am doing.

Thanks,

dahnuguy said:

I did not know you could make an array of UDTs .that's neat.

When I read the array discription, it saya all the data in the array has to be the same type. And most of my UDTs are of mixed type. I thought this would cause a problem.

Click to expand...

Yes, it saves a lot of typing. Also, you don't have to start at zero. You can start at 1, 10, -15, whatever.

When they refer to type, they are talking about multi-dimensional arrays, meaning you couldn't mix something like dints and bools.

or trying to levitate an X-wing fighter out of a swamp

Click to expand...

You've done that? Well then, STEP7 can't be that bad!

I am enjoying the challenge of S7 it is fun........

Ken M said:

You've done that? Well then, STEP7 can't be that bad!

Click to expand...

On the contrary, Step7 was introduced by the Sith Lords to defeat the Bright young programmers of the world by twisting their minds and warping their perspective.

"What? Of course you have to declare the data type on every memory location, how else would you do it? Of course you can address the same memory location 5 different ways simultaneously"

GOOD good........give in ........come to the Dahk Side.......

"Name one PLC programming language where the software editor can tell what a varible is without explicit declaration." (um all of them I have used.........)

Don't listen to them my young aprentice, your training is almost complete....


Step 7 is so much more powerfull than any of the others............we have Function Blocks.



<Jedi to Yoda> "Is it true Master Yoda? Do they have these powerfull Function Blocks?"

<Yoda> Yes.........

<Jedi> How can we possibly win against that?

<Yoda> "What? FB are just subroutines without the automatic data handling. They have to declare and define every electron that passes through the program. But they have devised very creative ways to make all these obstacles seem less painfull.

<Jedi> Why must they do this Master?

<Yoda> Beats me...........they seem to enjoy complication for its own sake.
Ok now back to levitating Xwing fighters, where were we? Oh yes I see ........concentrate ..............focus............

Or, someone has no doubt said many times before, in answer to the question about how to turn on a PLC output when the corresponding logic insists on solving false ...

"The force. Look, use the force."

Yes the force is strong with us.

I also like using Mexican timers................off delay ON DELAY!