Planning how an application will work...? Is it worth it? 4

[kaywarner]

Hi All,

Thanks for reading the post.

I'm a beginner/intermediate programmer and before I dive into my first (not-a-tutorial) program I would like some advice on how I should arrange everything, I hope you can help;

Here goes;

The application needs to read a stream of data (from a temp sensor), do a small sum with the data and plot a graph (which will be over time (sec)). Thats it.

Here's what I had in mind;

-Link up the programme with the sensor.

-Create 2 variables, called "Now" and "Last"

-Create an Array with the two variables with "Last" := 0

-Let "Now" := whatever the current data stream value is.

-Pass the "Now" variable to the "Last" variable and then get a new "Now" value.

-Loop the programme to do this once a second.

-Set up a graphic that uses Now and Last as "y" co-ord with "x" co-ord being time.

-Then on the side, a little TEdit could output "Increase" or "Decrease"

So,

Any ideas why this might not work? or are there better trees to bark up??!!

Cheers for your time all,

Kay

 

[DjangMan]

I'd consider a database to store the data and plot the data from the database. You'd have the data for your plot and you have history as well to longer timescale plotting.

 

[kaywarner]

That's excellent thank you, I'll look into that.

Could I use a Dynamic Array for this?

I'm thinking that I could load everything into a Dynamic Array and then reference the graph and the calc to that location.

Is it possible for any array to move a value down? so the value in A,n gets the value in A,n+1 after an OnEdit event? "Add one to the top" so to speak?
cheers,

Kay

 

[DjangMan]

You could use a TList to keep track of a list of your points and then you're freed up from writing lots of management code. Your database can also be in memory as well thereby freeing up even more management code. Create the table in memory and then add records to it.

 

[sggaunt]

Here are some other quite basic question you need to ask.

Do you know what format the 'Data' coming from your sensor will take.

How is it to be interfaced ? Some sensors out put a simple analog voltage that would have to be converted with AtoD hardware.
Some output actual values using a standard or proprietary protocol. You need to know how to extract the readings from this if that's the case.
The high level protocol could vary. e.g RS232, RS485, Ethernet, I2C, Modbus, etc, etc, you need to know what this is and how to handle it.
As far as the program is concerned the plan you have is fine you just need a number its simple to detect which direction it is moving in you seem to have that.
If you don't need to store the values then you don't need a database simply plot the values in real time.
On TCanvas. and print the direction of movement in an edit box as you say.







Steve: N.M.N.F.
If something is popular, it must be wrong: Mark Twain

 

[Griffyn]

I agree with the database approach to store the data too. This way, you can separate the program (if required later) into two components: one retrieves and records the data, the other displays the recorded data. This allows for the data retrieve/record process to be stored on a server or written as a service application.

It also allows you to do all sorts of testing with data that hasn't originated from the sensor, by simply creating a table of data for you to plot. It will allow multiple users to view the data, without needing direct access to the sensor data stream.

 

[smays]

Kay,

I am curious, in general, what would you say is your level of expertise with programming/automation and accessing/using databases? Unless you are familiar with databases, SQL, and the like, I would concern yourself with database stuff later.

All of us would like you to be successful with your program, etc... I started this kind of programming back in 1999, and I am very familiar with this kind of program and I know what it is like approaching this sort of thing for the first time (which I realize may not apply to you, you might be well versed in this sort of thing).

Today, unless you have a particular database in mind, SQLite, MySQL, BDE, Access, SQLServer, etc... just focus on acquiring data from the sensor, after which we can show you plenty of simple, creative ways of storing the data to be processed later.

Steve.

 

[kaywarner]

A massive thank-you-to-all, your feedback is excellent and helped be out no end.

Steve - my experience is marginal to naff all with SQL, Databases etc. I'm a structural engineer by day job and i'm working with a friend on a carbon fiber research project - so i'm learning on the fly!

DJangMan - I like the idea of the TList Box, i have used these several times before on tutorials so i think i could work this, thanks for the tip

sggaunt - cheers for this post, I had not even begun to consider this. I was of the assumption that the sensor would just output a number(!) i'll look into this if this and post back here what i find.

 

[mjfeldman]

Organize to divide and conquer from the beginning:

1) Acquisition
2) Processing (possibly optional but allow for it)
4) Storage (possibly optional but allow for it)
3) Display

Consider the volume of data you expect to be dealing with over a given time period. By avoiding a database or other disk storage and storing everything in memory you may quickly run out of memory with a high data volume. (But not likely with temperature readings I'd guess which will not change or be sampled rapidly.)

It sounds like your database needs are dead simple (one table, two columns - timestamp and datavalue - no relationships with any other tables) so I would not be scared off from that aspect.

If you do use memory storage, don't confuse Tlistbox with its parent TList, which is all you need since you are not actually displaying the list as a list (although a Listbox might be useful for debugging).

You did not say if you are sampling some industrial process or just your home weather station, but if it is important to know the direction the temperature is trending, you *will* want to store your data. The critical term being "trend".

Whether a single reading is higher or lower than the previous one does not actually tell you much. You may not want/need to do anything even as fancy as a moving average, but even comparing not the immediately previous reading but, say, the reading 100 seconds earlier may be more meaningful.

Good luck, have fun!

 

[kaywarner]

Organize to divide and conquer from the beginning"....Top Quote....!!!

I learnt this the hard way - even doing online/text book tutorials I had plenty of false starts...hence this thread!

I think from further reading (Ivan Hladni's "Inside Dephi 2006" and Ray Buchanan's "Master Series" books) and your post i'll go for a TList.

I've started to write the progamme now, but have decided to get the information using a file pointer to a .txt file as a start. Main reason is that trying to link in sensors, dll's, TLists etc all at once while i'm still a rookie almost gave me a nose bleed - so one step at a time i think!!!

I've put some arbitory data in a txt file, i'll work on reading that to the TList, then doing the calc then finally worry about communicating with exotic sensors later.

Whatch this thread for future updates...i'll let you know how it goes!