Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.os.msdos.programmer > #471 > unrolled thread

A Warning System

Started byKnut Schroder <Knut.Schroder@chem.ntnu.no>
First post2012-02-11 12:12 +0100
Last post2012-02-12 15:20 +0000
Articles 17 — 5 participants

Back to article view | Back to comp.os.msdos.programmer


Contents

  A Warning System Knut Schroder <Knut.Schroder@chem.ntnu.no> - 2012-02-11 12:12 +0100
    Re: A Warning System DOS Guy <DOS@Guy.com> - 2012-02-11 08:33 -0500
    Re: A Warning System "Auric__" <not.my.real@email.address> - 2012-02-11 22:34 +0000
      Re: A Warning System Knut Schroder <Knut.Schroder@chem.ntnu.no> - 2012-02-12 17:49 +0100
        Re: A Warning System DOS Guy <DOS@Guy.com> - 2012-02-12 13:19 -0500
          Re: A Warning System DOS Guy <DOS@Guy.com> - 2012-02-12 17:12 -0500
        Re: A Warning System "Auric__" <not.my.real@email.address> - 2012-02-13 03:25 +0000
          Re: A Warning System "Auric__" <not.my.real@email.address> - 2012-02-13 03:30 +0000
            Re: A Warning System Knut Schroder <Knut.Schroder@chem.ntnu.no> - 2012-02-13 18:08 +0100
              Re: A Warning System "Auric__" <not.my.real@email.address> - 2012-02-14 05:25 +0000
                Re: A Warning System Knut Schroder <Knut.Schroder@chem.ntnu.no> - 2012-02-29 13:41 +0100
                  Re: A Warning System "Auric__" <not.my.real@email.address> - 2012-02-29 13:20 +0000
                  Re: A Warning System DOS Guy <DOS@Guy.com> - 2012-02-29 23:33 -0500
                    Re: A Warning System Sjouke Burry <s@b> - 2012-03-01 05:04 +0000
                      Re: A Warning System DOS Guy <DOS@Guy.com> - 2012-03-01 10:01 -0500
                        Re: A Warning System Knut Schroder <Knut.Schroder@chem.ntnu.no> - 2012-03-11 09:51 +0100
    Re: A Warning System pete@nospam.demon.co.uk - 2012-02-12 15:20 +0000

#471 — A Warning System

FromKnut Schroder <Knut.Schroder@chem.ntnu.no>
Date2012-02-11 12:12 +0100
SubjectA Warning System
Message-ID<jh5ifv$f2a$1@orkan.itea.ntnu.no>
Hello,

Is there anybody who can help me with a problem?

We have developed a system for automatic monitoring of some pollutants 
in the environment.

The levels of the different pollutants are measured (typically every 
hour) and the results are calculated using a PC (WINDOWS XP or 7) and 
stored as a line in a text file. The results for the subsequent 
measurement is stored as a new line in the same file and so on.

What I want is a small program which runs in the background and monitors 
the last line in the text file, and if the results there exceed some 
given values, some action is taken (like sending the last line with SMS 
or switching a relay or giving a sound from the PC).

I am a chemist and not a programmer, but I assume that simple solutions 
are available. Can you help me with a link or other information.

Thank you
Knut Schroder

[toc] | [next] | [standalone]


#473

FromDOS Guy <DOS@Guy.com>
Date2012-02-11 08:33 -0500
Message-ID<4F366E45.556768C4@Guy.com>
In reply to#471
Knut Schroder wrote:
 
> We have developed a system for automatic monitoring of some
> pollutants in the environment.
> 
> The levels of the different pollutants are measured (typically
> every hour) and the results are calculated using a PC (WINDOWS XP
> or 7) and stored as a line in a text file. The results for the
> subsequent measurement is stored as a new line in the same file
> and so on.
> 
> What I want is a small program which runs in the background and
> monitors the last line in the text file, and if the results there
> exceed some given values, some action is taken (like sending the
> last line with SMS or switching a relay or giving a sound from
> the PC).
> 
> I am a chemist and not a programmer, but I assume that simple
> solutions are available. Can you help me with a link or other
> information.

It's trivial to write a basic program (gwbasic, powerbasic, etc) and
have it open a text file for read access and read the entire file - line
by line - until it reaches the end.  It would simply read in these
values into same variable or array (because it only has to know the last
value at the end of the file - not all preceeding values).

The easiest thing for a basic program to do is "BEEP" or send out
multiple beeps if your warning conditions are met.  Having the program
do anything else (like send an e-mail) is tricky, and sending an SMS is
really complicated.

So if an audible beep or series of beeps is satisfactory, then that's
easy to do.

I would suggest that if possible, that your pollution monitoring program
write the last measurement value to a separate text file so that the
warning program doesn't have to read through the entire log file every
time it wants to get to the last set of values.

