Studio 5000 OTE instruction not maintaining state?

cldarling · Jan 13, 2017

Good morning,

I am working on a program and I am having an issue with an OTE instruction. When the subroutine is called and the rung is true (seq_step=0)then it energizes an OTE instruction (set_valves_default) which starts another subroutine to set the valves to default position. The problem is that the instruction quickly switches from 0 to 1 back an forth and never energizes the corresponding XIC instruction. I use the same tag in multiple subroutines (studio gives me warnings) but only one subroutine with the instruction is called at a time. Any ideas as to what would cause this? Ive never seen it before.

I searched high and low through my logic to find some conflicting code but I can't find anything.

Any info would be appreciated

jstolaruk · Jan 13, 2017

Can't tell without looking at the code but its obvious two output rungs are active at the same time. Do yourself a favor and set up individual tags - what you are doing is considered extremely poor programming practice and causes nothing but confusion for anyone else trying to follow the code..

cldarling · Jan 13, 2017

I am just figuring things out as I go but I dont understand how it is bad practice. I have 20 different valve configurations needed to transfer material to different ares. One subroutine for each. I call the one I need, execute it, then return everything to default. I added an extra subroutine for the valve defaults so that I dont have to add 30 valves to the end each routine. Seems straight forward to me but I havent been doing this long.

jstolaruk · Jan 13, 2017

For the very reason you've posted here wondering why it doesn't work is the reason its bad programming practice. Imagine someone coming up later after the project is commissioned that didn't author it trying to debug it.

K.I.S.S. and you won't get those late night phone calls wondering why something doesn't work. The fancy stuff is what beginners/novices do thinking that its better - trust me, its not.

Paullys50 · Jan 13, 2017

As jstolaruk stated, duplicate OTEs are never good.

However, I understand your method of thinking and it is valid. Especially as we move towards more object-oriented/modular programming concepts. I've done very large process systems using similar thinking, with much success and I'd argue it's is extremely simple.

You need to modify your code to use OTL/OTU...HOWEVER YOU MUST USE THIS PROPERLY!!!

Create a REQUEST tag.

set_valves_default_REQUEST. Replace the "set_valves_default" tage and OTE with the set_valves_default_REQUEST tag/OTL.

You will have to create a new rung of logic in your program that is always monitoring the request tag.



set_valves_default_REQUEST                          set_valves_default

-----------| |----------------------------------+----------------(  )------

                                                          |

                                                          | set_valves_default_REQUST

                                                          +----------------(U)-----

IMPORTANT, each scan the request bit is active, it will process the OTE and you MUST RESET the REQUEST. The next scan through the logic will then process the request OTL and maintain the OTE if the OTL was still true. Cycle resets. If the request OTL is no longer true, the OTE will go false.

(I can never do the ladder editor right)

cldarling · Jan 13, 2017

You sir, are awesome. Cleared the problem right away, Thank you.

QvixoteRoux · Jan 13, 2017

instead of Latch and Unlatch I preffer other method, that may be less compact

I assign individual tags to each OTE, then all of the OTE have a XIC in parallel (OR) to the instruction or subroutine I want to be called.

If same tag is used in different OTE, all of them must be true to retain true state, if not, eventually the OTE will become false at the end of the scan.

Other funny way I saw in a machine is, declaring a DINT, use different bit for each OTE, then GRT compare the DINT, if greater than 0 another OTE will pass to true and call the requested instruction.

jstolaruk · Jan 13, 2017

QvixoteRoux said:
instead of Latch and Unlatch I preffer other method, that may be less compact

I assign individual tags to each OTE, then all of the OTE have a XIC in parallel (OR) to the instruction or subroutine I want to be called.

If same tag is used in different OTE, all of them must be true to retain true state, if not, eventually the OTE will become false at the end of the scan.

Other funny way I saw in a machine is, declaring a DINT, use different bit for each OTE, then GRT compare the DINT, if greater than 0 another OTE will pass to true and call the requested instruction.

I agree and also prefer it over multiple latches and unlatches.

labeledas · Jan 13, 2017

QvixoteRoux said:
instead of Latch and Unlatch I preffer other method, that may be less compact

I assign individual tags to each OTE, then all of the OTE have a XIC in parallel (OR) to the instruction or subroutine I want to be called.

If same tag is used in different OTE, all of them must be true to retain true state, if not, eventually the OTE will become false at the end of the scan.

Other funny way I saw in a machine is, declaring a DINT, use different bit for each OTE, then GRT compare the DINT, if greater than 0 another OTE will pass to true and call the requested instruction.

Normally how I do it as well I have done the DINT method a few times as well.

Paullys50 · Jan 13, 2017

QvixoteRoux said:
Other funny way I saw in a machine is, declaring a DINT, use different bit for each OTE, then GRT compare the DINT, if greater than 0 another OTE will pass to true and call the requested instruction.

funny is right!

jstolaruk said:
I agree and also prefer it over multiple latches and unlatches.

labeledas said:
Normally how I do it as well I have done the DINT method a few times as well.

Nothing wrong with parallel branches and OTEs, I'd say it's more of the "traditional" method. All device control I do is wrapped into an AOI, the AOI processes incoming control requests and controls the outputs as needed. I don't have to worry about unlatching anything ever. Sequence logic can get messy with parallel branches of EQU/LIM/GRT...and I often find this is were programmers get sloppy. They lose consistency and scrolling through all of this logic makes it harder to follow.

Code:

CASE StepEngine[1].Step.current OF
	// ***********************************
	1: // Initialization
	// ***********************************
	
	// ***********************************
	10: // Open Route #1 Path
	// ***********************************
		// Valve Activation
		SV101.request := TRUE;
		SV2101.request := TRUE;
		SV2110.request := TRUE;
			
	// ***********************************
	20: // Transfer Raw Material #1 - Fast
	// ***********************************
		// Valve Activation
		SV101.request := TRUE;
		SV2101.request := TRUE;
		SV2110.request := TRUE;
				
	// ***********************************
	30: // Transfer Raw Material #1 - Slow
	// ***********************************
		// Valve Activation
		SV101.request := TRUE;
		SV2101.request := TRUE;
		SV2110.request := TRUE;

	// ***********************************
	40: // Close Route #1 Path
	// ***********************************
		// Valve Activation
		SV2110.request := TRUE;

	// ***********************************
	50: // Drain to Tank
	// ***********************************
		// Valve Activation
		SV2110.request := TRUE;

	// ***********************************
	60: // Material #1 Complete
	// ***********************************
		// Valve Activation

I'd say it's much easier to follow the sequence logic, and it probably aligns nicely with the functional description documentation. This in LAD is just as clean. If you need to troubleshoot just go to the rung with the current step number and see what should be on. Only the devices that need to be activated in any given step are shown.

Studio 5000 OTE instruction not maintaining state?

cldarling

Member

jstolaruk

Lifetime Supporting Member

cldarling

Member

jstolaruk

Lifetime Supporting Member

Paullys50

Lifetime Supporting Member

cldarling

Member

QvixoteRoux

Member

jstolaruk

Lifetime Supporting Member

labeledas

Member

Paullys50

Lifetime Supporting Member

Similar Topics