Joe E.

To add to ElectronGuru's warning, I've seen a firmware update fail on a PF7xx once that bricked the drive. Thankfully, we had a spare on hand. Doubly thankfully, the one doing the flashing was an AB engineer so they ate the cost of the replacement. I've generally seen FW updates on PLCs and modules go pretty smoothly, but I would be cautious about flashing a drive. Could be that I'm biased because I've only been involved with a very small number of them and one of them failed but if I didn't really need the updated FW in that drive, I'd probably leave it alone.

I would be too.... Thank you for sharing the fix! Another reason why it's important to maintain current ProSave backups. That was part of my routine back when I was working with MP and Comfort panels.

Hmmmm.... No idea if this will help or not, but in Windows if you hold shift and right-click on a program in the taskbar you can pick "Move" and use the arrow keys to move it around. You'd need a USB keyboard and if the taskbar is hidden, you're out of luck. This is an interesting one.

I know some devices at least used to allow a "listen only" connection where additional "masters" can read data out but can't send commands. For example, more than one PLC could read the input/output status but only one PLC can control the configuration and outputs. Not sure if these support listen-only and it's not relevant to OP's original problem, but it could be useful to know at some point.

I'd probably try to plug in a USB mouse. Maybe it can grab the sliver.

The last license we bought was when I started here in early 2020 and subscription was an option. We went with lifetime. Interestingly our self-support online TechConnect is way less than the license was. I don't remember the subscription prices being nearly as high as a lifetime one, though. Their pricing has always been a little....schizophrenic on some things though.

To clarify what's been said above, with a warning that the latest RA licenses may not work the same way since they're really pushing subscriptions: At my last place, we had lifetime licenses originally purchased at v10 or so that were still active and in use to active up to v30 or v32 when I left. Others were bought around v20 or v24 and could also be configured to activate back to v10 and up to whatever was current. The only additional cost wasn't an additional license, but an annual support contract that lets you download the installer files for other versions. It's a similar situation where I am now. Our annual contract is substantially less than another lifetime license of the software. I use virtual machines for all of my automation software. Right now, I'm using a Win10 VM with versions 24 and 28-34 installed. I have an older Win7 VM with versions 10-16, 18-21, v24, 28, 30-32. I also have an XP VM with v10-16 and 18-20. I rarely use either of the older VMs any more since most of our stuff here is in the newer versions.  

So, some more details. The BSL and BSR instructions operate on a rising edge of the rung enable. You would enable the instruction once every time the encoder turns enough for a part to have passed by. The last one I did is in a CompactLogix. I had to create a tag called "Track_Array" of type DINT[1]. The Array tag of the BSL instruction was Track_Array[0]. Its Control tag is a new otherwise unused tag and the source bit (for me) is an Always_Off bit. Length is the number of parts that can be on the conveyor plus a few. If the conveyor is more than 32 parts long, you'll want to have your Track_Array tag bigger. For example, DINT[2] will get you 64 positions. The one I did was anchored at the load station being station 0 so I used a BSL. If instead you want the end to be bit 0, you'd use a BSR instead. Doesn't really affect things other than how you think of it. Here's the rung with the BSL. CAM_00 is on once per machine cycle. In your case, you'd flash it once every time a part spot has passed by on the conveyor: Here, we set bit 1, which is where the servo loads the blanks: Here, we clear bit 8, which is where the finished parts fall out of the machine. Like I said before, I'm not 100% sure this is really the best way to proceed for you. It may make more sense to use a FIFO array. Use an FFL instruction every time a part passes by the sensor and an FFU every time a part arrives at the end position. Downside to using a BSL/BSR is if the parts can slip on the conveyor. If that's not an issue, the FIFO won't work if parts can be removed from the conveyor between the sensor and end. That's why it's good to have multiple tools in your belt.

If all you want is to store good/bad, use a bit shift array using a BSL or BSR instruction. High level description: You'll execute the BSL/BSR once per "interval" of the conveyor's movement. Let's say the end position is at bit 0 of the array and the sensor is at bit 20. The sensor will set/reset bit 20 of the array while the reject/whatever sequence looks at bit 0. A BSR is fired to shift the data automatically.

I've seen many applications that used the dual ports in a daisy-chain configuration. Is the main drawback that all downstream devices go away if one in the middle is powered off? Or is there another reason too?

Are the products all the same size? If so, I would first create an array big enough to have one position for each place a product could be on the conveyor. Array could be bits or integers, depending on how much info you want to track. Use the encoder to advance the array. Write to the right spot in the array at the sensor and read from it at the "store" position. That's my first pass thought.

I replied to your PM.

I've been in the habit of running all of my automation software in virtual machines since about 2011 or so. If that's the only software you need, you could try it on Win11 and it will most likely be just fine even though it's not officially supported. If you ever need to run more software packages in the future, though, I would seriously recommend virtual machines.

There's a tech note (access level: TechConnect): https://rockwellautomation.custhelp.com/app/answers/answer_view/a_id/1136965/loc/en_US#__highlight Several things to try are listed there.

Interesting...I'm not sure if I have that problem or not, but my test bench 1769-L33ER (v34.11) is 2.5 hours fast right now. It's been a while since I checked the CPU time, so it may have been drifting for a very long time.