Modicon Pro Worx Plus - Counters Help

Hi,

I'm translating some old modicon code. First time I've worked with modicon in any deep capacity.

Just want to clarify the output operation of a counter...

In the example from this screenshot what can I expect in regards to the output state when the counter is done.

1 - Once the count is done will output 01445 be active for only 1 scan due to the rising edge of 10006 or...

2 - Once the count is done will output 01445 be active as long as 01038 is high.

I guess what i'm wondering is if the count is done will the output stay high if the reset input stays high even if the count / control condition ceases to be on. Or is that required for the signal to pass to the output.

Thanks,

http://www2.schneider-electric.com/resources/sites/SCHNEIDER_ELECTRIC/content/live/FAQS/272000/FA272374/en_US/840use10100.pdf

Once the count is done, (accumulated count = counter preset) output 01445 be active as long as 01038 is high.
01038 will reset the accumulated value to 0, when it is low.

Regards,

01038 is the "enable/reset". As long as 01038 is true, the counter will count the rising edges of 10006. When false, the counter resets to 0 and no longer counts. As long as 01038 is true and the accumulated value of the counter equals the preset value (6), 01445 will be true. When EITHER the accumulated value is less than the preset OR 01038 is false, 01445 will be false.

Thanks for the feedback guys. Makes sense now. I did read the manual, I just wasn't 100% sure when it said passes power if that meant passes from the count input and if that needed to be high to 'pass' power. Thanks again.

This is what my AB equivalent looks like. Feel free to abuse me if it looks like rubbish. Will this be ok?



Thanks,

I'd be careful direct referencing a 'real' input point, especially when within the Continuous Task; just 'map' the Local2:I.Data.5 to a memory BOOL tag in a rung prior to the CTU one and use that memory tag to trigger the count; Logix I/O updates are asynchronous to the program scan and you might miss the change-of-state of the Input if not explicitly reading the value prior to 'decision making' logic.

Also...I would RES the CTU when its .DN bit is set too, in addition to the 'Not Enabled' condition RES.

dmargineau said:

I'd be careful direct referencing a 'real' input point, especially when within the Continuous Task; just 'map' the Local2:I.Data.5 to a memory BOOL tag in a rung prior to the CTU one and use that memory tag to trigger the count; Logix I/O updates are asynchronous to the program scan and you might miss the change-of-state of the Input if not explicitly reading the value prior to 'decision making' logic.

Also...I would RES the CTU when its .DN bit is set too, in addition to the 'Not Enabled' condition RES.

Click to expand...

Interesting... since all my inputs and outputs are alias tags I could just change all the inputs to base tags and then map them all in a separate routine. Call that routine first then call the control logic routine next. That way the state of the inputs at the beginning of the scan is retained for the whole scan. Is that what you are suggesting??

Also why do you suggest resetting the counter on the done condition. That seems like it would not represent the original control in the modicon plc correctly as it would just reset every time it's done where as it was resetting when input 01038 goes low only.

Thanks for your help.

I just added the counter enabled bit to the output run at the bottom to make it more accurate with the scan. So if it ceases to be enabled the output will turn off in the same scan and not wait for the next one. Is that sufficient?

antsrealm said:

That way the state of the inputs at the beginning of the scan is retained for the whole scan. Is that what you are suggesting??

Click to expand...

Yes.

antsrealm said:

Also why do you suggest resetting the counter on the done condition. That seems like it would not represent the original control in the modicon plc correctly as it would just reset every time it's done where as it was resetting when input 01038 goes low only.

Click to expand...

If it is the 'intention' of the application to leave the CTU 'full' and wait for the 01038 Input to go OFF while the 'trigger' is still trying to count then leave it as it is.

dmargineau said:

Yes.



If it is the 'intention' of the application to leave the CTU 'full' and wait for the 01038 Input to go OFF while the 'trigger' is still trying to count then leave it as it is.

Click to expand...

Thank you for your assistance, much appreciated. All inputs now mapped as suggested.

antsrealm said:

Hi,

I'm translating some old modicon code. First time I've worked with modicon in any deep capacity.

Click to expand...

As you continue with the translation, be very mindful of how the modicon code is executed. Namely, a 'Network' of logic is executed columnwise from left to right (see page 5 in the link cited by gclshortt). Modicon does not execute row by row as intuition would suggest.

jamesau said:

As you continue with the translation, be very mindful of how the modicon code is executed. Namely, a 'Network' of logic is executed columnwise from left to right (see page 5 in the link cited by gclshortt). Modicon does not execute row by row as intuition would suggest.

Click to expand...

Yeah I saw that. I think I've got it covered (hopefully). But yeah I'm aware of it.

The only thing I hope is correct, is my interpretation of a 'SENS' instruction. If anyone wants to check my translation of that say the word and I'll post it here. I have created an add-on instruction to re-produce it.

Thanks,