Logging in RSLogix 500 Possible?

jds8086

Member
Join Date
Jan 2020
Location
Kansas
Posts
42
Is there any way to log data files in rslogix 500 to a file for later review or something of that nature. I have a SLC5/04 with 20+ I/O modules and way to much going on to try and catch my the issue the line is having without logging it and reviewing the log after the problem comes up again. Is there any kind of functionality in RS500 or some external program that could be made to work as such?
 
More information would be helpful, for example: how many variables do you need to log, how often & how long you need to keep the data.
There are hundreds of possible solutions.
1. for simple but limited logging I suppose you could use a file or files i.e. "N" "F" in the PLC but that would depend on how much memory you have & is limited to the type of files i.e. integer, bit & float.
2. Another is an HMI that has the ability to log events to a CSV file on a card (many have that).
3. A simple Scada package that runs on a PC logging to either a Data base or again CSV.
4. Kepware have an OPC I/O server that has the ability to log data to an SQL data base direct, again will need to run on a PC.
 
I think you will need an external program.

RSLogix 500 has a histogram feature that allows you to log data for one address and save that to a file. Now that can be one bit like I:3/4 or it could be one word like I:3.0. But it is limited to just one single address.

There is also something called Multipoint Monitor, but again no logging.

The RSLogix 500 Trend function allows monitoring multiple addresses, but in the 500 it does not allow logging. I thought it did, but it turns out this is only for the 5000 family.

I think you'll need to look at the suggestions Parky listed above.

OG
 
There is a trending function in RSLogix 500 and you can trend multiple variables.
And you can export the trend to a file, XDB or CSV as far as I remember (approx 17 years ago that I used that feature).

It is RSLogix that does the trending. You have to be online while you are trending.

rslogix_trending.png
 
Hey Jesper, I cannot see any way in the 500 version to log trend data. I've got one live here and there is no option for logging.

Now, it does have an option to Create Snapshot. This provides the data in a .DBF format. But this has to be done manually, and old data could be missed if it is no longer in the buffer.

There is this message in Help too...

You can create a trend while offline or online.
1.In the project tree, click the Trends folder.
2.Right-click and select New from the menu.
3.Type a name for your trend chart in the Trend Name text box.
4.Click OK to create an empty chart. An icon for the new chart appears under the Trends folder in the project tree.
5.Double-click the icon to open the chart. Trends are saved with the project. Logged data is not retained.


I thought you could do this too, but I'm thinking I might be confusing this with the early RSLogix 5000.

OG
 
I dont remember exactly the procedure, but it is possible that it is called "snapshot". Dont remember the name, I thought it was called "Trends". As far as I remember it was next to the watch table in the project navigation tree.

Yes, if the data scrolls off the screen then it is lost. But you can adjust the x-axis so that you get as much data as possible.

Obviosuly it is not perfect, but if you dont have anything else it could the only tool that you have available to troubleshoot a tricky situation.
 
To clarify...

In the Trend window you can right-click and select Create Snapshot. That does save the data in a DBF format with the proper columns of data as you would expect. It does not include the trend itself. The DBF file could be opened in Excel.

There is a separate Print Trend to print a graphic of the trend window. But it is only the visible window. This is fairly useless, to me at least.

My issue with the Create Snapshot is that (1) it isn't automatic. I must manually perform this step. And (2) The data buffer can only hold so much data. The default buffer size would only hold a little more than three minutes of data. I can increase the buffer size and decrease the log frequency. But there is still a maximum size. Once I hit that, I start losing data unless I manually save it. If I get disconnected, or someone closes the trend window, I lose everything.

Like you said, if there is no other tool available, you make do.
 
Thank you all for the info. Currently it looks like i'm going off the deep end with this. I found this manual which covers the "RSLogix Automation Interface". I'm going to attempt to write a VBA macro (with RSLinx internal VBA editor) to loop though exporting data to a file to later be parsed. On page 85 a " GetDataValue" method is listed and looks promising. I'm having some issues with this old VBA compiler, hopefully i will get that sorted out as this looks like it will be a very useful tool for building tools to help troubleshoot or send/receive data in non-conventional ways.
 
Rather then roll-your-own, which always runs into future support issue. I would consider a cheap historian. If you have a OPC server like a licensed version of RSLinx then you can get the free version of Proficy Historian to do this.
 
As Parky mentioned, HMI's can log data onto a flashdrive. C-more panels from Automation Direct can do that into an excel sheet, but there are better ways. Not sure what HMI you have hooked up to your PLC, but you may already have a data-logging option available.
 
Rather then roll-your-own, which always runs into future support issue. I would consider a cheap historian. If you have a OPC server like a licensed version of RSLinx then you can get the free version of Proficy Historian to do this.


As Parky mentioned, HMI's can log data onto a flashdrive. C-more panels from Automation Direct can do that into an excel sheet, but there are better ways. Not sure what HMI you have hooked up to your PLC, but you may already have a data-logging option available.


So i'm on board with either of those options. I believe at this point i've found a related but somewhat separate problem i need to weasel around or my logging adventures may not be that helpful (and likely misleading). In this particular case, i am working with a SLC5/04, and from what i gather, this processor cannot store and forward data, it looks like no matter how i go about it i get ~100ms update rate and miss anything that may have happened in between. The only thing i've thought of (that is somewhat limiting) would be to put timers on all the bits i'm interested in in a new ladder (with say 150ms preset) so if for example i keep getting random stops on a machine i could do this on the stop circuit input and other bits that could cause the issue and anytime those bits go high (or low if that is the case) i should for sure catch it with OPC/histogram/trend/etc...



This is where i hope i'm overthinking (under?) things and you awesome people have a much better idea.
 
