data logging question

Hey guys!

Think this is a straight forward question...

is it possible for me to get 100 readings per second logged from 10 defferent tags using FT Historian.....

PLC = not chosen yet......thinking compactlogix or SLC 5/05

just want to know if it is possible and if so what are some things i need to look at when getting this much data logged...

ALSO...

When setting up a trend, can the plots x and y be user set of only one and the other is default to time

Probably, but I doubt that you'll get "real" 10 ms updates no matter what direction you go with a networked PC based approach (through RSLinx, Kepware, Matrikon, Ignition OPC-UA, etc). 50-100 ms updates may be more realistic, maybe, depending on your network. Your PLC can catch events at that speed. If you really need to log at that frequency, you could set up a scheme where the PLC buffers the values and a PC triggers batch reads into your database. This most often has pesky implications when you try to visualize/analyze the data later. It depends how you set it up and what your requirements are.

I recommend that you also check out the Ignition SQL Bridge module for this application. I expect that it can perform this task at least as well as FT Historian. The (free) OPC-UA server will work fine with an Ethernet connected CompactLogix or SLC. They'll answer your questions in a free web demo. For such a high speed application, you may want to evaluate multiple packages in terms of performance and DB size.

so i tried data logging just using RSView...connected with ethernet and setting up my model to read a count every 1 hundreth of a second......i am coming out with 18 points a second roughly....but i did a ramp up of my tag from 0.3 to 42.2 and then back down and my results were terrible....it seems that it would still read the tag once a second but then report it 18 times untill it then chaged again.....i should have seen the curve but it was like 0.3 to 11.4 then said 11.4 18 times till it than changed to 19.4 and so on.

any advice??

The usual question:

What is it that you must ultimately achieve ?

Ultimately I want to know the value of an analog signal at every point at a minimum of 10 points per second. Think of it like data acquisition that's running at 10hz .. Now if I could achieve 100hz that would be optimal but I understand it's not logical especially if my scan rate is 25-40 ms per scan.... Like I stated before I can get 18 points per second but each point shows up the same during (in this test sequence) psi increase and only changes once per second. So if I look at my psi I crease in slope i see 0to 11 in one second.....well I wanna know how long it took (in milliseconds) to get from that 0 to 11 psi.... All the way up to 40psi. I think that is clear ask questions of I am not making myself clear

If this is just for research testing, not control at these speeds, it's where the AI card that plugs into a PC with xMb of buffer memory comes into play. Labview got its start as the software for that kinda stuff.

If you look into it, be sure to look at isolated, differential inputs. The low end multichannel AI card are always mulitplexed using a common signal ground and are very subject to common mode overload.

No it's not o ly for a test it will be for passing and failing ... We currently use labview and I want to set up the PLC to do it not labview cause setting up the labview program will be a huge learning curve at this point so if I can get what I have to do the job that is all I want. I guess I'm just not being clear enough as usual I have trouble explaining myef

Humm??? So my answer would be that, in general, you can achieve the benefits of faster effects with PLC side latching, averaging, buffering, etc. It doesn't sound like this will help you.

If you need those speeds, it sounds like dan's advice is on.

Jesper is dead on as well - it's hard to determine what your requirement actually is.

Care to expand again?

One other thought, the sensor has to output a change at the rate that you need to see it.

Somewhere you mention psi, so it must be pressure. What is the response of the pressure sensor?

The industrial pressure transmitters packaged for hazardous areas are 100mS update rate or slower. They have 'damping' settings that average the output value on the order of seconds.

Are you sure that your pressure transmitter is updating its output at a rate that in the range you're talking about (10mS or faster)?

What is the total signal lag of the Labview System? (Sum of input latency, processing, output hardware delays)

What is the real world origin of this data that changes every millisecond?

The fastest analog input I have worked with I think was 4ms. Many PLC digital input points aren't that fast.

So 10ms from a remote connection? Sure, but it's likely to get repeaters if your reading data from a value that is updated by some clunky ole 15ms scan delay on a RIO rack with another layer of potential delay...

