Here is a brand new problem dumped on me.

We have a large gantry crane that freezes up under certain conditions in a program run off a slc 5/04 with about thirty I/o modules. I have the proble pegged down to three different outputs on card #25. I even have a snapshot of what is true and not true when the fault occurs.

Is there a way to get the same snapshot of the logic when it is running in a normal mode at a certain instant in the code. Saving takes a few seconds and by that time the conditions would change. I guess I am looking for some sort of debug mode where I could tell it to save after a certain rung is energized or a certain condition comes true. Is this possible?

Thanks.

Sure, the best way is to add some debug logic that copies I/O and internal binary files to a scratch pad space. That allows you to go in later and look at the state of all of the rungs.

That sounds like a great idea.. How would I go about doing that? any examples out there?



Thanks



Bill

this is one basic idea ...

sorry that I don't have time to properly document this ... but I'm sure that there are people here who can help if you have questions ...

PS note to former students ... this should look very familiar ... it's a scaled down version of page 10-34 ...

Thanks for the reply. I actually had a solution. I am exactly looking for the conditions of all the inputs when a particular output is true. I have about ten inputs for this particular rung. I was going to create about ten rungs underneath the culprit rung and put one Input on a run causing an integer address to go to 1 when true. Then on the last rung have a "one shot" that will copy that integer file to a different rung when the output file becomes true. I will then have a snapshot of what was true and what was not when that input came on.

In your example, I don't really understand how that works. Could you explain a little bit more?

Thanks.

Bill

sorry I’m pressed for time ... there might be some typographical errors in this post ... I’m sure that someone can help straighten things out if I’ve made a mess ...



you can substitute any condition for B3/0 ... if you want to record the states when the condition goes OFF (rather than when it comes ON), then substitute an XIO instead of an XIC ...



when B3/0 comes ON, we MOVe the contents of all 16 bits of word I:2.0 into a storage location ... the storage location will be somewhere in file N17 ... the precise storage word within file N17 will be defined by the “indirect address” of the MOV’s “Destination” ... in the rung shown above, N7:0 currently contains the value “4” ... the address of the MOV’s Destination is entered as “N17:[N7:0]” ... the square brackets “[]” indicate a “pointer” ... the pointer in this case is N7:0 ... so the current address of the MOV’s destination is “N17:[4]” ... in simplest terms, the indirect address substitutes the value stored in the “pointer” for the part of the address which is enclosed in square brackets ...



nailing it all down ... the next time B3/0 comes ON, the ON/OFF pattern of all 16 bits of I:2.0 will be recorded into N17:4 ...



now ... after it stores the information, the processor next ADDs a 1 to the value of the pointer ... specifically, the value of N7:0 will now be increased from “4” to “5” ... this “re-aims” the MOV to the next available location in file N17 ... specifically, the target of the MOV the NEXT TIME that B3/0 comes on will be N17:5 ...



and so it goes ... this one little rung will faithfully record the status of 16 input bits for the first 100 times that B3/0 comes ON ...



as for the LES ... suppose that the indirect address tries to tell the MOV to store the information in a location which does not actually exist ... that will cause the processor to fault and shut down the whole darned system ... in my program I set aside 100 locations to hold the stored data ... specifically, N17:0 through and including N17:99 are available ... but suppose that B3/0 is having a bad day ... suppose that B3/0 comes on 101 times ... oops! ... that last time would tell the MOV to store data in a location (N17:100) that does not actually exist in the processor’s memory ... all of a sudden we have a fault! ... so ... that’s what the LES is for ... if the value in the pointer (N7:0) gets too high, then the LES will just stop the rung from collecting any more data ...



finally, try this out and then look at the values in the N17 file ... set the window’s radix to “binary” and you’ll be able to scroll down through the file ... you’ll be able to see exactly which bits in I:2.0 were ON and exactly which bits were OFF each time that B3/0 came on ... at least for the last 100 times ...

Thank you Ron, That is an excellent description of indirect addressing. I have been scouring the board for just such a description.