Help with Structured Text ST/SCL

[STL???]

What PLC are you using?

The CJ range can have a ST section, rather than trying to do it in a FB.
From what you said, you wanted to search through an Array of booleans, find a '1', then load the position of that find into another register?

I'm assuming the reason for the FB is for portability/security?

Hi, Its a NSJ (PLC/HMI)combination, Program/Section options are Ladder only unfortunately

So i thought i could utilize FB's to achieve this.

Looking at Ladder indirect addressing DR,IR now.

I was looking for portability ideally.

Functionality wise - it needs to loop through a range of Bools
If a match is found - store it,increment store register and then carry on looping till the next '1' is found until either the loop ends or max store registers is reached.

Regards

 

[TurpoUrpo]

I do not like Omron. It feels too restrictive on what you can do. There is things that i like about it way more than S7, but overall it loses. Mostly becouse programming itself is too restrictive. You can't mix and mach ladder/st section's for example.

FB implementation was also something I do not like in Omron. Also it feels stupid that all CPUs dont support programming languages equally.

 

[lostcontrol]

Hi, Its a NSJ (PLC/HMI)combination, Program/Section options are Ladder only unfortunately

So i thought i could utilize FB's to achieve this.

Looking at Ladder indirect addressing DR,IR now.

I was looking for portability ideally.

Functionality wise - it needs to loop through a range of Bools
If a match is found - store it,increment store register and then carry on looping till the next '1' is found until either the loop ends or max store registers is reached.

Regards

How many times will the block be used through the program?

To make it truly portable, the Boolean array index & destinations will need to be dynamic.

I can probably whip something up for you...

 

[STL???]

How many times will the block be used through the program?

To make it truly portable, the Boolean array index & destinations will need to be dynamic.

I can probably whip something up for you...

Block usage will vary from 1 call to a max of 5.

Any techniques/Pointers welcome

Thanks

 

[lostcontrol]

Hopefully someone can put me right here

I've wrote the following which should function as follows:

Scan x no of Bits (Highest to Lowest) and if a '1' is found move the current loop count to x Register

User specifies how many bits to scan (Decrementing)
User specifies how many consecutive registers to store results

e.g if set to 5,

register 1 will hold the highest result
register 2 next highest
register 3 etc
register 5 will hold the lowest result.

The Loop will exit either when 5 results are found or loop completes.

Thanks

How is the highest value determined? Highest bit position?
User specifies how many bits to scan, so if 54, and a 1 found in position 54, then 54 is loaded into register 1?

 

[STL???]

How is the highest value determined? Highest bit position?
User specifies how many bits to scan, so if 54, and a 1 found in position 54, then 54 is loaded into register 1?

Yes,
so if the User selects 54bits and 5 registers then we need to find the the highest 5 active bits in order

e.g Bits 54 53 50 40 10 are '1'

First register address = D10
D10 = 54
D11 = 53
D12 = 50
D13 = 40
D14 = 10

I have a solution using DR,IR working in ladder section, but there must be a cleaner way.

Thanks again

 

[lostcontrol]

Example attached.

This utilises CIO as the Bit Source Index & DM as the Destination result index.
The CIO_Index is the word address of where the bit address is to start, so if CIO10 (as in example) is required, then 10 is used as the parameter, likewise for the destination.

This quick example is limited in that it only uses CIO/DM, but could be easily changed to use another memory area, or have the option for all of them, but in general terms, defining the absolute should not be an issue.

No comments in example sorry, should be self-explanatory... If not, let me know & I will add some.

I have a solution using DR,IR working in ladder section, but there must be a cleaner way.

DR/IR are very useful, we use them all the time, but do not provide the 'portability' that ST does, and I guess ST is more readable as it has 'named' descriptions.....

 

[Peter Nachtwey]

Seems the PLC i'm using supports FB's but not IN/OUT variables.

Wonderful!!

Supporting VAR_IN_OUT for arrays is a problem when using FBs. The WHOLE array must be copied to the static input section of the FB. THAT IS SLOW and combersome. It would be much better if you could pass a reference ( pointer ) to the array and not need to pass the whole array but no, IEC doesn't really support pointers.

It is actually safer to copy the whole array of bits to the input area because then one doesn't need to worry about the data changing on successive scans.

Functions don't need to worry about keeping a copy of data over many scans. You might try using functions.

There is a huge difference between the way parameters are passed between the calling program and functions or FBs. This makes things tough for the compiler writer.

 

[lostcontrol]

combersome. It would be much better if you could pass a reference ( pointer ) to the array and not need to pass the whole array but no, IEC doesn't really support pointers.

I don't know exactly if my example does this, but it passes an index to the FB, and the array base index is declared within the FB. I am not sure if the complete array is accessed as the declaration is only 1x element long, but as many elements as required can be accessed.

 

[BITS N BYTES]

At first glance I wonder why you want to do this simple task in an ST function block.
Far easier to implement using the Bit Test instruction TST[350] and a FOR/NEXT loop.
Increment the N parameter of TST[350].
If TRUE then write N to a DM Array using N as the index.

My 2 cents.

 

[lostcontrol]

At first glance I wonder why you want to do this simple task in an ST function block.
Far easier to implement using the Bit Test instruction TST[350] and a FOR/NEXT loop.
Increment the N parameter of TST[350].
If TRUE then write N to a DM Array using N as the index.

My 2 cents.

Main reason I think was for portability between platforms that all supposedly implement the IEC standard.
Saying that, I think the OP siad something about Mitsubishi in there too, does mitsi have ST now aw well?

 

[STL???]

Thanks for the example code:beerchug:

Lostcontrol is right - i'm working with a variety of PLC's

ST features in most of them and being used to S7 i'd rather call a function block multiple times than copy and paste and then enter variables individually.

S7 has SCL
Telemech Micro has ST
Mitsi IEC Developer/GX Works has ST
omron has ST
etc

Far easier to implement using the Bit Test instruction TST[350] and a FOR/NEXT loop.
Increment the N parameter of TST[350].
If TRUE then write N to a DM Array using N as the index.

My 2 cents.

Noted - Ill have a look at those instuctions.

 

[JesperMP]

Supporting VAR_IN_OUT for arrays is a problem when using FBs. The WHOLE array must be copied to the static input section of the FB. THAT IS SLOW and combersome. It would be much better if you could pass a reference ( pointer ) to the array and not need to pass the whole array but no, IEC doesn't really support pointers.

S7 actually converts to an ANY POINTER for all parameters that cannot fit into max 4 bytes.
Here is an example:
http://www.plctalk.net/qanda/showthread.php?t=61273

Regarding slow, then to copy an entire array of maybe 100 bytes, is of course slower than copying a 10-byte ANY POINTER.
But the time saved is then lost again because indirect code via pointer access is much slower.
The solution: If possible, move the array to the STAT part of the FB so that the memory of the array becomes part of the IDB. Then there is no moving of the entire array, and the code execution is relatively fast because of the more direct memory access.

 

[L D[AR2P#0.0]]

S7 converts to DB pointers, not Any pointers.

 

[JesperMP]

LD, you are right. Same conclusion though.