Joe E.

Your existing structure shouldn't be affected; you would just add an intermediate step. Create a "holding" DB in both PLCs with the same structure that contains all of the DBs you want to send. Right before you send the DBs, you copy your local DBs to the "holding" DB, then send the "holding" DB. On the receiving end, you tell it to write the data to the local "holding" DB, then you copy it over to your local DBs. Or, create multiple connections. Based on my experience with Siemens processors, I have a feeling that combining them into a holding DB may be easier to follow later, but I could be wrong. Like I said, I've never done this. I don't know how big a deal it would be to have a bunch of BLKMOV FBs running versus having a connection for each DB.

I didn't study the link in detail, but it looks like the difference between TSEND and TSEND_C is that the _C instruction includes the TCON functionality to create a connection while the TSEND instruction does not. The TSEND_C instruction can exist on its own but TSEND needs either a TCON or TSEND_C instruction to precede it. The link explains that but doesn't provide a lot of details otherwise. If the TSEND/TSEND_C instructions can only send one DB at a time, can you combine the DBs you want to send into one? In other words, create a new DB with a structure that contains the DBs you want to send. I know you can (used to be able to...) declare a STRUCT inside a DB where the STRUCT's datatype is another DB. Maybe try that and have the FC/FB that calls the TSEND/TSEND_C instructions use Block Moves to copy the DBs you want to send into the new DB, then send it. Does that make sense? Alternatively, it looks like you can use multiple TSEND/TSEND_C instructions, each sending one DB at a time, until you've sent all of the DBs you need to send. Caveat: I'm at a new employer who doesn't use Siemens equipment, so I no longer have access to PLCs, TIA Portal, or Simatic Manager to tinker and test. The only time I've set up a data exchange between these PLCs, I used a Red Lion HMI as a gateway device. I've seen it done before over Profibus (a LONG time ago) but never set it up myself.

Good catch. One comment says "50msec" while the other says "100msec". Either way, it'll be too fast to see with the software. I would still expect to see the value of bit Q100.00 displayed the same throughout, though. Weird...

Hmmm... The simplest thing may be to just use Excel's RAND function to generate a series of random numbers to populate a look-up table in the PLC. Here's one idea, inspired by your desire for it to be random digits: https://www.geeksforgeeks.org/pseudo-random-number-generator-prng/ It was fairly straightforward to implement in Excel but I don't have a PLC on my desk any more to make sure it yields the exact same numbers. You'll have to do some manipulation (other than rounding/truncating) to make it always be 4 digits without leading zeros if that's important to you. You would also not be able to use the user administration that's built into the HMI. Do you have the source code for the Siemens HMI to take a look at how they did it? If you're using the runtime security functionality built into HMI, I don't know of a way to automatically change the password every day...but that doesn't mean it can't be done.

Not sure what platform it's emulating, but the NC of T0000 may be a problem, depending on what status of the timer it indicates (done, enabled, timing, etc.). If it means the timer is done timing, that looks like an off delay time function. The fact that Q100.00 looks like it's on in the output instruction of the first rung and off in input instructions is suspicious, like the simulation isn't properly running. Or the output is forced. Or something else...

At a previous employer, the password was the Julian date (day of the year) of the preceding Sunday. One of the 3rd shift maintenance guys would go around every Sunday morning and change the passwords. It wasn't reliable because sometimes he'd be too busy or he was out. I ended up automating it. Are you looking for an algorithm that you can implement in the PLC and in Excel so someone with access to the spreadsheet can look up the password? Or do you want the PLC to calculate the password and have it show up automatically in Excel? The first option won't be difficult if you keep the date & time updated in the PLCs. The second one will require a data connection to the PLC which won't be nearly as straightforward if you don't already have something like that in place.  

I didn't save the bookmark, but I downloaded a similar tool from Phoenix Contact that seemed to work better and more reliably than AB's BOOT/P. I used on Windows 7, though, not Win10. It's not at all unusual to have issues with BOOT/P. I usually use it in a virtual machine with a USB network adapter connected directly to the VM and all of the VM's other network adapters disabled and disconnected. That sometimes works...