The warning program can run continuously, and it can check your
pollution values on a fixed schedule (once per second, once per minute,
once per hour, etc) based on checking the $date and $time variables. 
The warning program could also open it's own log file to log the date
and time that it detected a warning condition.

[toc] | [prev] | [next] | [standalone]


#474

From"Auric__" <not.my.real@email.address>
Date2012-02-11 22:34 +0000
Message-ID<Xns9FF69EBA73534auricauricauricauric@88.198.244.100>
In reply to#471
Knut Schroder wrote:

> Is there anybody who can help me with a problem?
>
> We have developed a system for automatic monitoring of some pollutants
> in the environment.
>
> The levels of the different pollutants are measured (typically every
> hour) and the results are calculated using a PC (WINDOWS XP or 7) and
> stored as a line in a text file. The results for the subsequent
> measurement is stored as a new line in the same file and so on.
>
> What I want is a small program which runs in the background and monitors
> the last line in the text file, and if the results there exceed some
> given values, some action is taken (like sending the last line with SMS
> or switching a relay or giving a sound from the PC).
>
> I am a chemist and not a programmer, but I assume that simple solutions
> are available. Can you help me with a link or other information.

(This was inspired by DOS Guy's post.)

This FreeBASIC program will do what you want, for the most part. It's not 
the *best* way to do it, perhaps, but it works.

'--------------------------------------------------------------------
  #IFNDEF WIN_INCLUDEALL
    #DEFINE WIN_INCLUDEALL
  #ENDIF
  #INCLUDE ONCE "windows.bi"

  'Adjust this number as appropriate; whole numbers or real numbers,
  'positive or negative.
  CONST limit = 99999

  hnd = FREEFILE
  OPEN "measurements.txt" FOR INPUT AS hnd
  DO UNTIL EOF(hnd)
    LINE INPUT #hnd, i$
    IF LEN(i$) THEN f$ = i$
  LOOP
  CLOSE hnd
  IF VAL(f$) > limit THEN
    'This line will play the sound continually until the user
    'clicks the OK button on the alert.
    sndPlaySound "alert.wav", SND_ASYNC OR SND_LOOP
    MessageBox NULL, "Parameters exceed limits: " & f$, _
                     "Limit is " & STR$(limit), MB_OK
    sndPlaySound "", SND_SYNC
  END IF
'--------------------------------------------------------------------

Copy the above block of text to a file (the name is unimportant but it must 
end with ".bas", i.e. "test.bas"). Compile it with FreeBASIC using this 
command:
  fbc -s gui -lang fblite test.bas
(FreeBASIC is available from http://www.freebasic.net/get -- I recommend 
you download the Windows installer, not the zip archive.)

Put the program and alert.wav in the same directory. (The same directory as 
the text file is okay; anywhere else is fine too.) Make alert.wav some 
appropriately loud and obnoxious noise. ("alert.wav" must be a wav file, 
not just a renamed mp3 or whatever, or you'll just get the default beep.)

This program assumes that the *only* thing on the line in the text file is 
a single number; anything else will give unexpected results. (Post an 
example of what the text file looks like and I'll adjust the program 
appropriately.)

It also assumes that it's being run by whoever happens to be logged in. If 
it's being run as user "foo" but user "bar" is logged in, "bar" will hear 
the alert but be unable to do anything about it until "foo" (or an 
administrator) logs in and kills it.

Schedule it to run however often you want using the Windows scheduler. 
(Tell it to run "daily", and repeat every so many minutes or hours or 
whatever, for 23 hours and 59 minutes. Again, have it run as whoever is 
normally logged in to that particular machine.) Tell the scheduler to start 
the program in the same directory as the text file.

If there usually isn't anyone logged in to that particular machine (i.e. a 
dedicated server), tell the scheduler to stop the task after 0 hours and 1 
minute (or however long you want it to run).

-- 
"Reality" is a slippery notion.

[toc] | [prev] | [next] | [standalone]


#476

FromKnut Schroder <Knut.Schroder@chem.ntnu.no>
Date2012-02-12 17:49 +0100
Message-ID<jh8qjh$mu9$1@orkan.itea.ntnu.no>
In reply to#474
Thanks to DOS Guy and Auric__, this is very useful.

A typical txt file is like:

Date/Time,Zn,Pb,Cu,All Units in ppb
19.01.2012 13:27:43, 547.3, 19.4, 9.5
.......
.......
19.01.2012 16:00:42, 515.5, 20.5, 8.3
19.01.2012 16:15:42, 524.5, 17.4, 9.2
19.01.2012 16:30:42, 731.7, 28.0, 10.6

The first line is a heading with Date/Time and the different polluting 
metals, and then the lines with the subsequent measuring results.
Say the legal maximum levels of the three metals are 650.0, 40.0 and 
20.0 respectively. Then the alarm should be given after the last 
measurement. Auric__ kindly offered to adjust the program appropriately.

The beeping is of course the easiest way to do this, but it will be a 
great advantage if also a relay could be opened (or closed). Could that 
be arranged through USB or another way? With such a relay, a discharge 
of sewage to a lake can be stopped and it is also very simple to connect 
it to a cheap alarm system using SMS-messages, like 
http://www.ondico.se/index.php?page=3.4 (I am sorry, this is in Swedish 
only).

