Joe E.

Hmmm....the forum is being weird. This is my third attempt to post. My copy of the Kinetix 5500 manual has an Excel file attached to it that provides more information about the faults. I've tried to post a screenshot, but those posts didn't work, so I'll skip that step this time.

I've used the DataStorePlus before and I think you're right that it's periodic only. In the project tree, look for "Data Log" and try tinkering with that. I've never used it, but it looks like it can log an entry upon tag value change. You can set the storage path to a local or network directory. I never was able to get the data out of the HMI onto a PC automatically. I know the DataStorePlus can write to a network location, but our network was locked down so that I couldn't access any outside destinations and the internal memory filled up very fast. I ended up disabling the logging.

I'm using an HP zBook. It came with the OS installed on an internal SSD of some kind. The 2.5" HDD bay was unused. I was able to add a SSD to it easily. It's easy to remove the bottom cover of the laptop and the drive comes out with a few screws. The old Dell I used to use was good too. The bottom cover came off with a couple screws and the drive slid out the side after removing another small screw to unlock the latch.

It's asking where you want to install the software. In general, the default path is sufficient.

I would add a minor detail to Chris's post about the firmware versions. It's possible that the runtime file in the HMI was compiled for an older firmware version than what's in the HMI. We used to do that for a while until we had to upgrade to version 6 and finally migrated the runtime security from the old v3.x system. If the replacement HMI has at least as new a firmware version as the existing one, you're fine. If it's older, it's still worth a try to move the runtime file over. If you can get to the configuration mode described above, you can use a USB flash drive to transfer the runtime file without much trouble. I've heard that there's also a way to get to a CF card inside the device that contains the runtime files, but I can't help you with that. The runtime file can be de-compiled into a project if it was developed in View Studio version 5.0 (I think...) or later and the developer didn't lock it.

I haven't seen a JXR before, so I checked it out. It's a jump to an external subroutine, available in the Logix 5000 platform. The help refers to loading a DLL, so I'm not sure what it does exactly, or where the external subroutine is located. Another program?

Not sure what you mean by variable setpoint... If you're using tags inside Crimson, go to the data tag that points to the PLC register. On the "Data" tab, look at the "Data Scaling" section. The tag can also be configured to have limits of 1-8, preventing the entry of any other values. I haven't tested this particular configuration (I don't have access to a CompactLogix PLC) but I've done scaling before so I know it can be done.

Are you using Step 7 in Simatic Manager or in TIA Portal? I used Portal only briefly and with no training and no longer have access to it, so I can't help much with it, but I did use Simatic Manager a lot.  

You're not doing it wrong. Add-on instructions can't be edited online. They're not really meant to be like a Siemens FB, but to be a custom instruction that's fully tested before use.

Quite possibly. The dedicated comms gateways I've priced have been over $1,000, but I was always trying to go from Profinet to Ethernet/IP.  The Red Lion DSPs can be cheaper than that.

I agree here. Depending on the I/O count, it may be cheaper to buy some Ethernet/IP I/O to install in place of the LOGO instead of buying a gateway module. In the long run, it will be simpler and easier to troubleshoot too. If you want it to be a stand-alone machine instead of a slave of the CompactLogix, you can almost certainly replace the LOGO with a MicroLogix 1100 or 1400 for less than a gateway module. Either ML would talk natively with the CompactLogix far more easily than using any gateway device. Is there an HMI on the machine?

Round towards 0, round away from 0, round up, round to even...each can cause unexpected results for the x.5 case so you have to know what your platform does and act accordingly. The Logix 5000 PLCs I've used rounded to even; I don't remember what the 5s or 500s did. Or the S7-300s.

Honestly, when I first saw this, I thought, "Huh, a new bug I haven't encountered yet." Based on my experience with View Studio, it didn't occur to me to question it. Sigh...

So, I wrote, and then deleted a little mini-rant about STL programming. This probably isn't the place for it... I will say that not all code can be converted back and forth between LAD and STL. If you write code in LAD and convert it, you will end up with a number of NOP instructions scattered around. Sometimes, you can eliminate them and have it still convert back, other times not. Also, in my experience, code written in STL wasn't divided into networks correctly to be able to convert to LAD. To convert it, I would almost always have to divide each STL network into multiple networks before it would convert. I usually could get it to convert after that, but every now and then I'd encounter one that wouldn't go from STL to LAD. In my experience, LAD would always convert to STL, but not always the other way around.

That document is for the AIC module, which is (in my experience) mounted inside the control cabinet to connect multiple devices together. The UIC is a different animal. At a previous employer, we had issues with the white AB UIC adapter being a little unreliable but we were always able to get it to work as long as the cables are good. We ended up switching to the aftermarket model from Industrial Concepts with great results. I never had a problem getting it to connect. Of course, the last time I connected to a 5/02 was a few employers ago and we used an old laptop with a PCMCIA card (PCMK, I think is what it was called in RSLinx...). At my last place we had some 5/03s and some fixed IO L40Bs that used DH485. I found a few in the plant I'm in now but haven't had a chance to hook up to them yet.

In general, parts should be assumed bad until positively verified to be good. I've gone 'round and 'round with manufacturing engineers (newer ones) to explain that it's not enough to have the inspection device just hold its "good" status high until it sees a bad part. What if, for example, it misses the trigger and doesn't inspect at all? The result flag either has to be momentary or there has to be a momentary "inspection done" flag to let the PLC know the result flag is valid. Otherwise you're a failed trigger signal away from allowing bad parts through. Without knowing it...

I figured it was something wonky with our IT policies. I mean, it filters microsoft.com unless I'm on the guest network, so it's not an unreasonable suspicion.

I thought it was just me...

On simpler projects, I would download the code to a bench PLC with all I/O inhibited and then add a "Simulate" program that simulates the real world. So if an output makes a cylinder move, I put a timer on that output and have the timer DN bit turn on the input for the cylinder sensor. This is kind of crude, but for simpler machines, it's adequate. I can extend the timer presets to simulate a dying cylinder or use a toggle bit to disable them altogether to simulate a dead cylinder sensor to see how the logic reacts and recovers. The PLC is in Run mode, and the HMI (usually on the bench next to the PLC) is also being tested. This method is rather brute-force and inefficient and would be cumbersome with more complex machines or processes, of course, but it's served me well on the projects I've used it on.

The "right" way may depend on who you're talking to... There may not be a way to send multiple DBs with a single connection. Have you tried Siemens tech support? At least in North America, they're pretty easy (and free) to contact. They haven't always been the most helpful, but they're available.

That squares with my experience. We were repeatedly tasked with changing the passwords in a series of machines that all used the built-in runtime security system, which required going out to the machines (about 20 or so total HMIs), editing the project, and downloading it. It was an all-day task that we really didn't have time for. I spent a couple of days figuring out how to let them change their own passwords (very easy) and backup/restore them so we could make runtime changes at will (a lot more complicated). When we investigated doing that to the PV+ HMIs, we found out from tech support that the current password is stored in the MER file inside the HMI, so if we wanted to keep the passwords after making our changes, we would have to upload the existing MER from the HMI and restore it into View Studio. We wouldn't be able to use our APA project backups at all. I'd say to change from using the built-in user administration in the PV+ to using a number stored in the PLC. Make sure you're OK with anyone who can get into the PLC having access to the passwords, though. Then write either a pseudo-random calculation or look-up table.

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.