Skip to Content

Register Login

Industry Online Support

Technical Forum

Navigation

HSC reset anomaly

Created by: BryanG2001 at: 6/14/2013 10:34 AM (9 Replies)

Rating (0)

Thanks 0

10 Entries

6/14/2013 10:34 AM	Rate (0)
BryanG2001 Posts: 113 Rating: (22)	Have been fighting with an issue for a week or so, and have finally tied it down to having a second HSC start before a first has finished. I have a system that monitors the output of a two product reciprocating pump using two flowmeters. For testing I have been using another S7-1200 pulse output to simulate the flowmeters, further I have used one pulse output to drive both High Speed Counter inputs. The system is set with an interrupt for each HSC that runs when the HSC hits it's PV, following that, because I am monitoring a reciprocating pump I need to keep the two HSCs in sync, so after both HSCs have hit their PV I enable a Rising Edge interrupts to resync the count start. The problem showed itself that occasionally I would get a wrong reading from one or other of the counters. I know that both counters are seeing the same number of pulses so I have been looking for electrical interference or problems in programming. Finally I used the Data Logging functions to see what was happening, the strange thing was that just adding the Data Logging to the Interrupts helped to solve the problem, which made me realise that it was a timing issue. I added a small delay before enabling the Sync interrupt and the problem stopped. So the problem seems to be that if you start an HSC instruction before an earlier one had completed you can get values left in CV. You can't use the Busy output from an HSC because according to the manual that is always Off. I hope Siemens monitor this Forum so that they can pick up on problems like this.
BryanG2001 Posts: 113 Rating: (22)
Suggestion To thank Quote Answer

6/14/2013 2:32 PM	Rate (0)
allmächt! Posts: 215 Rating: (6)	Hello BryanG2001, did you look up the following entry as a reference? http://support.automation.siemens.com/WW/view/de/41127453? If it is not helpful, what about to post some specifications of your configuration here as well as the complete program? Maybe thesupply of the interface causes problems. Best regards
allmächt! Posts: 215 Rating: (6)
Suggestion To thank Quote Answer

6/14/2013 2:51 PM	Rate (0)
BryanG2001 Posts: 113 Rating: (22)	Hi Thanks for the link, I hadn't seen it, but have now read it. After the research that I have done I am pretty confident that it isn't something that I have done wrong. I have used the HSCs on the S7-200 extensively and would say that I am quite confident with the HSCs on the S7-1200. It definitely seems to be an issue with a strange result if an HSC is called twice, the CV doesn't get reset to 0 even though the programming is set up so that it should be. On the S7-200, the PLC would give an error code if you called HSC twice but it didn't go wrong. On the S7-1200 it doesn't give an error code but does seem to go wrong. I think I am going to able to use DIS_AIRT function to work around the problem, but I haven't used it before so I will have to experiment.
BryanG2001 Posts: 113 Rating: (22)
Suggestion To thank Quote Answer

6/17/2013 9:40 AM	Rate (0)
allmächt! Posts: 215 Rating: (6)	Hello BryanG2001, the manual regarding high speed counters specifies that more than one HSC can be run at one time no matter which type of CPU you are using. The behavior of your HSC seems to differ to that. I think you are able to apply the HSC in the right way because you are experianced with this matter. So I would recommendyou to ask the siemens technical support for help. http://support.automation.siemens.com/WW/view/en/4000024+16605032 http://support.automation.siemens.com/WW/view/en/16605656 Best regards
allmächt! Posts: 215 Rating: (6)
Suggestion To thank Quote Answer

6/17/2013 3:34 PM	Rate (0)
BryanG2001 Posts: 113 Rating: (22)	Thank you for the links, I will have to give Siemens Support a try.
BryanG2001 Posts: 113 Rating: (22)
Suggestion To thank Quote Answer

6/18/2013 10:29 AM	Rate (0)
allmächt! Posts: 215 Rating: (6)	Before you are going to contact the technical support you could check the following points: - did you install TIA V12? - does each function block call a separate instance DB? What about to post your program here? Please inform me alsoincase of technical support found a solution for this matter how to solve it. Regards
allmächt! Posts: 215 Rating: (6)
Suggestion To thank Quote Answer

