bit "collision"

Skidood

Member
Join Date
Oct 2016
Location
Ontario
Posts
213
MicroLogix 1400

Say that I have a bit I want to energize with an OTE in ladder logic. The same bit is also present in an OTE in another subroutine which is not being called/scanned. Nothing to worry about, correct?
 
Nothing to worry about, correct?
I wouldn't exactly say that. Will it cause a problem with your program as it is? No, as long as you are not calling that subroutine it will work. If you were to ever call that subroutine and forget that you have it in another location you could end up causing all kinds of strange issues that are not easy to troubleshoot.

So if you can I would use a different bit or change the unused subroutine to use a different bit just in case you end up needing that routine in the future.
 
OK thanks...the other subroutine is just essentially storage for an alternative strategy to a certain aspect of machine operation that I didn't want to delete just in case I need it in the future.
 
Something to consider.

if the subroutine is ever scanned, what will that subroutine cause the machine to do?

for example, will it tell a press to feed a part while the press is in the punch cycle? you must look at the subroutine and look at all the logic and make the determination if it is safe.

I know of one machine that was told to home in a subroutine and it did $250k in damage and took 9 months to rebuild.

james
 
Nothing even remotely that dramatic would happen in this case, I have removed the subroutine now anyway. Thanks.
 
Something to consider (for future reference). Don't forget that the main routine is always active even when a subroutine is so if the bit in question is in the main subroutine you will get a conflict when the subroutine is active. For me the simple way to deal with that is to disable any rungs that the bit is used on in the main routine when the subroutine is active. That should prevent the main routine from controlling the bit when the subroutine needs to. However, depending on the complexity of the overall program it may be easier (and better practice) to not share bits across different routines.
 
I'm solidly in that camp that says don't ever do it.

Like anything though, there are exceptions but that's a philosophical level discussion.

Another common beginner ladder programmer thing I see if that new ladder programmers see the word "subroutine" and think, oh yes, subroutine, I done it before and I know how to use it. NOOOO

Ladder is a quite unique programming language that shouldn't be compared to other more common programming languages. The best practice is to use it for organization only.
 
Bad practice, IMO.

Generally speaking, I've found it easiest when all of the outputs are in a single subroutine. Use other subroutines for timers, sequences, etc, and then use those to trigger your outputs.
 
What I do for a subroutine I am working on for a different method of operation is put an unconditional RET on the first line, then if somehow it is called it returns without processing any of its rungs.

When I want to test it I put an XIC "Test_New_Ladder" bit on the JSR with an XIO that bit on the original JSR. Then in both subroutines I put another check for that bit or it RET's. That way by toggling one bit on or off I can test the new routine or go back to the original.
 
I once took part in the comissionning of a line and in the program, which was done with the DCP standard (used at Ford & Jaguar/Land Rover), there were multiple bits that were written as OTE several times. Some of them as much as 30 times, including in the same routine.


The condition was tested and the state was only relevant before the next write.


It can save tags and memory, if you only need a condition to be tested in one part of the code. Like " Motor start condition OK", you can write the same bit each time before the call of Motor FB, it wont have consequences.


I admit I don't do it as it can be harder to search and it usually makes the software compiler spit warnings by hundreds. Generally with the memory available now and the speed of the processors, you don't need to do things like that.
 

Similar Topics

A couple days ago I accidentally toggled an alwasyoff bit. The issue is it was set up as a single OTU on a rung, nothing else, and used as XICs...
Replies
3
Views
194
Hi I have an old panel builder 32 that I’m replacing for a factory talk me hmi . In the plc for the old panel builder there is a coms bit for the...
Replies
0
Views
61
Hello, Haven't been on in a while. I need to generate a bit level pdf of the I/O for RSLogix 500. I can generate a report but it just shows the...
Replies
1
Views
115
I tried researching but I still don't quite get it. As far as I understood, it's used after a function is called in STL and then if the function...
Replies
1
Views
127
Hi. I'm struggling over some basic stuff here. 41001 I is a 16 bits integer that I'm able to read with InTouch. What I need to do is to read...
Replies
1
Views
84
Back
Top Bottom