Skip to Content

SiePortal

The integrated platform for your product selection, buying and support workflow - bringing together Industry Mall and Online Support.

SiePortalDeutsch

Search

Home
Support Support
{{(apiData.Support | filter:{'rank':1}:true)[0].title}} Support
- Menu temporary not available
- Menu temporary not available
- Menue temporary not available
- {{item.title}}

Products & Services
- Menu temporary not available
- Menue temporary not available
- {{item.title}}
Support Support
{{(apiData.Support | filter:{'rank':1}:true)[0].title}} Support
- Menu temporary not available
- Menue temporary not available
- {{item.title}}
MySiePortal MySiePortal
{{(apiData.MySiePortal | filter:{'rank':1}:true)[0].title}} MySiePortal
- Menu temporary not available
- Menue temporary not available
- {{item.title}}
Cart ({{apiData.CartCount}})

Navigation

Problem with Hardware Interrupt

Created by: JAC2016 at: 12/2/2016 7:12 PM (5 Replies)

Rating (1)

Thanks 2

6 Entries

12/2/2016 7:12 PM	Rate (0)
JAC2016 Posts: 50 Rating: (1)	Hello Guys... Hope you are all doing fine... I need some help with the below I did a simple project, using Siemens S7-1212C, a contrast sensor and an encoder to measure the print length. When the contrast sensor meets the ink-mark, the signal is given to I:0.1 of PLC, and encoder is connected to I:0.0 (High Speed Counter). So when contrast sensor meets ink-mark, it gives a pulse to PLC, and the encoder count is moved to a temp memory and value is datalogged and count is reset, and when the next contrast signal comes, the encoder count is moved to memory, datalogged and is reset... So this way, the length between two ink-marks can be obtained.The program works fine if i do all above in a cyclic interrupt. But when i tried hardware interrupt, i can see the hardware interrupt being activated every time sensor signal comes (which is 3-4 seconds). But if i use the same input (I:0.1) to move inside the hardware interrupt, it doesnt work (see pic) So I activated rising edge hardware interrupt on I0.1 (for contrast sensor), and you can see what i have done on the pic attached... How to make this work, when the sensor signal comes every 3 seconds, the encoder value should be moved, datalogged and then reset.... move and reset are working, but not datalog write... Attachment siemens hi.pdf (542 Downloads)
JAC2016 Posts: 50 Rating: (1)	Last edited by: JAC2016 at: 12/2/2016 7:15:16 PM Last edited by: JAC2016 at: 12/2/2016 7:18:23 PM
Suggestion To thank Quote Answer

12/2/2016 9:08 PM	Rate (0)
Fredrik567 Experienced Member Joined: 1/3/2013 Last visit: 10/5/2023 Posts: 16 Rating: (2)	Hi, interrupt starts on rising edge on I0.1. That means that you won't find a I0.1 rising edge again inside the interrupt (this is what triggers the -IPI-). Replace all -IPI- with reference to I0.1 with just straight connection (shortcut them) and it will work. //Fredrik

Suggestion To thank Quote Answer

12/2/2016 9:38 PM	Rate (0)
William_B Posts: 5225 Rating: (1203)	Hi there. I hope to add to the thoughts already given. First thought - Thank you for the screen captures.. it is very helpful. Second thought - Let me guess who worked too much with Rockwell products. (wink) No worry this does not make us enemies. (a) The DataLogWrite is looking for a transition from OFF to ON. Being called inside the interrupt is a problem, as the REQ pin does not see a OFF signal at all. I recommend to you (for more reasons than above mentioned).. take out the DataLogWrite instruction. Put it in an FC / FB that is called by OB1 or even inside OB1. Make for your interrupt something like (example)... %M10.0 ----(S) // YES! There is no contact in the above code. // This can any network inside the interrupt. Then in the FC / FB / OB you can have DataLogWrite.REQ pin listen to %M10.0: \| %M10.0 %M10.0 \| --\| \|------(R)------\| REQ \| // YES! Reset is in the same line as the contact and the input pin. // The interrupt is asynchronise to this code, so its important! // You can use anything instead of %M10.0 - DB bit or M-bit. It does not matter that DataLogWrite is not inside the interrupt assuming the PLC cycle is not too long. And also it does not tax the duty time inside the interrupt. Now for the bonus comments..... (b) Please do not leave the input filter on default. Calculate what is the fastest rate you need and change the filter to 10x faster rate. (c) Use "EncoderSignal":P in the MOVE instruction in Network 1. The :P ensures that you get the immediate signal, not the buffered signal according to the cycle time of the PLC. (d) Consider not resetting the encoder count. Best to record [now] and subtract [previous] from it. This is the most accurate. Else you can loose counts in the process. Are these notes clear? helpful? w
William_B Posts: 5225 Rating: (1203)	Last edited by: William_B at: 12/2/2016 9:39:43 PM
Suggestion To thank Quote Answer
This contribution was helpful to 2 thankful Users Duris_I JAC2016