Thank you very much,
Knut

On 11.02.2012 23:34, Auric__ wrote:
> Knut Schroder wrote:
>
>> Is there anybody who can help me with a problem?
>>
>> We have developed a system for automatic monitoring of some pollutants
>> in the environment.
>>
>> The levels of the different pollutants are measured (typically every
>> hour) and the results are calculated using a PC (WINDOWS XP or 7) and
>> stored as a line in a text file. The results for the subsequent
>> measurement is stored as a new line in the same file and so on.
>>
>> What I want is a small program which runs in the background and monitors
>> the last line in the text file, and if the results there exceed some
>> given values, some action is taken (like sending the last line with SMS
>> or switching a relay or giving a sound from the PC).
>>
>> I am a chemist and not a programmer, but I assume that simple solutions
>> are available. Can you help me with a link or other information.
>
> (This was inspired by DOS Guy's post.)
>
> This FreeBASIC program will do what you want, for the most part. It's not
> the *best* way to do it, perhaps, but it works.
>
> '--------------------------------------------------------------------
>    #IFNDEF WIN_INCLUDEALL
>      #DEFINE WIN_INCLUDEALL
>    #ENDIF
>    #INCLUDE ONCE "windows.bi"
>
>    'Adjust this number as appropriate; whole numbers or real numbers,
>    'positive or negative.
>    CONST limit = 99999
>
>    hnd = FREEFILE
>    OPEN "measurements.txt" FOR INPUT AS hnd
>    DO UNTIL EOF(hnd)
>      LINE INPUT #hnd, i$
>      IF LEN(i$) THEN f$ = i$
>    LOOP
>    CLOSE hnd
>    IF VAL(f$)>  limit THEN
>      'This line will play the sound continually until the user
>      'clicks the OK button on the alert.
>      sndPlaySound "alert.wav", SND_ASYNC OR SND_LOOP
>      MessageBox NULL, "Parameters exceed limits: "&  f$, _
>                       "Limit is "&  STR$(limit), MB_OK
>      sndPlaySound "", SND_SYNC
>    END IF
> '--------------------------------------------------------------------
>
> Copy the above block of text to a file (the name is unimportant but it must
> end with ".bas", i.e. "test.bas"). Compile it with FreeBASIC using this
> command:
>    fbc -s gui -lang fblite test.bas
> (FreeBASIC is available from http://www.freebasic.net/get -- I recommend
> you download the Windows installer, not the zip archive.)
>
> Put the program and alert.wav in the same directory. (The same directory as
> the text file is okay; anywhere else is fine too.) Make alert.wav some
> appropriately loud and obnoxious noise. ("alert.wav" must be a wav file,
> not just a renamed mp3 or whatever, or you'll just get the default beep.)
>
> This program assumes that the *only* thing on the line in the text file is
> a single number; anything else will give unexpected results. (Post an
> example of what the text file looks like and I'll adjust the program
> appropriately.)
>
> It also assumes that it's being run by whoever happens to be logged in. If
> it's being run as user "foo" but user "bar" is logged in, "bar" will hear
> the alert but be unable to do anything about it until "foo" (or an
> administrator) logs in and kills it.
>
> Schedule it to run however often you want using the Windows scheduler.
> (Tell it to run "daily", and repeat every so many minutes or hours or
> whatever, for 23 hours and 59 minutes. Again, have it run as whoever is
> normally logged in to that particular machine.) Tell the scheduler to start
> the program in the same directory as the text file.
>
> If there usually isn't anyone logged in to that particular machine (i.e. a
> dedicated server), tell the scheduler to stop the task after 0 hours and 1
> minute (or however long you want it to run).
>

[toc] | [prev] | [next] | [standalone]


#478

FromDOS Guy <DOS@Guy.com>
Date2012-02-12 13:19 -0500
Message-ID<4F380296.4FB64DBF@Guy.com>
In reply to#476
Knut Schroder wrote:
 
> A typical txt file is like:
> 
> Date/Time,Zn,Pb,Cu,All Units in ppb
> 19.01.2012 13:27:43, 547.3, 19.4, 9.5
> .......
> .......
> 19.01.2012 16:00:42, 515.5, 20.5, 8.3
> 19.01.2012 16:15:42, 524.5, 17.4, 9.2
> 19.01.2012 16:30:42, 731.7, 28.0, 10.6
> 
> The first line is a heading with Date/Time and the different
> polluting metals, and then the lines with the subsequent
> measuring results.

Is a new file created for each day, or is all of this being spewed into
a single (and increasingly large) text file?

Do you have any control over the design and programming of the program
that creates this file? (I assume not).

It looks like you have a new line being created every 15 minutes.

The basic program could therefore open the file for read-only access
maybe every 10 minutes (just so it doesn't miss any data) and read the
file to the end each time.

How critical is the time delay between when new data is written to the
file and when the file is read by this hypothetical warning program?

Also note this:  It's not uncommon on NT-based systems for log data to
be spooled to a file and NOT be "visible" or accessible to another
program or process until the NTFS file system has performed some
journaling action, which could happen maybe after an hour or more has
passed.  I see this a lot when it comes to web-server log files.

> Say the legal maximum levels of the three metals are 650.0, 40.0
> and 20.0 respectively. Then the alarm should be given after the
> last measurement. Auric__ kindly offered to adjust the program 
> appropriately.

Now that we know the number of variables present on each line, crafting
the proper code to read each line is easy.

> The beeping is of course the easiest way to do this, but it will be
> a great advantage if also a relay could be opened (or closed). 
> Could that be arranged through USB or another way? With such a relay,
> a discharge of sewage to a lake can be stopped and it is also very
> simple to connect it to a cheap alarm system using SMS-messages,

I would think that the simplest way to operate a relay from a compiled
basic program running under an NT-based OS is to send a control command
out through a com port (RS-232 port) to a control board that has the
appropriate relay.  Could also be done by sending through the LPT
printer port.

(NT-based OS's will present a virtualized com port to any 16-bit DOS
process or program, but in the end the DOS program will be able to send
data out of the computer's com and LPT ports as if this virtualization
layer is not present.  This would not be the case for other hardware
ports...)

I'm sure there are dozens if not hundreds of possible retail solutions
for this - here's the first one I found using a google search:

http://www.controlanything.com/Relay/Relay/RS232_Relay_Controllers

This assumes that the discharge valve to be controlled with the relay is
located relatively close to the computer (maybe 100 yards or meters at
maximum?).

And again I note that you seem to want sms messages to be sent.  It
would be easier to automate the sending of an e-mail from the computer
instead of an sms message.  It's not an easy thing to set up a
programatic interface to an sms message system.

[toc] | [prev] | [next] | [standalone]


#479

FromDOS Guy <DOS@Guy.com>
Date2012-02-12 17:12 -0500
Message-ID<4F383944.BD085638@Guy.com>
In reply to#478
DOS Guy wrote:

> And again I note that you seem to want sms messages to be sent.  
> It would be easier to automate the sending of an e-mail from the
> computer instead of an sms message.  It's not an easy thing to
> set up a programatic interface to an sms message system.

Regarding a command-prompt interface to SMS messaging:

http://www.sms-integration.com/p_41-command-line-sms.html

But setting up the SMS gateway?  Is it really worth it?

[toc] | [prev] | [next] | [standalone]


#480

From"Auric__" <not.my.real@email.address>
Date2012-02-13 03:25 +0000
Message-ID<Xns9FF7CFFA33A7Cauricauricauricauric@88.198.244.100>
In reply to#476
Knut Schroder wrote:

> Thanks to DOS Guy and Auric__, this is very useful.

Np.

> A typical txt file is like:
>
> Date/Time,Zn,Pb,Cu,All Units in ppb
> 19.01.2012 13:27:43, 547.3, 19.4, 9.5
> .......
> .......
> 19.01.2012 16:00:42, 515.5, 20.5, 8.3
> 19.01.2012 16:15:42, 524.5, 17.4, 9.2
> 19.01.2012 16:30:42, 731.7, 28.0, 10.6
>
> The first line is a heading with Date/Time and the different polluting 
> metals, and then the lines with the subsequent measuring results.
> Say the legal maximum levels of the three metals are 650.0, 40.0 and 
> 20.0 respectively. Then the alarm should be given after the last 
> measurement. Auric__ kindly offered to adjust the program appropriately.

So I did. New program at the end of this post. Somewhat longer than what I 
posted before. Shrug.

> The beeping is of course the easiest way to do this, but it will be a 
> great advantage if also a relay could be opened (or closed). Could that 
> be arranged through USB or another way? With such a relay, a discharge 
> of sewage to a lake can be stopped

*Could* it be arranged? Sure. Can *I* do it? Sorry, no, I have no 
experience dealing directly with hardware.

> and it is also very simple to connect
> it to a cheap alarm system using SMS-messages, like
> http://www.ondico.se/index.php?page=3.4 (I am sorry, this is in Swedish
> only).

I also have no experience with SMS, nor am I willing to even attempt 
writing for something that I personally don't have access to. Sorry.

New program follows...

'--------------------------------------------------------------------------
  #IFNDEF WIN_INCLUDEALL
    #DEFINE WIN_INCLUDEALL
  #ENDIF
  #INCLUDE ONCE "windows.bi"

  DECLARE SUB split(what AS STRING, divider AS STRING, target() AS STRING)

  'Legal limits here. Adjust as necessary.
  '*MUST* be in the same order as the text file!
  DIM limits(1 TO 3) AS SINGLE => {650.0, 40.0, 20.0}

  DIM a AS SINGLE, b AS SINGLE, c AS SINGLE, L1 AS LONG
  DIM hnd AS UInteger    '"datums" because "data" is a reserved word.
  DIM headers() AS STRING, datums() AS STRING

  hnd = FREEFILE
  'This assumes the filename doesn't change...
  OPEN "measurements.txt" FOR INPUT AS hnd
  LINE INPUT #hnd, i$
  split i$, ",", headers()

  DO UNTIL EOF(hnd)
    LINE INPUT #hnd, i$
    IF LEN(i$) THEN f$ = i$
  LOOP
  CLOSE hnd
  split f$, ",", datums()

  FOR L1 = 1 TO 3   'Can ignore datums(0).
    IF VAL(datums(L1)) > limits(L1) THEN
      'Send out alerts...
      sndPlaySound ExePath & "\alert.wav", SND_ASYNC OR SND_LOOP
      MessageBox NULL, headers(L1) & " exceeds limits: " & datums(L1), _
                 "Limit is " & STR$(limits(L1)), MB_OK OR MB_ICONERROR
      sndPlaySound "", SND_SYNC
    END IF
  NEXT

  SUB split(what AS STRING, divider AS STRING, target() AS STRING)
    'Public domain function. Written by Auric__. Do as thou wilt.
    DIM L0 AS LONG, found1 AS LONG, found2 AS LONG
    DIM c AS LONG = -1
    DO
      found2 = INSTR(found1 + 1, what, divider)
      IF found2 THEN
        c += 1
        REDIM PRESERVE target(c)
        target(c) = MID$(what, found1 + 1, (found2 - found1) - 1)
        found1 = found2
      ELSE
        'Last item.
        REDIM PRESERVE target(c + 1)
        target(c + 1) = MID$(what, found1 + 1)
        EXIT DO
      END IF
    LOOP
  END SUB
'--------------------------------------------------------------------------

Still FreeBASIC, instructions are the same as before. (alarm.wav in the 
same dir as the program, etc.)

This assumes a few things:
- the text file's name never changes (i.e. "report.txt", "data.lst", etc.)
- the text file's format never changes (always pretty much like you posted)
- there's a human being present and ready & able to react as necessary

If you find someone else who can automate the "shut off the flow" part, it 
should go immediately above or below the line that says "Send out alerts".

Also, this works somewhat like pete's suggested shell script, except a 
shell script would be *lots* easier to change... but you'd need a Unix-like 
system installed on the Windows machine to make a shell script work. (There 
are a few -- Cygwin, mingw, Ch, etc.) A set of batch files may or may not 
be able to do this, possibly VBscript could, etc. -- what I've posted is 
just one way of doing things.

-- 
Don't remember where I was when I realized life was a game.
The more seriously I took things, the harder the rules became.

[toc] | [prev] | [next] | [standalone]


#481

From"Auric__" <not.my.real@email.address>
Date2012-02-13 03:30 +0000
Message-ID<Xns9FF7D0D25A845auricauricauricauric@88.198.244.100>
In reply to#480
I wrote:

> - the text file's name never changes (i.e. "report.txt", "data.lst", etc.)

Forgot to mention, this comes directly as a result of DOS Guy's post -- I 
hadn't thought about the file name changing. (The logfile might be, for 
example, a date -- "2012-02-12.txt" for example.) If the name *does* change, 
that's another problem to be dealt with.

