The interrupt executes when CV=PV and exits. It will not execute again until CV=PV again.

So if HSC_Step := 1 then it will execute that line of code and exits.

You realize you monitored an interrupt that executes for milliseconds, if even that; do you see something odd in the network that is green?

Edit: I'm not sure what you meant by trying to put the code in the second image in Main OB. You mean without the interrupt at all?And I'm curious how does HSC_Step's value gets its initial value and what its is.

Hi, thank you for your answer. I guess I was not clear enough (nothing strange for this forum :D).

The problem is this piece of code in CV=PV interrupt routine works. It works most of the time, let's say it works for 20 revolutions of encoder but in 21st revolution it "forgots" to reset the HSC (EnCV bit) in step 3 but it sets the new PV (bit EnReference1).

Kal.A

The interrupt executes when CV=PV and exits. It will not execute again until CV=PV again.

So if HSC_Step := 1 then it will execute that line of code and exits.

You realize you monitored an interrupt that executes for milliseconds, if even that; do you see something odd in the network that is green?

I'm not a pro but this much I know :D

I'm turning encoder shaft with my hand on desk and doing it slowly so I can monitor execution (entering) of interrupt routine in every step. And it is ok even if I turn encoder fast. But then after some turns (sometimes 10, 20, 50, random) it just does not reset the HSC.

It is not clear to me how EnCV bit works, it is not clear from the S7-1200 manual. Does it perform some "invisible" interrupt in background which interferes with this CV=PV interrupt routine? And this "invisible" interrupt has lower priority then CV=PV? Even if something like this would exist doesn't all interrupt events go into queue and then execute one by one until queue is empty?

Kal.A

Edit: I'm not sure what you meant by trying to put the code in the second image in Main OB. You mean without the interrupt at all?And I'm curious how does HSC_Step's value gets its initial value and what its is.

There is another interrupt routine (Cyclic 2ms) including code from the second image. I thought that this interrupt is interfering with CV=PV so I tried to put this piece of code in Main OB and disable/delete cyclic interrupt. This was even worse because it was happening more often (less revolutions and lower shaft speeds).

Hsc_Step is set to one at machine "nulling/homing". After that it is only written to in CV=PV interrupt.

It is worth noticing that in my code EnCV is reset in this Cyclic interrupt routine. Does EnCV gets reset before it has time to reset the HSC? I tried putting a 5/10/20ms delay (Main OB code version) but it didn't help...

Thanks Mark. I confused image #1 with #2. Sure putting HSC instruction in main OB will not make a difference.

I apologize if I don't quite understand you questions or if I seem to be explaining things that you already understand.

The interrupt is triggered whe CV=PV which we already know it works.

The Interrupt block starts from the top and looks at the first instruction and continues to evaluate your logic sequentially downward till it reaches the end and exits. It will not go back under any circumstances and will not start from the top again until the interrupt block is triggered again when CV=PV again.

So, the interrupt is triggered.

First introduction in the first line is evaluated> HSC_Step := 1 then the result of the comparison is false and the result of the code  in this line is not evaluated (MOVE, INCREMENT and SET)

Then first instruction in the second line is evaluated> HSC_Step := 1 then the result of the comparison is false and the rest of the code in this line is not evaluated.

Then the first instruction in the third line is evaluated >HSC_Step :=1 then the result of the comparison is TRUE and the code in this line is executed and HSC_Step is incremented to 2

Then the first instruction in the fourth line is evaluated> HSC_Step :=2 and the comparison result is False and the code in the rest of this line is not evaluated.

Then the block exits and that is the end of execution for that block.

So in reality HSC.EnCV should never be set. IF you say that it does work gets SET then that would simply mean that the interrupt was executed when HSC_Step := 3 . Somehow HSC_Step was set to equal 3 before the interrupt was triggered. But the problem with that is if the block starts with HSC_Step := 3 then the first and fourth lines of code would execute but not lines 2 and 3.

Now HSC_Step is a global variable and will retain its value until its changed by some instruction. So if the hardware interrupt is triggered again without HSC_Step being set to equal 1 then it could the interrupt could start with HSC_Step having the last value it had whatever that was.

In the snapshot you posted HSC_Step :=1 but I can see in the second line of code that HSC.EnCapture was set which means that it either was set outside the interrupt or if it is only set inside the interrupt then the interrupt must've been triggered at some point while HSC_Step := 2

I don't have time to proof read my post right now ad hopefully I didn't mess up.

Cheers

Thank you for your effort Kal.A and no need to apologize. I'm grateful for any help offered here.

Kal.A

I don't have time to proof read my post right now ad hopefully I didn't mess up.

Cheers

You explained the code right but I see you still don't understand what I'm trying to achieve so I will try to put it in short:

1. Manual "Homing" - HSC is reset, PV is set to 200, HSC_Step=1; (this all is done just once at machine start); encoder starts counting

2. CV=PV occurs at 200; HSC_Step 1 executes; new PV is set to 800; HSC_Step incremented to 2; interrupt exit; encoder keeps counting

3. CV=PV occurs at 800; HSC_Step 2 executes; new PV is set to 1000; HSC_Step incremented to 3; interrupt exit; encoder keeps counting

3. CV=PV occurs at 1000; HSC_Step 3 executes; new PV is set to 200; HSC_Step incremented to 4; HSC is reset by EnCV bit; logic goes to step 4; Step 4 executes and moves 1 to HSC_Step to enable repeating the above cycle; interrupt exit; encoder keeps counting

4. CV=PV occurs at 200 and we are back at point 2 above

The above cycle repeats every encoder revolution (1000ppr encoder).

So bolded part above (HSC reset) is actually executing but not every time. What is strange is that it accepts NewPV (with EnReference1) but not NewCV (with EnCV).

Application - I'm just trying to create a registration mark window between 0-200 pulses and 800-1000 pulses so that the signal from optical registration mark sensor on printed material is accepted if it occurs inside the window and disregarded if it occurs outside (between 200 and 800).

And once again I really appreciate your help. Must admit that Siemens really haven't done the greatest job in explaining new HSC in manual...

OK I now understand.

I will have a look later but for now I will guess that EnCV requires a riding edge and maybe it is not being reset every time before the interrupt is triggered again.

Edit: I should add what I didn't want to write all along which you already stated and that is that code is best placed outside the interrupt. Most people (not me) have one or two tags set in the interrupt to minimize impact on scan cycle and deal with the rest of logic outside. I actually have a unique but risky way of using HSC interrupt.

Well I'm stumped. If as you say the new reference value is being updated that means that line of code is executed and also it means that the EnReference is getting reset so EnCV should work the same.

But I really don't understand the P-Trigger purpose in your code. I don't see it's value and if tag M2000.1 is being used somewhere else or there's a memory overlap of M2000 (like MB2000 or MW2000 or MW1999 etc etc) then that maybe the problem.

Add a bunch of tags for troubleshooting and set and reset them at trouble spots bypassing suspect instruction to narrow things down.

Edit: I'm re-reading your posts and looking closer at your attachments. Yes, HSC instruction and resetting ENCV and should not be and a cyclic interrupt. Again I see not value for them being in a cyclic interrupt and could be problematic. Having said that if that was the source of your problem then it should have the same effect on new reference value.

Edit2: And placed FB1 inside OB30. How long is OB30 set to execute for?

Here's something for the imagination. Let's assume OB200 has higher priority than OB30 (you can find out in your hardware configuration) and say hardware interrupt OB200 is triggered while OB30  is executing and before Newtork2 then EnCV will be reset right after OB200 finishes and OB30 continues and Newtwork2 is executed. Then the next time HSC instruction is executed EnCV will be false and the counter will keep counting.

Try changing the Cyclic interrupt priority to a higher value than that of OB200.

Kal.A

Here's something for the imagination. Let's assume OB200 has higher priority than OB30 (you can find out in your hardware configuration) and say hardware interrupt OB200 is triggered while OB30  is executing and before Newtork2 then EnCV will be reset right after OB200 finishes and OB30 continues and Newtwork2 is executed. Then the next time HSC instruction is executed EnCV will be false and the counter will keep counting.

Try changing the Cyclic interrupt priority to a higher value than that of OB200.

Hi, this actually helped. I put the OB30 priority to highest possible (24) and 0B200 to default priority 18. Now I cannot get HSC to make this error again and... it works!

Also I removed p_trig instructions from OB30.

In the attachment parameters of OB30 and OB200.

I'm not sure if Nr of events to be queued makes any difference.

Kal.A

Well I'm stumped. If as you say the new reference value is being updated that means that line of code is executed and also it means that the EnReference is getting reset so EnCV should work the same.

Today I realized it is not always true actually. Sometimes it does accept NwPV and does not reset, sometimes NewPV is stucked at 1000 (Step 2) and does not reset. But in most cases it does accept NewPV and doesn't accept NewCV.

Kal.A

Edit: I should add what I didn't want to write all along which you already stated and that is that code is best placed outside the interrupt. Most people (not me) have one or two tags set in the interrupt to minimize impact on scan cycle and deal with the rest of logic outside. I actually have a unique but risky way of using HSC interrupt.

This machine will not run fast (60-80rpm max) and I think that maybe putting the whole code in Main OB with execution of around 2ms would not pose a problem. The whole code is not large, there are just few pushbuttons, one reversing motor, encoder and optical sensor so execution would probably be 1-2ms, 3ms the most.

But I really want to get to the bottom of this because using HSC really requires (and implies) using interrupt routines. Also the precision is of importance - one Encoder pulse is around 0,4mm. So losing a few pulses could lead to an error of a few mm.


Question about CTRL_HSC_EXT instruction - where "should" it be placed? Main cycle OB? Maybe putting it in Cyclic interrupt OB30 is not a good idea? Executing it maybe consumes a lot of time? Is there any difference putting it in OB1 or OB30?

These forums suck sometimes and it deleted my what I wrote.

So, glad to know you figured it out.

The attache archive will show the use of :P to immediately write to a physical output (and input if you want). You can search for it in the manual to read more.

There's another tag that is SET to indicate the change of motor state and update your code so that your code doesn't continue to run the motor. The first tag is for immediacy and the second is to update the code.

Cheers