comparing problems

[sjeggefjes]

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

[Phil Salkie]

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_.

[Damian]

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?

[sjeggefjes]

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?

[sjeggefjes]

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?

[Phil Salkie]

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.

[Damian]

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?

[Patrick]

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.

 

 

[Flex727]

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.

[acisre]

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

[Flex727]

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:

[Patrick]

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.

[Flex727]

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.

[acisre]

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:

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.

[Flex727]

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.

[Patrick]

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

[Flex727]

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.