-- 
There's a moral here -- never post when you're very, very tired.

[toc] | [prev] | [next] | [standalone]


#482

FromKnut Schroder <Knut.Schroder@chem.ntnu.no>
Date2012-02-13 18:08 +0100
Message-ID<jhbg2e$dfs$1@orkan.itea.ntnu.no>
In reply to#481
Thanks to Pete, DOS Guy and Auric_ for all help, and in particular to 
Auric_ for making the program.

I have tested it and it seems to work fine.

You have sent some questions:
- The measuring series can last over several months, and the file with 
all the results has always the same name (Scan.log) and format (except 
from the number of lines). If we start another measuring series later 
on, we make another directory for it.

- Normally the measurements are unattended on a measuring station far 
away with the PC there, or with a PC connected to the station via 
internet. That is the reason for being so keen on SMS, email and relay 
switching in additional to the beep.

- We have not control over the program that creates the file.

- The time delay between the new data line is written to the file and 
the run of the warning is normally not critical. However, as this could 
be due to a damage, it should not be too long.

I have one question:
What happens if the alarm program happens to run just when a new line is 
inserted in the Scan.log?

I will certainly have more questions later on after being more familiar 
with all this.

Greetings, Knut

On 13.02.2012 04:30, Auric__ wrote:
> I wrote:
>
>> - the text file's name never changes (i.e. "report.txt", "data.lst", etc.)
>
> Forgot to mention, this comes directly as a result of DOS Guy's post -- I
> hadn't thought about the file name changing. (The logfile might be, for
> example, a date -- "2012-02-12.txt" for example.) If the name *does* change,
> that's another problem to be dealt with.
>

