RS Logix: No unlatch Bit

Im not sure whether this is me just being naieve or what. but i was doing some searching in a program and found that a single bit was latched on but nowhere in the program was unlatched. i have a few ideas how this could be done but i was wondering if this is usual and how it is unlatched.

Cheers

BMW

Bit could be unlatched by a word operation or file operation. Also could be done via HMI/SCADA system.
Is this an issue for you or are you just curious?

Marc

Maybe the programmer needed a bit that was always on. I like to set up an "Always On" and an "Always Off" and a "Dummy" flag

it is not an issue as such but i am just doing some fault finding and i hit a kind of dead end there. i am finding ways around it but mostly i need to know its operation.
it is not an always on/off it is a fault flag. when x y conditions are correct the fault is latched on. but nowhere is it latched off. i had a look and found a rung that has a FLL funtion writing 0s into the word containing this bit being latched on and so this will effectively unlatch it. the strange thing is that to unlatch it and effectively clear the fault it shows that you simply have to put the station into manual. that seems odd...i will do some more digging.

ah ok, i understand slightly more now. the FLL function will fill the destination with the given value every scan until the conditions before it arent true anymore. this means that when you are in manual mode you do not have any of the faults that will stop you from steppin back and forward and only will also mask out any faults that are unnecessary in manual but still allow any critical faults.

this is me talking to myself more than anything. haha. at least this post made me think about it a bit more.

Cheers

I've seen some machine programs that MOV a "0" into a fault word to clear individual fault bits. I don't care for the practice.

i have to agree that the whole section of code around this piece of kit is not how i would have liked it to be done. but it does make sense, plus its a nice way of just using the manual to clear the major faults then if auto is selected the faults will become clear again. but hey, theres always another method....

Rube said:

I've seen some machine programs that MOV a "0" into a fault word to clear individual fault bits. I don't care for the practice.

Click to expand...

I actually use it quite often. It's a much easier and very powerful practice and makes adding additional alarms to a particular sub-system very easy.

As an example:

A particular Pump has the following faults associated with it:

Zero Speed
Drive Fault
Run Fault
Disconnect Fault

So, I'll take one word (B3:0) and that becomes the fault word for that pump. The individual faults are latched as follows:

Zero Speed = B3:0/0
Drive Fault = B3:0/1
Run Fault = B3:0/2
Disc Fault = B3:0/3

The beauty of this is that the pump run logic uses a single EQU statment of B3:0 = 0 for the permissive.

The fault clear uses a single MOV statement of B3:0 gets 0 to clear all the faults.

There are no worries of latching/unlatching individual fault bits, or remembering to put them all in the permissive.

Now the real power comes in when I need to add a High Amp fault. I simply add a single rung that latches B3:0/4 (the next available unused bit of the fault word). None of the permissive logic or fault reset logic has to change. No searching around the cross reference for places that I might need to add this new fault bit. Even the HMI doesn't have to change if the fault indicator for that pump is using the fact that B3:0 is not zero.

I should have said I use integer words for my faults instead of bits, which is the practice I don't care for. I then use the fault words, not bits, to a master fault word for display on an HMI.

I'm not saying either is right/wrong. Sorry for mistating my point.

ok, so is a mov hugely different from a fll? i know they are different...thats a rubbish way of putting it. is there any advantage using one or the other for this?

If we're talking AB, a MOV is a single word, a FLL is consecutive words. A FLL of length one is the same as a MOV.

is a MOV restricted to a single word. im being slightly lazy and not looking myself. sorry...

bmw_apprentice said:

is a MOV restricted to a single word. im being slightly lazy and not looking myself. sorry...

Click to expand...

Again, if we are talking RSLogix (5,500,5000) then yes a MOV instruction is source to destination, one word. If you have something like a TI505 series processor (now siemens), then a MOV is one word, while a MOVE is multiple words.

ah i see. thankyou for your help.

a lesson from "slightly beyond the Boot Camp" ...

from robertmee:

A FLL of length one is the same as a MOV.

Click to expand...

that’s a VERY popular misconception - but it’s not QUITE accurate ...



note that in MOST cases, the description quoted above is “close enough” to work just fine ... but ... in other cases the important distinctions between the MOV, COP, and FLL instructions can lead to some very “intense” types of troubleshooting and program debugging problems ...



in other words, most people will probably never need to worry about these issues ... but if you’re dealing with higher-level programs - especially where “format” conversions are involved (integer to float, etc.) - then you might want to put these ideas in your little notebook of miscellaneous information ...



in a (too-small) nutshell:



(1) the MOV instruction copies VALUES ...



(2) the COP and FLL instructions copy BIT PATTERNS - but they each do that operation in different ways ...



if you’re “in to this” type of stuff, the best way to learn it is “hands-on” by entering something like the program below in a SPARE processor ...

be sure to manually type the “start up” values into N7:10 and N7:11 first ... then toggle the “test” bits ON - ONE AT A TIME ... watch the results that pop up in the N7:0 - N7:1 “Destination” area ... you’ll soon see that the MOV, the COP, and the FLL instructions are all slightly different in their operation ...



the most confusion occurs when going from a floating point-type to an integer-type location ... or vice versa ... at other times, the operational differences don’t usually show up ... mountain out of a molehill? ... maybe when we’re just poking around on the forum ... but when you’re trying to debug a program with these types of issues, little nuggets of knowledge like this can become very important ...