TC2_HVAC.FB_HVACBlink resolution issue?

[AlfredoQuintero]

Hi. I am trying to generate a pulse every two msec in my PLC program. Thought I would be able to figure this out easily with TC2_HVAC.FB_HVACBlink, but the function does not seem to work properly for low values of tTimeON and tTimeOFF. The documentation has no information on the resolution for this function. Is there a "known" (as in "known to the very experts only") issue with this TC2_HVAC.FB_HVACBlink?

(And you can feel free to lecture/scold me on better ways to generate a pulse. Will trade my dignity for a good solution.)
Edit: The resolution is not so good so I quote the result: If tTimeON and tTimeOFF are 1 msec after 10 sec we get 2500 counts as opposed to 5000. In case of 5 msec setting the count is 834 as opposed to expected 1000. And for 1 sec setting the count is the expected 5 times. Thanks.

 

[AlfredoQuintero]

Number 2

 

[AlfredoQuintero]

Last..

 

[drbitboy]

https://infosys.beckhoff.com/english.php?content=../content/1033/ethercatsystem/2469114379.html&id=

 

[AlfredoQuintero]

DrBitBoy, thansk for this information. By the way, I cracked my problem with TON function.

 

[drbitboy]

You could also drive a -]P[- with the low bit of the .ET of a timer. A lot less code that way, but there may be a hiccup at each timer expiry.

 

[g.mccormick]

Alfredo
On your last pic, im curious about what appears to be the same timer "TON_ECrefr" specified twice one of which is after the TON_ECrefr.Q. what is having it twice doing?

 

[AlfredoQuintero]

Hi g.mccormick: Once the TON function is triggered once, it will not work again unless you call the function with the IN signal in FALSE value to reset it. That is why when the TON function's output (TON_ECrefr.Q) is set to TRUE the program calls the function again with IN := FALSE.

 

[g.mccormick]

I guess this is accomplishing the same thing as putting a Not TON_ECrefr.Q in front of the first TON call? But perhaps not suffering from a wasted scan?

 

[AlfredoQuintero]

Sorry, I cannot figure out the circuit from your description, so I cannot answer. The TON function needs to be called with the input in FALSE after this timer has expired. Otherwise it will not work next time. Does your solution accomplish this?

 

[drbitboy]

Sorry, I cannot figure out the circuit from your description, ...

See image below where the TON.Q is connected to the TON reset (IN), so the second TON is not needed. I think that is what @g.mccormick is suggesting, but as they noted, that might take an extra scan, which would generate a pulse every 3ms i.e. every three-scan cycle:

1. scan 1: timer starts, .Q is 0 so timer does not reset
2. scan 2: timer expires after 1ms, .Q is 0 at rung start so timer does not reset, .Q becomes 1 at rung end
3. scan 3: timer resets because .Q (=> IN) is 1 at rung start, .Q becomes 0 from reset
4. scan 4: duplicate of scan 1
5. scan 5: duplicate of scan 2
6. scan 6: duplicate of scan 3
7. etc.

I think it is odd that the solution OP found seems to depend on the scan time being 1ms - is this running in a timed-interrupt routine? If that is the case, a TON is not needed, rather a flip-flop that toogles a bit every scan i.e. every 1ms, so that bit will have a rising edge (pulse) every 2ms. Or if a clock counter running at 1kHz could be found, the low bit of that clock count would have a rising edge every 2ms.

 

[AlfredoQuintero]

Hello DrBitBoy. You say "I think it is odd that the solution OP found seems to depend on the scan time being 1ms" That is the case in which I needed a pulse every 2 msec. But for longer periods the solution will work even if the PLC scan cycle is linger.
Thanks for pointing out about system clocks. Will study the Bechoff literature to see if there are any.

As for the solution above, I must be missing something. If the input for the TON function block is its own TON_ECrefr.Q output, then this function block will never execute because TON_ECrefr.Q will start as FALSE will remain so during the program's execution. Again, I may be missing something.

 

[drbitboy]

As for the solution above, I must be missing something. If the input for the TON function block is its own TON_ECrefr.Q output, then this function block will never execute because TON_ECrefr.Q will start as FALSE will remain so during the program's execution. Again, I may be missing something.

No, you are right, good catch, that's my bad. I should have fed [NOT .Q] into the IN pin; however that does effectively reduce to the program below.

Also, see this link; I think that is saying that the 1ms minimum scan cycle is the default. That suggests two things, which would take some experimenting to confirm:

1. If the scan period runs longer than 1ms, e.g. because of a longer program, then there is no way to get a pulse with a 2ms period.
2. If the scan period is a consistent 1ms*, then the code to generate a 2ms pulse can be simplified to two instructions: a Normally Open contact feeding a Coil, with both having the pulsed output bit (b_Exec) as their single parameter; see below.

* which yours appears to be i.e. CycleCnt_10sec is 9997, implying CycleCnt counted to 9997 in 10s.

 

[g.mccormick]

Hi g.mccormick: Once the TON function is triggered once, it will not work again unless you call the function with the IN signal in FALSE value to reset it. That is why when the TON function's output (TON_ECrefr.Q) is set to TRUE the program calls the function again with IN := FALSE.

Alfredo,
In your first call to the timer, instead of calling with "true" for .IN , couldnt you instead have set tge .IN to "NOT TON_ECrefr Q"

What is your scan time set to?

 

[AlfredoQuintero]

g.mccormick, drbitboy: Now I understand what you mean. I will be testing this later today. Thanks very much. Of course this will simplify the program significantly.

I have set the scan cycle to 1 msec. I will also send the screenshot for this setup.