Logging Data (not by me)

Post any examples or modules that you want to share here
User avatar
JB_AU
Posts: 171
Joined: Tue May 21, 2013 11:01 pm

Logging Data (not by me)

Post by JB_AU »

Here's a very good example of using Ruby to log data continuously , many thanks to Carl & support :)
Attachments
Ruby Data Logger.fsm
(6.71 KiB) Downloaded 1555 times
"Two things are infinite: the universe and human stupidity; and I'm not sure about the the universe."

Albert Einstein
GLIC
Posts: 11
Joined: Tue Sep 11, 2018 3:00 pm

Re: Logging Data (not by me)

Post by GLIC »

Hi.

Nice logger.

Just one problem with it - when it gets time, its not very accurate. How to fix this data logger so instead of getting real time it just counts from zero in milliseconds?

Thank you

p.s.
I am really lousy on any normal programming languages (including ruby) so that is why I am using FlowStone. :oops:
User avatar
nix
Posts: 817
Joined: Tue Jul 13, 2010 10:51 am

Re: Logging Data (not by me)

Post by nix »

type 'time' into the toolbox mate
does that help?- trigger it at 250hz with Ruby for accuracy,
or whatever for a demo period
GLIC
Posts: 11
Joined: Tue Sep 11, 2018 3:00 pm

Re: Logging Data (not by me)

Post by GLIC »

nix wrote:type 'time' into the toolbox mate
does that help?- trigger it at 250hz with Ruby for accuracy,
or whatever for a demo period


It does not help because Time module as well communicates with Windows and not accurate enough.

I am triggering (pushing data) with actual data received from a Phidgets board at what ever rate it has, so time stamp from Windows is not accurate enough. If from the beginning of log Ruby itself was counting time and stamping it at the rate of data input from Phidgets board it should be fine.
User avatar
nix
Posts: 817
Joined: Tue Jul 13, 2010 10:51 am

Re: Logging Data (not by me)

Post by nix »

here is ruby time->
time(secs).fsm
(1.25 KiB) Downloaded 1247 times


what do we need to do here- do u have a schematic?
I can try and do the requisite automation, but I don't have the electronics
GLIC
Posts: 11
Joined: Tue Sep 11, 2018 3:00 pm

Re: Logging Data (not by me)

Post by GLIC »

nix wrote:here is ruby time->
The attachment time(secs).fsm is no longer available


what do we need to do here- do u have a schematic?
I can try and do the requisite automation, but I don't have the electronics



Hopefully file attached makes more sense what I am trying to achieve.
If to compare time signature from 1st column (generated by Ruby get time) to 2nd column (generated by Ruby tick) obvious that there is some kind of latency fluctuation.
3rd column is just generated random number to represent data coming from sensor.

So how to modify data loggers Ruby code in order to replace 1st column with just a simple timer. I don`t trust external module to represent time for this task, because seems like there is some kind of delay issue between modules.

And its looks like Ruby is eating more resources than something built with primitive modules.
Attachments
Ruby Data Logger mod.fsm
modified example
(141.82 KiB) Downloaded 1206 times
tulamide
Posts: 2714
Joined: Sat Jun 21, 2014 2:48 pm
Location: Germany

Re: Logging Data (not by me)

Post by tulamide »

The question is, why do you think you need a timer/counter/etc running totally unrelated to the phidget prim? That's not the way to log data from Phidget prims. They are green prims, which means, they are event based. They pass a value as soon as the phidget hardware sends it. So just store them in a buffer in RAM (for example as a string). You can then regularly save the buffer to a file, without working on milliseconds. For example, the file could be stored once each minute. That's also less stressfull for your computer.
"There lies the dog buried" (German saying translated literally)
GLIC
Posts: 11
Joined: Tue Sep 11, 2018 3:00 pm

Re: Logging Data (not by me)

Post by GLIC »

tulamide wrote:The question is, why do you think you need a timer/counter/etc running totally unrelated to the phidget prim? That's not the way to log data from Phidget prims. They are green prims, which means, they are event based. They pass a value as soon as the phidget hardware sends it. So just store them in a buffer in RAM (for example as a string). You can then regularly save the buffer to a file, without working on milliseconds. For example, the file could be stored once each minute. That's also less stressfull for your computer.


So how I will know time of event happened without timestamping it? If I running experiment, I need to know exact time (in miliseconds) when event did happened so I can compare experiments results after. Its pointless for me to have data points without timeline.
tulamide
Posts: 2714
Joined: Sat Jun 21, 2014 2:48 pm
Location: Germany

Re: Logging Data (not by me)

Post by tulamide »

GLIC wrote:
tulamide wrote:The question is, why do you think you need a timer/counter/etc running totally unrelated to the phidget prim? That's not the way to log data from Phidget prims. They are green prims, which means, they are event based. They pass a value as soon as the phidget hardware sends it. So just store them in a buffer in RAM (for example as a string). You can then regularly save the buffer to a file, without working on milliseconds. For example, the file could be stored once each minute. That's also less stressfull for your computer.


So how I will know time of event happened without timestamping it? If I running experiment, I need to know exact time (in miliseconds) when event did happened so I can compare experiments results after. Its pointless for me to have data points without timeline.

If you mean the exact time, when the hardware did something, the answer is never. No matter the preciseness of a timing system. This is due to the event system used.
If you mean the exact time, when Flowstone passes a new value, that's done easy by triggering the time prim. That's the internal system clock, down to milliseconds precisely. You won't get any more precise than that.

A bit more info:
Green isn't time based. It's event based. So there is no timing at all.
Ruby runs at 100 Hz. You get a time value only precise to each 10ms.
Blue runs at sample rate (for example 44100 Hz), but the input/output is buffered (often times to 10ms or more), so it won't be more precise than Ruby for your specific application.
The system clock runs on a quartz and is the most precise timing measurement you can get. At request it will pass the exact time (unbuffered).
"There lies the dog buried" (German saying translated literally)
GLIC
Posts: 11
Joined: Tue Sep 11, 2018 3:00 pm

Re: Logging Data (not by me)

Post by GLIC »

Thank you
Post Reply