[toc] | [prev] | [next] | [standalone]


#483

From"Auric__" <not.my.real@email.address>
Date2012-02-14 05:25 +0000
Message-ID<Xns9FF8E438C934Cauricauricauricauric@88.198.244.100>
In reply to#482
[Second attempt posting this.]

Knut Schroder wrote:

> Thanks to Pete, DOS Guy and Auric_ for all help, and in particular to
> Auric_ for making the program.

Np.

> I have tested it and it seems to work fine.

Good.

> You have sent some questions:
> - The measuring series can last over several months, and the file with
> all the results has always the same name (Scan.log) and format (except
> from the number of lines). If we start another measuring series later
> on, we make another directory for it.

Might I suggest renaming the log file (once it's no longer the "active" 
log) to a datestamp? (Something like "20120101-20120131.log" or whatever.) 
That way you can tell what dates are included in the file without the need 
to open it to check.

> - Normally the measurements are unattended on a measuring station far
> away with the PC there, or with a PC connected to the station via
> internet. That is the reason for being so keen on SMS, email and relay
> switching in additional to the beep.

From what I've read, controlling a relay from the program shouldn't be too 
difficult if it is connected to the PC in some standard way. Many 
manufacturers supply sample code to show you how it's done.

> - We have not control over the program that creates the file.
>
> - The time delay between the new data line is written to the file and
> the run of the warning is normally not critical. However, as this could
> be due to a damage, it should not be too long.