I have monitored a Compactlogix Hardy Weigh module with RSLinx Pro and a good ethernet connection. There is a counter that gets updated every ten milliseconds inside the module, and I was able to trace it using RSLinx but setting that as the sole OPC topic, and maximizing the settings. This will not be realistic with a SLC, but I have a checkweigher running on a Compactlogix brick, and one of its programs has a 10ms cycle, and I used its built in CPU incremental counter to test the speed of RSLinx OPC using excel to read that 10ms counter.

Also, on the PAC for that app, I capture data from the hardy module every 10ms into a large array which then gets transferred to the pixel size of my HMI scatter graph of the raw weight on an in motion case weighing application. The scan time of the main is averaging about 2-3ms IIRC and I did set it to 5ms for a test, and I did see almost even duplication in the array.

This is not, in my opinion, possible with a SLC, perhaps some of the Micrologix are fast enough to do this.

If you labview data is getting gathered at 10ms, I would keep it and learn it. Stepping down to a PLC might be a huge error.

it seems that it would still read the tag once a second but then report it 18 times untill it then chaged again.....

Click to expand...

you didn't mention what hardware you're using – so this is just a GUESS - but based on your statement quoted above, you MIGHT find the information in the following link to be helpful ...

http://www.plctalk.net/qanda/showthread.php?p=391975&postcount=1

it deals with the interaction between RPI (Requested Packet Interval) and RTS (Real Time Sampling) ...

the analogy about the daily newspaper in post #4 should give you the basic idea ... the graphs throughout the thread should help with the details ... I've attached a randomly chosen sample below ...

good luck with your project ...

.

You sure can. Try OPC Desktop Historian. It's a light weight historian that is reliable and comes with many tools to help you analyze your data after.

Look at Beckhoff Automation's EtherCAT. I use it because it was the only PLC fast enough for our needs in 2004 (still is). Most AI modules can sample at 10 kSps and PLC cycle time can run at 0.1 ms with the better CPU's. I see smooth 1 kHz sine waves on the PC side. The special EL3102 module can sample at 100 kSps, if you ever need that (returns N samples per cycle). Beckhoff terms "Scientific Automation", meaning they play in National Instrument's space. You should also be able to use NI's CompactRIO modules since their expansion chassis uses EtherCAT. You will find the costs less than A-B or Siemens and the wiring simpler and robust. Their new TwinCAT3 will allow the PLC to be programmed similar to the embedded devices that EE normally use (Visual Studio, C++, etc). For now they support the 5 IEC lanuages (I use mostly ST), via modified CodeSys environment. Wago is similar (slower K-bus modules).

As far as getting data to the PC, I agree it is best to store an array of samples in the PLC and bring it across periodically, as one does with most plug-in A/D boards. That is what I do. Another approach (simpler?) would be to continually poll the PLC for the latest values each time sample, as you currently do. Maybe the PC would be fast enough and real-time enough that its clock gives the "almost true" sample time, but better to read the PLC's "run clock" each time to get the "truer" sample time. Obviously, insuring time synchronization can be problematic, which is why I suggest the "move arrays" method above. You can probably store all the data in the PLC memory and move a single array at the end of recording, so you don't need "ping-pong handshakes" if moving multiple arrays.

If it's only for a test, the RSLogix software has a trend function you can use to capture the data at a fast rate.

Then you can export the captured trend data to a CSV file, and manipulate it as you wish

thank you guys for all the comments, the hardware has not been bought yet.....that's why I had said I was testing. the test hardware was a PLC5/40....the reason for discussing this on the forum was to see what hardware I should look at if compact logix is capable of such a task than this is the option I will lean towards when I build the panel. it will be implemented soon tho...someone else, as I was looking at a million different forum posts, had said something that I may end up noting in the next team meeting....."PLC's are optimized for running and solving logic, not data acquisition." simply stated, and we may just need to have the curve ball thrown at us...or well me....and try to configure the compact logix to communicate with Labview. it would be the only logical solution if we wanted to collect data at 100hz. even though the CGS states that we only need 10 readings per second. with 10 readings per second I feel a PLC is more than adequate but I could be wrong.... if we do however go with compact or even controllogix...Ron the post you lead me to was very very helpful! seems I can get a nice curve if I adjust my RPI and/or RTS just right.

anyone have experience with NI's Labview communicating with compactlogix? there are some posts about it but most are unanswered.