C_Arlotte91

Hello, Just as an update if anyone is looking, The above checks fine, I've placed counters on each of the bits around the run ( one on the latch, one on the input, one on the equals value) These show that the equal is working fine even though the display shows strange. The input it self however seems to pulse several times at random intervals after this, so we can have a count of 1 after equals - 1 on the coil that latchs and 13 on the input.. this however when the older software is put back in shows as 1-1-0 as it should for a reject and 1-1-1 for goodware.  Has anyone had it where an input is malfunctioning after a software download and reverts back good afterwards?

Hello Michael,  Thankyou for your reply, The post you put there exactly shows what is happening, I shall have a look through this morning and test the suggestions.

Hello All wondering if you can help? I've got two programs at work, One is the standard verified and working correctly however the other which I have now added additional data points of counters and data points for collecting some OEE, however the original program works fine, I've found in the additional somehow the CF006 bit of Equals is always on? I've checked through/done the following and i'm getting stuck along with some co workers as to how to progress to get this fixed as it is causing rejects to become good ware on the machine. The ZCP function is used on this machine to ensure what is needed to happen at various stations happens when the Encoder provides a certain CAM angle. (this has not been modified in any way) - I've tried adjusting manually the value. - The extra code added has no ZCP or compare functions added. - No additional CF instances have been used. (the checks are all the same as original) - The extra counters/Data points have all been zeroed just in case of overlap somehow. (not appearing to be the case) - Running machine in Auto, Cycle or Inch mode (normally is fine) - When you inch really slowly (1degree at a time) this is when the issue occurs? - Checked old code and this holds fine as it should. - Simulating the code, it runs fine. on the machine it acts differently straight away?   I'm sorting of getting stuck and the only thing that makes sense is that the value is being written as a 1 somewhere/somehow, the help suggests that possibly the flag will stay on when arithmetic functions are placed in between (this is not the case anywhere also has not been modified in any way since the original working program.