Step 7 problem (OB 40 I think is the issue)

uptown47 · Jun 1, 2008

Hi all

I've got a major problem after translating some S5 code to S7. The system basically lifts up some bottles and places them into boxes.

There are two proxys watching two toothed wheels attached to the motor. The idea being that as the motor spins the proxies count the pulses either up/down or left/right.

The previous S5 system used a special digital input card and OB 2 (interrupt block) in order to count the pulses.

In order to convert to S7 I've used a CPU 314 and used the built in interrupts to call OB 40 on the rising edge of the proxies.

The problem is that every couple of cycles of the machine the "height" word starts incrementing or decrementing as the machine moves left or right (i.e. without the machine going up and down).

I've never set up an OB40 before so it could be a set up problem or a code problem. I think its code but in the interests of completeness I'll try and include as much info as I can here...

Here's a piccy of my hardware config...

My proxies are wired into I 2.0 and I 2.1

There are also "product pick up" and "product drop" sensors wired to I 2.6 and I 2.7

Here is a copy of OB 40...



L PIB 2

T IB 3

//;

A "I 3.0"

A M 0.0

JCN X000

CALL FB 3 , DB75

X000: NOP 0

//;

A "I 3.1"

A "Q 13.2"

A M 0.0

JCN X001

CALL FB 4 , DB76

X001: NOP 0

//;

A "I 3.1"

A( 

AN "Q 13.2"

A M 0.0

O M 1.1

) 

JCN X002

CALL FB 5 , DB77

X002: NOP 0

//;

A( 

A M 3.1

A "I 3.6"

O "I 3.7"

) 

A "I 6.0"

JCN X003

CALL FB 6 , DB78

X003: NOP 0

FB 3, 4, 5, and 6 do the addition and subtraction.

Here is a copy of them...



**** FC 3 *****

 

L MW 40

L 1

+I 

T MW 40

NOP 0

 

***************

 

**** FC 4 *****

 

L MW 50

L 1

+I 

T MW 50

NOP 0

 

 

***************

 

 

**** FC 5 *****

 

L MW 50

L 1

-I 

T MW 50

NOP 0

 

 

***************

 

 

**** FC 6 *****

 

L QW 12

L W#16#FFFD

AW 

T PQW 12

NOP 0

 

 

***************

MW 50 is the "height count" and MW 40 is the left/right count.

MW 50 should go from -90 to +90 roughly and MW 40 goes from 0 to 280 ish.

MW 50 is the one giving me the trouble. (although that's not to say that MW 40 won't be a problem as well when the machine runs properly).

The machine moves to a STOP LEFT sensor and resets MW 40. Drives down and picks up product.

Then it drives up and moves right to a STOP RIGHT sensor. Drives down and drops product off.

The LEFT and RIGHT extremes both reset MW 40 to 0 which is why there is only an ADD for MW 40.

When the machine is moving left or right it also seemingly randomly increments or decrements MW 50 ???

MW 50 will start off at +90 after picking up the product, then, as the machine moves over (not altering its height) MW 50 decrements to a minus number. Its not always the same number. Its like its getting 'phantom' pulses somehow??..??

Anyone any ideas why this could be??

This is a really massive problem for me and I would be very grateful if you have any ideas?

Many many thanks

PeterW · Jun 1, 2008

L PIB 2
T IB 3

Why transferring IB2 periphery into IB3?

You show jumps to FB's and examples show FC's, which is it?

For the little code in the block, personally I would have neither,
I would program the code all in one block.

If I had to use any, it would be a FC, as there is no storage requirement
so an FB would be wastelful. Those DB's would be empty.

I've never set up a hardware interupt on an S7, but looking at that picture confuses me
a bit. It looks like IB16, 17, 22 and 23 have been selected for rising edge interupts.