12/5/2016 8:37 PM	Rate (0)
JAC2016 Posts: 50 Rating: (1)	Hey Williams... Thanks a lot for your time... And yeah, I am playing with Siemens these days... Ive given some rest to Rockwell automation.... (a) I understand from what you said that DataLogWrite needs a transition from off to on... and I'll try your method and see how it works... but i think putting set %M10.0 inside interrupt and calling that inside main program for datalog write, the scan time will affect the accuracy.... right now, i have put these codes inside 1ms cycle interrupt, and the is good, but not precise... real print length measured with tape is 1062mm, but the plc is calculating as 1070mm... somewhere there is a milli sec delay.. the circumfence of the encoder wheel is 200mm, and so the counts directly gives the print length... (b) Yes, I have changed the input filter to fastest possible... (c) Yes, I have used the move instruction in the first network.. I'll try and let you know, how the accuracy is... Once again, thanks a lot.....
JAC2016 Posts: 50 Rating: (1)	Last edited by: JAC2016 at: 12/5/2016 8:38:38 PM
Suggestion To thank Quote Answer

12/5/2016 8:47 PM	Rate (0)
William_B Posts: 5225 Rating: (1203)	JAC2016 Hey Williams... Thanks a lot for your time... And yeah, I am playing with Siemens these days... Ive given some rest to Rockwell automation.... (a) I understand from what you said that DataLogWrite needs a transition from off to on... and I'll try your method and see how it works... but i think putting set %M10.0 inside interrupt and calling that inside main program for datalog write, the scan time will affect the accuracy.... right now, i have put these codes inside 1ms cycle interrupt, and the is good, but not precise... real print length measured with tape is 1062mm, but the plc is calculating as 1070mm... somewhere there is a milli sec delay.. the circumfence of the encoder wheel is 200mm, and so the counts directly gives the print length... (b) Yes, I have changed the input filter to fastest possible... (c) Yes, I have used the move instruction in the first network.. I'll try and let you know, how the accuracy is... Once again, thanks a lot..... Hi.. good to hear from you. I understand better what sort of problem you have with updating the data log. (a) Did you not say the occurrences are a few seconds apart? Then it would not matter when you write to the log. The writing to log takes longer than normal instructions.. there is also a ceiling limit of how quickly it can be called. So explain to me again - how long in between hardware trigger events? You can also consider a double trigger hardware trigger. OFF>ON as what you have now and ON>OFF is to only ensure the write-to-log goes off........ but you'll have to make sure the write-to-log has done the task in time. Your comments? w ^{PS: (smile) It is my first name and it is of GB origin... not (US) Bill or (EU) Willy either.}
William_B Posts: 5225 Rating: (1203)	Last edited by: William_B at: 12/5/2016 8:53:16 PM
Suggestion To thank Quote Answer

12/7/2016 3:33 PM	Rate (1)
0_Einstein Diamond Member Joined: 7/7/2010 Last visit: 4/21/2025 Posts: 15810 Rating: (2496)	My experiences with attempting 1ms interrupts is it generates a backlog in the PLC in certain situations which can cause severe process degradation, and missed interrupt events. I would urge you to consider hardware interrupt options, perhaps with a sensor. As for the encoder, how did you calibrate the counts versus physical distance? Do you have a calibrated tape you run through, capture the counts, and adjust your process to reflect reality? We often have to fudge reality and theory to make things work. Perhaps that's really all that's required is an initial calibration, as well as anytime the encoder / roller are serviced. JAC2016 Hey Williams... Thanks a lot for your time... And yeah, I am playing with Siemens these days... Ive given some rest to Rockwell automation.... (a) I understand from what you said that DataLogWrite needs a transition from off to on... and I'll try your method and see how it works... but i think putting set %M10.0 inside interrupt and calling that inside main program for datalog write, the scan time will affect the accuracy.... right now, i have put these codes inside 1ms cycle interrupt, and the is good, but not precise... real print length measured with tape is 1062mm, but the plc is calculating as 1070mm... somewhere there is a milli sec delay.. the circumfence of the encoder wheel is 200mm, and so the counts directly gives the print length... (b) Yes, I have changed the input filter to fastest possible... (c) Yes, I have used the move instruction in the first network.. I'll try and let you know, how the accuracy is... Once again, thanks a lot.....
	science guy
Suggestion To thank Quote Answer

|

Share this page:

Share this page on...

Related topics by keywords:

Follow us on