Jump to content

Recommended Posts

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. 

image.png.c1589f29d18aa5f6749303cb138a10aa.png

Any help is much appreciated.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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??

Share this post


Link to post
Share on other sites
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?

 

Share this post


Link to post
Share on other sites
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.

 

Share this post


Link to post
Share on other sites

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:

image.png.ed50b756b98d9a3d420f2fa9a249a6f5.png

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.

Share this post


Link to post
Share on other sites

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?

  • Like 1

Share this post


Link to post
Share on other sites
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. :)

Share this post


Link to post
Share on other sites
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

image.png.de8ae8e15c969ae3484fd4b6b4cff6c6.png

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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. 

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites

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:

image.png.0a682e79c10e5253e172f090575dc606.png

Working:

image.png.e498b30926b889db21c894fca6b64e62.png

Thank you Flex and Ausman for your help.

Share this post


Link to post
Share on other sites

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.

  • Like 1

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

  • Like 1

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...