Please educate me on the proper usage of DIFU/DIFD.

[Van 0]

Equipment: CJ1M-CPU12 I have mentioned before that I am a PC programmer learning how to program PLCs so please keep this in mind. I think like a PC programmer. I read about DIFU (and DIFD) and thought this was the neatest tool. So, I used it all over my programs. However, I starting to think this is also part of my problem. I suspect DIFU is a two-edged sword. My program behaves irrationally. It sometimes works and sometimes doesn't. I can't figure it out. I am using the DIFU for the same bit in multiple rungs of a task and in multiple tasks. I suspect this might be my problem. I just realized that, although only one task/rung may execute the DIFU instruction on the bit - I don't know when the bit truly gets set and reset. Is the bit reset when the same DIFU that flipped the bit is encountered on the next scan? Or is the bit reset on the very next encounter of a DIFU instruction? Or is the bit reset at the very end of the current scan or the beginning of the next scan? Am I guaranteed that the bit will survive a complete scan before it's reset (i.e. every rung of every task will have access to the high signal?)? If so, then What is a complete scan to DIFU? Also, does it matter where DIFU you is in the program? Can I DIFU on TASK 30 and TASK 2 still get the signal? Here is an example of logic in pseudo code: BEGIN SCAN **** TASK A **** RUNG 1: if BIT-AA then DO STUFF RUNG 2: if BIT-A then DIFU BIT-ZZ **** TASK A **** **** TASK B **** RUNG 1: if BIT-BA then DO STUFF RUNG 2: if BIT-B then DIFU BIT-ZZ RUNG 3: if BIT-BB then DIFU BIT-AA **** TASK B **** **** TASK ZZ **** RUNG 1: IF BIT-ZZ then DO STUFF RUNG 2: IF BIT-ZA then DIFU BIT-AA RUNG 3: IF BIT-ZB then DIFU BIT-BA **** TASK ZZ **** END SCAN Is the above logic valid for DIFU? I suspect that there is something wrong with my logic here.

[Andy_P 7]

If a task only executes for one scan then I am pretty sure this will mess up any DIFU or other edge trigger instructions that occur within it for that matter, as it needs to see the next cycle to turn the bit off. If tasks that have the same bit DIFU'ed run consecutively, then I am pretty sure that this will mess up the state of your bit too. In my opinion, it would be better to have all your DIFU instructions act upon individual bits, otherwise you have an output duplication problem. A DIFU instruction sets the bit on which it is applied to true for one cycle of the PLC scan, when the input logic to it is true. To re-DIFU the bit, the input logic must become false first, and then back to true again. I know what you mean about being a PC versus a PLC programmer. It is a totally different kettle of fish!

[scottmurphy 1]

A DIFx instruction is a 1-shot, this is very common in the PLC world. In omron, there are many different implementations, have a look here http://forums.mrplc.com/index.php?showtopic=11451&hl= This should explain the different methods. As Andy_P pointed out, if your task is only executing once, then there is not really a need for a 1-shot. A 1-shot will only be true for 1 PLC scan, if the prevaling condition is still true on the next scan, then the instruction associated with the 1-shot will be false.

[Van 0]

I would like to better understand the above statement: BEGIN SCAN ONE *** TASK A *** RUNG 1: IF AA then Do Stuff (<---- AA False) RUNG 2: Do Stuff *** TASK A *** *** TASK B *** RUNG 1: IF BB then DIFU AA (<--- BB is TRUE this scan so AA goes from False to True) RUNG 2: Do Stuff *** TASK B *** *** TASK C *** RUNG 1: IF AA then Do Stuff (<---- Is AA True of False?) RUNG 2: Do Stuff *** TASK C *** END SCAN ONE BEGIN SCAN TWO *** TASK A *** RUNG 1: IF AA then Do Stuff (<---- Is AA True or False?) RUNG 2: Do Stuff *** TASK A *** *** TASK B *** RUNG 1: IF BB then DIFU AA (<--- Is this where AA is reset to false again? (BB is FALSE this scan) ) RUNG 2: Do Stuff *** TASK B *** *** TASK C *** RUNG 1: IF AA then Do Stuff (<---- Is AA True or False?) RUNG 2: Do Stuff *** TASK C *** END SCAN TWO

[scottmurphy 1]

I guess I'm not that good at explaining things in writing. Try googling 1-shot. http://www.plcer.net/Program/2007One_shots...rograms_46.html http://www.plcs.net/chapters/oneshot18.htm These are both the same page, one has the animation of what happens in the 1-shot scenario. How do you implement something to be executed only once in PC programming?

[Van 0]

