Issue with positive transition contact

[Ken Hoang]

Hello,

I'm currently having issue with the positive transition contact. When MB 12 (Run ENABLE) goes from LOW to HIGH, the positive transition contact is activated but for some reason, the coil down stream of the contact is not activated.  Please see the screenshot below. This is a standard 2-net routine for a MODBUS command. 

Any help is much appreciated.

[Flex727]

The two most likely reasons are:

1) MB 33 has a coil elsewhere in the program which is overriding the Set coil activated by MB 12.

2) These ladder rungs are in a subroutine which is not being called by the Main Routine.

[Cam]

How are you turning off MB33?? is the system trying make it go high and low in the same cycle??  or do you have a direct coil in the project for MB 33??

[viscoelastic]

Is that the entire ladder? Do you have a reset for MB33?

[viscoelastic]

.

[Flex727]

Just now, viscoelastic said:

Is that the entire ladder? Do you have a reset for MB33?

If the Reset for MB 33 is just to the right of the screen capture you posted, you won't see MB 33 turn on when you're online, but it will still activate your MODBUS FB. I notice there are many sessions and acknowledements - is there some reason you think the code isn't working?

 

[Ken Hoang]

18 minutes ago, Flex727 said:

If the Reset for MB 33 is just to the right of the screen capture you posted, you won't see MB 33 turn on when you're online, but it will still activate your MODBUS FB. I notice there are many sessions and acknowledements - is there some reason you think the code isn't working?

 

Many thanks for the replies.

Yes the Reset for MB 33 would normally be placed just after the MODBUS command. However, to show that it's not working, I've deleted the Reset on the right. MB 33 is also reset during start up to ensure it's LOW in the beginning.  MB33 are only called twice as shown above.

This subroutine is called by the main routine. Everything else execute fine but just these two rungs are problematic.

 

[Ken Hoang]

Regarding the high number of sessions, my MODBUS slave goes into error mode if it doesn't receive a command from the master for 3 seconds. The master is set up to check the state of the slave every 0.5 second, hence the high number of sessions.

Also, when I delete the MB 33 contact, the code works fine:

This is not ideal, because I want to send the 'motor ON' command once only. This will repeatedly send out the command as long as the subroutine is called.

[Flex727]

Everyone encounters this type of problem from time to time. Rest assured that the PLC is executing the code properly. You can troubleshoot by placing an Increment function with an unused MI at strategic places on the suspect rungs. Here is how I would go about it:

First, perform a search to make sure MB 12 & MB 33 are not being used elsewhere by mistake.

Second, confirm the subroutine is being called by the Main Routine.

Third, place an increment function just after your MB 33 Set coil.

Fourth, place another increment function (different MI) at the end of your logic thread with the MODBUS FB.

Then download and go online and watch what happens.

I have one more question. You addressed how MB 33 was being Reset. How about MB 12?

[Ausman]

Why do you have MB33 at all?  MB12 can go straight in front of MB30 in your ladder. 

cheers, Aus

[Flex727]

27 minutes ago, Ausman said:

Why do you have MB33 at all?  MB12 can go straight in front of MB30 in your ladder. 

Leave it to Ausman to see what should be blindingly obvious to the rest of us, but we missed.

[Ken Hoang]

20 hours ago, Flex727 said:

Everyone encounters this type of problem from time to time. Rest assured that the PLC is executing the code properly. You can troubleshoot by placing an Increment function with an unused MI at strategic places on the suspect rungs. Here is how I would go about it:

First, perform a search to make sure MB 12 & MB 33 are not being used elsewhere by mistake.

Second, confirm the subroutine is being called by the Main Routine.

Third, place an increment function just after your MB 33 Set coil.

Fourth, place another increment function (different MI) at the end of your logic thread with the MODBUS FB.

Then download and go online and watch what happens.

I have one more question. You addressed how MB 33 was being Reset. How about MB 12?

Many thanks for your detail instruction.

I have tried what you suggested and the increment function is not being activated

As before, the subroutine is called, and MB12 has a positive transition but MB33 and the increment function is not carried out.

For your question, MB12 is reset during start up and also when the stop sequence is activated. The routine shown above is in the run sequence. I've checked and the state of MB12 is definitely HIGH during the above operation.

[Ausman]

Have you read my post 3 above this one?  (Which Flex nicely replied to!)

Also, I would try doing a full Initialise and Reset, and then running your program again.  This often clears up strange gremlins that seem to arise due to "old internal references" somehow being retained.    Connection/Communication & OS/2nd tab/bottom right.

cheers, Aus

[Flex727]

46 minutes ago, Ken Hoang said:

I've checked and the state of MB12 is definitely HIGH during the above operation.

Remember that power flow will only occur on the scan with the positive transition. MB 12 can be high all day and there will be no power flow to MB 33 except on the scan when the transition occurred. While you're online, manually Reset MB 12, then Set it again to see if the MI increments.

[Flex727]

21 minutes ago, Ausman said:

(Which Flex nicely replied to!)

I'm going to have to take back my nicety. You must have MB 33 there because of MB 30. MB 33 being set allows the function to wait if there is a Function in Progress until MB 30 goes low. Without MB 33, then if MB 30 is high, that MODBUS transaction will not occur.

