Program continues from whrere I turned it off, instead of starting over after pressing on again

[KristinaEgh]

I'm fairly inexperienced with Ladder programming and completely new to Visilogic. I'm working with a SM-35-J-R20 PLC/HMI and trying to make the following routine  (State_diagram) to work, I'm sure there are better methods at approaching this, but this is what I came up with. My issue is, when I click the off button on the touchscreen, the program stops as expected, but clicking on doesn't reset the program and start over from step 4000, it simply continues where it left off. I wanted to refrain from using set/reset as much as possible, but realized along the way that I couldn't get the program to work without it, with my current skillset. Can someone tell me what I'm doing wrong? Step 3900 should reset all the steps as off signal is pressed, but it's not going through.

I'm providing all of the subroutines in here, but the issue is in VisiLogic ProjectMain routine.pdf and VisiLogic Project_Steps.pdf.

VisiLogic Project_Outputs.pdf VisiLogic Project_timers.pdf

[Flex727]

It's difficult to follow your logic flow without the actual program, and also because it seems confusing. I'll offer this to start: you seem to be confusing two different types of latch circuits which overly complicates your logic.

I've rewritten your Main Routine ladder rung 2 in two different ways. Either can work but you might choose one over the other based on other program requirements. The top (rungs 1 & 2) use Set & Reset coils to latch MB 13. The bottom (rung 4) is a standard latch circuit without Set & Reset coils. Your logic combines them weirdly and I don't know what the result would be without spending more time than I would like puzzling through it.

 

[Fernando Castro]

Maybe this will help, on unitronics PLC everything is retained on the PLC memory, 
I had the same issues while working with unitronics for the first time, on my experience with other PLCs by default everything is non retained unless you specified otherwise. Unitronics is the opposite way everything will be retentive on power loss, or on software reset which means everything will be in the last state it was last time it ran. what I do is to have an "initialization" sequence on power-up, but that depends on your logic

[Fernando Castro]

Also sub routines will not change its own values even if you are not running the subroutine.

for example if you have something like this:

-------|I0|-----------------\Insert Sub routine here\--------------

everything inside the sub routine will remain as it was even if I0 is on OFF

[Flex727]

1 hour ago, Fernando Castro said:

Also sub routines will not change its own values even if you are not running the subroutine.

for example if you have something like this:

-------|I0|-----------------\Insert Sub routine here\--------------

everything inside the sub routine will remain as it was even if I0 is on OFF

This is true. However, it is strongly recommended that conditional subroutines be avoided if at all possible.

[Fernando Castro]

16 hours ago, Flex727 said:

This is true. However, it is strongly recommended that conditional subroutines be avoided if at all possible.

why?

 

Unitronics VisiLogic Help shows other wise: "

Program Sequencing: Modules, Subroutines, Labels & Jumps

A module is a container of subroutines.  Use modules and subroutines to divide your application into program blocks. You can then run these program blocks conditionally, from any point in your control application. "

 

And on its examples shows like that:

 

The program that I am developing uses conditional logic for many subroutines and it works fine.
I have had many problems with Unitronics in the past, but conditional logic for subroutines ain't one of them... in fact, the "core" of my application relies on this.
besides that, what will be the point of having subroutines if you can not use them conditionally? ... it will be like having one very big ladder but harder to troubleshoot🤔

 

[Flex727]

28 minutes ago, Fernando Castro said:

why?

Because coils and timers in an unexecuted subroutine are in limbo. They remain in the last state they were in regardless of activating condition. If you are an experienced programmer and understand clearly what's going on then it is fine. On this forum we deal mostly with inexperienced programmers who can easily get themselves in trouble using conditional subroutine calls. In my opinion it is poor programming practice anyway and should be avoided - much like GOTOs (Jumps), which you will also find is available to the programmer, but in my opinion should be avoided, if possible.

[Fernando Castro]

1 hour ago, Flex727 said:

Because coils and timers in an unexecuted subroutine are in limbo. They remain in the last state they were in regardless of activating condition.

well that is a very good reason 😅 on wich I agree,  If you do not read the documentation carefully you will be very screwed. but also that is a poor implementation from unitronics in my opinion.

 

1 hour ago, Flex727 said:

- much like GOTOs (Jumps), which you will also find is available to the programmer, but in my opinion should be avoided, if possible.

I do agree, if you need to use for "optimizing scan time" then clearly you have a poor program. all the execution of the program should be "almost" instantaneus  on a PLC (taking a side the time it takes from rung execution between scans)   however recenty I found it very usefull to do a "foor loop":

 

 

