Arrays in SCL

[HHertoghs]

I am trying to program an FB using SCL langage in which I have 64 boolean inputs. I want to put these inputs into an array so i can easily manipulate their value and compare them the values stored in another array using FOR loops.
How can I reference these 64 inputs into my INPUT array ( initialisation ) with a short instruction and address the binary inputs into this array ?
I once saw an example, but I cannot remember how it was done.

greetings
Herman

 

[Ken M]

Hi Herman

You can use variable indexed addressing for memory areas in the CPU as well the elements of an array. So if all your inputs are contiguous in the PLC you might be able to put something together like -

FOR ByteNumber = 0 TO 3 DO
	FOR BitNumber = 0 to 7 DO
		BitArrayNumber := BitArrayNumber + 1;
		BitStore[BitArrayNumber] := M[ByteNumber.BitNumber];	
	END_FOR;
END_FOR;

This assumes your inputs are stored between M0.0 and M3.7. Of course you could adjust the code for other memory areas, such as I, and for other addresses by applying offsets. Once the data is correctly assigned in the array BitStore you can do the rest of your work on it.

Of course if your input addresses are scattered throughout the PLC memory the solution is 64 very short instructions!

BitStore[1]:=I0.1;
BitStore[2]:=M31.3;
BitStore[3]:=DB21.DBX17.5;
...
...
BitStore[64]:=I66.6;

Good luck,

Regards

Ken

 

[HHertoghs]

Hi Herman

You can use variable indexed addressing for memory areas in the CPU as well the elements of an array. So if all your inputs are contiguous in the PLC you might be able to put something together like -

FOR ByteNumber = 0 TO 3 DO
	FOR BitNumber = 0 to 7 DO
		BitArrayNumber := BitArrayNumber + 1;
		BitStore[BitArrayNumber] := M[ByteNumber.BitNumber];	
	END_FOR;
END_FOR;

This assumes your inputs are stored between M0.0 and M3.7. Of course you could adjust the code for other memory areas, such as I, and for other addresses by applying offsets. Once the data is correctly assigned in the array BitStore you can do the rest of your work on it.

Hello Ken,
Thanx for your reply.
I almost got it to work with above mentioned code.
The problem I am facing now is that I need to address the bits within my instance db.
So I have

BitStore[BitArrayNummer] := DB463.DX[ 4 + Bytenummer , Bitnummer ] where 4 is the offset within my instance db.
The only thing I need to change now is the explicit use of DB463, my instance db number of this FB.
I should be able to define it as a parameter, so when I create another instance of my FB, the DB number is changed accordingly.

Greetings

Herman

 

[PeterW]

You can get the DB or DI numbers in STL by using the L DBNO or L DINO instructions.


But in your case you should not need it, where you write DB463.DX (I think you actually meant to write DB463.DBX) replace it with DIX.

i.e.

BitStore[BitArrayNummer] := DIX[ 4 + Bytenummer , Bitnummer ]

as the Instance DB is open at this point within the function block.

 

[SimonGoldsworthy]

Why do you have to refer to the variables by an absolute address ? Surely if they are in the instance DB they must be named. Can you explain why you can't refer to them by name ?

 

[HHertoghs]

You can get the DB or DI numbers in STL by using the L DBNO or L DINO instructions.


BitStore[BitArrayNummer] := DIX[ 4 + Bytenummer , Bitnummer ]

DIX seems to be STL code to me and DINO also only works in STL
I actually use DX to call a bit within DB.

Why do you have to refer to the variables by an absolute address ? Surely if they are in the instance DB they must be named. Can you explain why you can't refer to them by name ?

I do not refer them by name because i want to loop through my inputs with a FOR loop, so it's easier to read them one by one, byte by byte.
If i want to address them directly by their name i would have to find something to address TRIG_0 , TRIG_1, ... TRIG_63 from within this loop.

gr
Herman

 

[Ken M]

Herman

If DB463 is your Instance Data Block, and if all the BOOLs are already in DB463, does this mean you have 64 declared BOOL inputs?

My code suggestion was not at all clear - I'm sorry. I meant this to be used as an alternative to declaring and assigning 64 inputs. The code simply picks up the status of 64 contiguous bits anywhere in memory (M, I, Q, DB).

Simon, I think Herman's problem is that he can't refer to the name of the Instance Data Block in code since the IDB will vary with each instance of the FB. And if he has 64 discrete declarations, each with their own name, he can't use any form of indexed addressing to incorporate these in the type of code I suggested.