As a client to do what? What exactly are you trying to accomplish?

If you're trying to roll your own from scratch without using their native protocols, you're way beyond anything I can suggest. I know the Ethernet/IP and CIP standards are handled by ODVA, but they're not free and they're going to be a big deal to implement properly. I *think* both AB and Siemens PLCs can be Modbus masters and the Modbus TCP standard is a lot more open (and less rigidly defined) than E/IP and Profinet. And that arrangement may not work for what you're doing (I've only been peripherally involved with a Modbus system and it didn't use Modbus to talk to the PLCs but to other auxiliary devices, so definitely don't take that to the bank).  

I don't know the protocol, but I know you can read/write any tags in the PLC. Are you wanting a PC to be able to control physical I/O directly? If so, this is likely not the most cost-efficient way to get I/O onto a PC.

If all you want to do is display the current status of the I/O, I would seriously consider using AdvancedHMI. It's a plug-in into Visual Studio. It's written in Visual Basic, but the library may work with C/C++ too. The software to create a PC-based HMI is free. I tested it once with a CompactLogix and it worked well. I installed the free version of Visual Studio and imported the AdvancedHMI solution per the instructions. After that, it took me less than 5 minutes to have a tag displayed on the PC.

At my previous location, I did the same thing...until IT updated our network and group policy settings. At each update, the Ethernet/IP driver was less and less likely to see the devices until it finally stopped finding anything, even if we were plugged directly into the device. At that point, I just stopped using it altogether and always use the Ethernet Devices driver. It's a bit of a pain to type in the addresses manually, and you have to know the addresses ahead of time, but that's what we have to do here.

To view routines in FBD, SFC, or ST, you will need a higher license of Logix 5000 or a language pack add-on. With the add-ons, you can buy them individually or as a multi-pack. The multi-pack is more expensive than each individual language but far cheaper than buying all of them individually. You only need the language license to look at the code. You can upload/download without it. It's possible you have a language pack license already. Were you able to open them before? If so, try to find the activation certificate for your language pack. If you can't find it, reach out to Rockwell and ask them what to do to re-send the certificate so you can re-host it.

Without knowing the IP address, it's going to be tricky. In this case, the serial port is probably going to be simplest method. If the 5/05 is at factory default settings (DHCP enabled), you can use Rockwell's BOOT/P utility, or one from another vendor (I like the one from Phoenix Contact better) to set an IP address. If it doesn't have DHCP enabled, you can try to use a program like Zenmap to run a ping scan but that gets really cumbersome if you don't know the subnet range it could be.

Ok. What driver in RSLinx are you using? When you open RSLinx, there will be a driver called "Linx gateways, Ethernet". Don't try that. Instead, add a driver. Either use the blue "configure drivers" button in the toolbar or go to Communications -> Configure Drivers in the menu. Under "Available Driver Types", select "Ethernet devices" and click "Add New...". Name it something (or keep the default name) and click OK. In the dialog box that pops up, there's a place to map stations. Enter the IP address of the PLC and click OK. Select the new driver in the left panel of RSWho and the PLC's IP address should show up to the right. It may take a few moments for it to make a connection, but that *should* work. I've seldom seen it not work. If it doesn't, try another Ethernet patch cable. Believe it or not, I've had a bad cable allow me to ping but not communicate. I banged my head against a machine for a LONG time once trying to get it to talk and finally replaced the cable out of desperation and it immediately started working. I then cut the ends off of the Ethernet cable...

So: PLC: 192.168.1.100 PC: 192.168.1.99 Computer: 192.168.1.105 That should work. Can you ping the PLC from your computer? Exactly what trouble are you having connecting to the PLC?

