Jump to content

Recommended Posts

Hi.

I'm having trouble with the compare funktion. When in online test mode I can see that the statement is true, the block is red but it will not set the coil behind it.

I've had this problem before but it have been solved by downloading the program again. This time it dosen't fix it.

I'm using vision130 with unitronics V 8.6.1 .

Anyone having any thoughts about this?

regards

sjeggefjes

Share this post


Link to post
Share on other sites

Is this compare function in a subroutine? I've often built a subroutine, but forgotten to call it from the main sequence program, so it monitors and appears correct, but it is never actually _run_.

Share this post


Link to post
Share on other sites

Hi.

I'm having trouble with the compare funktion. When in online test mode I can see that the statement is true, the block is red but it will not set the coil behind it.

I've had this problem before but it have been solved by downloading the program again. This time it dosen't fix it.

I'm using vision130 with unitronics V 8.6.1 .

Anyone having any thoughts about this?

regards

sjeggefjes

Have you done a cross reference to check if you accidently created a duplicate coil elsewhere?

Share this post


Link to post
Share on other sites

Hi.

Yes the compare function is in a subrutine but I know it's running/ been called cause I have a timer beeing set in this subrutine wich is running.

All of the other logic in this subrutine is working fine. I also have done a cross refrence and this direct coil is only in this one place.

Acording to the help file it should be able to compare negative numbers (MI's), which I'm doing, could this be the problem?

Share this post


Link to post
Share on other sites

the problem is solved and was:

you can't use the status of an output (direct contact) to set anything, changed the output status with the logic to set the output and everything is as it should.

Is this normal? why can you use the output status( direct contact) in the ladder diagram when it isn't working?

Share this post


Link to post
Share on other sites

Were you reading the output in the same network that you changed it in? Remember that the Unitronics follows an international PLC standard which states that no bit statuses change during the processing of a single network. Therefore this:

------------------------

MB0     MB1
-|P|-----( )-

MB0  MB1   MB2
-| |--| |---( )-

------------------------

will never turn on MB2 because the read of MB1 gives the status that MB1 had on entering the network, whereas this:

------------------------

MB0     MB1
-|P|-----( )-

------------------------

MB0  MB1   MB2
-| |--| |---( )-

------------------------

will do what everyone in the world (except the standards committee) would expect the first network to do, turn on MB2 for one scan on the rising edge of MB0.

As a general rule, don't combine rungs in networks. If you feel it's necessary or advisable, then look at the STL Quick View to make sure the actual compiled logic does what you thought it was going to do.

Share this post


Link to post
Share on other sites

the problem is solved and was:

you can't use the status of an output (direct contact) to set anything, changed the output status with the logic to set the output and everything is as it should.

Is this normal? why can you use the output status( direct contact) in the ladder diagram when it isn't working?

Could you post a pic of the before and after so we can understand what you mean?

Share this post


Link to post
Share on other sites

Hi everyone,

I am having the same problem as the OP here, however it seems to be intermittent

In a subroutine I am using a  >= compare (rung 5 in the photo).  The output is a direct coil.  The contact is in the main routine is a positive transition.

When the criteria are met, the online test shows red passing through and sometimes the coil works and sometimes it doesn't.  I deleted the coil and the contact, created new ones with a new MB and the problem remains.

In the same subroutine I have three compares in three consecutive rungs, the first two work fine, it is only the last one that bugs

BTW it is also the last line of the subroutine, could this cause a problem?

I am using a Samba SM70-J-R20 and Visilogic 9.8.65

Any thoughts or tips will be greatly appreciated.

Compare.thumb.JPG.88bfd0a9be8b6a73d3f2cf05ea86c97a.JPG1040382611_Stoprung.JPG.fae39b48c99f1bbc60d741b050b3d298.JPG

 

 

Share this post


Link to post
Share on other sites
3 hours ago, Patrick said:

In the same subroutine I have three compares in three consecutive rungs, the first two work fine, it is only the last one that bugs

The first two don't look fine. The compare is false, yet the coil shows as true (they're in red). Do a find on each of the coils (MB 16, 17, & 41) and confirm they are not duplicated elsewhere. Also, confirm the subroutine with the compares is being called in the Main Routine.

Share this post


Link to post
Share on other sites
On 10/6/2010 at 6:21 PM, Phil Salkie said:

Were you reading the output in the same network that you changed it in? Remember that the Unitronics follows an international PLC standard which states that no bit statuses change during the processing of a single network. Therefore this:

 


