OkiePC
Lifetime Supporting Member
I was looking over a kludge of two SLC500 systems this week with the task of fixing some sequencing issues between a food batching/mixing system and a relatively recently added salt dispenser system.
The dispenser SLC sequence is awful, the Grind Area system SLC isn't much better.
The area SLC talks to a RSView32 standalone system.
The dispenser SLC talks to a PV+.
The PV+ also contains screens added for the grind_area slc.
The batch/mix area SLC MSGs the dispenser SLC too. Very simple two or three word read and write.
Sunday, the operators were fill-ins, and managed to make a batch with no salt. They reported that the PV+ was wrong.
I found at least eighteen different permutuations in the existing logic that would explain what had happened and fixed the SLC code by day's end so the two systems were sync'd in two appropriate places in their respective sequences. I needed to update the PV+ to ensure the new information was available to the operators to prevent confusion in the event that my patch was not all inclusive and the system failed to dispense for a different set of reasons.
Now, I associate the salt weight with a Batch Number and a SLC timestamp with some COPy FIFO stacks that are displayed on their PV+.
Adding 6 analog display entries to an existing project took four hours. I spent another 2 on it yesterday before I was ready to download. That part was a breeze, taking only a minute or so.
Today, I uncover more issues that prompt some editing and another download.
Reasons for the inefficiency:
Alarm Triggers of Integer data type and a BIT trigger type are associated bits numbered 1-16 in the PanelView.
I can't think of any reason for them to be numbered anything other than 0 through 15, or 0 through A, but why would it be necessary for the designers of RSView Editor to do this to us? Is there a valid reason to number the bits in an integer (or any other data type) 1-16?
'RSView Studio Help: Alarms when using bit trigger type: bits are numbered 1 through 16'???
I wasted an hour finding this info after thinking I had stumbled on a handful of mislabelled alarms.
Project Manager:
Using project manager to retrieve the latest file from our shared server and moving it back for archive added at least 2 hours to my work. TG for multi-tasking. There were numerous hang-ups, glitches, and opportunities for errors on my part that accounted for most of that lost time. I don't have the specifics in front of me, but it is easily reproducible.
Factory Talk: How does this program really and truly interact with RSViewStudio? Some of my fault windows popped up with Factory Talk blah blah blah ... in the task title on the Taskbar. And, where specifically does RSLinx Enterprise blend in with the aforementioned?
File Close: Why does part of my project remain open or flagged as open? I frequently had to perform tasks on a file I had already closed, only to receive a message that one of about five things was 'broken' everything checked out okay except that the file was "open or in use by another application". Restarting RSView Studio did not help, I had to reboot the PC and start RSView then perform the operation before ever having the file open. May have been another way to get it unhung, but I had no time to troubleshoot RSViewStudio and restarting it did not help.
Comms setup disappeared. An atttempt to compile generated an error which led me to discover that my Comms settings were gone. I had to restore them from the previous version. Yesterday, following the exact same steps with Project Manager, (editing, saving, backing up, compiling), did not have any errors during compile. Today, I lose my comms when I restore the file to my local machine. repeatably...
Testing screens...the play button.
Some of my string pointers assigned to Memory tags failed to make it from my project tags, into MY PC ram without causing RSLinxEnterprise errors. I had errors in the activity bar and in the text display on my PC, the text was missing entirely sometimes, and displaying gargabe at other times. I simply shutdown Studio, fired it back up, opened the same local project, and they work just fine.
The Blinking Tank: I noticed in my investigation that the indication of an empty bulk salt bag does not generate an alarm and it barely noticeable. The operators also don't have a clue what the weight display should read, so I convert it to a bargraph shaped like a salt hopper. It holds up to 400 pounds before the scale loses accuracy, and less than about 60 pounds should be an alarm point. Luckily, the bar graph object has thresholds built right in. I want to make the hopper blink yellow when near empty, be solid white when between 60 and 380, and be flashing red above 380. The simple threshold controls didn't allow me to do this, and the test (play) feature on my PC did not show the blink status correctly. I had it blinking only when outised of 60 and 380 in my test, but on the PV+, it was blinking when BETWEEN the limits and not below the low one. there was no direction flag associated with the built in thresholds. I guess object animation may provide that flexibility?
I can't understand how the editor can so poorly emulate the hardware when the firmware and everything is contained within it.
More to come...
The dispenser SLC sequence is awful, the Grind Area system SLC isn't much better.
The area SLC talks to a RSView32 standalone system.
The dispenser SLC talks to a PV+.
The PV+ also contains screens added for the grind_area slc.
The batch/mix area SLC MSGs the dispenser SLC too. Very simple two or three word read and write.
Sunday, the operators were fill-ins, and managed to make a batch with no salt. They reported that the PV+ was wrong.
I found at least eighteen different permutuations in the existing logic that would explain what had happened and fixed the SLC code by day's end so the two systems were sync'd in two appropriate places in their respective sequences. I needed to update the PV+ to ensure the new information was available to the operators to prevent confusion in the event that my patch was not all inclusive and the system failed to dispense for a different set of reasons.
Now, I associate the salt weight with a Batch Number and a SLC timestamp with some COPy FIFO stacks that are displayed on their PV+.
Adding 6 analog display entries to an existing project took four hours. I spent another 2 on it yesterday before I was ready to download. That part was a breeze, taking only a minute or so.
Today, I uncover more issues that prompt some editing and another download.
Reasons for the inefficiency:
Alarm Triggers of Integer data type and a BIT trigger type are associated bits numbered 1-16 in the PanelView.
I can't think of any reason for them to be numbered anything other than 0 through 15, or 0 through A, but why would it be necessary for the designers of RSView Editor to do this to us? Is there a valid reason to number the bits in an integer (or any other data type) 1-16?
'RSView Studio Help: Alarms when using bit trigger type: bits are numbered 1 through 16'???
I wasted an hour finding this info after thinking I had stumbled on a handful of mislabelled alarms.
Project Manager:
Using project manager to retrieve the latest file from our shared server and moving it back for archive added at least 2 hours to my work. TG for multi-tasking. There were numerous hang-ups, glitches, and opportunities for errors on my part that accounted for most of that lost time. I don't have the specifics in front of me, but it is easily reproducible.
Factory Talk: How does this program really and truly interact with RSViewStudio? Some of my fault windows popped up with Factory Talk blah blah blah ... in the task title on the Taskbar. And, where specifically does RSLinx Enterprise blend in with the aforementioned?
File Close: Why does part of my project remain open or flagged as open? I frequently had to perform tasks on a file I had already closed, only to receive a message that one of about five things was 'broken' everything checked out okay except that the file was "open or in use by another application". Restarting RSView Studio did not help, I had to reboot the PC and start RSView then perform the operation before ever having the file open. May have been another way to get it unhung, but I had no time to troubleshoot RSViewStudio and restarting it did not help.
Comms setup disappeared. An atttempt to compile generated an error which led me to discover that my Comms settings were gone. I had to restore them from the previous version. Yesterday, following the exact same steps with Project Manager, (editing, saving, backing up, compiling), did not have any errors during compile. Today, I lose my comms when I restore the file to my local machine. repeatably...
Testing screens...the play button.
Some of my string pointers assigned to Memory tags failed to make it from my project tags, into MY PC ram without causing RSLinxEnterprise errors. I had errors in the activity bar and in the text display on my PC, the text was missing entirely sometimes, and displaying gargabe at other times. I simply shutdown Studio, fired it back up, opened the same local project, and they work just fine.
The Blinking Tank: I noticed in my investigation that the indication of an empty bulk salt bag does not generate an alarm and it barely noticeable. The operators also don't have a clue what the weight display should read, so I convert it to a bargraph shaped like a salt hopper. It holds up to 400 pounds before the scale loses accuracy, and less than about 60 pounds should be an alarm point. Luckily, the bar graph object has thresholds built right in. I want to make the hopper blink yellow when near empty, be solid white when between 60 and 380, and be flashing red above 380. The simple threshold controls didn't allow me to do this, and the test (play) feature on my PC did not show the blink status correctly. I had it blinking only when outised of 60 and 380 in my test, but on the PV+, it was blinking when BETWEEN the limits and not below the low one. there was no direction flag associated with the built in thresholds. I guess object animation may provide that flexibility?
I can't understand how the editor can so poorly emulate the hardware when the firmware and everything is contained within it.
More to come...
Last edited:
