MLS/MLR , For/Next , (orout) , D0-06's

Master Line Set/Reset - do you folks use this?

For/Next - same question

(orout) - found out the hard way

Am going back to a project from last year. Machine was basically a compactor 'modified' to do other things.

It has 2 (two) modes of operation, 'manual' and 'automatic'. One selector switch handles this, as each mode sends 120V into an input.

Tried to set up 'subroutines' for each mode in programme. Initially seemed a nice way to structure programme. If 'manual' bit was true, MLS/MLR a section of logic to deal with that. Did the same for 'automatic'.

It did end up working, and will post logic next week as this machine must work. Found out the hard way that you can not have the same output ie, (out y6) be the result of two or more rungs of logic.

Basically in 'manual' mode Solonoid Fwd is 'fired' at certain times. In 'automatic' mode Solonoid Fwd is 'fired' at certain times as well.

With two subroutines for each mode, problems were plenty. Had to use (orout y6) for it to work. Basically 'ouput y6' was the 'result' of more than one rung of logic.

If For/Next was used for each 'subroutine' it ignored any logic other than what was in that 'loop'. Could not stop the damn machine at one point, on the simulator of course.

Why would DirectSoft allow you to write code like that as you get no errors. Rung 1 results in ouput y11 'true'; Rung 2 results in output y11 'true'; - for example.

It makes crazy things happen. Ended up, as stated, using (orout y11) for each rung (as an example), and it worked. Used Master Line Set/Reset for each subroutine, and it worked.

Documented it very well, teacher did not understand, gave me a 'B'.

Johnny

I use the MLR/MLS a lot.
Manual/Automatic mode and a lot else

But to set outputs I use the following:

For instance the Solonoid forward would set C100 = M_SOL_FW in manual mode (hence the M_)
Solonoid forward in auto mode would set C200 = A_SOL_FW

Then before the end of the program I set all my outputs, so M_SOL_FW or A_SOL_FW would trigger the output.

This is a good way for debugging, since in my programs I can set the solenoid forward in many routines in the automatic mode. So I have A_SOL_FW_STA(with the description "Solenoid forward during automatic start") and A_SOL_FW_STO ("Solenoid forward during automatic stop")
(just a lousy example)

So, in the end of the program I can see what triggers the solenoid forward output and now where the program "is" at the moment.
I am bad in explaining thing but I hope you'll get the idea.

I don't use OrOut's, they are handy but mostly limited to a certain type of plc.

I don't try to subroutines, only for initialization (on a stop to run transition) and math-routines. I had to much problems with it. If you set an output in a subroutine and don't call that subroutine anymore the output will stay on!

I don't use set/reset, only out's. That way, if you clear the MLS bit, all outputs that are used between the MLR/MLS are off. This way I don't have to think what outputs were set.

Hope it helps

I personally prefer to put the logic in subroutines rather than master control relay. It makes the logic more modular for re-use on different projects, and breaks the logic into smaller sections which makes reviewing the code simpler.

One trick - in DirectSoft you should keep the timers in the main section of the program or they won't keep track properly.

I use both MLS/MLR and subroutines. Like Tom mentioned, if oit is going to be a routine i plan to use a lot, I make a subroutine out of it. With MLS/MLR, I use them only when I have multiple output conditions driven off of a common input. For example, If Master Switch is on and Switch A is on, do B. If Master Switch is On and Switch A is off, do C. Works real well. The only time you should ever double coil is when using stages and you know that two conflicting stages will not be on at the same time. Else I would do as littleone suggested and turn on a Cbit for each condition and at the end of the program use all the Cbits in Parallel to drive the Y out.

Bob

I use orout in every program I write. This comes in handy if you use the Block/Stage programming techniques. If I use orout in the stages I can see exactly what that stage is doing.

We had a programmer that would use stage bits at the end of the program to fire an output using an or rung, the problem with this is that you had no way of knowing that an output was going to be fired just by looking at the stage logic.

I rarely use subroutines unless I have some math routines. I find that using stages is much easier to use after you create a flow diagram for the process.

could be