Just needed to test 15 bits in a row and depending of the result copy the indexed value or assign a -1 value (the intention was to sort a list of commands before I send it over serial protocol), and in this specific case was worth it to have the list of commands ready and sorted before the scan cycle to complete.

 

1 hour ago, Flex727 said:

On this forum we deal mostly with inexperienced programmers who can easily get themselves in trouble using conditional subroutine calls

😂 AKA people who does not read the documentation first.

[Flex727]

59 minutes ago, Fernando Castro said:

well that is a very good reason 😅 on wich I agree,  If you do not read the documentation carefully you will be very screwed. but also that is a poor implementation from unitronics in my opinion.

Gratified that we agree, but how is it a poor implementation from Unitronics?

[Fernando Castro]

1 hour ago, Flex727 said:

Gratified that we agree, but how is it a poor implementation from Unitronics?

Having everything on the last state or in "limbo" in case of not running the logic does not feel the best way

I mean if you have this:

-------|I0|-----------------\Insert Sub routine here\--------------

and your Sub routine is like this:

-------|I1|---------------------------------------------------------------( O1)

there makes no sense to me that the behavior will be O1 == True  even if I0 == FALSE

but It is what it is 

 

 

[Ausman]

3 hours ago, Fernando Castro said:

there makes no sense to me that the behavior

This is just which way personal opinion sways. 

On one hand it makes complete sense that if something controlling  an output gets turned off, then the output will retain the state that control set it at.

On the other hand it is the opinion working along the lines of cascaded circuit breakers.  If you turn off the breaker closer to the source, then everything beneath it goes off, even though the downstream breakers are actually still ON.

Both points of view have their own valid reasons, but in the world of PLCs, the implementation of how things are done varies greatly across makers.  If you are used to the way others do things, then when first using Unitronics there are some things that seem very odd, but once you get used to them, they often make far more sense. 

An example of this is your reference elsewhere to retained values.  As you say, other plcs require you to specify what elements you want to retain in memory.  Unitronics holds them all, unless otherwise instructed.  At first I found this an issue, then realised that it is far more useful way of doing things.  If your project has the ability to fine tune some running parameters, or works by having numbers calculated internally, having all those things retained is good.   The ability to be able to very easily pick and choose which items to retain is a huge bonus in my eyes.  Other PLC types I've worked with only allow a single adjustment that controls a range you specify, mostly starting at element 0.  This makes things hard to have organised numbering layouts which might have some things you want to retain, and others you want to reset at boot.  The Vision method makes this really easy.  (I always try to have numbering layouts such that any element involved in part X of a project all run numbers in the same range, be it bits, integers etc).

I often make analogies to cars on here.  I'm sure your car has some things that you find really annoying, but you have learnt to live with.  Then one day you hop in a different car, with a different approach to your annoyances, and you either get more annoyed or impressed with how they've done things.  It all comes down to keeping your mind flexible and open to different ideas, that at first glance might seem strange.

So endeth the philosophy lesson!

cheers,

Aus

[kratmel]

I am the leader of a PLC programming group for students, some of whom are studying computer programming.

To my surprise, their approach to solving the simplest control problems based on PLCs differed significantly from the typical one.

I was especially impressed by the bit shift algorithm built on a typical computer cycle implemented in a PLC.

At the same time, they were impressed by the possibility of using vector copying to solve this problem in one rung.

 

Therefore, I support the Ausman tip

2 hours ago, Ausman said:

to keeping your mind flexible and open to different ideas, that at first glance might seem strange

This quickly adds experience and speeds up the creation of new program.

P.S. I am sincerely impressed with the structure of Fernando PLC project - after simple reading the names of the subroutines I was able to imagine the content of the task you are solving.

[Ausman]

On 2/16/2022 at 6:26 AM, Fernando Castro said:

what I do is to have an "initialization" sequence on power-up

Fernando, if you need such a sequence can't you achieve the same result by using selective power up values?  Which is much easier to do.

cheers, Aus

[Fernando Castro]

On 2/18/2022 at 4:29 PM, Ausman said:

Fernando, if you need such a sequence can't you achieve the same result by using selective power up values?  Which is much easier to do.

cheers, Aus

I do, but  not always... I mean it depends on the application but a clear example is timers and counters. anyway I found it more likely to forget to enable power up value than have an initialization sequence but I guess that that also depends on the programer