------------------------

MB0     MB1
-|P|-----( )-

MB0  MB1   MB2
-| |--| |---( )-

------------------------
 

 

will never turn on MB2 because the read of MB1 gives the status that MB1 had on entering the network, whereas this:

 


------------------------

MB0     MB1
-|P|-----( )-

------------------------

MB0  MB1   MB2
-| |--| |---( )-

------------------------
 

 

will do what everyone in the world (except the standards committee) would expect the first network to do, turn on MB2 for one scan on the rising edge of MB0.

As a general rule, don't combine rungs in networks. If you feel it's necessary or advisable, then look at the STL Quick View to make sure the actual compiled logic does what you thought it was going to do.

Hi Phil,

 

I find this interesting. What exactly do you mean with “a single network”?

in de second figure do you mean that the second rung is in a subroutine? I dont really see the difference between the first and the second picture right now..

 

thank you

Share this post


Link to post
Share on other sites

I think he said it backwards - do not combine networks in a single ladder rung. The first picture shows two independent networks, or logic strings in a single ladder rung. NEVER DO THAT. The second picture shows the the logic broken up into two separate ladder rungs properly. I created the examples in VisiLogic to show more clearly. Rung 1 shows how NOT to do it. Rungs 2 & 3 show the correct way:

image.png.61bbe935ced41d1158b06f0209a1bd11.png

Share this post


Link to post
Share on other sites
3 hours ago, Flex727 said:

The first two don't look fine. The compare is false, yet the coil shows as true (they're in red). Do a find on each of the coils (MB 16, 17, & 41) and confirm they are not duplicated elsewhere. Also, confirm the subroutine with the compares is being called in the Main Routine.

I checked everything, and subroutines are being called.   Strangely I did some other work and decided to do a download all and burn, and they work again.

I am still trying to track down the reason why the coils show true and the compare is false.

Share this post


Link to post
Share on other sites
29 minutes ago, Patrick said:

decided to do a download all and burn

You don't need to do Download All & Burn until you're ready to place the machine into service. During program development and troubleshooting, just do a simple Download. Download All & Burn wastes a LOT of time unnecessarily.

Share this post


Link to post
Share on other sites
23 hours ago, Flex727 said:

I think he said it backwards - do not combine networks in a single ladder rung. The first picture shows two independent networks, or logic strings in a single ladder rung. NEVER DO THAT. The second picture shows the the logic broken up into two separate ladder rungs properly. I created the examples in VisiLogic to show more clearly. Rung 1 shows how NOT to do it. Rungs 2 & 3 show the correct way:

image.png.61bbe935ced41d1158b06f0209a1bd11.png

Thanks for explaining.

So the first rung will not work as expected but rung 2+3 will ? I have seen things like this in a program so I will pay attention to this.

Share this post


Link to post
Share on other sites

It seems that way too many programmers (especially in the beginning) fail to recognize what the ladder rungs are in ladder logic. The screen is not just a blank slate to write the logic willy-nilly. The purpose of the rungs and separating logic threads is that the compiler will create machine code that tells the PLC to fully evaluate a single ladder rung before moving on to the next rung. When you have two logic threads with dependency between them and place them both in the same ladder rung, the programmer has lost control over order of execution. When in separate rungs, the programmer knows the first rung will be fully evaluated before starting on the next.

Share this post


Link to post
Share on other sites

Is there a way of setting up a goto equivalent?  For example using a compare, if a>=b then goto xxxx, leaving out the rungs in between which would be evaluated if a<b

I am still having endless problems with the compare.  It happens in both main routine and subroutine, and only on one particular thing, stopping a motor, which is kind of important .....

I am using other compares and they are fine

Share this post


Link to post
Share on other sites

Yes, there is a GoTo in Unitronics Ladder Logic, but it should be avoided. It is poor programming practice in 99.9% of circumstances. There are far better ways to execute only the rungs you want executed.

My philosophy is to work backwards from outputs or coils to inputs or contacts. Determine every circumstance that should turn that output or coil on and write that logic. When that is correctly done, there is no need to skip rungs because they will not activate the output or coil automatically.

43 minutes ago, Patrick said:

For example using a compare, if a>=b then goto xxxx, leaving out the rungs in between which would be evaluated if a<b

A simple way of accomplishing this is to assign a coil to turn on when a>=b, then place the inverted contact of that coil in front of the logic you want skipped. 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×