Joe E.

You will need a managed switch to automatically assign the IP address to the drive. You will also need strong controls in place to make sure that the right device is plugged into the right port of the managed switch. If someone gets the patch cables swapped, you will have bad things happen.

In version 30, you can set it to store the comments and such inside the processor (controller properties, "project" tab, "Download Project Documentation and Extended Properties"). The last time I was online at the same time as another engineer, the symbols and comments stayed synchronized between us. We were also at v30. Here's some of the help file for that setting:  

I was hoping Ken would chime in here. I managed to use the ActiveX control to log data to a USB flash drive, but it didn't take long for the flash drive to end up corrupted. At first, I used internal memory, but it filled up too fast. To get it to work the best, we would probably have to set up a ftp server that the HMI can get to and log to. That would eliminate a lot of the issues we saw.

Sorry for the delay, we've had major power outage issues here that took out an old drive that we have to replace. The first on (4351890A) has comments, the second one (4351890A_28_10_06) does not. These programs use a SLC 5/04, which requires a licensed version of RSLogix 500. We're using the "standard" version. I also attached a printout of the compare tool's report showing the differences between the files. 4351890A_28_10_06.pdf 4351890A.pdf 4351890A_CompareResults.pdf

The 1756-EN2TR module is a different platform (ControlLogix) than your L24. Most of their devices I've seen that have 2 ports are for Device Level Ring (DLR) or linear configuration. If DLR is configured correctly, you would have a loop of patch cables and devices. The idea is that any one of the devices can fail or be powered off and all the others will keep talking. Frankly, in my experience with the equipment I've worked on, if any one device fails the whole system can't run anyway, so I've never implemented DLR. I have, however, used the dual ports to daisy-chain connections (linear topology). It's a convenient way to reduce the size (and maybe quantity) of network switches in the system. The 1769-AENTR has 2 ports. It looks like it's intended solely for the DLR/linear network topology. There is a newer CompactLogix family that has dual ports that can be configured separately with different IP addresses so they can connect to different subnets (like a local machine network and a company network). At first glance, it doesn't look like this -AENTR can do that.

Here you go. The "...Anew" file doesn't have symbols or comments. 4351890B.pdf 4351890Anew.pdf

I've never used high speed counter modules either, but I think there's a way to set up a hardware interrupt so that the high speed counter module can break into the PLC scan when it needs to. I don't know how to set that up or if the windows can be set up in the module or not. It's worth investigating, though. Failing that, it may be possible to use a different PLC that supports motion control commands. A quick look in Proposal Works shows the -L18ERM-BB1B that supports CIP motion and 1734 I/O, but it has less memory (512KB instead of 1MB).

I don't know how helpful it will be, but there is a Tech note that talks about CodeMeter stopping (access level: Everyone): https://rockwellautomation.custhelp.com/app/answers/detail/a_id/1068583  

With a quick glance at the information on Phoenix Contact's website, that device does not communicate with any controller. It's just a "connection extender". Check this link: https://www.phoenixcontact.com/online/portal/us?uri=pxc-oc-itemdetail:pid=1452916&library=usen&tab=1&requestType=product&productId=1452916&productDetection=true&redirectTarget=country&redirectTo=US Each sub-connector's pin 3 is tied to 0V, pin 5 to ground, and pin 1 to "UN" (the "hot" connection). Their pins 2 and 4 are broken out at the main connector. This device will NOT be in the I/O tree. You would instead supply it with power (either from the PLC if it has enough or from an external source), then connect the wires from the device to individual input points on the PLC. It's a wiring convenience device, not an I/O device.