If I had to do this from scratch, as a 1-time diagnostic and not a long-term solution, I would write a subroutine to continually, i.e. on every scan, log (MOV or COP or CPW) the relevant tags (bits, ints, etc.) into circular buffers i.e. the largest (256-element) data files the SLC supports, so each logged tag gets its own log file. There would be one INT, "the_index," that is incremented on each call of the subroutine and represents an indirect points to the element of each log file that gets the next datum; the_index would be ANDED with N-1 (255?) to wrap around after being incremented. Then set some triggers, which indicate that the event being diagnosed has occurred, plus perhaps either some additional delay or number of index steps, to either stop calling the subroutine or return from the routine immediate it is called.

Now all I have to do is wait for the trigger event(s), and then go in with RSLogix500 online and look at, or even upload, the buffered data; I would need to look at the_index to see where those data stop and start, but it should be straightforward.

If a single data file is too small, then use multiple buffers for each tag.

There is summat similar here to evaluate statistics of repeating timers; the guts of the proposed subroutine are on the next to last rung of each of the programs.

There is a multi-file (1024 data = 4 files x 256 data/file) save of data in Rungs 0010-0013 here, to evaluate statistics of a Gaussian/Normal random number generator.

It's a fair bit of yak-shaving, but the algorithm is simple and direct, basically bookkeeping (like most programming), and very unlikely to not provide per-scan data of the event; one possible deal-breaker could be available resources e.g. memory or scan time. This thread is already a few days old, so it will be worth the effort assuming those data will provide insight into the original issue.
 
Last edited:
If the root cause of your analysis is a machine that stops for undetermined reasons, and you just need to determine and annunciate those reasons, you should be able to do that with minor additions or restructuring of the code. The true root cause might boil down to a flaky contact on a pushbutton or limit switch, but with PLC code you should be able to latch an alarm bit or word for the first thing that occurs to cause a stop command. Clear the latched info when the machine restarts, use the normal means of tying that bit to an HMI alarm and/or historian, and carry on.

You may find that there are a handful of field devices that could benefit from a "debounce" timer without any performance penalty but I would be hesitant to just add them to a large number of inputs as a shotgun approach to killing this bug.
 
If I had to do this from scratch, as a 1-time diagnostic and not a long-term solution, I would write a subroutine to continually, i.e. on every scan, log (MOV or COP or CPW) the relevant tags (bits, ints, etc.) into circular buffers i.e. the largest (256-element) data files the SLC supports, so each logged tag gets its own log file. There would be one INT, "the_index," that is incremented on each call of the subroutine and represents an indirect points to the element of each log file that gets the next datum; the_index would be ANDED with N-1 (255?) to wrap around after being incremented. Then set some triggers, which indicate that the event being diagnosed has occurred, plus perhaps either some additional delay or number of index steps, to either stop calling the subroutine or return from the routine immediate it is called.

Now all I have to do is wait for the trigger event(s), and then go in with RSLogix500 online and look at, or even upload, the buffered data; I would need to look at the_index to see where those data stop and start, but it should be straightforward.

If a single data file is too small, then use multiple buffers for each tag.

There is summat similar here to evaluate statistics of repeating timers; the guts of the proposed subroutine are on the next to last rung of each of the programs.

There is a multi-file (1024 data = 4 files x 256 data/file) save of data in Rungs 0010-0013 here, to evaluate statistics of a Gaussian/Normal random number generator.

It's a fair bit of yak-shaving, but the algorithm is simple and direct, basically bookkeeping (like most programming), and very unlikely to not provide per-scan data of the event; one possible deal-breaker could be available resources e.g. memory or scan time. This thread is already a few days old, so it will be worth the effort assuming those data will provide insight into the original issue.

If the root cause of your analysis is a machine that stops for undetermined reasons, and you just need to determine and annunciate those reasons, you should be able to do that with minor additions or restructuring of the code. The true root cause might boil down to a flaky contact on a pushbutton or limit switch, but with PLC code you should be able to latch an alarm bit or word for the first thing that occurs to cause a stop command. Clear the latched info when the machine restarts, use the normal means of tying that bit to an HMI alarm and/or historian, and carry on.

You may find that there are a handful of field devices that could benefit from a "debounce" timer without any performance penalty but I would be hesitant to just add them to a large number of inputs as a shotgun approach to killing this bug.


Now you guys have my light bulb at least flickering, i think i can figure something out along these lines. I'm still fairly new to working with ladder logic, i hadn't even considered that i could buffer data and "send it out" in such a way but it's clicking now. I know it doesn't have the inherent troubleshoot-ability of ladder logic but every time i need to do anything but the very basics in ladder i find myself wishing i could just program these in C or really any text based language. It seems like in ladder it takes a lot more effort to produce something but again, i haven't had my time with it.
 
I use to log quite a bit of data out of SLC's, (Same time frame as Jesper :) )

To keep it low budget, I would send out the data serial and setup a PC with a serial port and Ethernet.

Or if was temporary, I would leave one of my old laptops connected (this whas back when a laptop had a serial port)
 

Similar Topics

Hello everyone, I am working on a project that provides for each operation performed by the operator to save on variables "N" and "T"; which will...
Replies
2
Views
1,591
Hello My name is Harry and i am fixing some program for a client. He has Micrologix 1100 controller and i am using RSLogix 500. I do not have...
Replies
5
Views
2,369
Hello, I've been browsing the forum and doing internet searches but i haven't been able to make anything work. What i am trying to do is log how...
Replies
5
Views
2,143
Good Monday morning to everyone I am using FTV, RS micro developer and MicroLogix 1400 A PLC's I need help to understand the data logging that's...
Replies
3
Views
1,857
Hi Guys i have a machine which i would like to record the down time, the machine has a rsview 32 hmi and we have a compact logix plc, i have not...
Replies
2
Views
5,812
Back
Top Bottom