Time measurement of HSC

Hi All, 

I have a HSC setup will reset itself after 100 counts. I was wondering is there any way I can figure out the time it took for those 100 counts?

Working with S7 1200. 

Thanks!

chiragshah

Hi All, 

I have a HSC setup will reset itself after 100 counts. I was wondering is there any way I can figure out the time it took for those 100 counts?

Working with S7 1200. 

Thanks!

Three methods possible: {not too much detail given}

1. IEC-TIMER

Place a timer in the ladder code. {method not tested, opinion follows}

When the encoder reaches 100 counts the following happens..
* capture the timer value
* reset the timer
* reset the HSC

Problem:
* dependant on PLC cycle
* timer measures in [ms] resolution
* for a fast acting HSC the count could be a little more than the 100
* CTRL_HSC instruction can take a little time making the 100 pulse measurement a little inaccurate


2. Interrupt for HSC:CV == HSC:RV

The CTRL_HSC is used to set the RV (Reference value) for an interrupt to trigger if the HSC count value and reference value is the same. The interrupt OB4x is configured in the hardware configuration.

The trick is to NOT reset the HSC, but rather adapt the RV to the next increment.

+ Hardware configuration (HSC #1) activate OB41 as interrupt OB with CV := 0 and RV := 100.
+ Inside OB41:
  * Set "triggerRV"
  * "valueRV" := "valueRV" + 100
  * RUNTIME instruction to get period (time) between interrupts as a REAL number
  * Ensure the RUNTIME instruction is giving a valid value
+ Inside OB1
  * use "triggerRV" and "valueRV" on the CTRL_HSC instruction to set up the next trigger.
  * reset "triggerRV"

Caution:
* It is important to know how the RUNTIME instruction works. The instruction sometimes give negative numbers which should be ignored!  It can only be used in the OB41 for this case. It will however give a brilliant accuracy in time measurement.

3. Cyclic (time) interrupt

OB3x is time repeat interrupts. The SET_CINT instruction is called to tell it what is the time period between triggers to call the OB3x. The instruction must used because a microsecond period can be specified.. and should be called once.

Inside the OB3x:
* "counter" := "counter + 1"
* compare if ID1000:P is equal or bigger than "value".. if not then ---(RET).
{  With ID1000:P is equal or bigger than "value":   }
* "timeCount" := "counter"
* "counter := 0
* "value" := "value" + 100

Then "timeCount" x {period for OB3x} is the time for the 100 encoder counts.

-----------------------------
So that concludes a "brief" explanation of what is possible for answering the question.
w

William_B

chiragshah

Hi All, 

I have a HSC setup will reset itself after 100 counts. I was wondering is there any way I can figure out the time it took for those 100 counts?

Working with S7 1200. 

Thanks!

Three methods possible: {not too much detail given}

1. IEC-TIMER

Place a timer in the ladder code. {method not tested, opinion follows}

When the encoder reaches 100 counts the following happens..
* capture the timer value
* reset the timer
* reset the HSC

Problem:
* dependant on PLC cycle
* timer measures in [ms] resolution
* for a fast acting HSC the count could be a little more than the 100
* CTRL_HSC instruction can take a little time making the 100 pulse measurement a little inaccurate


2. Interrupt for HSC:CV == HSC:RV

The CTRL_HSC is used to set the RV (Reference value) for an interrupt to trigger if the HSC count value and reference value is the same. The interrupt OB4x is configured in the hardware configuration.

The trick is to NOT reset the HSC, but rather adapt the RV to the next increment.

+ Hardware configuration (HSC #1) activate OB41 as interrupt OB with CV := 0 and RV := 100.
+ Inside OB41:
  * Set "triggerRV"
  * "valueRV" := "valueRV" + 100
  * RUNTIME instruction to get period (time) between interrupts as a REAL number
  * Ensure the RUNTIME instruction is giving a valid value
+ Inside OB1
  * use "triggerRV" and "valueRV" on the CTRL_HSC instruction to set up the next trigger.
  * reset "triggerRV"

Caution:
* It is important to know how the RUNTIME instruction works. The instruction sometimes give negative numbers which should be ignored!  It can only be used in the OB41 for this case. It will however give a brilliant accuracy in time measurement.

-----------------------------
So that concludes a "brief" explanation of what is possible for answering the question.
w

I like the first two methods. Few questions before I choose one and get going! 

For method 1. IEC-TIMER

 How can I capture the time value when the count reaches 100? I know as soon as the belt start I will start the timer, and reset the timer on the condition where the counts are 100. But I am not sure how can I capture it?  And I think resolution in ms is good. But the more resolution is always better! 

For method 2. Interrupt for HSC:CV == HSC:RV 

 Will we use  "triggerRV" parameter for the CV? And instead of doing "valueRV" := "valueRV" + 100 what if I just reset the HSC right there, then I don't need to worry about triggerRV, valueRV right? So then It will never give negative numbers for the counts? 

Also using this discussion for help, but please see attached folder that I found on another discussion. Is there I would put 100 right?  But lets say as you said don't reset, then how would the interrupt will happen every 100 counts?

https://support.industry.siemens.com/tf/ww/en/posts/hsc-interrupt/45457/?page=0&pageSize=10

You do know I am not paid enough for helping you..
you do know that right? ..and even at 10% increase  
$0 x 0.10 = $0

chiragshah

For method 1. IEC-TIMER

 How can I capture the time value when the count reaches 100? I know as soon as the belt start I will start the timer, and reset the timer on the condition where the counts are 100. But I am not sure how can I capture it?  And I think resolution in ms is good. But the more resolution is always better! 

Look at the attached ZIP.. you should get a good idea from that and hopefully learn a few tricks - - - seeing that you set this pace.

chiragshah

 For method 2. Interrupt for HSC:CV == HSC:RV 

 Will we use  "triggerRV" parameter for the CV? And instead of doing "valueRV" := "valueRV" + 100 what if I just reset the HSC right there, then I don't need to worry about triggerRV, valueRV right? So then It will never give negative numbers for the counts? 

Also using this discussion for help, but please see attached folder that I found on another discussion. Is there I would put 100 right?  But lets say as you said don't reset, then how would the interrupt will happen every 100 counts?

https://support.industry.siemens.com/tf/ww/en/posts/hsc-interrupt/45457/?page=0&pageSize=10

Thanks as always!

The pictures you give in the ZIP file is something that is worth trying.

I have had issues (unrelated instruction) calling an instruction in OB1 and then again in OB40 that is using the same DB.The trouble is that you could be scanning through the instruction in OB1 right at the moment OB40 occurs which can cause issues. The trouble is you have to have a transition (at the CV pin) from off to on to make the instruction do its work.

Try it and see if it works.

Frankly - I am not a fan of resetting the counter to zero / [any other number]. Granted the processes I have is much quicker, but the zeroing of the HSC count do take time and you may miss counts.

The count value going negative is not a problem. So also the instruction that adds 100 will automatically work itself out.

The method (#3) I proposed does not change CV at all.

Answered?
w

William_B

Answered?
w

 Yes you have answered! And I really appreciate you helping. What I finally decided to do is reset my HSC every 100 counts. And then I will measure the time it took for those counts. If this doesn't work then I will do what you said which is to keep going, not resetting the HSC. You can see in the attachment what I am trying to do. I hope it works!! I am just not sure if I will be able to measure the time in RUNTIME, atleast the way I have set it up. 

William_B

Try it and see if it works.

Frankly - I am not a fan of resetting the counter to zero / [any other number]. Granted the processes I have is much quicker, but the zeroing of the HSC count do take time and you may miss counts.

The count value going negative is not a problem. So also the instruction that adds 100 will automatically work itself out.

Since resetting at every 100 counts, the timing is not precise if the speed is over 20ft/min. So I decided to use your idea where I just keep increment the varaueRV but I have the same problem. I still get some timing error. Do you know why it would do that? Because now I am not even resetting back to 0 how what possibly can be talking time?  

chiragshah

Since resetting at every 100 counts, the timing is not precise if the speed is over 20ft/min. So I decided to use your idea where I just keep increment the varaueRV but I have the same problem. I still get some timing error. Do you know why it would do that? Because now I am not even resetting back to 0 how what possibly can be talking time?  

Hi.

Working with time as a measurement can roll many problems in your way. There is a 1000 + 1 things that can be the problem. ..and you do not show all of the program,,,,,

Do you even RESET the "triggerRV"?.. you should as soon as you know the trigger has been used.

What is you variation like? What measurements do you get for 100 pulses?

What type of coupling do you use between the encoder and conveyor? Is slippage possible?

Has the filter for the input used by the encoder been set to the appropriate level? (Hardware configuration / inputs)

That is just a few brain-storming thoughts.
w

William_B

Hi.

Working with time as a measurement can roll many problems in your way. There is a 1000 + 1 things that can be the problem. ..and you do not show all of the program,,,,,

Do you even RESET the "triggerRV"?.. you should as soon as you know the trigger has been used.

What is you variation like? What measurements do you get for 100 pulses?

What type of coupling do you use between the encoder and conveyor? Is slippage possible?

Has the filter for the input used by the encoder been set to the appropriate level? (Hardware configuration / inputs)

That is just a few brain-storming thoughts.
w

Hi! 

 I don't reset the triggerRV because I tried that and if I reset the triggerRV as soon as it is used then It will be false and the next interrupt won't happen!?

The variation is not a lot, the time that I get is consistent but when i did the math, in order to be accurate the time that i get should be 60ms faster ( I get 1.6864ms but I should get 1.6255ms) And the problem is only visible when the speed is over 20ft/min. So if the belt is running slow then I won't have any problem and it will hit the part. 

I have set the input filter to be .2millisec. I think that's appropriate right?! I mean it's pretty fast. 

And the slippage is not possible. 

Thanks

chiragshah

Hi! 

 I don't reset the triggerRV because I tried that and if I reset the triggerRV as soon as it is used then It will be false and the next interrupt won't happen!?

The variation is not a lot, the time that I get is consistent but when i did the math, in order to be accurate the time that i get should be 60ms faster ( I get 1.6864ms but I should get 1.6255ms) And the problem is only visible when the speed is over 20ft/min. So if the belt is running slow then I won't have any problem and it will hit the part. 

I have set the input filter to be .2millisec. I think that's appropriate right?! I mean it's pretty fast. 

And the slippage is not possible. 

Thanks

To better the trigger timing you can use:
(..using global variables and not local variables as seen below)

I get 1.6864ms but I should get 1.6255ms
Surely those time values are in seconds - right?

I cannot help but wonder what the quality of the signal looks like. Quality goes down when working in higher frequency and the encoder cable is not properly shielded. 60ms is a big time gap.. even accumulated over 100 pulses that amounts to 6ms per pulse which should be more that the PLC scan at this moment.

This does not seem right.. but I do not know what the issue is.

What is the PLC scan time?

Does this situation change when the PLC and PC is not connected?

w