Less than compare function not powering coil

[wbarkley]

For some reason this compare function is not energizing MB33 coil when the compare function is true, and I can't figure out why.

[kratmel]

Please Find MB33 in Visilogic project.

I think you have another MB33 coil -(    )-  in project  (only one direct coil must be in project)   or do not add subroutine with this function into Main routine.

 

[Sideway]

Hi,

if i see it correctly, it seems like your net wire (on the left of your comparison) is not activated (does not turn red). So it seems like your rung is not runned, which means your routine is not activated

 

Cheers,

Sideway.

[wbarkley]

I searched for it elsewhere and this is the only MB33 direct coil in the project. 

The net wire is active and red in the project.

Quote

 or do not add subroutine with this function into Main routine.

This function is in a subroutine and is meant to activate an a direct contact within the same subroutine.  I do not have it correlated to anything within the main routine.

 

cheers.

[Ausman]

Kratmel has likely hit the nail on the head.  And Sideway has just chimed in too as I'm writing this...and wbarkley just as I posted.  However, Sideway's "red" observation is not true and likely because the screenshot doesn't show red well.

A really annoying thing with Visilogic is that it shows power on things that aren't actually running.  It shows the state of operands, regardless of whether they are active in the power stream or not.  As well, the net wire as Sideway calls it, which I call the left rail, shows red even though it is not active.  This has been brought up many times on the forum and is just one of those things that has never been fixed because of limitations available in the way the system works.  The creators say it can't be done.

There are many suggestions here of how to check a sub is actually running.  Some use cycling counters.

Running Subroutines also has specific operational rules that must be kept in mind.  It is an absolute must to fully read "Program Sequencing: Modules, Subroutines, Labels & Jumps" in the Help files.  Found under Index search for Subroutines.  Many people often get caught with something not turning off, or behaving as expected, when they deactivate a sub.  If something is on and the sub is stopped, the thing will remain on.  Whether this influences overall operation will depend on it's further use in the entire project.

To show the power rail flow, I quickly went online to a job.  I changed the power flow colour to green so that it is more easily seen in screenshots.

This shows the DamperForce subroutine NOT being called because the bit is not on.  The left rail IS green.

This is the sub view.  Note that the rail is still green.   Any operands within the sub, whose state is "active" will also be showing green.   But they perhaps will not be doing anything, or vice versa.

It is all a bit confusing and takes a while to get your head around.  Especially when working with other systems that DO show power flow "correctly".  You simply have to keep it in mind at all times.

cheers, Aus

 

 

[Ausman]

And wbarkley, are your oil filter hours running as an addition?  In that case your compare is the wrong one for what I think you are wanting to achieve.  Whenever your hours are less than 200 your MB33 is going to be on...when the thing is working correctly!   I think you should be using a larger than compare.

9 minutes ago, wbarkley said:

This function is in a subroutine

Ahh yes, but is it actually being called?

cheers, Aus

[wbarkley]

Looked at the project again and realized I had the subroutine this was contained in disabled from the main routine..... 😩

It's working now...

 

Thank for the help.

[Sideway]

Hi Ausman,

Thank you for your explanations, i didnt notice that the power rail would turn red whether or not the routine would be called, sorry for that ^^'

Though, in some of my ladder programs, i remember i used to put a direct coil sometimes in my leading net, which would turn red if the subroutine was ON.

I have always been "learning-by-doing" automation (for 1 year now), so i may have bad calls sometimes

Cheers.

[Flex727]

Glad this is solved. I'll just place a reminder here to avoid conditional subroutine calls. This is poor programming practice when it can be avoided - and it nearly always can be avoided.

[Ausman]

On 12/5/2021 at 9:13 AM, Sideway said:

i may have bad calls sometimes

Everyone is only allowed 1 bad call per week.  🙃

In Aus we get 3 or more "bad" calls a day.  They go like this...answer phone....delay delay "heellllooo, is that Mr Ausman?  This is Microsoft/Amazon/Any bank/Whatever the scammers can think up next Security.   Essentially give us your account numbers and passwords!  But we'll be devious about getting them from you."  OK, I digress a little, mingling different meanings on the same word.  ⁉️  📞 

cheers, Aus

[Flex727]

On 12/4/2021 at 4:13 PM, Sideway said:

Though, in some of my ladder programs, i remember i used to put a direct coil sometimes in my leading net, which would turn red if the subroutine was ON.

Actually this does not tell you as much as you think. If it's a conditional subroutine call and the subroutine stops being called, the coil will remain on. This is only one of the reasons to never perform conditional subroutine calls.

[Sideway]

On 12/8/2021 at 3:09 PM, Flex727 said:

Actually this does not tell you as much as you think. If it's a conditional subroutine call and the subroutine stops being called, the coil will remain on. This is only one of the reasons to never perform conditional subroutine calls.

Thank you for your warning ! Conditional subroutines are a habit i have often seen in the ladder programs i have been working on... Since it was a bit of code written by some senior automation experts, i used to take those habits as "good practices".

I realize now that i was very wrong about that, and realize how good it is to be part of this forum, where i can fullfill my knowledge thanks to the help of all of you, and think more in depth about the programs i am writing

 

Cheers,

Sideway.

[Ausman]

I have to say here that in some specific instances I do use conditional sub calls.  They are where I need to totally stop something the sub is running, and the best or easiest way is to stop the sub.  But the thing I do that "covers" the inherent danger in doing so is that I set all operands that the sub has been generating to what I need them to be for the reason to stop the sub in the first place.  The sub gets stopped and a few scans later a whole host of operands get set to what is needed.  Once the "over-ride the sub" action has been completed and things can go back to normal, the sub resumes and sorts itself out to "current" running values within a few scans.

The real thing that makes this possible in my case is that the sub resuming is not dangerous to machine operations and can't cause any issues.    In some machines such an action would  cause problems.  It is an "ease of operations" type thing and a judgement call on the most practical way to do something.

Don't do it, but if it really is the easiest way, cover your bases.

Also remember the way the brand you're working on does things....it can often get confusing if skipping between makers, and a little writeup of brand quirks can help jog the memory cells when needed.

cheers, Aus