I cannot see where you look for changing state, if I 3.0 (are you sure thos shouldn't be I 2.0?) was on last scan
it will jump and count if the interupt block has been called again and its still on.

I would do some sort of XOR of the byte and remember the lasts state, to ensure that
I didn't increment the wrong ones.

EDIT:

I would do somethong like

L PIB2
T IB2 //Update Input Byte

L MB4 // Memory of last scan
XOW // Exclusive OR to get bits changed
L IB2 // Recover IB2
T MB4 // Save for next call
AW // AW, so only bits that have changed and are on left on
T MB5 // Work bits for this block

uptown47 · Jun 1, 2008

Hi Peter and a MASSIVE thank you for replying to my post...

Yes, you're right, they are FB's and I typed FC's by mistake.

As for your other points..

I'm transferring the PIB 2 to IB 3 because in the S5 code they transferred IB 0 to IB 1.

IB 1 wasn't being used but it was apparently part of the make-up of the special input card that was being used. Would it be the same thing to just transfer from PIB 2 to IB 2? I'm pretty sure I tried that and got some strange results...?

The hardware config picture, as I understand it, has 24 bits because the CPU 314 has 24 digital inputs and any or all of them can initiate a hardware interrupt. I've wired my proxies to I 2.0 - I 2.7 (although not all those bits are needed as interrupts) so I'm setting up bit 16, 17, 22, 23 as hardware interrupts which I believe equates to I2.0, I2.1, I2.6 and I2.7 (although correct me if I'm wrong)

Just looking at your code.. would MB5 be a carbon copy then of IB2 ??

Once again a really big thanks for your input so far..

Cheers

PeterW · Jun 1, 2008

OK, I see what you mean with the inputs. I've never used a 314, I didn't know it had built in IO.

In my example MB5 would have ON, only the bits that went off to on for this interupt.

For example IB2=00000010 from last time OB40 was called.

MB4 in my example is a last scan store, so would also be 00000010

Say now I 2.0 comes on, then IB2 would change to 00000011

Therefore

00000011
00000010 XOR

00000001 = Only 1 bit changed
00000011 AW

00000001 = Bit 0, changed and is in a state of 1. This goes into MB5.

If Bit 0 then goes off

00000010
00000011 XOR

00000001 = Only 1 bit changed
00000010 AW

00000000 = Bit 0 going off, does not create a 1.

Therefore M 5.0 will be ON, only when I 2.0 goes from OFF to ON. If the next time OB 40 is called, it is because of I 2.1 going on for example, then M 5.0 will be off as the XOR would ensure it is off.

Therefore M 5.0 can be used as a condition (together with the drive output perhaps) to increment the count.

In your code, it looks possible that if I 2.0 caused OB 40 to be called it would increment a count, if I 2.1 then caused OB40 to be called and I 2.0 is still on, then it would increment a count again, even though the input to caused the OB to be called did not change state.

uptown47 · Jun 1, 2008

Peter

That could explain the problem!!

So if the machine is driving from left to right and the up/down proxy is still at a 'high' state then will it increment or decrement the MW50 height count?!?

If so, then that could very well be the issue. It certainly makes sense as to why it sometimes works and other times doesn't...

If so, using your example, would this code work...



 

 

L PIB 2

T IB 3

 



L MB4        // Memory of last scan

XOW          // Exclusive OR to get bits changed

L IB3        // Recover IB2

T MB4        // Save for next call

AW           // AW, so only bits that have changed and are on left on

T MB5        // Work bits for this block

//;

A M 5.0

A M 0.0

JCN X000

CALL FB 3 , DB75

X000: NOP 0

//;

A M 5.1

A "Q 13.2"

A M 0.0

JCN X001

CALL FB 4 , DB76

X001: NOP 0

//;

A M 5.1

A( 

AN "Q 13.2"

A M 0.0

O M 1.1

) 

JCN X002

CALL FB 5 , DB77

X002: NOP 0

//;

A( 

A M 3.1

A M 5.6

O M 5.7

) 

A "I 6.0"

JCN X003

CALL FB 6 , DB78

X003: NOP 0

Do you think this would work then?

Many many thanks

PeterW · Jun 1, 2008

Just thinking my explanation is compicated.

Basically, how do you one shot the sensors.

Looking at your last FC/B

L QW 12
L W#16#FFFD
AW
T PQW 12
NOP 0You should add

T QW12, otherwise at the end of the scan, the output will be turned back on by the image.

As I said, cannot see why you use FB's, open DB77 and you'll find an empty DB.

For this type of code though, I'd jump over the sections you don't want and have all the code in the OB, no need for FC's/FB's at all.

uptown47 · Jun 1, 2008

Hi Peter

I only used FB's because that was what was used in the S5 version of the code that I translated. I used FC's in exchange for PB's and FB's in exchange for FB's..

I did think about putting all the code in OB 40 (in fact I have a version with all the code in it) but I wasn't sure if I was missing something or not and that maybe they had written it like that for a reason that I wasn't familiar with.

I'm not "one shotting" the sensors. The sensors are set in the hardware config to call OB40 on their rising edge. I've never set up a hardware interrupt before but I assume that this is the correct way of doing it?

I'm not sure what you mean about 'jumping' over the bits of code I don't want...

Do you mean just tagging the ADDition or SUBtraction to the end of the network instead of having the call to the FB there??

Would that work?

Many thanks for your continued support

L D[AR2P#0.0] · Jun 1, 2008

For future reference, if you use the S5/S7 converter it will only produce OB's and FC's. Step 5 FB's convert to Step 7 FC's. There is no equivalant of a Step 7 FB in Step 5.

PeterW · Jun 1, 2008

What I would do, following the above example is:

Code:

   	   AN M 5.0
   	   ON M 0.0
   	   JC =JMP1 //So Jump over of M5.0 or M 0.0 is OFF
    [font=courier]
   	
  [/font]	 L MW 40
   	   L 1
   	   +I 
   	   T MW 40
    
   JMP1:  AN M 5.1 
	 ON "Q 13.2"
   	   ONM 0.0
   	   JC =JMP2
   
   	   [font=courier]L MW 50
   	   L 1
   	   +I 
   	   T MW 50
    
    JMP2:    etc.. etc

[/font]

uptown47 · Jun 1, 2008

L D[AR2 said:
For future reference, if you use the S5/S7 converter it will only produce OB's and FC's. Step 5 FB's convert to Step 7 FC's. There is no equivalant of a Step 7 FB in Step 5.

I did use the converter and saw that it only uses FC's but it made it more difficult to fault find on. At least by calling the blocks the same I can easily directly compare the new S7 code with the old S5 code.

OB 40 is a direct translation from the S5 code from the old OB2 S5 Interrupt Block.

Peter, when you say "following the above example" I take it you mean that I still use the XOR'ing method and then use JUMPs as well as per your code?

Many thanks

L D[AR2P#0.0] · Jun 1, 2008

Just to amplify - You have to detect the rising edge of the inputs using XOR or FP's or any other method that you prefer. When you have detected the edge, you perform the relevant count processing.

(The input that caused the interrupt can be found by examining OB40_POINT_ADDR from the temp area of OB40 - I wouldn't change tack half way through though, stay with Peter's suggestion)

uptown47 · Jun 1, 2008

A massive thanks for all your help Peter, Simon.

You've both helped me out hugely. I hope you both know that it is really appreciated. Thank you.

I'll try Peters suggestion tomorrow (ie. the XOR's and the JMPs) and I'll post back on the results.

Thanks again

L D[AR2P#0.0] · Jun 1, 2008

Here's a ladder implementation of your original post in source code format. Call FB40 from OB40 using an instance DB.
Hope this helps.

Code:

FUNCTION_BLOCK FB 40
TITLE =called from OB40
VERSION : 0.1

VAR
  bUpDownProxyEdgeStore : BOOL ; 
  bAcrossProxyEdgeStore : BOOL ; 
  bUpdownEdgeDetected : BOOL ; 
  bAcrossEdgeDetected : BOOL ; 
END_VAR
BEGIN
NETWORK
TITLE =update inputs
	  L	 PIB	2; 
	  T	 IB	 2; 
	  NOP   0; 
NETWORK
TITLE =detect up/down rising edge
	  A	 I	  2.0; 
	  FP	#bUpDownProxyEdgeStore; 
	  =	 #bUpdownEdgeDetected; 
NETWORK
TITLE =detect across rising edge
	  A	 I	  2.1; 
	  FP	#bAcrossProxyEdgeStore; 
	  =	 #bAcrossEdgeDetected; 
NETWORK
TITLE =up (+)
	  A	 #bUpdownEdgeDetected; 
	  A	 M	  0.0; 
	  JNB   _001; 
	  L	 MW	40; 
	  L	 1; 
	  +I	; 
	  T	 MW	40; 
_001: NOP   0; 
NETWORK
TITLE =across (+)
	  A	 #bAcrossEdgeDetected; 
	  A	 Q	 13.2; 
	  A	 M	  0.0; 
	  JNB   _002; 
	  L	 MW	50; 
	  L	 1; 
	  +I	; 
	  T	 MW	50; 
_002: NOP   0; 
NETWORK
TITLE =across (-)
	  A	 #bAcrossEdgeDetected; 
	  A(	; 
	  AN	Q	 13.2; 
	  A	 M	  0.0; 
	  O	 M	  1.1; 
	  )	 ; 
	  JNB   _003; 

	  L	 MW	50; 
	  L	 1; 
	  -I	; 
	  T	 MW	50; 
_003: NOP   0; 
NETWORK
TITLE =Stop
	  A(	; 
	  A	 M	  3.1; 
	  A	 I	  2.6; 
	  O	 I	  2.7; 
	  )	 ; 
	  A	 I	  6.0; 
	  =	 L	  0.0; 

	  A	 L	  0.0; 
	  BLD   102; 
	  R	 Q	 13.2; 
	  A	 L	  0.0; 
	  JNB   _004; 
	  L	 QB	13; 
	  T	 PQB   13; 
_004: NOP   0; 
END_FUNCTION_BLOCK

uptown47 · Jun 1, 2008

Thanks again Simon. I'll try implementing FB40 into my code tomorrow. I'll post back as to the results.

Cheers

L D[AR2P#0.0] · Jun 1, 2008

Please note there is a coding error in the last network, replace the Reset of Q13.2 with Q13.1

Step 7 problem (OB 40 I think is the issue)

uptown47

Lifetime Supporting Member

PeterW

Member

uptown47

Lifetime Supporting Member

PeterW

Member

uptown47

Lifetime Supporting Member

PeterW

Member

uptown47

Lifetime Supporting Member

L D[AR2P#0.0]

Lifetime Supporting Member

PeterW

Member

uptown47

Lifetime Supporting Member

L D[AR2P#0.0]

Lifetime Supporting Member

uptown47

Lifetime Supporting Member

L D[AR2P#0.0]

Lifetime Supporting Member

uptown47

Lifetime Supporting Member

L D[AR2P#0.0]

Lifetime Supporting Member

Similar Topics