Hi gys,

This is my first project with TIA and S1200,

I need to shift  a bit in an array of 50 bits from bit 0 to bit 50 by 1 bit  when the trigger is set.

did a lot of coding :( but did not work, so please if some have an idea would be greate .

thnx in advance 

simtex

Hi gys,

This is my first project with TIA and S1200,

I need to shift  a bit in an array of 50 bits from bit 0 to bit 50 by 1 bit  when the trigger is set.

did a lot of coding :( but did not work, so please if some have an idea would be greate .

thnx in advance 

My suggestion:
Do not shift the bits.

What you do is, you have x2 index numbers (call it #N1 and #N2). The 1st is where the first bit goes in and the other is where the last bit is written in.

1. At the start, #N1 and #N2 is 0.

2. When a new boolean value needs to be written into the array..
#N2 := #N2 + 1;
#BitArray[#N2]:= #BooleanValue;

3. This continues until #N2 == 50 then (circular action)
#N2 := 0;

4. #N1 now also increments so that the position of #N1 and #N2 is 51 elements from each other.

5. OutBoolean := #BitArray[#N1];

If the array is already filled with 51 bits, then you can skip ahead to step 3 with #N1 := 1 and #N2 := 0.

Does this makes sense to you?
w

William_B

My suggestion:
Do not shift the bits.

What you do is, you have x2 index numbers (call it #N1 and #N2). The 1st is where the first bit goes in and the other is where the last bit is written in.

1. At the start, #N1 and #N2 is 0.

2. When a new boolean value needs to be written into the array..
#N2 := #N2 + 1;
#BitArray[#N2]:= #BooleanValue;

3. This continues until #N2 == 50 then (circular action)
#N2 := 0;

4. #N1 now also increments so that the position of #N1 and #N2 is 51 elements from each other.

5. OutBoolean := #BitArray[#N1];

If the array is already filled with 51 bits, then you can skip ahead to step 3 with #N1 := 1 and #N2 := 0.

Does this makes sense to you?
w

 Thank you william_b,

No , it does not,

i `ll explain some more:

i have a chain with hooks on it , with a product . 

when a hook is detected with a bad product , this product will be rejected later on in the line ,reject after 

X hooks ( depends where the ejector is installed).

So i wanted to set the first array bit when a bad product is detected and  move it ( arraybit0 to arraybit1)

one bit if the trigger is set , and so on untill it reaches the array bit that i need to use ( depends of the

hooks there are between the detector and ejector) . example ( when arraybit[45] is set my output will be set.

I hope you want to explain your methode some more. 

( sorry for my poor english)

And thank you in Advance

Dear friends,

There is an easy solution for S7-300/400 and please migrate that to TIA Portal for S7-1200.I don't have TIA to test and it hope it works for your case.

FUNCTION FC1 : VOID
VAR_INPUT
init:BOOL;
obj:BOOL;
obj_ok:BOOL;   
END_VAR



VAR_IN_OUT
  FL1:BOOL;
FL2:BOOL;
END_VAR

VAR_OUTPUT
 OUT:BOOL;  

END_VAR


VAR_TEMP
    // Temporary Variables
i:INT;
END_VAR

    // Statement Section
    ;
  
  IF init = 1 THEN
    ;
    FOR i:=0 TO 49 BY 1 DO
    ;
    AR.main[i]:=false;
     AR.copy[i]:=false;
   
END_FOR;

 
  
 
ELSE
   
    IF (obj=1 AND obj_ok=0) AND  (FL1=0) THEN
     AR.main[0]:=1; //error
   
        FOR i:=0 TO 49 BY 1 DO
    ;
    AR.main[i+1]:=AR.copy[i];
    FL1:=1;
   
END_FOR;
ELSE
    ;
     IF obj=1 AND obj_ok=1 AND (FL2=0) THEN
     AR.main[0]:=0; //OK
   
        FOR i:=0 TO 49 BY 1 DO
    ;
    AR.main[i+1]:=AR.copy[i];
   
    FL2:=1;
END_FOR;
END_IF;
END_IF;
 
 IF AR.MAIN[45]=1 THEN
    OUT:=1;
ELSE
    OUT:=0;
END_IF;
FL1:=0;
FL2:=0;
     FOR i:=0 TO 49 BY 1 DO
    ;
    AR.copy[i]:=AR.main[i];
   
  
END_FOR;
  
    END_IF;
END_FUNCTION

Best regards,

Hamid Hosseini

hdhosseini

Dear friends,

There is an easy solution for S7-300/400 and please migrate that to TIA Portal for S7-1200.I don't have TIA to test and it hope it works for your case.

{code}

Best regards,

Hamid Hosseini

@Mr. Hosseini:
How can there be any doubt of the quality of your suggestion.
Thank you for your contribution.

@simtex:
I have another alternative now that there is more background
information. Please evaluate the attached picture.

Manipulating the array in this way is more processor intensive than what was proposed earlier, but I concede that this will suit you better. Mr. Hosseini has filled in far more detail as I have.. I hope you look intensely at what he has done and please thank him for his share.

Greetings.
w

If I understand the problem right, a simple code in SCL would do the trick:

I don't have TIA installed in my machine to test so there might be compile or logic errors in this code snippet. But, it is enough to get the idea.

Firstly, create a temporary variable "index". Then, use this code snippet:

If Trigger = TRUE And FP_1 = FALSE Then

For index = 1 To 49 Do

Array[49 - index + 1] := Array[49 - index];

End_For;

Array[0] := "NewProductInfo";

End_If;

FP_1 := Trigger;

Here, "Trigger " is your trigger signal (bool) which shifts the bits of array. "FP_1" is an auxilliary signal (bool) for evaluating pulse of "Trigger". That way, bits shift with the positive pulse of "Trigger". "NewProductInfo" is the sensor value of the product (good/bad).

I hope this helps.

beserb

If I understand the problem right, a simple code in SCL would do the trick:

I don't have TIA installed in my machine to test so there might be compile or logic errors in this code snippet. But, it is enough to get the idea.

Firstly, create a temporary variable "index". Then, use this code snippet:

If Trigger = TRUE And FP_1 = FALSE Then

For index = 1 To 49 Do

Array[49 - index + 1] := Array[49 - index];

End_For;

Array[0] := "NewProductInfo";

End_If;

FP_1 := Trigger;

Here, "Trigger " is your trigger signal (bool) which shifts the bits of array. "FP_1" is an auxilliary signal (bool) for evaluating pulse of "Trigger". That way, bits shift with the positive pulse of "Trigger". "NewProductInfo" is the sensor value of the product (good/bad).

I hope this helps.

Very good! It sure is better than my suggestion. (smile)
It should be helpful to simtex.
Just out of jealousy I make this small variation.. (wink)

IF #Trigger AND NOT(#FP_1) THEN
   
    FOR #index := 49 TO 0 BY -1 DO
        #BitArray[#index + 1] := #BitArray[#index];
    END_FOR;
   
    #BitArray[0] := "NewProductInfo";
   
END_IF;

#FP_1 := #Trigger;

William_B

beserb

...

Very good! It sure is better than my suggestion. (smile)
It should be helpful to simtex.
Just out of jealousy I make this small variation.. (wink)

IF #Trigger AND NOT(#FP_1) THEN
   
    FOR #index := 49 TO 0 BY -1 DO
        #BitArray[#index + 1] := #BitArray[#index];
    END_FOR;
   
    #BitArray[0] := "NewProductInfo";
   
END_IF;

#FP_1 := #Trigger;

w

 Honestly, I didn't know that it was possible to use "BY -1" expression in SCL. Amazing, I'll try it as soon as possible. Such a win-win night 

The only problem with this variation is the start value of the index. It should be 48 instead of 49 

beserb

Honestly, I didn't know that it was possible to use "BY -1" expression in SCL. Amazing, I'll try it as soon as possible. Such a win-win night 

The only problem with this variation is the start value of the index. It should be 48 instead of 49 

" It should be 48 instead of 49 "
Okay, yes that can be true - it depends on the definition of the array.
Even though 50 elements were asked for I worked with 51: [0..50].
Do see my LAD code. And I do have a reason for this definition.

But then your definition could be [0..49].. which is good.
..but then again [1..50] is also good.

(smile) I am glad this was a win-win.

w

Hi guys

hdhosseini . william_b and beserb , thank you very much guys.

i`ll use them and will put here some feedback .

thank you very much all of you.

My 2 cents. Call the FB only when your trigger comes. Not tested but it looks like having chance to work. Why do I bother you with this code? Because of its speed.

FUNCTION_BLOCK "Block_1"
{ S7_Optimized_Access := 'TRUE' }
VERSION : 0.1
   VAR_INPUT
      In { S7_HMI_Accessible := 'False'; S7_HMI_Visible := 'False'} : Bool;
   END_VAR

   VAR_OUTPUT
      Out { S7_HMI_Accessible := 'False'; S7_HMI_Visible := 'False'} : Bool;
   END_VAR

   VAR
      ShiftRegister { S7_HMI_Accessible := 'False'; S7_HMI_Visible := 'False'} : Array[1..2] of DWord;
   END_VAR

BEGIN
 #ShiftRegister[2]:=SHL(IN:=#ShiftRegister[2], N:=1);
 #ShiftRegister[2].%X0 := #ShiftRegister[1].%X31;
 #ShiftRegister[1] := SHL(IN := #ShiftRegister[1], N := 1);
 #ShiftRegister[1].%X0 := #In;
 #Out := #ShiftRegister[2].%X17;
END_FUNCTION_BLOCK

jacek d

My 2 cents. Call the FB only when your trigger comes. Not tested but it looks like having chance to work. Why do I bother you with this code? Because of its speed.

{code using multiple DWORD approach}

It is a pleasure to have you participate (smile).

"Call the FB only when your trigger comes. "
yes.. that is how I would have done it too. Then it may also make sense to use an FC instead of an FB and pass the array through the In/Out parameter.. using less memory resources.

Your design approach does have an issue or two.

The design intend for the system is to be able to have an index number in the array so that the index number represents a station number -  #BitArray[#StationNr]   as example. Using a DWORD approach makes it inconvenient to work with the data.

How many clock pulses does it take to process a DWORD shift command? I do not know what total scan time is spent on the FOR-loop, but you might find that it may compete against the DWORD shifting approach.

But it is VERY good for a designer to weight up different methods and be able to select the best approach for the design of the system. Therefore thank you for your contribution. (no sarcasm intended)

Other (academical?) questions -
1. What will happen if there is a power-outage and the PLC was busy doing a bit shift?
2. Can the system detect such an occurrence and compensate for it?

w

jacek d

My 2 cents. Call the FB only when your trigger comes. Not tested but it looks like having chance to work. Why do I bother you with this code? Because of its speed.

Thanx jacek d.

i ll  look into it later on .

But i have an issue , with calling an FB with array ,

thnx in advance 

simtex

 

jacek d

My 2 cents. Call the FB only when your trigger comes. Not tested but it looks like having chance to work. Why do I bother you with this code? Because of its speed.

 

Thanx jacek d.

i ll  look into it later on .

But i have an issue , with calling an FB with array ,

thnx in advance 

Careful.. you are feeding the array that is sourced from DB1, into the FB1 that uses DB1 also. Rather create a similar structured array in another DB and then feed that into FB1.

w

Dear William, 

Using FC with InOut seems to be good idea.

Yes, it's less convenient. But only when you want to change "StationNumber" often. And you can solve this by writting function getting or setting specific "StationNumber" bit.

Good question about clock pulses. This info can't be found for S7-1200/1500.  However I believe that the shift alone takes 1 clock pulse, like in the old good days of S7-300/400 :). So, execution time... I don't have S7-1200 hw. So I used PLCSim. According to it the code with DWord shifts is 5-10x faster than 49 iterations of the FOR loop. But this may be only the PLCSim...

And I miss the RLDA instruction of S7-300/400 a lot...

Anyway, in case of longer shift registers, or more data describing the objects, nothing will beat circular buffers.

Power outage. What will happen is quite obvious I think - the register gets corrupted. And trying to compensate for it may not be possible or at least complicated. I'd rather consider UPS if it's a problem.

Jacek,

Much can be said about convenience to programmer & maintenance vs cycle time of program. Only by a good understanding of the process and personal using/modifying the system will we know. However it is less critical in most cases to have a short scan cycle.

having some code working out what the WORD/BIT position is in the WORD shift concept will probably negate the cycle time advantage you had.

I do miss some commands too... for me more of what the S7-200 had. Working out the cycling time influence of coding is much of a challenge - I agree.

It is possible to detect and re-act to an error brought on by a power outage:
(Some details are left out.)

- Before doing the shift command..
1. Store a copy (BUFFER) of the current state of the array in a retentive DB
2. Reset the status bit indicating the array has correct values
3. Set status bit indicating array is being shifted.

- Execute the shift command

- Set the status bit indicating the array has correct values
- Reset status bit indicating array is shifted.


-- If power outage occurred.. check the two status bits..
10> No further action
01> BUFFER >> array and execute shift command again
00 / 11> Do a manual recovery

As for the UPS suggestion - very good idea, but it is needed to have some feedback to PLC to say that the system is running on UPS power only.

w

William,

my point of view is highly influenced by machinery we (company) build, i.e. scan time is the most important factor and in case of any stop (also after power outage) all product is out of a machine long before it is stopped.   

jacek d

William,

my point of view is highly influenced by machinery we (company) build, i.e. scan time is the most important factor and in case of any stop (also after power outage) all product is out of a machine long before it is stopped.   

 Until now, I have never had a problem with cycle time as most of my projects are based on process automation (where nothing changes in milliseconds). But even in projects with hundreds of signals, around 150kb of work memory and nearly 100 datablocks, cycle time never exceeded 10ms when using 315 CPU. I know that doesn't sound like a big project but we can call it moderate. And considering the power of new 1500 family, cycle time might be an issue only for a very limited kind of projects, in my opinion. 

I like to think about the fastest (in terms of CPU) and the most elegant (in terms of programmer) solution I can come up with. And whenever I'm stuck between speed and ease of use, I try to remember my golden rule: my time is more important than the cycle time. Because, I know sooner or later I have to read, modify and reuse the code I have written which I would like to do quickly. 

All I want to say is, this is the biggest difference of programming paradigm in machinery and process automation, which is never an interesting subject for customer :)

[smile]

Processes like motion control or rather in-motion control does change the game somewhat.

Hi,

is it possible to apply the same solution to an array of any other type beside bool (byte, int etc). 

Janko