As DOS Guy pointed out, the data seems to be added every 15 minutes. 
Therefore, running my program every 15 minutes seems to be all that's 
required. More often is fine; less often might miss a problem.

Another thing that he pointed out is that the actual writing of the data to 
the file on disk might be delayed by the operating system, sometimes by 
seconds, but on rare occasions by *hours*.

> I have one question:
> What happens if the alarm program happens to run just when a new line is
> inserted in the Scan.log?

Hm... depends on the timing, and how the data program opens the log. 
Replace this block:
'------------------------------------------
  OPEN "measurements.txt" FOR INPUT AS hnd
  LINE INPUT #hnd, i$
  split i$, ",", headers()

  DO UNTIL EOF(hnd)
    LINE INPUT #hnd, i$
    IF LEN(i$) THEN f$ = i$
  LOOP
  CLOSE hnd
  split f$, ",", datums()
'------------------------------------------

with this block:

'------------------------------------------------
  DO
    IF OPEN ("scan.log", FOR INPUT, AS hnd) THEN
      SLEEP 1000
    ELSE
      EXIT DO
    END IF
  LOOP

  LINE INPUT #hnd, h$

  DO UNTIL EOF(hnd)
    LINE INPUT #hnd, i$
    IF LEN(i$) THEN f$ = i$
  LOOP
  CLOSE hnd

  split h$, ",", headers()
  split f$, ",", datums()
'------------------------------------------------

What this change does is, if there's an error opening the log, the program 
waits a second and then tries again, repeating until it succeeds. (I also 
moved a bit of data mangling to after the file is released to reduce the 
amount of time the file is actually open.)

As for what might happen to the data program (the one that is logging) if 
it tries to open the log while my program is reading it, nothing should 
happen.

> I will certainly have more questions later on after being more familiar
> with all this.

Ask away.

-- 
Rock on! We're descended from the wicked stepmother!

[toc] | [prev] | [next] | [standalone]


#487

FromKnut Schroder <Knut.Schroder@chem.ntnu.no>
Date2012-02-29 13:41 +0100
Message-ID<jil6de$vna$1@orkan.itea.ntnu.no>
In reply to#483
It seems now that the alarm system works fine.

I have now also connected a relay via an USB port. However, different 
COM port is automatically assigned from one installation to another and 
consequently I have to change the COM port in the freebasic program 
accordingly. Of course this is inconvenient.
Is it possible to "force" this port to be a given one, say COM7?

Greetings from Knut

