How to do complex math in S7

[S7Guy]

Just set your tempValue to zero first. From your code, the variables you are using are 32bit dints. Can you be sure the numbers will not overflow when all the arithmetic is done ?

In this particular case, you wouldn't have to clear the temp values, since it is initialized with the first calculation. But it's a good idea to understand when you do and don't have to do it.

Another good way to learn STL (IMHO) is to write the code you want in ladder and then convert it to STL (View-STL). Then read and digest.

I agree. But remember that ladder requires a lot of extra instructions, so when you convert it to STL, it's good to strip out the extra stuff so you can see the code that is actually doing the work. After you do this a little bit, you'll be flying in STL.

Btw, does anyone have a sample SCL project I could look at? I have the SCL package, but haven't found a compelling reason to use it. I'd like to see an appropriate real life application.

 

[RMA]

Roy

I haven't seen Simon's STL code, nor do I want to. The SCL, excluding the declarations etc, comes to 4 lines of perfectly comprehensible code. I can understand it, I would know what the end purpose was, even if I hadn't seen the preceding messages. If I write a piece of code in any language, I want to be able to monitor, debug and correct it in that language, using the same thinking that created it in the first place. Sure you can look at the resulting compiled code decompiled back in to STL but what does that tell you that the SCL doesn't?

Ken

No, wasn't seriously wanting to work with it that way rather than use SCL. I heard some horror stories during my first PCS7 project about 4 years ago, where the project manager heavily restricted the use of SCL because he claimed the compiler was so inefficient that programs came out between 3 and 10 times longer. Somebody commented recently that the compiler was now very much better and I was interested to see what that meant in practice. Certainly I think the 52 (or so) lines of code compare pretty well with the simple code S7Guy proposed, although I'm sure he would do it a lot more compactly for himself!

Having said that, not having an SCL editor it was interesting to see that I could actually follow the program without too much trouble - you definitely can't say that for an S7GRAPH program looked in STL!

 

[JesperMP]

Here is link of RPN Calculator