Another thought, Herman...
Do you have a requirement for this data packing (64 BOOLS in to 1 ARRAY) to be done several times? I wonder if it might be better to create a new data block containing nothing but ARRAYs, and write an FC which does nothing but load these ARRAYs with the required BOOL variable statuses. Then each FB instance can use this 'master' DB as a fixed store for the arrays, or even pass an array from there as a parameter to the FB rather than pass 64 separate BOOLs?

Can you explain the whole problem to us please?

Regards

Ken

 

[HHertoghs]

Thx Ken for your suggestions, but I think I should be more precise about the whole purpose :

main goal is this : I have 64 binary inputs to my FB.
I must check if there is a positive edge on each of these 64 binaries, so I save within the same FB the previous state of each binary input.
My main question was if it was possible to put those 64 binaries into 1 array so I could loop through both array's ( current and previous state ) and see if there was a positive edge.
With a positive edge I put a binary output high and the index of my array is also brought to an int output. AFter this i exit my loop so other positive edges on other binary inputs are only seen in a next cycle.
I wanted to do this somehow efficient, I could compare each binary by itself in my FB and copy this code 64 times.
With an array , I just would have to write say 8 lines of code to implement the functionality.

Hope this explains a bit

Herman

 

[PeterW]

DIX seems to be STL code to me and DINO also only works in STL
I actually use DX to call a bit within DB.

I don't use SCL as its a waste of space to me, why come up with another method of prohramming where the three already there are sufficient. I've had to fault find where SCL was used and did not have the SCL package, therefore could only look in STL. It translates into the worse code I've ever seen (with no documentation of course).

It supprises me that you cannot specify DBX or DIX as STL is the base code for all the languages and even in SCL I would have thought you would be able to access DB's and DI's.

I shall have to look up the SCL manual

 

[PeterW]

Thx Ken for your suggestions, but I think I should be more precise about the whole purpose :

main goal is this : I have 64 binary inputs to my FB.
I must check if there is a positive edge on each of these 64 binaries, so I save within the same FB the previous state of each binary input.
My main question was if it was possible to put those 64 binaries into 1 array so I could loop through both array's ( current and previous state ) and see if there was a positive edge.
With a positive edge I put a binary output high and the index of my array is also brought to an int output. AFter this i exit my loop so other positive edges on other binary inputs are only seen in a next cycle.
I wanted to do this somehow efficient, I could compare each binary by itself in my FB and copy this code 64 times.
With an array , I just would have to write say 8 lines of code to implement the functionality.

Hope this explains a bit

Herman

Why SCL for this function?

 

[SimonGoldsworthy]

If the only functionality is as described i.e. detect a rising edge from 1 of 64 inputs and report which input it occurs on, then STL would be the best choice. NB, what do you do if there are no edges detected, set the index to -1 ?

 

[PeterW]

Looking at the manual, if you declare the array in the static variable declaration field, won't these automatically be part of your instance DB on calling the FB, like any other FB.

Therefore you would not need to open the instance DB.

 

[HHertoghs]

I am not familiar with STL, I am used to program in "higher" programming languages, not at all in PLC native language. Usually I only change someone's program, I always use SCL if I need some additional functionality.

No worries, I will call someone in to program this.
I was just wondering if it could be done in SCL, but apparently it's not that easy even though it's only simple functionality.

Thx all for the help

Herman

 

[SimonGoldsworthy]

Is this block going to be called more than once (with a different set of inputs) - if not, then use Ken's suggestion

[left]BitStore[1]:=I0.1;
BitStore[2]:=M31.3;
BitStore[3]:=DB21.DBX17.5;
...
...
BitStore[64]:=I66.6;[/left]

and simply allocate the inputs to an array (yes that's 64 allocations but you will have to type in 64 addresses at the FB call anyway), and then do the edge detection in your loop.

 

[PeterW]

To be fair I think this is why I don't like SCL, the language itself is quite simple but the only times I've seen it is when it is programmed by someone who comes from a background similar to yourself.

I feel its whole purpose is to open the doorway into PLC's for higher level programmers or maybe a first step towards the replacement of PLC's with PC's.

Where I have seen it, it has always been inappropriately used. I think perhaps its best use is in special comms packages or perhaps the more complicated mathematical calculations, I don't know really.

I was involved in a project last year, where they employed a programmer to do a number of blocks of code, he was more comfortable with C and such and programmed virtually everything in SCL.

To monitor SCL you have to have the additional packages, whicjh of course we didn't have on site, so all the tracking of products was done in a way in which we could not monitor or fault find.

Most of the code would have been far more easily constructed in ladder and STL in any case.