Store Trend Data in a FIFO

[AMarks95]

Hello all,

I'm using a 5069-L330ER in a project and I need to essentially capture some data that will be shown as a trend on a screen. The data to be captured is the amp draw and voltage on the motor during startup.

I'm thinking I could use a 60ms periodic task with a FIFO to fill a 1500 element array, triggered by our 'call to run' that would essentially store 90 seconds of data after that call to run, and then stop collecting when that FIFO is full.

Then, once the motor is no longer called, that array is moved into a 'historical' array - of which there would be 5 to store the last 5 starts, and the FIFO reset for the next start.

Has anybody done something similar, or have some other suggestion for a better approach?

TIA

 

[tooslow]

SLC500 Trend Question

You have to go offline to create a new 'Trend'
Can you go back Online after you create it or do you have to Download the program then go Online?

 

[JaxGTO]

Yes. I have used them like that and to smooth out a noisy analog signal.
They are of course also great for queuing up calls for product in multiple kettles.

 

[GaryS]

Wow some people like to make things more complicated then they need to be
Why do you want to create a Periodic task
All you need to do is
set up 60ms timer
set up a FIFO file for your trend data the length would be sized for the data you want to display on your trend in the display
set a FIFO Load to trigger on the time done bit
the load word would be the data you want to save to the file
the timer DN would also reset the timer
don’t forget you also need a FIFO Unload on the same timer
it could be done with just a few rungs of code
no periodic task needed and frankly I don’t see where it would have any advantage
the average scan time for programs is far less than 1 ms

 

[pk_test]

Consider running it off of a 60ms timer in the continuous task instead of a periodic task. Periodic tasks have priority over continuous, unless it important to make sure this data log happens exactly every 60ms.

 

[AMarks95]

Timer in the continuous task was my first thought as well, but I was worried about the scan time. I'll have to take a look at what scan times are currently on this PLC. I haven't looked at scan times much, but on human-scale 60ms seems tiny so it's hard to imagine much less.

I'd bet this would be the best/easiest route to take.

 

[GaryS]

I wouldn’t be concerned about the scan time
I have seen large programs with only 200 Pico sec scan time
Keep in mind Logix controllers have multiple processors running at the same time
And it is only doing the update for 1 scan every 60ms

 

[Peter Nachtwey]

Hello all,

I'm using a 5069-L330ER in a project and I need to essentially capture some data that will be shown as a trend on a screen. The data to be captured is the amp draw and voltage on the motor during startup.

I'm thinking I could use a 60ms periodic task with a FIFO to fill a 1500 element array, triggered by our 'call to run' that would essentially store 90 seconds of data after that call to run, and then stop collecting when that FIFO is full.

Then, once the motor is no longer called, that array is moved into a 'historical' array - of which there would be 5 to store the last 5 starts, and the FIFO reset for the next start.

Has anybody done something similar, or have some other suggestion for a better approach?

TIA

Why 60 ms? I think that is too long and much can be lost between samples. As pointed out above, the scan time can be very short so scanning the motor data as fast as you can to capture the peaks would be most helpful. One could calculate and update an average every scan and the then stop updating when the motor is off.

BTW, I doubt 200 pico second scan times. Picos are 1000 time shorter than nano that are 1000 times shorter than micros. I believe 200 microseconds..

 

[kekrahulik]

To answer your question yes, I use a FIFO for exactly that. I then post the data on a panelview screen using "Chart OCX control". I'm capturing data at a MUCH slower rate than you and I'm only capturing the last 100 occurrences of an event. I think you can find some sample code if you search AB for the Chart OCX.

If you implement it, observe your program scan time before and after implementation to make sure you haven't taxed the CPU. I don't know if that's an issue, but i always try to be aware of that when I add new code such as this.

 

[drbitboy]

You don't need a FIFO per se, but it is one way to encapsulate the execution, sometime simultaneously, of several sampling tasks:

• loading of the data to the next slot in the array
• incrementing the index of the next slot
• detecting when the array is full (fifo_control.DN) and the current 1500-sample event is complete.
• triggering the next sampling event (RES fifo_control).

Also, unless you want the movement of the most recently completed sampling event to be under operator control, you could write the data directly to the historical array.

For example, the historical array could be DINT[5,1500]. Then the logic to save an event involves a few tags and a few rungs:

• trend_value
  • The value being sampled
• five_trends, DINT[5,1500]
  • [0,0:1499] is oldest trend
  • [4,0:1499] is newest, or currently-being-sampled, trend
• start_sampling, BOOL
  • the one-shot result that starts the sampling (.EN of FFL)
• sample_index, DINT
  • An index to keep track of the next sample's slot,
  • initialized to 1500
• XIC start_sampling CLR sample_index
  • Start new trend to five_trends[4,...]
• EQU sample_index 0 COP five_trends[1,0] five_trends[0,0]
  • Shift all trends down one, overwriting oldest trend
• LES sample_index 1500 MOV trend_value five_trends[4,sample_index] ADD sample_index 1 sample_index BND
  • save value to next sample slot, increment sample index

Adding a timer to sub-sample the data is not much more complex e.g.

• LES sample_index 1500 BST XIO sample_timer.DN TON sample_timer 60 0 NXB XIC sample_timer.DN MOV trend_value five_trends[4,sample_index] ADD sample_index 1 sample_index BND