Joe E.

@ElectronGuru That makes sense about the letters since that's the behavior I see in Logix 500. I flashed my desktop -L33ER back to v20.19 and did some tests. The "e" indicator shows up when the rung is being edited but is invalid and changes to "i" when it's being edited but is valid. Then switches to uppercase letters as the edit is accepted and tested. I started an online edit and then went offline with it invalid (XIC with a missing tag) and closed the file without saving. I then went online with the old file and it went online without issue or indicators. Next, I uploaded without a file and, again, the file uploaded without any extra "e" indicators. I haven't been able to replicate what your colleagues found, in v20 or v32, but I think their findings are very interesting. In my testing, mid-edit rungs that are valid/invalid don't show up at all when uploading. Mid-edit rungs that are being tested DO show up, along with the original rung (upper case "I" and "R" indicators). So far, I haven't been able to get it to upload an invalid rung. Do you know what version of software/firmware they're using? Today's test has all been in firmware v20.19 and software v20.04. I also can't quite figure out how to end up with an invalid AOI inside a running PLC, even in an edited rung. You can't edit AOIs online. This is a really interesting issue....

So I found a knowledgebase article that explains the rung status indicators (access level: TechConnect), but I don't think it's totally accurate: https://rockwellautomation.custhelp.com/app/answers/answer_view/a_id/106109/ When online, "e" means there's an error. It changes to "i" when all tags are present and rail-to-rail logic is valid. I was never able to replicate the "e" indicator, either in v20 or v32.The letter stays "i" but there's an "X" next to the rung number until it's all valid. But it does point to a corrupted AOI. It's correct in the PLC but the software corrupts it while uploading. Since your AOI is ST instead of ladder, I don't think it applies directly, but I've come across another tech note (access level: TechConnect): https://rockwellautomation.custhelp.com/app/answers/answer_view/a_id/866333 It discusses an anomaly when uploading ladder logic if you have controller-scoped tags aliased to program-scoped tags. It was an anomaly in v24.00 that was fixed with 24.02. Whatever major rev you're using, I'd go to Rockwell's Compatibility and Download Center and verify you have the newest minor revision of that major revision. If you're already at the newest minor rev, I'm not sure what to suggest now. I suspect the AOI is getting corrupted somehow upon upload. If you have access to another PC with the programming software, you could try that one and see if you get the same result. Or uninstall and reinstall the software.

At its simplest, initialize the setpoint to the starting value and use a self-resetting timer with its preset the ramp step interval. Every time the timer finishes, add the ramp step size to the setpoint until the setpoint reaches the target value.

