Is this possible??

[plc_user]

If we setup a HSC using the HSCDEF statement and then the counter trips the function associated with it in the HSCDEF statement.  Then through some sort of movement in an encoder it decrements the counter and then increments back to the set point that trips the function again and again and again.  If this occurs at such a rate could a recursive type action occur in the calling of the function associated with the HSCDEF statement?  For example:

HSCDEF 1,1,1000
//  when the counter hits 1000 it trips function 1
//  the counter dithers around a difference of one count down
// and up and fires function 1 again before the first function
// finishes, what would keep this from happening over and over // at high speed, thus causing a recursion of some sort?

Function 1:

OUTPUT[1]=0
REFRESH


P.S.  Does the refresh statement take precedence in execution over the updating of the HSC?  Thus a missing of counts while the refresh occurs?


Thanks again, great product and may the new year bring even more success to your company.




 

[support]

No -  there will never be recursive call to the ISR defined to handle the HSC when the terminal count is reached. Function calls in TBASIC are not re-entrant and it cannot handle recursive function calls.

If you execute REFRESH in the ISR the CPU will spend time refreshing the I/O. But the system interrupt that takes care of the HSC counting will continue to run and should not result in any loss count.

Thank you for your kind comments and we wish you and all our customers great success in 2011. Do look out for our announcements of new PLCs models and new i-TRiLOGI software version in the next 2 months.

[plc_user]

Thanks for your answer.  If I don't place another HSCDEF within a function of previous HSCDEF statement's function. It will fire over and over if it dither's around a particular set point in the counter.  My thoughts maybe are better explained with an example.

HSCDEF 1,1,1000

Function 1

OUTPUT[1]=0
REFRESH
....
....
....
Now as the HSC counter(connected to an encoder) moves back and forth dithering around the set point firing function 1 over and over.  Can this cause a problem even if there isn't a re-entrant function possibility can this make the same function fire at a proportional frequency of the dither around the set point?
What technical ramifications would this have at high frequency, large function size or both?  

I know this kind of operation could be desirable especially if a particular location from encoder data was desired from a moving table or gantry mechanism across a given set point.  It's fine if its desired motion that caused the firing of the function, if a dither around the setpoint for whatever reason caused it, it may be undesirable.

I am sure it can be cured by placing this statement in function 1 at the beginning.
HSCDEF 1,15,-4545434  //whatever count cannot occur in the system.

Just trying to get my head around these situations without too much programming or machine connections, just thinking.

[support]

Yes, if the HSCDEF is in action then whenever there is a change of the HSCPV value the CPU will check against the target count and if it sees the matching target count it will trigger the ISR. If after the target count is reached and ISR is fired and you either define another location value or disable the HSC by running HSCOFF to prevent the ISR from being triggered repeatedly when the HSC jiggle around the target count value.

Are you using the HSC in enhanced quadrature mode? That should reduce the possibility of jiggling around the target count.