If you've ever had to scroll through a few hundred rungs of code to find what you're looking for, you'll understand the value of subroutines for organization. We have 3 production lines that bond steel and aluminum strip. The first two are well-divided into subroutines that are meaningfully named according to specific pieces of equipment on the line. The 3rd is subdivided but not as much or as well. Most of the code is in LAD 2 (it's a PLC-5). It's really a pain to find what you're looking for, especially if you don't know ahead of time how the programmer commented things so you can search for it. I've been here long enough that I know a few search terms to use to find what I'm looking for, but someone who hasn't seen the machine before will be in for a tough time. On our bonding lines, there is code that tracks defects in the strip that was written by a contractor. He used a LOT of conditional subroutines and nested loops. When it works, it works, but occasionally it glitches and freezes up. Because of the conditional subroutines and nested loops, it's been impossible to find the problem. I once spent 2 days straight mapping out the subroutine calls and loops, trying to at least figure out the program flow, but still couldn't isolate the problem. If you value your time, and the time of the people who are on-call after hours, sacrifice the "ideal" efficiency of the code to make it easier to troubleshoot. Those few milliseconds you save don't really matter when the line goes down and it's not making product while your technicians are trying to figure it out. Write code defensively, to avoid 2AM phone calls when something weird happens and the technician sees the spaghetti logic and gets stuck. Even if the spaghetti logic is completely unrelated to the problem, your phone will still be ringing.

We've used Red Lion Kadet and G3, TCP/Proface/QuickPanel, Siemens MPxxx/Comfort, Panelview Standard and Plus HMIs. Of them all, the ones we've had to replace the least were the PanelView Pluses. The ones we've replaced the most are the Siemens MP277s. The TCP/Proface/QuickPanels and PV Standards are ancient, so it's probably not fair to compare them to the others. We have had some weird failures and glitches with the Red Lion G3s. I would rather program a Red Lion G3 over a PV+, but their prices are closer together than when we started using them, so they're harder to justify based on the glitches.

I would move the pump control OTE instructions to the main routine or a subroutine that's unconditionally run. Each other subroutine would have an "output bit" that turns on when it wants the pump to run. The "output bits" would then be paralleled to control the pump's main OTE. Put a conditional branch for each subroutine's "output bit" so that IF Subroutine1 is active AND Subroutine1's "output bit" is on, THEN run the pump. Repeat for the other subroutines. Edited to add: You need to make sure that the subroutine runs at least one scan before allowing it to control the pump, otherwise the pump's OTE could be on for a scan, which would cause problems. For all those reasons, I tend to NOT use conditional subroutines except in very rare situations and generally for functions that can complete in one scan of the subroutine. In my experience, conditional subroutines are an effective way to get 2AM phone calls...

Are the auxiliaries all controlled by the main PLC as I/O devices or are they independent PLCs? If they're independent PLCs, do they communicate with the main PLC over Ethernet/IP? If the main PLC has the auxiliary machines in its I/O tree (whether as I/O devices or as other PLCs it's talking to), you can use a GSV instruction to check the "connected" status of that device. The return value is a number that explains the status of the module connection. It's shown here in decimal, but the help file explains the results in HEX: In this example, 24576d = 6000h, which means that module is inhibited (the drive isn't actually installed yet in this system). If it were connected and running, it would be 16384d = 4000h.  

If we have an engineer or two who need training, we will probably send them to off-site training. When we wanted to train our electricians, we brought the trainer to the facility. The first time around (for Siemens PLCs), we brought in Siemens with their trainer and hardware. The second time around (for Rockwell), we brought in a local guy with a LOT of experience to train our guys. We had one of the electricians build trainers using spare hardware of the different platforms and used our laptops. So...bottom line...yes, it would be useful. And actually preferred to bring in someone local who knows what they're doing and is more likely to be able to customize the training to match our systems.

I looked at your program.  Open the data file I1. It will show you which input words are available. There are 4 words of inputs available at slot 0, 0.0-0.3. These should be the built-in inputs. The next input word is I:1.0, which is part of a 4-channel Thermocouple input module. Are you trying to get information out of the 1762-IT4?

We all have gotchas like that. Thank you for posting the resolution!

I found this in the drives integration manual: Edit to add: https://literature.rockwellautomation.com/idc/groups/literature/documents/in/2098-in005_-en-p.pdf Page 82

This may seem stupid...but... Try rebooting your PC and re-compiling the .mer file. I've had multiple glitches with stuff like this that were fixed with a simple reboot and recompile.

I ended up creating my own number pad that interacts with code in the PLC to blank out the entry. It took a bunch of work to get it right, but it does work. At each button push, it checks the existing number to make sure it won't exceed the max value for the register (I originally wrote it for a MicroLogix, so 32767 is the max it will take). I tried to make it self contained within the HMI using macros but I had a hard time making it work.