It's up to the programmer. The programmer can do it: 1) at the top of every loop (scan) 2) at the bottom of every loop (scan) 3) at the next pass of the function/command/method that is responsible for the bit. Could be in the middle of the loop. This is why I ask the question: At what point does the signal actually rise and fall. If I DIFU a bit in the middle of the curent scan, is the bit ON for the rest of the current scan or, does he bit remain off until the start of the NEXT scan?

[Andy_P 7]

To be honest, I think this explanation from Scott is a pretty good one: To try and put my own spin on it: A bit that is DIFU'ed will be set to true once the preceeding logic is true, and it will stay in this state for 1 PLC cycle. If, on the next cycle, the preceeding logic is still true, the DIFU'ed bit will be set to false. I think the key to all this is understanding the concept of a PLC cycle. At the risk of confusing things further... Where you have written the code snippets like this: *** TASK B *** RUNG 1: IF BB then DIFU AA RUNG 2: Do Stuff *** TASK B *** Are you expecting that the 'Do Stuff'' code in rung 2 will be executed only when there is a DIFU of bit AA? This will not happen unless there is a condition of 'AA' in there. Otherwise, it will always execute. I hope I haven't muddied the waters still further. Andy.

[Andy_P 7]

Yes, the bit comes on immediately, wherever he DIFU instruction is. It stays on until the end of that cycle, and right the way around the following cycle until the DIFU instruction is encountered again, at which point the bit turns off if the logic preceeding the DIFU is still true. Andy.

[Van 0]

A big thanks to everyone for their help. I wrote a test application and used the PLC simulator (CXL-Programmer 7.2) to try and understand just what was actually happening. I didn't just want to know WHAT DIFU does but HOW it actually worked. My suspicions were correct. Using Multiple DIFUs for the same memory address is detrimental. Although it doesn't say it in the manual, in reality you should only use DIFU once per memory address. This may be common knowledge to you PLC folk. Attached are two little application I wrote. DIFU_TEST_GOOD - shows a typical application using a DIFUs with each having it's own memory address. DIFU_TEST_BAD - shows an application using two DIFUs using the same memory location (W0.00). Note RUNG 2. If you run DIFU_TEST_BAD in the simulator the PLC simulator behaves unpredictably (exactly what is happening in my real PLC). I noticed a couple of scenarios happening: 1) Stepping through the code (SET W0.00 ON) you will notice that in just the same scan DIFU will change states twice. If W0.00 is ON, W0.01 will go ON in RUNG 1 however, in RUNG 2 if W0.02 is OFF, W0.01 will go OFF. 2) OR; Stepping through the code (SET W0.00 ON) you will notice that the DIFU in RUNG 1 does nothing to W0.01. If in RUNG 2: 2A) W0.02 is ON, W0.01 will go ON. 2B) W0.02 is OFF, W0.01 will stay OFF. It would appear that a DIFU instruction is always evaluated at every occurrence irregardless of the logic in front of the instruction. In other words, every DIFU instruction is processed using some logic similar to the following: IF DIFU = TRUE THEN DIFU = FALSE ELSE IF LOGIC=TRUE THEN DIFU = TRUE Also note. The DIFU'd bit changes state at a every scan. For a DIFU, a scan appears to be a loop FROM the DIFU location back to the DIFU. Again, that may be common knowledge to you PLC folk but in the PLC programmers manual I read, a scan was defined to be from TOP of PLC code to BOTTOM of PLC code. That made it confusing to me. DIFU_TEST_BAD.cxp DIFU_TEST_GOOD.cxp Edited 6 Jul 2008 by Van

[Andy_P 7]

I guess it is somewhat confusing to somebody fresh to the world of PLC's as the principles involved are a bit different from programming PC's with VB, C++, C# etc. On a slightly different subject, although still relevant to the idea of a PLC scan: Suppose you have a physical output that controls a lamp, relay etc. If you turn this output bit on and off a thousand times from with your program, this does not mean you will see your lamp turn on and off a thousand times. The lamp will be set to the state that the bit is in at the end of the PLC cycle. A similar process occurs for inputs. If you have a switch connected to an input, then the bit it addresses is scanned at the start of the PLC cycle, and the status of this bit is used throughout the cycle. If you somehow managed to flick the switch a thousand times during the cycle, the status of the bit in your program will not change. (At least not with regular inputs and regular programming, but let's not get into that right now!) This is worth knowing, because it means that if an input signal duration is quicker, or indeed the same length as the PLC cycle time, it is very likely that the signal will be missed. I believe that a good rule of thumb is that the signal duration of a regular input should be at least twice the length of the PLC cycle time, to ensure that it is not missed. This includes both the on time and off time of the signal. Hope that helps! Andy.