Sooo.....in Logix/Studio 5000, when doing an online edit, I get a lower case "i" as soon as I enter "edit" mode of the rung and the power rail is dark next to it. the original version of the rung is marked "r" and power rail is on. When the rung is being edited and is invalid, a red "X" circle shows up until the rung is valid. Once the rung is valid and accepted, the rung flags become capital "I" and "R". While testing, the power rail switches so the "I" rung is lit and the "R" rung is not. Once assembled, the extra rung and rung flags go away. Throughout the editing process, in 5000, I never saw the "e" at all. I only saw that in 500. And never while the power rail was lit up. As an additional test, I switched the PLC to "Program" mode with the mode switch and initiated an online edit. The "i" and "r" followed the same pattern except that accepting the edit also assembled it (no intermediate test, as expected when it's not running). With the switch still in Program, I then made an invalid edit and switched it to Run. I was unable to complete the edit. The only option was to cancel the rung edits, but at no point did I get the "e". Even switching the mode switch to "Run" while an edit was active didn't give me an "e". So...I created an AOI, a really simple one. You can't do that online, so I did it offline and downloaded. I then created several errors but couldn't reproduce the "e" indicator. The other error messages in the first screenshot show up when the controller is offline, so I suspect, like the others, that something got messed up while offline. The "e" indicator is still a mystery to me, though. They were online in run mode with something weird happening with that tag value....  

Looking at rung 16 in the last screenshot, what would cause the letter "e" to be there with the rung lit up green? The green indicates that it's being scanned, which would tell me that it's in the online processor properly. When doing online edits in RSLogix 5000/Studio 5000, the letter "i" shows up, but not "e". I see "e" when editing a rung in RSLogix 500, but the rung isn't lit up green in that case. Interesting... I wonder if there's a conflict somehow between the AOI in the offline (uploaded) file and what's online? Total speculation....

One more thing: make sure you don't have the display open when you try to delete/rename it. I seem to remember that being part of the weird glitch I experienced.

I've seen weird things with View Studio in the past and remember having something weird happen when deleting a display too. I don't remember the exact resolution of the issue but usually closing the software and rebooting the PC clears up a lot of bugs. If that doesn't work, try restoring a fresh copy from the mer file, then try again. If that doesn't work, restore a fresh copy from the mer, then archive it to apa format, then restore the apa file and try again.

I have SLC Logistics, but it is still copyrighted software. Can you zip the files and post it here? If the software still runs, I can generate a pdf printout for you.

I would try to get the module you're missing. But...in my experience with Siemens...you can make changes to an FC or FB and download it without affecting other parts of the program. Portal has an option to do a "consistent download" that I would un-check since you're missing a module. It may not be necessary, but I would feel safer.

Most of the time when I'm changing processor type (not just firmware version), I create a new project with the new processor and copy-paste the I/O, then the controller-scoped tags, then the programs. Then fix the errors (if any). I was surprised once how easy it was to convert an older CompactLogix (serial port only) to a remote rack of a ControlLogix with an -AENT adapter. I did what I described above: added the -AENT and IO to the ControlLogix IO tree, then copied everything over. Once It was copied over, I had to re-alias the IO tags, but there were only like 5 IO modules so that didn't take long at all. The whole process took like 30 minutes, including swapping the hardware (replacing CPU with -AENT) and setting its IP address.

You could use an AVE instruction on the array and then MUL the average by the size of the array. You'll have to "blink" the AVE instruction since it only calculates once per rung-goes-to-true. I've tested that with either a flasher bit in front of it or by immediately unlatching the .EN and .DN bits of the AVE instruction's control tag. You can decide which is what you want to do.

What I typically do is set up a hearbeat, a flasher. I usually have them anyway for blinking lights at different rates, so I just send that bit as part of a word of flag bits that get sent. Both stations in the link generate and send a heartbeat so both can check the bit to see if it stops blinking. Blink rate should be much slower than your packet rate to make sure you see both states.

Looking at your pdf, reverse the way you're controlling your bits: Each output coil should only be referenced once. Gather all conditions that will turn that coil on together, in parallel, on a single rung. Another thing you could do is assign a number to each message. So, for example, message 3 would require that bits 0 and 1 are both on. You can have the alarm conditions write a number to a tag and then map the individual bits of that tag to individual outputs: If the speaker turns off when its input 0 is turned on, then you can only configure 31 messages instead of 64 (you can get 32 messages if having all channels turned off can trigger a message). You could use AlarmMSG=0 to turn on Output_0 and then offset the remaining bits:  

I know it's been done successfully. My colleague at a previous employer got a PV+ to talk to PLCs over DH+ using that gateway. I believe he used a SLC 5/04 and a PLC-5 during his experiments. I seem to remember there being something special he had to do to the ProSoft gateway to make it work. He had to reach out to ProSoft tech support. I've had to contact them too, for help with a Profinet/EthernetIP gateway and they were very helpful. I second Ken's suggestion to make an empty project that has just one tag it's reading. Ether a number or a blinking bit. Once that's working, you can do the rest.You also have to watch your syntax with the tag names and such, using colons and curly braces {} correctly or it won't work.

I'm not sure I can provide much insight, but it's probable that FCs in Scout work differently than those in Simatic Manager. I'm pretty sure, from memory, that you can indeed make changes within the declaration area of a Simatic Manager FC without affecting other areas of the program. Scout is likely a different animal. My brief forays into the Sinamics drives used the version of Starter/Scout that's embedded inside S7 Technology, which looks very similar to what you see, but I never had to poke around and change any code. I'd suggest you reach out to Siemens tech support, with the understanding that, based on my experience with them, your chances are even at best. I fully support your plan to not load RAM to ROM. That's a very good idea until you're 1000% sure you haven't broken anything. Even then, I'd be absolutely sure you have a good backup you can download.

This is one of my pet peeves about Rockwell, but it's their material so their rules.

I think I misunderstood your first post, thinking you had one question instead of two. To scale engineering to raw, you're going to use ratios. EngSpan = EngMax - EngMin RawSpan = RawMax - RawMin Ratio = RawSpan / EngSpan Raw = Ratio * (Eng - EngMin) + RawMin Most of the scaling I've done is zero-based, where the EngMin and RawMin are both zero. That simplifies things: Ratio = RawSpan / EngSpan Raw = Ratio * Eng   On your second question, that block doesn't appear to do much. It just decides which of two numbers to pass on to the third register based on the value of a boolean flag. There isn't any scaling or conversion done there. Does your software have a "Copy" or "Move" instruction that works with floating point values? If so, just use two of those instructions, selecting them based on the value of your boolean flag. Beyond that, I'm afraid I won't be of much help with that since I've never used that software.

What HMI are you using? If you're using a PanelView Plus: Right-click on an empty area of each display and open "Display Settings". There's a field called "Display Number". Make sure each display has a unique number. Or at least, give the manual display its own number that no other display has. Unfortunately, when you create a new display, the software doesn't automatically assign it a unique number so if your project already has a lot of displays and this feature isn't already in use this step can be annoying. In the project explorer, open "Global Connections". On the "Display" tab, enter a tagname in "Replace Display Number". That tag gets written with the number of the current display. I've only ever seen PLC tags used here, for when the PLC needs to know where the HMI is, but you could probably use an internal HMI tag too. Back on the manual display, select the object whose visibility you want to control and go to the "Animation" menu above the toolbar. Select "Visibility". The animation dialog box will open. You can write an expression comparing the display number tag to the number you gave the manual display. If they're equal, the object can be visible. NOTE: if you're using a display to show the global sidebar, the "current display" tag may be written with the number of the popup. I've never tested that, so you may have to put a numeric display on there temporarily to watch the value of that tag if the visibility doesn't do what you want. Since global connection is "Replace Display Number" and your options for showing a display are "Replace" or "On Top", and a popup would be "On Top", I think this will work...but you never know until you try.  

I don't know that software, but...I've seen it done before where the floating point value is multiplied by 100 and stored as an integer. That gets you 2 decimal places. You can then work with it as an integer and then divide by 100 to get it back to a floating point. Or, if it's just scaling you're doing, the formula isn't complicated. You could just skip the block and use math instructions directly.

panic mode: can you access that technote with a generic (free) login? When I opened it, it said it requires TechConnect:  

If you have an ACD file for the machine, you can post it here and someone can make you a pdf printout. That may not help you with the current issue but can help in the future. If that message is showing up on the HMI, you may need to look in the HMI program to isolate it if the PLC program isn't well documented.

That may not quite work, but it's really close. The first COP instruction will copy the avg_array to avg_array_Temp, but offset by one position. If your arrays are 5 elements long, you're going to have a problem with it since you're starting the copy into the destination at register [1] for length 5. The last element that will get written to is element [5], but the last element of a 5-element array will be [4] (they start at [0]). That also leaves the value in avg_array_Temp[0] unchanged, which then gets copied back to avg_array[0]. During the times between pulses of System_One_Shot_Min, your avg_array will not have valid data. Element [0] will always be invalid except during the scan of that rung of code. What I would do is use a COP instruction to shift the avg_array one position UP (closer to [0]) like this: Source: avg_array[1] Dest: avg_array[0] Length: 4 That will move [1] into [0], then [2] into [1], then [3] into [2], and finally [4] into [3]. [4] will remain unchanged while the data in the other registers moves one position towards [0]. Then MOV your counter .ACC into avg_array[4]. The most recent minute's data will always be in element [4] of the array with the preceding 4 minutes' of data always there and available for display or other purposes. Then you can use the AVE instruction on the array to get the average of the last 5 minutes. You won't need the _Temp array or the MUL instruction. You can also investigate the FIFO instructions (FFL/FFU), but they may be overkill for this. The RES instruction of the counter may also cause you to be off by one count. If Unit_sensor is still on for the next scan after RES, your CTU will increment again, double-counting that part. To avoid that, you can either use an ONS instruction between Unit_sensor and CTU or MOV 0 into counter_avg.ACC instead of RES.

Here's the third part CNV9451_2019_01_31_C.pdf

Here's the second part CNV9451_2019_01_31_B.pdf

The CNV... file is in v29, which I don't have installed. I bumped it to v30 while opening it, so be aware that some things may not be an exact match. Here's the first part CNV9451_2019_01_31_A.pdf