But since it has the attribute of being LOW, we have to AssUMe that it will do the opposite for the ladder input representation. Am I right with my ASSumptions? lol
In addition to the LOW and HIGH designations on you I/O list, I also observed the indicator lights on each sensor. When the ones marked LOW were not seeing anything (no object in front of the switch), the indicator was ON, which I think means that the sensor (digital not analog) output contact was CLOSED (allowing the built-in indicator light to turn ON). When these same sensors were tripped by a part, the light would go OFF, I think indicating that the sensor output was then LOW or OFF or OPEN or a binary "0". Go back and look at that video and let me know if you see the same thing. I am an old guy and sometimes get confused.
Can you explain me the major differences between the FIFO logic you've used in Rev.1 and this Indexed Addressing for the Rev.2 ?
I can only try to explain the differences. The basic difference is in the instructions used.
Method 1 uses the FFL (FIFO Load) and FFU (FIFO Unload) instructions. These instructions have built-in capabilities to keep up with the Number of objects, and also the Order of these objects. Then you can use the FFL to insert new objects as they occur, which advances the FIFO position indicator for each object. When you get rid of an object (rejected in this case), you trigger the FFU, which pushes the data for that object to the FFU Destination address. See the RSLogix Help file (click "Help, SLC Instruction Help, then select your instruction neumonic) to find the details for each instruction.
Method 2 uses Up and Down Counters and Indexed Addressing (because your MicroLogix does not have the capability for the easier Indirect Addressing). To use the Indexed Addressing method, you load an "offset" (a number to be added to a base address) to memory location S:24. Then when you use an Indexed adddress designation (put a "#" in front of an address, RSLogix automatically adds the value of S:24 to that address. In this way, you can in effect have a variable address that changes as needed for the process. So we can use the CTU and CTD to keep up with how many parts have passed IP4 but have not yet arrived at IP5. I figure that you could potentially have 3 or 4 parts, maybe even 5. If there are more than that, you should increase the Counter Presets to whatever the number of parts could possibly be between those points. Now that we have a way to count or index the number of parts, for each new part, we save the part condition (0 = good, 1 = reject, but you could use any numbers from 0 to 32767) to the B3:1 memory word by using Indexed Addressing and the Counter Accumulator value as the index value. This may be how the authors wanted you to do this task, since they did mention "index" in their description.
As Forest Gump said, "That is all I have to say about that right now".