Sorry, I got caught up in work stuff and couldn't take a look yesterday. Today isn't looking good either.

If you have a spare 5000 PLC (you do, don't you?), set it up on your desk or workbench and "play" with it. Try porting over a PLC-5 program. One of the things I really like about the 5000 platform is that you can inhibit all of the I/O and the PLC will sit there happily running the program without any issues. You can then add an extra program to simulate the I/O. For instance, I've written code in the simulation program that will turn on an input a certain time after its associated output turns on. That way, I can test and validate the logic. You can also adjust the response time of the devices to see how a cylinder that's wearing out would affect the overall machine's operation and find a good way to interlock it with other components and develop alarm messages to notify the operator. If you don't have a spare PLC, you should definitely get one. At least one. With all of the parts and pieces it needs to operate on your bench (chassis, power supply, network module, etc.).  

I think I understand what you're trying to achieve. Based on what I see, if you see a part that is NOT an assembly, set the bit in the reject array. If it is, don't set the bit. Whether it's an assembly or not is determined solely by the status of IP3. So, if you see an item at IP4 without IP3 being on, set the reject bit. If I'm missing something or misunderstanding, I'm sorry. I have to leave now and will take another look in the morning.

Do you really care about the rings per se? As I understand it, you only care if it's an assembly or not. If it's an assembly (latch/seal for IP3 = 1), don't reject it. Otherwise, track it and reject it. For that purpose, IP8 is redundant. It doesn't give you any information you need, at least to solve this particular problem. However... In my experience, "they" will always want to know more than good/bad; they will want to track why it's bad. To do that, you could set up a tracking array for each defect (2 in this case). Use one array to track pegs (easy, IP4 = 1 while the latch/seal for IP8 = 1) and the other to track rings (harder but not too bad, IP4 = 1 while the latches/seals for IP3 and IP8 are both 0). Then you'd reject if either array has a "1" at the reject position and you could also accumulate a count of each type of reject. Both arrays would shift at the same time. If you get many more defect reasons, you probably won't want to stay with bit shifts but use word shifts, where you have an array of integers. Each integer represents a "position" while each bit within each integer represents a defect cause. Also: will there ever be more than one part between IP4 and the reject station? If so, will the number of parts ever change? If so, you will likely need some sort of FIFO arrangement instead of a bit shift array. That will be a problem for another day...  

Ok... With there being a lag between IP3/IP8 and IP4, that does complicate it somewhat but not unduly...as long as there's a gap between the parts. If there's sufficient gap between the parts, you can use a latch or seal-in to record IP3/IP8 when they come on. Generally, using a seal-in is preferred, but a latch will work. Then, when IP4 comes on, you check the status of the bits that IP3/IP8 set/sealed and make a decision at that point whether or not to set the bit in the shift array. So... In the instant that IP4 comes on...if IP3's latch/seal is OFF, the item is not an assembly, so you reject it. If IP3's latch/seal is ON, the part is an assembly so you don't reject it. In either case, you set the input bit status and shift the register, either when IP4 comes on or when it goes off. After you shift, you then clear the latches/seals from IP3/IP8 and you're ready for the next part. For just this purpose, where you're trying to reject everything except assemblies, you don't need IP8 at all. You just care that something's there (IP4) and it is/isn't an assembly (IP3). It may be useful at a later date to track pegs and rings separately, but that's beyond the scope of what you're asking here. My other question was merely curiosity about why there are two different instructions that appear to do the same thing: write 0 to a bit. In the AB world that I'm used to, the RES instruction is used to reset timers, counters, etc. while the U instruction unlatches a single bit.

Sorry, I can't look at a youtube video right now. I'm really not just ignoring it... Do IP3, IP4, and IP8 operate simultaneously? In other words, if an assembly passes by, do all 3 inputs turn on and off at the same time? If the 3 inputs are synchronized, try changing rung 11 so that it only turns on R1.15 when IP4 is on AND IP3 is off. Eliminate rung 12. Then shift the data. You may need to use the other state of IP4 to shift it properly. I see an RES instruction and a "U" instruction. Both seem to be used on individual memory bits. What is the difference between them?