Offline Data Logger

billwatson · 2017-05-11 05:57:51

Hi everyone,

What are your thoughts as to the best and simplest way to set up and use an offline data logger?

I'm wanting to log 3 - 10 analog signals at a time and use that data to generate some graphs and tables.
What do you think? Should I try the Database block, or have a go at Rexlang?

I'm thinking that a full database would be overkill and getting that info to excel might be a better approach.

billwatson · 2017-05-11 12:19:57

Hi everyone,

What do you think is the best way to setup Rex to capture analog samples for an offline database?

Should I go down the path of the database block, or with the rexlang block, or is there other options more suited to my purpose?

I'm wanting to compare analog inputs and create graphs and tables of their differences to use in documents.
I would be wanting to create separate files for each sequence run so I can do all the analysis work later.

Initially I would only be recording two AI and 1AO, but would expand to six AI and 3 AO.

I'd like to hear your opinion on how I should best invest my time.

scoobsalamander · 2017-05-11 12:58:56

Maybe you should take a look at Influxdb as time series database and Grafana for visualization. Both are free to use.

example on Raspberri Pi : http://engineer.john-whittington.co.uk/ … b-grafana/

Instead of using a Python script you can post your data straight from REXcontrols to the Influxdb.

https://www.rexygen.com/oldforum/viewt … 1290#p1290

Last edited by scoobsalamander (2017-05-11 12:59:45)

oza77 · 2017-05-11 14:18:04

Hi,

how about using REX 2.50.1.7567\Bin\RexArc.exe that uses REA files from REX archives ?
It is easy to use and it generates CSV files.

Last edited by oza77 (2017-05-11 14:18:31)

jaroslav_sobota · 2017-05-13 15:36:43

Hi Bill,
can you please provide more details about the signals? What sampling rate? How long will the logging take (minutes, hours, weeks, ... )?

There are multiple approaches to achieving what you need, therefore having more information would be helpful for choosing the most appropriate method.

The internal archiving system of REX mentioned by oza77 is certainly valid.

Thanks.

Jaroslav

billwatson · 2017-05-14 08:22:27

Thanks for your suggestions Scoobsalamander, I'll have a look around both of those thoughts.

billwatson · 2017-05-14 08:40:30

Hi oza77 and Jaroslav,

Thanks oza77, I'm back in the computer saddle this evening and will check that one out

Here's some further info Jaroslav. The scope of the project is to verify process instruments. The signals would all be 4-20ma, sample rate would be approx 1/s for each signal. The logging would be for between 10 - 30 mins for the whole verification run (will know more when we build the test rig), however it would be good to also store the values at a specified moment when a verification point is accepted by the program.

Thanks for your thoughts on this. Looking forward to your response.

billwatson · 2017-05-14 08:51:54

oops, forgot to mention how I will use the data.

I would be using the data to generate a verification pass/fail document for the tested instrument

jaroslav_sobota · 2017-05-16 08:55:45

Hi Bill,
I would use the TRND or TRNDV block for storing the signals during the verification run. After the data is collected, you can read the data using RexDraw/RexView and export it to CSV. Or you can read the data via REST API, which would allow you to automate the whole process. In that case you simply download a CSV file from the target device, e.g. from

http://192.168.1.100:8008/api/tasks/mytask/TRND?export&mime=text/plain

In this case the data is stored only in RAM. If you need to store the data permanently, you can still use REX archives (binary files on disk), REXLANG block (text files on disk), or a database (either on the same machine or external).

Another solution could rely on the EPC block, which allows you to collect data from the verification run and then process it using an external script or program. You could e.g. generate graphs using gnuplot and send it via e-mail. This requires a bit of Linux scripting skills but the advantage is that everything is performed on the same machine (Raspberry Pi) and you only export the resulting graphs.

Unless you need to combine data from individual verification runs together, you should be fine with one of these approaches.

Hope this helps!

Best regards,
Jaroslav

PS It would be nice to know the PASS/FAIL conditions. Maybe it would be possible to evaluate them during or right after the verification run...

billwatson · 2017-05-18 22:15:58

Hi Jaroslav, thanks for all the information!

I'll have a look at all of these and consider which one most suits my needs. Lots of options, I love it!
I'm away riding dirt bikes this weekend so it may take a week for me to get back into this.

I hadn't considered generating the reports from the pi. My only concern with that is the user having to input a lot of device data (serial numbers etc) on a hmi on a rig that is to be used in the field. I've found those screens very hard to see sometimes when outdoors.

The pass fail condition is only based on an error tolerance of the tested meter to the reference meter. If any of the points fail the run is failed. The error allowed will be entered in via the hmi before the run starts.

it would be nice to see a quick report after each run so I may have to use a couple of your options!

Thanks again,

Have a great weekend

REXYGEN Community Forum

Announcement

REXYGEN forum has been moved. This one is closed.
Head over to the new REXYGEN Community Forum at https://forum.rexygen.com.

Looking forward to meeting you there!

#1 2017-05-11 05:57:51