In general terms, your PC and the PLC have to be routable to each other. At its simplest, they should be connected to the same physical network with unique addresses on the same subnet. See this link for information about subnetting: https://www.lifewire.com/internet-protocol-tutorial-subnets-818378 In most settings I've worked with, we used a subnet mask of 255.255.255.0, meaning that the first 3 octets of the IP addresses had to be identical. We did have a situation once where we used 255.255.254.0, allowing devices with addresses in the 10.130.32.* range communicate with devices in the 10.130.33.* range. That was ultimately eliminated via the use of VLANs in the managed switches (all done by our IT group, not us). So... If your PLC is at 192.168.1.50, your PC will need to be set to 192.168.1.x, where "x" is an unused address on that physical network. Set the subnet mask to 255.255.255.0. Set the default gateway to 192.168.1.1 or leave it blank. Our standard practice was to allocate the higher values of the last octet (like 240 and above) for static assignment to laptops and virtual machines. Those addresses were reserved in all subnets (it was a messy disaster in that plant, so we had several subnets in use).  

Slight clarification: the COP instruction does a bit-level copy of the data with no conversion. Its length parameter is the number of destination elements to overwrite so if you're copying from a float (32 bit) to an integer (16 bit), you'll just get the first 16 bits of the float, which will be gibberish. If you COP the float to 2 16-bit integer registers, you'll have the full bit pattern to interpret, but it'll be gibberish as-is. The PLC won't decipher the bit pattern as a usable number with out a bunch of custom code in between. Using the MOV instruction will interpret the numerical value of the data and convert it. As I recall, MOV instruction (and other math instructions) will round before storing the result in the integer register. You'll want to experiment with your processor to see how it handles the x.5 boundary case. Some may round up, others round to even. I'm pretty sure the 5000 class processors round to even, but I don't remember how the 500 class handles it. It's been a while since I worked with having to round data values in a 500. Ultimately, the correct path depends on  your desired destination and what you're trying to do with the data. In general, it's best to avoid rounding any numbers until the very last step of the calculation to avoid accumulated rounding errors.  

Unless AB has changed something, the MicroLogix 1000 (serial only) and 1100 (serial & Ethernet) can be programmed using the free version of RSLogix 500. The ML1100 supports the 1762 family of expansion modules, so that should do what you need it to. Won't be as cheap up front as using the 850 you have laying around but I wouldn't be surprised if it ends up costing you less in the long run with development time and failures.

I was thinking of something similar to BobLfoot's suggestion with arrays. When you get the result of the first inspection, you look in the first element of the setup array  to see which bit in the results word to set. So, using your and Bob's examples, when the first inspection completes, you refer to InspectionOrderArray[1], whose value is 2, so you set/reset bit #2 in the results word. I wish I had a PLC at my desk I could play with again...

I've never tried the discovery feature that way, because of network/group policy setting issues that mean the Ethernet/IP driver never finds anything. Instead, I right-click on the network in the I/O tree and add the device. In the device properties dialog box that opens up, there's a "Match Drive" button that opens an RSWho window that you use to select the drive. It then builds the drive database inside Studio 5000 by uploading directly from the drive. (I don't have a PLC/drive in front of me, so I wrote that from memory)

Entirely possible. The ones I've seen could be reconfigured to be powered separately, but his may not be.

I don't think I've ever seen an industrial illuminated pushbutton that did NOT operate that way. A lot of them are very modular so you can select the specific components you need. For your home project, check out Automation Direct: https://www.automationdirect.com/adc/shopping/catalog/pushbuttons_-z-_switches_-z-_indicators/22mm_plastic/illuminated_pushbuttons_flush_-a-_extended/led  

You didn't say what processor it is. Some of them have an EEPROM or SD card and can be configured to load from flash in certain situations. When you make a change to the code, there's generally an additional step required to update the flash memory. What model PLC do you have? Did you note the fault code before resetting it?

Just thinking out loud here.... Could you use  FIFO stack? FFL and FFU instructions. Whenever there's a setpoint change, add the current date/time using FFL. You would use 2 FIFO stacks: one for the 3/min limit and the other for the 10/hour limit. Compare the oldest record in the FIFO to the current date/time. If the oldest record is older than a minute (or an hour), use FFU to unload it. If the length parameter reaches 3 for the 3/min stack or 10 for the 10/hour stack, block further changes. I wish I had a CPU on my desk I could test this with. I'd like to tinker with it.