6/18/2013 12:41 PM	Rate (0)
BryanG2001 Posts: 113 Rating: (22)	I am still on TIA V11SP2 Update 5, I was hoping to avoid another upgrade until I had a fully working program, otherwise you introduce a new set of variables. Posting my program here won't help, first it is rather large, I am at 86% of Load memory in an, S7-1215, second you would need a Beijer HMI to be able to run it. What I will try to do is create a cut down version that just has the needed FCs. I will have to do this before I contact Tech Support. Just to confirm the set up. I have two High Speed Counters, which have separate instance DBs. Product_1_HSC_DB Product_2_HSC_DB The two CTRL_HSC blocks are in separate FC blocks: FC65 has the CTRL_HSC that uses Product_1_HSC_DB FC66 has the CTRL_HSC that uses Product_2_HSC_DB The CTRL_HSC that is in FC65 is linked to HSC B#16#02 The CTRL_HSC that is in FC66 is linked to HSC B#16#03 For testing I am using one pulse stream to run both HSC inputs. Each FC block can get called from two different interrupts, the first is 'HSC at SP', the second happens shortly after using a 'Rising Edge' interrupt. I don't think the problem is if FC66 is called straight after FC65, or the other way round. I think the problem is if FC65 (or FC66) is called again before the CTRL_HSC instruction has completed. This is one of those annoying problems that only happens occasionally, most of the time the system works perfectly. So I have to run the system for a few hours whilst I test program mods and capture diagnostic information.
BryanG2001 Posts: 113 Rating: (22)	Last edited by: BryanG2001 at: 6/18/2013 12:42 PM
Suggestion To thank Quote Answer

6/18/2013 2:37 PM	Rate (0)
0_Einstein Diamond Member Joined: 7/7/2010 Last visit: 11/19/2024 Posts: 15406 Rating: (2446)	BryanG2001 I am still on TIA V11SP2 Update 5, I was hoping to avoid another upgrade until I had a fully working program, otherwise you introduce a new set of variables. ... Each FC block can get called from two different interrupts, the first is 'HSC at SP', the second happens shortly after using a 'Rising Edge' interrupt. I don't think the problem is if FC66 is called straight after FC65, or the other way round. *I think the problem is if FC65 (or FC66) is called again before the CTRL_HSC instruction has completed.* This is one of those annoying problems that only happens occasionally, most of the time the system works perfectly. So I have to run the system for a few hours whilst I test program mods and capture diagnostic information. I would agree with your above assessment. I would bet your diagnostic data indicates your FC for the missing CTRL_HSC instruction was not run because another interrupt occurred. With 80%+ load memory used, the s7-1200 scan time must be pretty high (as compared to say 10% utilization). If your communications load is equally high, the plc may be stressed and unable to complete all assigned tasks with the configured system timeslice. You can adjust the communications overhead (higher) to see if that alters your hsc control issues. However, what you might want to do is adjust your interrupt driven logic do even less. If your plc logic is configured in such a way that you can schedule OBs to run rather than having them run every scan, you may improve overall scan time without harming perceived system performance. For example, updating hmi tags less often is not necessarily a bad thing. If you already have a single DB with all the hmi tags, the hmi related update overhead is even less. I have battled using a s7-1200 at the resource limits and found many tricks to improve overall perceived performance by giving time on the plc only as needed for smooth operation. For example, having all your first scan logic in the first scan OB rather than spread around in program scan OBs/FBs/FCs will improve running scan time. You are probably already doing this, but I mention it simply as an idea you may want to expand upon by only running code when it is needed. As your scan time improves, so should your interrupt driven OB responsiveness improve. For example, you can detect the need for reset earlier than the PV so the counter does not actually overflow. Then have the reset happen in regular scan logic, reducing the amount of time required to service the hsc interrupt. Any trick you can do to quickly return from an interrupt is one step closer to your solution. Lastly, since you are artifically inserting the worst-case scenario (by wiring the same input to 2 HSCs), you can configure the second HSC to read B & A rather than A & B, and call it a count down rather than count up. In this way, you can adjust the interrupt to happen one count earlier or later, depending on what phase leads.
	science guy
Suggestion To thank Quote Answer