On 14.02.2012 06:25, Auric__ wrote:
> [Second attempt posting this.]
>
> Knut Schroder wrote:
>
>> Thanks to Pete, DOS Guy and Auric_ for all help, and in particular to
>> Auric_ for making the program.
>
> Np.
>
>> I have tested it and it seems to work fine.
>
> Good.
>
>> You have sent some questions:
>> - The measuring series can last over several months, and the file with
>> all the results has always the same name (Scan.log) and format (except
>> from the number of lines). If we start another measuring series later
>> on, we make another directory for it.
>
> Might I suggest renaming the log file (once it's no longer the "active"
> log) to a datestamp? (Something like "20120101-20120131.log" or whatever.)
> That way you can tell what dates are included in the file without the need
> to open it to check.
>
>> - Normally the measurements are unattended on a measuring station far
>> away with the PC there, or with a PC connected to the station via
>> internet. That is the reason for being so keen on SMS, email and relay
>> switching in additional to the beep.
>
>  From what I've read, controlling a relay from the program shouldn't be too
> difficult if it is connected to the PC in some standard way. Many
> manufacturers supply sample code to show you how it's done.
>
>> - We have not control over the program that creates the file.
>>
>> - The time delay between the new data line is written to the file and
>> the run of the warning is normally not critical. However, as this could
>> be due to a damage, it should not be too long.
>
> As DOS Guy pointed out, the data seems to be added every 15 minutes.
> Therefore, running my program every 15 minutes seems to be all that's
> required. More often is fine; less often might miss a problem.
>
> Another thing that he pointed out is that the actual writing of the data to
> the file on disk might be delayed by the operating system, sometimes by
> seconds, but on rare occasions by *hours*.
>
>> I have one question:
>> What happens if the alarm program happens to run just when a new line is
>> inserted in the Scan.log?
>
> Hm... depends on the timing, and how the data program opens the log.
> Replace this block:
> '------------------------------------------
>    OPEN "measurements.txt" FOR INPUT AS hnd
>    LINE INPUT #hnd, i$
>    split i$, ",", headers()
>
>    DO UNTIL EOF(hnd)
>      LINE INPUT #hnd, i$
>      IF LEN(i$) THEN f$ = i$
>    LOOP
>    CLOSE hnd
>    split f$, ",", datums()
> '------------------------------------------
>
> with this block:
>
> '------------------------------------------------
>    DO
>      IF OPEN ("scan.log", FOR INPUT, AS hnd) THEN
>        SLEEP 1000
>      ELSE
>        EXIT DO
>      END IF
>    LOOP
>
>    LINE INPUT #hnd, h$
>
>    DO UNTIL EOF(hnd)
>      LINE INPUT #hnd, i$
>      IF LEN(i$) THEN f$ = i$
>    LOOP
>    CLOSE hnd
>
>    split h$, ",", headers()
>    split f$, ",", datums()
> '------------------------------------------------
>
> What this change does is, if there's an error opening the log, the program
> waits a second and then tries again, repeating until it succeeds. (I also
> moved a bit of data mangling to after the file is released to reduce the
> amount of time the file is actually open.)
>
> As for what might happen to the data program (the one that is logging) if
> it tries to open the log while my program is reading it, nothing should
> happen.
>
>> I will certainly have more questions later on after being more familiar
>> with all this.
>
> Ask away.
>

[toc] | [prev] | [next] | [standalone]


#488

From"Auric__" <not.my.real@email.address>
Date2012-02-29 13:20 +0000
Message-ID<XnsA0084092C6A9Fauricauricauricauric@88.198.244.100>
In reply to#487
Knut Schroder wrote:

> It seems now that the alarm system works fine.
>
> I have now also connected a relay via an USB port. However, different
> COM port is automatically assigned from one installation to another and
> consequently I have to change the COM port in the freebasic program
> accordingly. Of course this is inconvenient.

I assume that the relay has some sort of handshaking protocol. You could just 
step through the COM ports and try the handshaking with each one; the first 
one that succeeds is the hardware.

> Is it possible to "force" this port to be a given one, say COM7?

Maybe, but I certainly don't have the slightest idea how. I'd ask the 
manufacturer.

-- 
The killer cannot survive.

[toc] | [prev] | [next] | [standalone]


#489

FromDOS Guy <DOS@Guy.com>
Date2012-02-29 23:33 -0500
Message-ID<4F4EFC0E.4C7EE2F6@Guy.com>
In reply to#487
Knut Schroder used improper usenet message composition style by
top-poasting and unnecessarily full-quoting:

> I have now also connected a relay via an USB port. However,
> different COM port is automatically assigned from one
> installation 

Why are you being a dink and using a USB to Com-port adapter, instead of
using the computer's actual com port?

[toc] | [prev] | [next] | [standalone]


#490