Johnny what may be happening is when you MSR you have left something on you needed off. Like in a subrutine anything you don`t want on out of the sub you better turn off when you jump out. Also the logix is still scanned between MLS AND MLR but not executed where in subroutines I believe the logix isn`t scanned if not called. As for the orout this means they are all in parallel, if on anywhere in program the output is on. Where if not (ored)? is this a word??? What ever the last state when scanned is what you get out. I like (GOTO)(LBL) and SUB`S better

I thought that the MLS/MLR combination set up a zone in the program where the rungs were evaluated as not true if the MLS is reset. So if the MLS is reset the outputs are set to 0 regardless of the logical state of the rungs in the zone.

Keith

Keith, I believe that is true. Thanks for all the ideas, very helpful. Basically what I was getting at is what 'instruction' do you use for subroutines. I honestly have never used them. Same with stage/block. I tried to use MLS/MLR as a 'poor mans' subroutine.

Here are some pics from that shredder/conveyor/compactor project. I did clean up the control panel. Everything works nicely.

Johnny

[attachment]

Thanks for the photos. Nice job overall, Johnny...

They won't be leaving that garage door open anymore!...

beerchug

-Eric

P.S. Did the conduit bending guy leave early? IOW, why did you choose to run all that sealtite instead of EMT?...

Thanks Eric, for all of your help. The conduit guy was not there, thank God. This is the north-east corner of a 5 million sq. ft. building. The mess of existing EMT was crazy.

My conduit goes from the switch to the control cabinet (first picture). And from the middle of the control cabinet to the shredder control cabinet. The messy cords, and other 'total' mess were not mine of course.

Was going to run EMT with a conn./rigid coupl./PVC TA and change to PVC through the outside wall to an outside Junction Box. Had all the Teck 90 in stock, and it was faster. Used uni-strut floor stands to clamp cables so door can open. The Teck 90 allows conveyor belt adjustment as well.

Used Liquid Tight to the hydraulic unit because of vibrations.

Had 'Special Inspection' by the Electrical Safety Authority yesterday (Thursday), and no problems. (5KVA Short Circuit Calculations)

Handed project over to customer today. Having a few drinks, enjoying this board.

Have to rewire my old snowmachine, help my 'rich' sister move new furniture in Toronto, and maybe, go to church this weekend lol.

Johnny

Anyhow, would love more suggestions on 'subroutines'. Will lay this 'subject' to rest. Sometimes talk/type too much.

Just for you Eric. Yes I will get the 'sizing' of attached pictures 'down'.

Does Phil give badges for 'job well done'. Maybe '1%' like the Outlaws. And each badge goes in increments of 0.1% after that. Phil, TestSubject, Terry, Eric and Tom would maybe be 120.8%, but I'll take 1% for starters. Cheers!!!

Johnny

[attachment]

Johnny Rotten said:

Just for you Eric. Yes I will get the 'sizing' of attached pictures 'down'.

Click to expand...

Yes, that's much better...

I think a subroutine's 'intended' purpose is to keep scan time down by running only when needed. I rarely use them for this. Most often, my subroutines are called unconditionally (always scanned). I just use them for organization. Each process gets it's own subroutine, even though all are always running. Makes it easier to test out each section by enabling/disabling the subroutine call.

A few have conditional calls. I'll fire one at power up (first scan) to set parameters. Another example is for communication. If I have something on the serial port, I'll call a subroutine to send data out the port only when the data NEEDS to be sent. No need to send it repeatedly.

Also, subroutines make it REALLY easy to re-use code from machine to machine. Copy, paste, DONE!...

beerchug

-Eric

OK

Good looking job Johnny and great pictures! EXCEPT FOR THAT LAST ONE WHERE`S THE CONTROLS FOR THAT? SHE MUST HAVE BEEN TAKING THE PICTURE?



:site:

Eric Nelson said:

Each process gets it's own subroutine, even though all are always running. Makes it easier to test out each section by enabling/disabling the subroutine call.

Click to expand...

Eric,

Block/Stages do the same thing without all the subroutine breaks/returns... <whistles quietly as I walk away>


Bob

I am currently changing a program over from AB to AD. The AB programs has several MCR areas. I assume that the equivelant in AD is MLS and MLR. Well I have tried using these and they are not working.
In AB there are 7 MCR with bit control input, and 7 MCR on a rung by themselves. They are not nested together but scattered throughout the entire program.
Does the MLS and MLR in AD need to be nested to work? I scattered them in the program like AB did but they actually won't allow the program to function. The examples in the 205 manual has them nested. I would attach the program but it is over 900 rungs.

Billy Seay
Knoxville, TN