JRoss

Yes it can, but you need an adapter.

Unfortunately, I have only used that module for temperature inputs, not control, do I can't really help other than to point you to the manuals, which you already have done. Do you have a local distributor?

Tim is trying to convey that going online makes the PLC scan time longer. His thinking is that the divert is dependent on the timing of the communications, and that the scan time of the PLC is on the edge of being too fast, which might throw the timing off. Going online slows the PLC down enough to resolve the issue. I've seen this sort of thing before, so I agree it's pretty likely. Ideally you can figure out what the timing issue is and correct it properly.

Which main PLC are you using? How many expansion modules do you have? The first argument in the TO/FROM instructions is the backplane address of the module. If you are using an FX3, the first Special Function Module (SFM) is address 0, the next is 1, and so on. An SFM is any module that isn't a digital I/O module, so you would skip those. If you are using the FX5U, then you will have an adapter between the main PLC and any older-style SFM like the one you are using. This throws the addressing off, and I'd have to look up how to handle that.

Tell us more about the control software. What is it? How does it work? How do you know it isn't communicating?

What you are showing is 2, 3, and 4 wire configuration for a Pt100 RTD temperature sensor. This gives a millivolt signal that needs either a converter to change the signal to 4-20mA, or a special input card on the PLC. I haven't dug into the different wiring configurations on RTDs, as I mostly work with thermocouples. There are also 2, 3, and 4 wire configurations of 4-20mA devices also. In this case, 2-wire means that the devices receives it's power from the loop. You supply 24V on one wire and receive the current signal on the other. Unless your analog input card does it for you, you need to inject 24V into the loop. Newer Siemens cards have this capability. With 3-wire devices, you supply power separately to the device. One wire for supply power, one for common, one for signal. 4-wire is the same, except that the supply and signal commons are separated. In my experience, 4-wire are much more common than 3-wire.

I have used the SC-09 cables from www.plccable.com for the last 8 years or so and never had an issue. I mostly use the cheaper version without a dedicated RS422/RS232 converter, but I also have one of the full versions, and it works just as well. I think most other cheap knockoffs do not have the dedicated converter, and so the quality of the components can make a big difference in how well it works.

  + - addition instruction Z0 - index register K1 - integer constant of "1" D100 - data register Adds together the value in Z0 and the constant 1, and puts the result in D100

Sounds good to me. It should save much headache.

I was focused on the motion networks and didn't think of this previously, but  there are generic pulse and direction and analog motion cards for the ControlLogix that use the integrated motion controller and instructions. These would work with a variety of 3rd party products, though you wouldn't have access to much feedback data from the servo drive. 1756-M02AE 1756-M02AS 1756-M08SEG

In my case all the sensors etc. were fixed at the appropriate station. The dial didn't have anything except a series of metal flags that triggered a single position to indicate the dial was in position. You can use a variation on the array and word shift to track which nest is at which station. Or you could go even simpler and just increment a counter with each index and reset the counter when it gets to 3. Then use that to know which orientation the dial is in. Of course, you'll need a procedure to "home" the dial in case it gets out of sync. If I were you I'd consider adding something to external to track the dial position. One idea is a single turn absolute encoder. Or since you only have three positions, use three in position sensors, one at each station, with one flag on the dial. Then based on which sensor is made you know the orientation of the dial, and therefore which nest is wear. Either method would ensure you won't get out of sync.

Unhook the wire from the output contact and see if there is still voltage on the contact. If so, then the output has failed.

I recently helped program a similar system, though with more stations. I wrote a sequence for each station, with the end of the sequence turning on a bit that indicated the sequence was complete. The sequence would not reset and run again until the dial indexed. The dial itself didn't need a full sequence, but had a similar principle. I would wait until every station was complete, then start the dial index. When the index was complete, this would restart all the station sequences. For status tracking, I used an array of integers, where each position in the array corresponded with a station (Status[1] for station 1, Status[2] for station 2, etc.). The integer value indicated status in each station (0-empty, 1-good, 2-failed, etc.). The sequence code for each station would interact with the status value for that station. Skip actions if part failed or not present. Set status to failed if torque not met, etc. Then whenever the dial indexed, I would use a word shift instruction to shift all the array values so the status would move with the part from station to station.

There are 3rd party drives that can be commanded over Ethernet/IP, but not with the Logix instruction set. They typically have their own set of Add-On Instructions (AOI) that are usually pretty similar. I have used Koll-Morgen and LinMot, and I think Mitsubishi has them now. I'm sure there are others. CAUTION! These products do not use the high-speed motion layer of Ethernet/IP that Logix uses with their motion instruction, so it is not appropriate for synchronized motion or very high-speed applications unless there is a way to do it on the drive level. The application I did with Koll-Morgen was a fairly high-speed packaging system, and for the most part worked well, but we had to use a couple of tricks with digital I/O for one of the axes to get the repeatability we needed.