Cant toggle bit or force in Studio 5000

[MattMatt9]

We have PLCs on the line and I am using Logix Emulate. No matter which one I am connected to I can not toggle or force anything.

 

[RAYBRITO]

I'm not familiar with logix emulate, but check if the key on your PLC's is on "REM" then try to force/toggle:beer:

 

[I_Automation]

As long as you are online you should be able to toggle a bit, even if the PLC is in Program mode. If something else in the program is turning the bit off then it will seem to not be toggling on. (But only when running)



Forcing only works in Run or RemRun - and you can only force inputs and outputs. But, if you are monitoring the program online the status shown will be as per the program.


IE - an output is forced ON. Watching online the logic may have the output OFF, and if the output is checked elsewhere in the program it will be seen as OFF, but the physical output will be told to turn ON.


If, say a flow control valve, is forced ON and the program checks to see if it is ON to do something else relying on that valve open, the other thing(s) will not see the valve being held open in the logic.

 

[MattMatt9]

I couldnt toggle or force any input/ouput, but I can toggle or force a memory bit.

 

[Bob O]

"We have PLCs on the line and I am using Logix Emulate."

I don't understand the above.

 

[MattMatt9]

Sorry what I meant is we have actual PLCs running on the line with code that I couldnt toggle the bits, AND as practice I also created a project in Emulate and its the same thing. That is what I meant.

 

[I_Automation]

in the upper left of Studio5000, under RUN, look for 2 Force tabs.


Set each one to Forces Enabled. If these are off it will not let forces work.

 

[MattMatt9]

Thank you. What about toggling though? That worked for forces?

 

[I_Automation]

Create a new rung in online edit.

A XIC and create a new tag, then some junk output (MOV 0 UselessTag), OTE UselessBit), etc

This being the only use of this tag you should be able to toggle it.

If it does toggle then the other bits are being turned right back off.

If it does not toggle then something else is happening. Are the other bits and values being updated while online?

 

[bornwild]

Cross refrence the bits you are toggling , and check if these are used elsewhere. If yes, your toggle wont work because you plc will reset to bit to false .

 

[Operaghost]

I think there is a misunderstanding about what toggling actually does in regard to inputs and outputs. Toggling simply changes the bit in memory. If it is a 1 it makes it a 0. If it is a 0 then it makes it a 1. I'm guessing you understand that. But lets dig a bit deeper.

Inputs
Lets say you have a limit switch in the field with N.O. contacts and the switch is open. Since the contacts are open, the input module is not seeing a signal from the field device so it stores a 0 internally and then transmits that to the controller at a regular timed interval called the RPI. It is then stored in a controller tag. Open contact, 0 in the module, 0 in the tag.

If you toggle that bit, you are toggling the controller tag to a 1. So now you have an open contact, 0 in the input module, 1 in the tag. But the next interval of the RPI (usually 5ms) the input module will re-transmit the 0 and overwrite the bit you have toggled. So your toggle was present, but the input module overwrote it. Toggling a limit switch doesn't actually close the contacts on that field device. The PLC will use the data we are getting from that field device. Unless you can repeatedly toggle faster than the RPI.

Outputs
When you toggle an output bit you run into a similar issue, but this time it is the logic that would overwrite your toggle. If my logic is false then my output bit would be turned off (using an OTE). Every scan of the logic it keeps turning that bit off. If I toggle the bit and turn it on, it will turn on but only until the next time that rung is scanned, then because my rung is still logically false, it will be turned back off by my logic. So at most I will get one scan where it was on.

Toggling has no priority so toggled bits get overwritten by everything. That is where forcing come in. Forcing has priority. Toggling also happens mid-scan. So you might toggle a bit and see nothing happen. You might do that 8 times with nothing happening, then the ninth time it triggers what you wanted.

And Emulate versus a real PLC doesn't really matter except that in an emulator you cannot read from I/O modules. If your PLC program has I/O modules, they need to be inhibited otherwise they will appear as faulted and won't function.

OG

 

[JaxGTO]

I believe even in Emulator you have to disable an input card (on the Connections tab) to be able to set/reset input bits or analog values.

 

[daba]

I couldnt toggle or force any input/ouput, but I can toggle or force a memory bit.

You cannot force internal memory bits - only I/O bits.

 

[Bit_Bucket_07]

You cannot force internal memory bits - only I/O bits.

That's standard among various PLCs, but I've noticed that forces in CLX PLCs aren't even reflected within the program logic. For instance, if you force an output on, an HMI will still see the output tag's status as "0", although the output point on the IO module will be in an on state.

 

[Ron Beaufort]

For instance, if you force an output on, an HMI will still see the output tag's status as "0"

this is one of the MAIN stumbling blocks for technicians who habitually use FORCES while trying to troubleshoot a system ... suppose that their line of reasoning is something along these lines:

OK ... we've forced the lamp/pump/valve/etc. to be ON in the field – so that means that the rest of the logic SHOULD respond to that ON status ...

if they haven't had quite enough training along these lines, then they fail to realize that their reasoning is being misled – simply because there is STILL a ZERO in the output's bit/box – even though the output in the field (the actual device) is being turned ON ...

in simplest terms – the PLC's logic will NOT respond to the forced status of the output bit/box as expected – which can lead to a time and money extensive "chase of the wild goose" ...

on the other hand, when you force an INPUT, the forced status (either ONE or ZERO) will (generally) be reflected in the rest of the program's logic ... this can be very confusing to bleary eyes at 3:00 in the morning – and the machinery is down ...

takeaway: INPUTS and OUTPUTS behave differently when they are forced ...

for those who want more details – start here ...

http://www.plctalk.net/qanda/showthread.php?p=537414&postcount=1

and skip ahead to paragraphs 38 through 43 for a quick start ...

party on ...