I cant figure this out clx Input dropping out

[Ken Roach]

I think rdrast has the best advice:

Cross reference on I4[0], see if anything destructive comes up.

It looks like there is some template logic that was intended to iterate through some DeviceNet connection diagnostics that instead gets information from the Discrete Input modules that are in the local rack. If it also writes to I4[x] at some point, that would explain why you are getting "inputs" that appear to change state, when in fact it's the buffer target being written to by multiple sources.

 

[Jinto]

Yes you're right, I didn't think that through.

 

[kf5pv]

Well besides the DNET MOV that is never true because the scanner resides in slot 2 always, I dont see anything for DNET that writes to the other slots. However there are some destructive tags on the cross reference for I4[0]8. one of them is a FLL instruction that should be for the first scan only so I think something may be happening with this. I have included an attachment of it and will follow through with this to see what may be happening. I also moved my timer trap to the top of the routine and I am still not getting any data in my trap but still getting counts on my counters further down in the routine. One more thing; Should I see counts on a counter for the physical input (local:4:1.data.8) also if I am really not loosing my input or would it also clear that file with the FLL instruction? Thanks for all the help guys. now I have some good direction to go on. 98% of the people on here have far more experience on here than I do and this has to be some of the hardest code I have ever seen.

 

[Jinto]

I apologise for misleading you with the moving of the timer trap, as PLCMentor pointed out, this will not work as the timer accumulator will not be evaluated until the timer instruction is reached on a true rung. Basically to get a value in the accumulator the timer must be true for two consecutive scans. If the bit is only off for one scan you will not get a value in the timer accumulator even if it was a periodic task only running every second.
The logic you have posted looks ok and should only be running on the first scan but you mentioned other instances of destructive logic, can you post those.
Yes you could do a similar trap using the real input which would confirm that you not really losing it but my guess would be that there is some destructive logic clearing your data for one scan.

 

[kf5pv]

Yes you could do a similar trap using the real input which would confirm that you not really losing it but my guess would be that there is some destructive logic clearing your data for one scan.

I did put in a counter off of the input and not the array word and am also getting counts. That will be the first attachment. the other two are of some destructive logic code that frankly I dont understand what they are doing. The programs on these machines are very bloated. not to say its bad code, Just beyond my scope of CLX.
I guess If I have to I can put everthing back in series and put it on an input that I have not seen this happen to yet. I just hate to not fix the problem and just work around it.
Keep in mind I have the same thing happening in slot 10 and the the 24vdc is from the same power source. however, if I lost that source I SHOULD have counts on 12 other counters that I have installed unless the power loss is for such short amount of time. I really dont think this is the case though because it is happening 90% of the time on an input in slot 4 and 10% of the time on an input in slot 10. I am also using 12 other inputs in slot 10 That do not go false and are from the same power source. I do have a counter off of the actual input (not the array word) for the one in slot 10 now so I will watch it and see if it gets any counts on it or not. Oh and no problem with the timer.I just through it up at the top just to see. I really just want this issue gone. I have even thought about using the delay in the card in the I/O config.