Now we're getting somewhere, Step7 / 313C

I am now gettign closer to what I hope to be the end of this project.

The last bit to tackle involves a couple basic issues.

1) I have oil being consumed by a venturi and supplied as a fine suspended mist.

2)I can measure the drop in oil level

3)I can measure the vacuum at the venturi

4)I can read the pressure of the outlet

5)I know the size of the orifice used to limit the flow.


I have measured and scaled the analog in from the oil tank

I have recorded the first reading to use as a comparison to check the ongoing function against a standard. Additional readings are taken every X minutes and compared to this first reading.

The boss seems to think the flow of air from 10 inH2O to 46 inH2O through a given size orifice does not produce a linear flow in CFM.

We have several days of data that make it intuitivly obvious that the pressure in is linear and directly proportionate to the flow through a given orifice.

I have charted it...........now I have included this in my program.

I an taking the pressure reading before the venturi and use it to control the pressure regulator. This give X flow at various presures.

Now for the Step7 PLC question:

I have used a block that takes air pressure at the orifice and scales the flow based on the actual flow data plotted at several points on a flow bench to indicate the flow in CFM.

I then look at the amount the oil level has dropped during a period and combine the two to give a reading of how much oil is suspended in XCFM of air to give oil density.

Now I need to do this 16 times for each change in orifice. The orifice can be changed and will be different in each location but will require mechanical setup and will be noted by the HMI, so the PLC will be given the size of the orifice as a data point.

I could repeat what I have done 16 times for each orifice.

I am looking for a better way.

Can I use a function or technique in Step7 to load the new scale variables for each orifice?

I would save the MIN and MAX for input and output for each orifice. So 4 variables for each orifice and maybe an alarm band as well which would make 6 total variables.

Idealy , I would like to select, orifice X and have the FB load the correct variables based on a table of data.

I am going to look at DBs next, I suspect there is a solution here and I suspect Step7 can do it better than what I have now.

So, the small question is :

How do I use Step7 with a 313C to load a set of variables into several different memory locations when given one input bit or word.

I could just set a bit for each orifice selection and use that bit to load the other variables. That is my plan right now, pending input from this fine forum and further reading.

I'm not sure if exactly how many variables you are talking about, but there are several ways to do it.

Probably LD can give you a finished function, but off the top of my head I would look at the JL instruction. It is a very good way to access a lookup table, and is easy to manage without using a lot of pointers.

Or, if you set up your table as an array, and you know the length of each udt or variable in the array, it would be easy to calculate a pointer based on one of these 16 values.

Or maybe I'm missing what you are trying to accomplish. But like I said, if you are accessing a table, I'd look at JL.

A shorter version of the question.

Here is what I have for orifice, see image orifice01.

From the data I have, the flow apears to be somewhat linear through a given orifice at various presures from 10 to 46 inH20 in the lab.

So given that the deviation from absolute linear is not a concern, I simply scaled the pressure in to the flow that was recorded out and put the result in a real number.

Now the question is: What is a nice way of doing this 16 times where the orifice size will be given and will dictate the change in variables and the varibles to be changed will be "IN_MIN, IN_MAX, OUT_MIN, OUT_MAX"? and possibly 2 additional variables for alarms. These will all be located in "FC1001".

FC1001 is just my version of scale.

"IN" is the actual pressure reading from the analog in moved to a word and defined as "real" data type.

Maybe I'm missing the point, but I'd replicate network 4 sixteen times using the different orifice select bits for each one and using the calibration constants for each orifice.