FromSjouke Burry <s@b>
Date2012-03-01 05:04 +0000
Message-ID<XnsA0093DCCFB98Esjoukeburrysoesterbe@213.75.12.10>
In reply to#489
DOS Guy <DOS@Guy.com> wrote in news:4F4EFC0E.4C7EE2F6@Guy.com:

> Knut Schroder used improper usenet message composition style by
> top-poasting and unnecessarily full-quoting:
> 
>> I have now also connected a relay via an USB port. However,
>> different COM port is automatically assigned from one
>> installation 
> 
> Why are you being a dink and using a USB to Com-port adapter, instead of
> using the computer's actual com port?
> 

Maybe because there aint any?(comports that is)
The marvels of downgrading new computers.........

[toc] | [prev] | [next] | [standalone]


#491

FromDOS Guy <DOS@Guy.com>
Date2012-03-01 10:01 -0500
Message-ID<4F4F8F5E.5D9A32DE@Guy.com>
In reply to#490
Sjouke Burry wrote:
 
> > Why are you being a dink and using a USB to Com-port adapter,
> > instead of using the computer's actual com port?
> 
> Maybe because there aint any?(comports that is)

You don't know that.  Only Knut can tell us.

> The marvels of downgrading new computers.........

Is this a laptop computer?

Because if it's a desktop or mini-tower, I bet there is a header
connector on the motherboard for a serial port.

[toc] | [prev] | [next] | [standalone]


#508

FromKnut Schroder <Knut.Schroder@chem.ntnu.no>
Date2012-03-11 09:51 +0100
Message-ID<jjhp2t$kt1$1@orkan.itea.ntnu.no>
In reply to#491
The answer is simply because it is no COM port on the computer and 
because the actual relay is with USB connection only.

But I have another question:
The warning system works fine now, I run it in the background and I can 
even monitor more measuring units by running the same program (from 
other folders).

However, as the program runs only a fraction of a second every hour and 
the rest of the time is waiting, I assume that too much of the computer 
is used just for the waiting loop (and this makes problems if the 
computer is used for streaming video etc.).

In Freebasic I use:
LOOP UNTIL (TIMER-start)>scantime*60
for waiting (start is a starting time and scantime is the time between 
each monitoring).
Is it a better way to arrange the waiting to make the run more idle 
during the waiting period?

Greetings, Knut

On 01/03/2012 16:01, DOS Guy wrote:
> Sjouke Burry wrote:
>
>>> Why are you being a dink and using a USB to Com-port adapter,
>>> instead of using the computer's actual com port?
>>
>> Maybe because there aint any?(comports that is)
>
> You don't know that.  Only Knut can tell us.
>
>> The marvels of downgrading new computers.........
>
> Is this a laptop computer?
>
> Because if it's a desktop or mini-tower, I bet there is a header
> connector on the motherboard for a serial port.

[toc] | [prev] | [next] | [standalone]


#477

Frompete@nospam.demon.co.uk
Date2012-02-12 15:20 +0000
Message-ID<1329060005snz@nospam.demon.co.uk>
In reply to#471
In article <jh5ifv$f2a$1@orkan.itea.ntnu.no>
           Knut.Schroder@chem.ntnu.no "Knut Schroder" writes:

> Hello,
> 
> Is there anybody who can help me with a problem?
> 
> We have developed a system for automatic monitoring of some pollutants
> in the environment.
> 
> The levels of the different pollutants are measured (typically every
> hour) and the results are calculated using a PC (WINDOWS XP or 7) and
> stored as a line in a text file. The results for the subsequent
> measurement is stored as a new line in the same file and so on.
> 
> What I want is a small program which runs in the background and monitors
> the last line in the text file, and if the results there exceed some
> given values, some action is taken (like sending the last line with SMS
> or switching a relay or giving a sound from the PC).
> 
> I am a chemist and not a programmer, but I assume that simple solutions
> are available. Can you help me with a link or other information.
> 
> Thank you
> Knut Schroder

Both DOS Guy and Auric have already replied with possible solutions, 
and here is another possibility.  At the risk of introducing *nixy 
stuff in a thread that's already talking Windows in a DOS group, you 
might be able to do what you want with Gnu UnxUtils or Cygwin tools.
Something like:

  tail -1f $(logfile) | cut whatever_fields | some_script

where 'some_script' could test those fields and output a sound, send 
an email or whatever if the field values trigger it.  ("tail -1f" will 
track the last line in the file and only output something when a new 
line arrives.  Testing it here with Cygwin, it occupies about 5K in 
memory and consumes negligible CPU in Win XP, so could be invoked at 
startup and forgotten about...)

If you could post a sample line or two from the log file (as Auric 
suggested) we might be able to provide concrete, working answers to 
the problem.

Pete
-- 
Believe those who are seeking the truth.
Doubt those who find it.  -  André Gide

[toc] | [prev] | [standalone]


Back to top | Article view | comp.os.msdos.programmer


csiph-web