[Ken Hoang]

10 minutes ago, Ausman said:

Have you read my post 3 above this one?  (Which Flex nicely replied to!)

Also, I would try doing a full Initialise and Reset, and then running your program again.  This often clears up strange gremlins that seem to arise due to "old internal references" somehow being retained.    Connection/Communication & OS/2nd tab/bottom right.

cheers, Aus

Hi Ausman,

Thank you for the suggestion. I've tried to Initialise and Reset, unfortunately, the issue is still occuring. 

Regarding your question, MB30 (function in progress) is a bit that is HIGH is the device busy sending out a MODBUS command. If I have the positive transition contact of MB12 goes straight to MB30, that net will only be carried out for one scan; and if at that time, the device happens to be busy (MB30 is HIGH), the desirable MODBUS command will not be executed., hence the need for MB33. 

[Flex727]

2 hours ago, Flex727 said:

While you're online, manually Reset MB 12, then Set it again to see if the MI increments.

Did you do this yet?

[Ausman]

9 hours ago, Flex727 said:

I'm going to have to take back my nicety.

All noted & reasons etc  😢   😀  .......I was always looking at it with the view that this was the only modbus thing going on in the program.

At this stage have you actually done a right click on element and done a "Find"?  Just to make sure that you're not referencing things somewhere else.

And are you sure that the sub is being called at that time.  Visi displays power flow in a way that has a sub looking like it has power when in fact it doesn't, and this has been discussed here ad nauseum. One way that is used to check subs are truly active is to put a counter at the very top.

Also you might have some other button reference that is stopping the sub during push.  Keep in mind that Button interaction on different screens can sometimes be a big PITA, as there are often a few scans involved to fully set things correctly and something unexpected going on during one of those "setup" scans can affect things.  A careful read of the way screens work is crucial, as the use of a rising edge during such times often leads to problems.

cheers, Aus

[Ken Hoang]

18 hours ago, Flex727 said:

Remember that power flow will only occur on the scan with the positive transition. MB 12 can be high all day and there will be no power flow to MB 33 except on the scan when the transition occurred. While you're online, manually Reset MB 12, then Set it again to see if the MI increments.

I've tried Reseting MB12 while the subroutine is called; but for some reasons, the MB12 couldn't be reset. I stopped the subroutine being called, so now MB12 is LOW, and manual SET the bit to make it go HIGH. MB12 did go HIGH but the subsequent elements are not activated. 

9 hours ago, Ausman said:

All noted & reasons etc  😢   😀  .......I was always looking at it with the view that this was the only modbus thing going on in the program.

At this stage have you actually done a right click on element and done a "Find"?  Just to make sure that you're not referencing things somewhere else.

And are you sure that the sub is being called at that time.  Visi displays power flow in a way that has a sub looking like it has power when in fact it doesn't, and this has been discussed here ad nauseum. One way that is used to check subs are truly active is to put a counter at the very top.

Also you might have some other button reference that is stopping the sub during push.  Keep in mind that Button interaction on different screens can sometimes be a big PITA, as there are often a few scans involved to fully set things correctly and something unexpected going on during one of those "setup" scans can affect things.  A careful read of the way screens work is crucial, as the use of a rising edge during such times often leads to problems.

 cheers, Aus

I have tried to 'Find' the bit and I can be sure that MB33 is being used twice only, as shown in the attached screenshot above.  This subroutine is being called for sure, as there are other nets below this and they all execute without problem

[Ken Hoang]

I've found a solution to the issue. It's the order of calling the subroutine. The below screenshot is in the main routine where the subroutine (Run sequence where I have MB12, MB33, Modbus etc) being called. I used to have MB12 go high first and then call the "Run sequence" subroutine which did not work. After swapping the two around, the subroutine is executed correctly as intended.

Not working:

Working:

Thank you Flex and Ausman for your help.

[Flex727]

You should always endeavor to avoid conditional subroutine calls for this very reason. Write your code so that every ladder rung is executed on every scan.

[Ken Hoang]

Hi Flex. There are several actions being carried out in the subroutine. For the above example, the four conditions that activate the "Run sequence" subroutine are the four conditions required for all the actions inside that subroutine. To avoid conditional call of this subroutine, I guess I'd have to  add the conditions for every ladder rung inside the subroutine.  I'm wondering if there is a better practice to avoid conditional subroutine calls without having extra repeated code? Thank you.

[Ausman]

This is a classic example of how a transitional being called affects things akin to my statement above:  " something unexpected going on during one of those "setup" scans can affect things ".  The plc deciding what is being asked and finally setting things at the end of the scan, such that only one scan totally disrupts an expected operation, is an easy trap to fall into.  And we have all done it at some stage!  "Why didn't that work?   Hmmmmmmm....the logic looks right so it must be a sequence issue missed by the dumbkerfarfen who wrote it!"  (Hey...my new word that google's never heard of!)

Without knowing the rest of your program, I would be putting ALL your motor controls in the one sub, which is constantly called. Another thing that you may possibly need to take into account is that you are running the motor via modbus, which has inherent delays that must be allowed for within all your controls.  Things like emergency stops, deadband/hysteresis, etc.

cheers, Aus