L D[AR2 said:

Maybe I'm missing the point, but I'd replicate network 4 sixteen times using the different orifice select bits for each one and using the calibration constants for each orifice.

Click to expand...

Yep you missed it.

Your sugestion is the only way I can see to do it easily with what I know now about Step7.

This repeat the block 16 times method would work, but why repeat all that?

Why not just load a set of 4 or 6 variables instead?

Like if orificeX then move var1 into "IN_MIN" etc for each variable.

This is my second idea.

But I suspect there is a way to use a DB to solve this issue which may open new understanding with Step7 that could be used elsewhere.

Sixteen sets of moves or sixteen calls - it's all pretty much the same in the scheme of things. Of course there are other methods that will reduce the number of calls but at added programming complexity.

e.g. have a look at this example:

L D[AR2 said:

Sixteen sets of moves or sixteen calls - it's all pretty much the same in the scheme of things. Of course there are other methods that will reduce the number of calls but at added programming complexity.

Click to expand...

And these "other methods" would be...........

see previous post, just added one. It's a Step 7 archive so you have to retrieve it from Simatic Manager.

Now that is very much like what I imagined..........only with alot more detail than what I imagined.

I have not gone through UDTs yet or arrays and I need to look up a couple of the STL commands you used.

Very nice.

How does one put the data into the arrays?

I don't feel comfortable using something I don't understand, so I will go through it all and hopefully be able to use it this evening.

Thanks,

My two cents worth

dahnuguy said:

Yep you missed it.

Your sugestion is the only way I can see to do it easily with what I know now about Step7.

This repeat the block 16 times method would work, but why repeat all that?

Why not just load a set of 4 or 6 variables instead?

Like if orificeX then move var1 into "IN_MIN" etc for each variable.

This is my second idea.

But I suspect there is a way to use a DB to solve this issue which may open new understanding with Step7 that could be used elsewhere.

Click to expand...

You should also take into account the "ease of understanding" of your solution. There may be lots of different ways to do what you want, but don't forget that sometime in the future someone else may have to fault find your code. I always try to write my code using the Keep It Simple principle. If you have forsake some "elegance" or some really clever moves for the sake of simplicity thne one day (probably around 3 am on a sunday night) someone will thank you..

Simon looks to have finished for the evening so.....

dahnuguy said:

How does one put the data into the arrays?

Click to expand...

Open DB1
Menu -> View -> Data View

Add your data then save.

If you want to access/change the data in an array, you have to use indirect addressing in STL, the only way to do an array in format ARRAY[OFFSET] type is to use SCL.

Step7...........Step 1 = not simple ........

Dua Anjing said:

You should also take into account the "ease of understanding" of your solution. There may be lots of different ways to do what you want, but don't forget that sometime in the future someone else may have to fault find your code. I always try to write my code using the Keep It Simple principle. If you have forsake some "elegance" or some really clever moves for the sake of simplicity thne one day (probably around 3 am on a sunday night) someone will thank you..

Click to expand...

I normaly use the simple simple simple rule, anybody can follow most of every program I have ever written. In fact, I normaly write and re-wrtie something until it functions, flows well on the page, and is obvious to the eye.

However, with Step7, the whole thing is so cryptic, there is no chance anyone willever be able to get into it to begin with. And if they do, and they are a Step7 programer, I am leaving lots of notes to explain everything.

I have written this project using several custom blocks that make it very easy to see the important bits without searching through all the lines and lines of conversions and moves and comparisons.

I give a paragraph of text to describe what is in the block and then you are looking at 5 or 10 pieces of data and the "big picture" comes into focus.

You Step7 guys may not realize what a big deal it is to do this. But when you go searching through brand Y for something, it can take hours to get it all sorted out. Then once you get all the bits located and sort out the how, you are left to wonder, "Did I miss something? Did this guy do this because he doesn't know what he is doing, or does it just look that way? Why would anybody do it like that?" After awhile you learn to supress the urge to just re-write it so it does work and move on.

Yeah I like simple, but with S7 that's the first thing to go out the door, so why write 27 rungs x 16 when I can use a DB, a FC, and a FB and move the one block of data I need?

Now if I locked the custom blocks...................now that would be mean.

Especialy if the next guy doesn't have a canopener..........hehe

I normaly write and re-wrtie something until it functions, flows well on the page, and is obvious to the eye.

Click to expand...

... and now I'll clamber aboard one of my hobby-horses.

<MOUNT>
This idea of re-writing something till it works strikes me as wrong, wrong, wrong. Put away the STEP7, the PLC-SIM. Get the pencil and paper out. Define your problem clearly. Design your solution thoroughly. Keep the iterations going within this stage. Simply start with a list of what needs to to done. Go back through this and expand on each item in the list. Do this a few times making corrections and additions as they become obvious - and they will. Gradually introduce pseudo-code to explain how these requirements will be met in the PLC. Eventually the code itself should start to drop out of the exercise, and what's more you've now already got the documentation to justify why it's done the way it is.

Unless it is an incredibly simple task I really hate the idea of just plugging bits of code in to the PLC from scratch and gradually writing nothing but corrections.

Now I know what I've described is an ideal, but you must have heard the old saying "He aimed low in life, and usually missed." Set yourself some high standards and even if you don't meet them all the time the results will be better than if you have no or low standards.
</MOUNT>

deleted.

I missed the bit about that you want to switch one program between 16 possible datasets.

Well, I think LD gave it to you then.