6/18/2013 3:23 PM	Rate (0)
BryanG2001 Posts: 113 Rating: (22)	Thanks for the ideas. The machine has various modes and I only run what is needed is each mode so the scan time is better than the Load memory might suggest. I just checked and worst case is 33ms with a last of 30ms. I'm not in the PLCs busiest mode yet but from experience on the S7-200 it only adds a couple of ms. I am going to have to re-read the manual because there is a bit of weirdness between going to Tools/Resouces and Online/Diagnostics, the Load memory doesn't match. In Tools/Resouces it give me the 86% used but in Online and Diagnostics it tells me that I am running with 78% free Load memory. I also have 36% free Work memory. The HMI was connected to the PLC via RS485 with the S7-200 and it took 2 to 3 seconds to load a screen with values (even after optimisation). With the Ethernet connection I have had to increase the HMI polling time because data was changing too quickly to read. So variables now poll at 1 second whilst material names and measurement units, that don't change, poll at 5 seconds. I always keep my Interrupts as short as possible, which probably worked against me here. So I grab data, reset HSCs and Timers, then Set a calculation needed flag, and then do the calculations inside an FC (operating when needed) called from the Main body of the program. I haven't optimsed the S7-1200 program yet, just done a Line for Line conversion from the S7-200 original. Hopefully I can find better ways of doing things. The bit that I miss are the tables of execution times that the S7-200 manual had. How can I know if something is going to be quicker if I don't know how long things take. The S7-1200 and its manual are definitely a 'work in progress'.
BryanG2001 Posts: 113 Rating: (22)
Suggestion To thank Quote Answer

6/18/2013 4:43 PM	Rate (0)
0_Einstein Diamond Member Joined: 7/7/2010 Last visit: 11/19/2024 Posts: 15406 Rating: (2446)	BryanG2001 Thanks for the ideas. The machine has various modes and I only run what is needed is each mode so the scan time is better than the Load memory might suggest. I just checked and worst case is 33ms with a last of 30ms. I'm not in the PLCs busiest mode yet but from experience on the S7-200 it only adds a couple of ms. I am going to have to re-read the manual because there is a bit of weirdness between going to Tools/Resouces and Online/Diagnostics, the Load memory doesn't match. In Tools/Resouces it give me the 86% used but in Online and Diagnostics it tells me that I am running with 78% free Load memory. I also have 36% free Work memory. The HMI was connected to the PLC via RS485 with the S7-200 and it took 2 to 3 seconds to load a screen with values (even after optimisation). With the Ethernet connection I have had to increase the HMI polling time because data was changing too quickly to read. So variables now poll at 1 second whilst material names and measurement units, that don't change, poll at 5 seconds. I always keep my Interrupts as short as possible, which probably worked against me here. So I grab data, reset HSCs and Timers, then Set a calculation needed flag, and then do the calculations inside an FC (operating when needed) called from the Main body of the program. I haven't optimsed the S7-1200 program yet, just done a Line for Line conversion from the S7-200 original. Hopefully I can find better ways of doing things. The bit that I miss are the tables of execution times that the S7-200 manual had. How can I know if something is going to be quicker if I don't know how long things take. The S7-1200 and its manual are definitely a 'work in progress'. I am running an s7-1215 project with HMI (Siemens, via ethernet), PC (with modbus/tcp), 3 rs485 drives, with around 70% memory usage. Scan time is 7-13 ms. I would expect your diagnostic buffer to constantly add entries which is an escalation that self-perpetuates doom for scan time and smooth execution. If your buffer is stable and only gets entries when you stop and start the plc, that is ideal - and fantastic! If you are running any periodic interrupt OBs, the fastest you can reliabily run is 2ms on a plc without much load. We have some control loops running at 1ms that several times a day will fail to meet the 1ms time, but we really had to optimize things to get it to work smoothly at that rate. We had very little trouble with 2ms, essentially none - except when we were _online_ with the plc actually using watch tables and viewing logic in real time. You know, the normal things we do. If you have just one OB, you may not be aware that you can have several program cycle OBs that just run. I use them (multiple OBs) to separate logical components that are easy to rip out and insert as needed between projects. Let's say project A needs 1 RS485 drive, but project B needs 3. I can create Project B, then drag the OB and it's group of related FBs/FCs to project A and without much effort the drive just works. This is very different from the s7-200 world I was using where there was only 1 main OB. If you have any looping logic, try to spread the loops over several scans if it is a long loop (time-wise). You can read the time of day at the beginning and end of each block, use the Time Difference instruction tosee the time used in that block. You could makea quick FB to handle that and then display the values in a watch table. You may find some duplication in your logic. 30ms is long for the s7-1215 in my experience. If I saw 30ms, it was because I had something interrupting too often and failing to complete within the allocated time.
	science guy
Suggestion To thank Quote Answer

|

Share this page:

Share this page on...

Related topics by keywords:

Follow us on