Good link, I see that there are many more RPN calculators there.
(http://www.web-ee.com/Downloads/Calculator/calculators.htm)
Unfortunately there isnt my favourite HP15C.

(I humbly excuse everyone for sidetracking this thread).

 

[RMA]

Btw, does anyone have a sample SCL project I could look at? I have the SCL package, but haven't found a compelling reason to use it. I'd like to see an appropriate real life application.

Eric Noe's Braumaster program was heavily into SCL, I'm not sure how much of it wasn't knowhow protected, but it might be worth a look.

By the way, I noticed he's posted again on MrPLC, evidently he still hasn't got it sorted, which I really don't understand, because I thought we'd got to the point where it was pretty clearly some incorrect addresses, weird. I think there was quite a lot of misunderstanding and talking at crossed purpopses in that Thread. Two nations divided by a common language again, perhaps?

 

[douyi]

Here is another question. I know in LAD it requires all the operators have to be the same type, such as all are DINT or all are REAL, so instruction 'move' sometime is used for type translation and pass values in between.

Is that the same thing in STL or it will do it automatically ?

About STL, if I want to give same value to more than one variables, is that correct:

L 10
T Var1
T Var2
T Var3
...
...
...

Is that right ?
Thanks.

 

[kamenges]

STL doesn't do automatic type conversion. However, there are type conversion instructions that operate on the accumulator. For example, if you want to multiply two double integers together and then multiply that product by a real and return the result back to a double integer you would have:

L   DINT1
L   DINT2
*D
DTR
L   REAL1
*R
RND
T   DINTProduct

So you just do any necessary type copnversions on the fly. Just realize that when you do the real to double integer conversion (RND) you may lose some precision.


Also, the example you give below with the multiple transfers afterr a single load is valid. I've always though that transfer was kind of a bad name. Transfer infers that you are removing the value from the source. It is really more of a copy.

Keith

 

[douyi]

About STL again

I toggle between STL and LAD several times, got some clue. Thanks. For some move instructions, if use LAD style of STL it will be like this:

L "HMI".Knife_DINT9[100]
T DB104.DBD 218
NOP 0

L "HMI".Knife_DINT9[120]
T DB104.DBD 222
NOP 0

and so on.

I think I can combine them together like:

L "HMI".Knife_DINT9[100]
T DB104.DBD 218
L "HMI".Knife_DINT9[120]
T DB104.DBD 222

So I have two questions. 1st is :

Do I need the 'NOP 0' at the end?

2nd is :

I don't know what benefit is in such kind of combination? for Processor, it should be the same I think.

But on the other hand, if these move instructions has some repeat work, I can use a pointer and make a loop to do that. That's another story.

==============================

For another instruction : -----(#)----- (Midline output),

The STL is like this:

A "HMI".Comm_Bits3[100].B15
= "Servo".In_Position.Program
A "Servo".In_Position.Program
= "Servo".Homed.Program

Can I make it like this: ?

A "HMI".Comm_Bits3[100].B15
= "Servo".In_Position.Program
= "Servo".Homed.Program


Thanks.

 

[lhughes39]

Nop 0

1. The "NOP 0" (no operation zero) is a place holder for the coil/exit rung from the instuction so that it can be translated back into Ladder. If you remove them and combine the two instructions as you did they will work and it can be done in one network, BUT it will NOT translate back into Ladder. So if down the road some one has to look at your code who does not know STL they are will not be able to understand it.

2. Yes you can remove the second "A" (and). It should work the same, but I would ask why it was programmed that way to begin with. There may be some reason I can not se for it. I have never seen a VERY good reason for using a Midline Output, but have seen them added after code was written and they wanted a quick fix.

Hope this helps.

 

[JRW]

A couple of tidbits
Eric's program was written in CFC. When CFC compiles, it uses SCL.
He is missing the CFC chart folder in his project.
Some of the protected blocks are Siemens CFC library blocks- the source files are not given away with these.

 

[douyi]

I have never seen a VERY good reason for using a Midline Output, but have seen them added after code was written and they wanted a quick fix.

Sometime when using RSLogix5000, because it allows so many midline output, so that's already become a style of RSLogix programming (5000 only, 500 doesn't support).

So when I translate the logic, I want to keep mostly same, now it seems I have to use STL for complex math because LAD doesn't support make it only 1 rung like A-B "CPT" does.

Thanks again.

 

[douyi]

If I don't want to use "JUMP TO"

Now, I can easily write math in STL. So I'm starting combine the math with logic, then I found if I want to do something like

...
"If logic_1 AND (NOT logic_2) AND logic_3
then
do some complex math ...

end if"
...

The only thing I can find out is use temp bool (like S7 did use local temp when I transfer back and forth from LAD to STL) for simple math or use jump for complex (more than one line, like assemble language) logic.

Do we have other way to do that? because I don't want to use jump too much.

 

[SimonGoldsworthy]

You could put the complex math in a FC or FB and then make the call conditional on logic. This will keep it in ladder but the STL will still use jumps.

 

[JesperMP]

douyi,
I understand your last post as "I like to have the logical conditions for doing the math calculations in LAD", but then "when I make complex math in STL, the logical conditions in the same rung will not display as LAD".

You solve this by splitting the logical conditions and the math into two rungs, passing the condition for executing the math from the first rung to the second rung.
That is actually a perfectly acceptable solution to the problem.

In that way you also dont use any extra jumps, apart from the single one that decides if you do or dont execute the math.

The CPT instruction AB is absolutely genial, unfortunately there isnt a similar one in S7.
The way you are doing it now is probably the closest you will get.

If you can accept the hassle of splitting the logic and the math into separate rungs, you get an advantage that you dont have in AB:
When debugging, in S7 STL you can follow how the variables change for each instruction. In an AB CPT instruction you can only see what come out of the formula - if there is an error in the formula it can be tricky to find it.

 

[Ken M]

S7Guy wrote

Btw, does anyone have a sample SCL project I could look at?

I've been looking for a particluar project I was involved in where we used SCL, but I haven't unearthed it yet. (Don't worry - I haven't looked too deeply - it's not that I have a really bad filing or backup system!)

In this case we used mixed languages where we felt they were appropriate. Basically it was just a conveyor control system, so there was a lot of STL and LAD in it. But there were also two cameras on Profibus returning data values to the PLC about what they were seeing. There wasn't much analysis available in the cameras themselves so a lot of the maths had to be done in the PLC and SCL seemed the right tool. The advantage that it gave was very much on the thinking and designing aspects of the code.

We were working with empty unlabelled whisky bottles. These were almost square section and would eventually have the label applied slanting from bottom-left up to top-right (got the brand yet?). On the face where the label would be are two parallel moulded ridges (eyebrows) also slanted at the same angle. These are designed to protect the paper label once it has been applied by preventing rubbing, scraping etc. in packing and transit. Part of our job was to ensure the bottles were the right way round before they entered the labelling section. This was where the two cameras, at right-angles to each other, took an image of each bottle as it passed and tried to see where the ridges were. Unfortunately, the bottle glass used is anything but optical quality and has lots of small blemishes, bubbles and swirls in it (presumably it looks more rustic and authentic). Sometimes the reflection of light from these could fool the camera in to 'seeing' a moulded ridge where none existed.

Overall we had to write some code that was working on probability, not binary logic. We had to simultaneously weigh the two images from the cameras, decide whether they agreed about the bottle orientation, and if so which was it. If there was no agreement, was one camera image sufficiently strong in certain key signals that we could trust it alone, even if the other disagreed weakly? How much disagreement would we permit before diverting the bottle for a recycle (and therefore slowing the operation)? We had to map distribution curves where if we thought we detected a ridge within certain zones it was accorded a strong score, but elsewhere it was more likely to be an optical atrefact caused by a blemish. Personally I honestly couldn't imagine even thinking correctly abouut these problems in LAD or STL. That's not to say that SCL is 'superior' or 'better', just that I knew how to express myself using it.

After commissioning and tuning we had the system running at a level of reliability where we were exceeding the user's un-detected error target by a factor of 3x. In fact they became slightly suspicious and installed two people to check the output of our section, sure that some of the bottles we passed had to be the wrong way round! Sure enough they were, but as I said the original spec called for something like no more than 1 undetected wrong bottle per 10000 and we were achieving 30000+. Given more or better data we think we could have achieved 100% (yes, dangerous thing to say, I know), but the user decided the cost of scrapping one wrong bottle (before filling!) every 30000 or so, was cheaper than another camera or enhanced lighting etc.

Now, just where did I put that code, S7Guy?

Regards

Ken.

 

[JesperMP]

I havent worked with SCL, but being interested I have a quick question:
Is it possible to view the SCL code online in order to debug it ?
Or does it switch to STL ?