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

Groups > comp.lang.forth > #20143 > unrolled thread

Adding widget to web page to display data from serial port.

Started by"Clyde W. Phillips Jr." <cwpjr02@gmail.com>
First post2013-03-01 15:33 -0800
Last post2013-03-08 20:10 -0800
Articles 16 — 3 participants

Back to article view | Back to comp.lang.forth

Contents

  Adding widget to web page to display data from serial port. "Clyde W. Phillips Jr." <cwpjr02@gmail.com> - 2013-03-01 15:33 -0800
    Re: Adding widget to web page to display data from serial port. stephenXXX@mpeforth.com (Stephen Pelc) - 2013-03-02 11:45 +0000
      Re: Adding widget to web page to display data from serial port. "Clyde W. Phillips Jr." <cwpjr02@gmail.com> - 2013-03-02 19:21 -0800
        Re: Adding widget to web page to display data from serial port. "Clyde W. Phillips Jr." <cwpjr02@gmail.com> - 2013-03-02 19:25 -0800
        Re: Adding widget to web page to display data from serial port. stephenXXX@mpeforth.com (Stephen Pelc) - 2013-03-03 21:42 +0000
          Re: Adding widget to web page to display data from serial port. "Clyde W. Phillips Jr." <cwpjr02@gmail.com> - 2013-03-03 17:01 -0800
            Re: Adding widget to web page to display data from serial port. stephenXXX@mpeforth.com (Stephen Pelc) - 2013-03-04 10:25 +0000
              Re: Adding widget to web page to display data from serial port. "Clyde W. Phillips Jr." <cwpjr02@gmail.com> - 2013-03-04 20:19 -0800
                Re: Adding widget to web page to display data from serial port. Mark Wills <markrobertwills@yahoo.co.uk> - 2013-03-04 23:46 -0800
                Re: Adding widget to web page to display data from serial port. stephenXXX@mpeforth.com (Stephen Pelc) - 2013-03-05 10:37 +0000
                  Re: Adding widget to web page to display data from serial port. Mark Wills <markrobertwills@yahoo.co.uk> - 2013-03-05 03:08 -0800
                    Re: Adding widget to web page to display data from serial port. stephenXXX@mpeforth.com (Stephen Pelc) - 2013-03-06 11:39 +0000
    Re: Adding widget to web page to display data from serial port. "Clyde W. Phillips Jr." <cwpjr02@gmail.com> - 2013-03-05 11:04 -0800
    Re: Adding widget to web page to display data from serial port. "Clyde W. Phillips Jr." <cwpjr02@gmail.com> - 2013-03-05 11:07 -0800
      Re: Adding widget to web page to display data from serial port. Mark Wills <markrobertwills@yahoo.co.uk> - 2013-03-05 12:00 -0800
    Re: Adding widget to web page to display data from serial port. "Clyde W. Phillips Jr." <cwpjr02@gmail.com> - 2013-03-08 20:10 -0800

#20143 — Adding widget to web page to display data from serial port.

From"Clyde W. Phillips Jr." <cwpjr02@gmail.com>
Date2013-03-01 15:33 -0800
SubjectAdding widget to web page to display data from serial port.
Message-ID<adb5552e-39bf-48fd-a3ef-b5b8992178e8@googlegroups.com>
I trust the experience and analysis of this group. If there is a forth way (or a way forth!) I prefer it.

The serial part needs a strategy to transfer the incoming data to something that web code can access. AFAIK web pages cannot directly access HW like serial ports.

The display widget needs to be ploop-able into a site that is willing to add it to it's page. Something about iFrames may be the best current practice but I don't know.

Are web page display widgets written in or by FORTH code any one is sharing?

In my particular need the display would be a differential meter or at least an LCD mock-up.

Thanks in advance and let me know if this is too far afield for the groups liking... Clyde

[toc] | [next] | [standalone]

#20166

FromstephenXXX@mpeforth.com (Stephen Pelc)
Date2013-03-02 11:45 +0000
Message-ID<5131e444.1498603527@192.168.0.50>
In reply to#20143
On Fri, 1 Mar 2013 15:33:03 -0800 (PST), "Clyde W. Phillips Jr."
<cwpjr02@gmail.com> wrote:

>The serial part needs a strategy to transfer the incoming data to 
>something that web code can access. AFAIK web pages cannot directly
>access HW like serial ports.

On the desktop the VFX Forth Professional editions, and the embedded
Forth 7 cross compilers, include the PowerNet web servers. These use
ForthScript (yes, just Forth) for server-side scripting. Here's a
simple example:

<html>
<head><title>Test form response by ASP</title></head>
<body>
<h3>Thank you</h3>
<p>The form response has been processed using ASP and ForthScript
by the PowerNet Web Server. You can see the code in the file
<i>TestPages\thanks.asp</i>, which is the file that generated
this page.
</p>
<% language=forthscript %>
<br><h3>Your responses were:</h3>
<p>Name : <% s" sname" .qstring %> </p>
<p>Email: <% s" smail" .qstring %> </p>
<p>State: <% s" state" .qstring %> </p>
<p>You pressed the <% s" send" .qstring space %> button</p>
</body>
</html>

The code between <% and %> is just Forth source code which is
executed on the server when the page is served.
  s" sname" .qstring
displays the value of of a connection variable called SNAME.

Stephen

-- 
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

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

#20196

From"Clyde W. Phillips Jr." <cwpjr02@gmail.com>
Date2013-03-02 19:21 -0800
Message-ID<74832313-d536-4bb8-97ea-c4360cc28177@googlegroups.com>
In reply to#20166
This looks like Form population which would be console I/O. If I am incorrect so be it.
So Does the forth scripting allow access to other i/o, as in the serial port as in this request I need?

Am I in the same ballpark?

Thanks Clyde

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

#20197

From"Clyde W. Phillips Jr." <cwpjr02@gmail.com>
Date2013-03-02 19:25 -0800
Message-ID<52407c14-1982-4eb9-be1f-511606a34b5e@googlegroups.com>
In reply to#20196
On Saturday, March 2, 2013 9:21:19 PM UTC-6, Clyde W. Phillips Jr. wrote:
> This looks like Form population which would be console I/O. If I am incorrect so be it.
> 
> So Does the forth scripting allow access to other i/o, as in the serial port as in this request I need?
> 
> 
> 
> Am I in the same ballpark?
> 
> 
> 
> Thanks Clyde

AM I confusing server side scripting with the environment of the web page my widget has been added, using say your forth script,  and where the data is coming from a dongle device I have supplied...?

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

#20219

FromstephenXXX@mpeforth.com (Stephen Pelc)
Date2013-03-03 21:42 +0000
Message-ID<5133c385.1621305099@news.demon.co.uk>
In reply to#20196
On Sat, 2 Mar 2013 19:21:19 -0800 (PST), "Clyde W. Phillips Jr."
<cwpjr02@gmail.com> wrote:

>This looks like Form population which would be console I/O. If I am incorrect so be it.
>So Does the forth scripting allow access to other i/o, as in the serial port as in this request I need?

Anything you can do in the host Forth on the server can be part of the
server-side script.

Stephen

-- 
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

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

#20228

From"Clyde W. Phillips Jr." <cwpjr02@gmail.com>
Date2013-03-03 17:01 -0800
Message-ID<b3325036-b744-4f07-bfc1-3458674c2f56@googlegroups.com>
In reply to#20219
 
> 
> 
> Anything you can do in the host Forth on the server can be part of the
> 
> server-side script.
> 
> 
> 
> Stephen
> 
I may be a little confused or unclear. What I think your statement means is that the HOST FORTH you refer to can be thought of as a complete FORTH system running of a HOST that can be used for any programming the host system supports, i.e. is not sand-boxed like client side browser scripts are. And the designation HOST implies the web server hosting the web page and in turn your FORTH based web server with forth scripting capabilities.

So a part of what I need that differs from the above scenario is that the served up page, rendered on my client PC in a browser needs to access data from a serial port dongle attached to my client.

I hope this is understandable stated.

Clyde

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

#20236

FromstephenXXX@mpeforth.com (Stephen Pelc)
Date2013-03-04 10:25 +0000
Message-ID<513474fa.1666734587@news.demon.co.uk>
In reply to#20228
On Sun, 3 Mar 2013 17:01:59 -0800 (PST), "Clyde W. Phillips Jr."
<cwpjr02@gmail.com> wrote:

>So a part of what I need that differs from the above scenario is that the s=
>erved up page, rendered on my client PC in a browser needs to access data f=
>rom a serial port dongle attached to my client.

Now you have two choices;
1) send the data to the server for format and page generation.
You can do this with CGI or POST messages.
2) use client-side scripting.

Without writing tools, option 1 is what we currently have. I also
suspect that work involved in using one custom server is much less
than that involved in writing plugins for a rang of browsers.

Your explanation begs the question that, if the display and serial
port are on the same PC, why do you need a browser?

Stephen

-- 
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

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

#20273

From"Clyde W. Phillips Jr." <cwpjr02@gmail.com>
Date2013-03-04 20:19 -0800
Message-ID<efa94c66-1deb-41d5-a79c-db382d176b31@googlegroups.com>
In reply to#20236
> <cwpjr02@gmail.com> wrote:
> >So a part of what I need that differs from the above scenario is that the s=
> >erved up page, rendered on my client PC in a browser needs to access data f=
> >rom a serial port dongle attached to my client.
> 
> Now you have two choices;
> 
> 1) send the data to the server for format and page generation.
> You can do this with CGI or POST messages.
> 2) use client-side scripting.
> 
> Without writing tools, option 1 is what we currently have. I also
> suspect that work involved in using one custom server is much less
> than that involved in writing plugins for a rang of browsers.
> 
IS this "one custom server" in my client sending POST messages generated from it's scripts reading the dongle on my client? And the POST messages sent to the host server will have scripting there to incorporate into a web page it serves back to my client?

> 
> Your explanation begs the question that, if the display and serial
> port are on the same PC, why do you need a browser?
> 
Fair and good question. The need is to aggregate client data and share it through the web. So a community of clients would be feeding a server that would produce a report page representing all the clients individual and aggregate data.

Is there a better way to generate this type of data from disparate client sources?

Clyde

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

#20279

FromMark Wills <markrobertwills@yahoo.co.uk>
Date2013-03-04 23:46 -0800
Message-ID<5f825291-8d41-4c10-8228-25549cf0d054@he10g2000vbb.googlegroups.com>
In reply to#20273
On Mar 5, 4:19 am, "Clyde W. Phillips Jr." <cwpj...@gmail.com> wrote:
> The need is to aggregate client data and share it through the web. So a community of clients would be feeding a server that would produce a report page representing all the clients individual and aggregate data.

Clyde,

That sounds (to me) as if the serial ports are on the *clients* and
they post their data (collected from the serial port) to a central
server. Can you confirm that this is the architecture?

If so, then I would advocate trying to separate out the two distinct
'phases' of the system in your mind:

1) The delivery of visually formatted, aggregated client-data to an
audience on the internet via web browsers.
2) The delivery of raw data-sets, captured by serial port, from data-
gatherers to a central server.

1 is a 'web application' (as I would use the term) as it would employ
a web server, running on the central server which collects the pre-
aggregated data (maybe from an SQL database, maybe a simple file,
maybe XML) and delivers it to the (human?) audience, in a nicely
formatted visual form, using HTML and cascading style sheets etc).

2 is *not* a web application. At least, I would not choose to deliver
my data to the central server using HTTP or SOAP or anything like
that. Too much like hard work. I would:

a) Use FTP if at all possible. That would be my preference. I would
simply have an executable running on the 'data gatherers' that takes
the data in from the serial port, and appends it to a file on disk. At
the appropriate time, the same executable would log into an FTP server
running on the central server and:
1a) Upload its data file
1b) If 1a was succesful, delete the same data file.

The central server would periodically check its FTP directory, and if
a new file is found:
1c) Process the data in the file (add it to an SQL database, etc)
1d) Delete the file

That would be my preference.

If FTP were not possible, then I would

b) gather serial data to disk files, as above, and then, at the
appropriate time, use sockets between the data-gatherers and the
server, and roll my own (simple) protocol to stream the data to the
server. When all the data is delivered, delete the file. I'd probably
use UDP and do my own handshaking etc.

So, your application would have two distinct 'types' of technology:

1) Delivery of web pages to an audience - a "web" application.
2) Collection of data from data-gatherers - a network application.

That 2) is using the Internet doesn't make it a "web" application.
It's a network application. The Internet, in this case, is simply the
wire that the data traverses :-)

As far as I know, VFX would be an ideal candidate, as it has the web
server technology already written, and has a socket library etc. You'd
need the Professional version. See http://www.mpeforth.com/vfxcom.htm#powernet

Also see http://www.mpeforth.com/powernet.htm

There are probably other Forths (Swift etc) that can also do the job
nicely. I think GForth has access to sockets too.

HTH

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

#20284

FromstephenXXX@mpeforth.com (Stephen Pelc)
Date2013-03-05 10:37 +0000
Message-ID<5135c95b.1753871036@news.demon.co.uk>
In reply to#20273
On Mon, 4 Mar 2013 20:19:51 -0800 (PST), "Clyde W. Phillips Jr."
<cwpjr02@gmail.com> wrote:

>> Your explanation begs the question that, if the display and serial
>> port are on the same PC, why do you need a browser?
>> 
>Fair and good question. The need is to aggregate client data and share
>it through the web. So a community of clients would be feeding a server
>that would produce a report page representing all the clients individual
>and aggregate data.

As Mark suggests, this is a network operation feeding serial data
from the clients to the server. You will need custom code on the
clients for this. Whether you do the feed from the clients to the 
server using POSTs, CGI scripts, or TCP sockets is an operational
decision based on user location, paranoia and funding.

We are available for consultancy on database-driven websites that
collect data from remote sites and prepare reports for various
levels of management. As used by several major UK supermarkets
that must remain nameless.

Stephen

-- 
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

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

#20286

FromMark Wills <markrobertwills@yahoo.co.uk>
Date2013-03-05 03:08 -0800
Message-ID<664854f8-ba32-404e-97f8-93a433071f52@g8g2000vbf.googlegroups.com>
In reply to#20284
On Mar 5, 10:37 am, stephen...@mpeforth.com (Stephen Pelc) wrote:
>
> Whether you do the feed from the clients to the
> server using POSTs, CGI scripts, or TCP sockets is an operational
> decision based on user location, paranoia and funding.
>
Actually, that's a good point. Whilst FTP and or raw sockets would be
preferable (at least, it would be to me) your corporate firewall(s)
may have different ideas! If you can only use port 80 then your stuck
with either posting FORM data to the server via http, or XML/SOAP
which is the stuff of Satan IMHO!

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

#20342

FromstephenXXX@mpeforth.com (Stephen Pelc)
Date2013-03-06 11:39 +0000
Message-ID<51367f8a.1800510125@news.demon.co.uk>
In reply to#20286
On Tue, 5 Mar 2013 03:08:43 -0800 (PST), Mark Wills
<markrobertwills@yahoo.co.uk> wrote:

>If you can only use port 80 then your stuck
>with either posting FORM data to the server via http, or XML/SOAP
>which is the stuff of Satan IMHO!

Then Satan exists in PowerNet. But XML/SOAP is distinctly upleasant
and cycle-stealing. However, stateless use of CGI is better than
one might think; but it needs careful design.

Stephen

-- 
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

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

#20310

From"Clyde W. Phillips Jr." <cwpjr02@gmail.com>
Date2013-03-05 11:04 -0800
Message-ID<ae8c258b-068c-4264-94c0-941f63b4f664@googlegroups.com>
In reply to#20143
On Friday, March 1, 2013 5:33:03 PM UTC-6, Clyde W. Phillips Jr. wrote:
> I trust the experience and analysis of this group. If there is a forth way (or a way forth!) I prefer it.
> 
> 
> 
> The serial part needs a strategy to transfer the incoming data to something that web code can access. AFAIK web pages cannot directly access HW like serial ports.
> 
> 
> 
> The display widget needs to be ploop-able into a site that is willing to add it to it's page. Something about iFrames may be the best current practice but I don't know.
> 
> 
> 
> Are web page display widgets written in or by FORTH code any one is sharing?
> 
> 
> 
> In my particular need the display would be a differential meter or at least an LCD mock-up.
> 
> 
> 
> Thanks in advance and let me know if this is too far afield for the groups liking... Clyde

Thank you Stephan and Mark, your discussions have concluded as I suspected, that the client app was more of a network app.

With near real-time updates of small amounts of data I suspect the host provider will have to provided a special contract service vs. standard hosting, so if this goes forward that is the last thing to negotiate.

Now let me ask if the Host Web Server side Forth scripting has examples of creating display objects, like one would in Java or Javascript? Especially meters or LCD display mock-ups.

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

#20311

From"Clyde W. Phillips Jr." <cwpjr02@gmail.com>
Date2013-03-05 11:07 -0800
Message-ID<467969d4-cf85-4e54-b90b-f179fb92bdb5@googlegroups.com>
In reply to#20143
Thank you Stephen and Mark, your discussions have concluded as I suspected, that the client app was more of a network app just Inter vs. Intra in my case.

With near real-time updates of small amounts of data I suspect the host provider will have to provided a special contract service vs. standard hosting, so if this goes forward that is the last thing to negotiate.

Now let me ask if the Host Web Server side Forth scripting has examples of creating display objects/widgets, like one would create using Java or Javascript? Especially meters or LCD display mock-ups.

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

#20315

FromMark Wills <markrobertwills@yahoo.co.uk>
Date2013-03-05 12:00 -0800
Message-ID<06fb8f2a-4a33-40e7-9f59-0c3a9b39c331@googlegroups.com>
In reply to#20311
On Tuesday, March 5, 2013 7:07:04 PM UTC, Clyde W. Phillips Jr. wrote:
> Thank you Stephen and Mark, your discussions have concluded as I suspected, that the client app was more of a network app just Inter vs. Intra in my case.
> 
> 
> 
> With near real-time updates of small amounts of data I suspect the host provider will have to provided a special contract service vs. standard hosting, so if this goes forward that is the last thing to negotiate.
> 
> 
> 
> Now let me ask if the Host Web Server side Forth scripting has examples of creating display objects/widgets, like one would create using Java or Javascript? Especially meters or LCD display mock-ups.

I'd be surprised if any Forth system would supply such objects/widgets. If you are wanting to display the results of the aggregated data visually using meters and gauges, then you'll be wanting to leverage JavaScript on the client side.

The server would extract some data from the dataset, and render a (static) page for the client that includes calls to JavaScript routines that render gauges and meters, using the data supplied by the server (which can be embedded into invisible HTML elements by the server at the time that the page is rendered; this is then used by the JavaScript on the client side as the data source). The page can simply refresh automatically (causing the page generation to be triggered again on the server, supplying the latest set of readings) or the refreshing could be done in javascript (which would look better visually). Javascript is outside of my area though, I never really bothered with it.

Here's some nice JavaScript gauges: 

http://justgage.com/
http://bernii.github.com/gauge.js/
http://code.google.com/p/jgauge/
http://perfectwidgets.com/ (looks very good-but not free)
http://codecanyon.net/item/svg-based-gauges-for-javascript-/3318267 <-- looks really good

HTH

Mark

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

#20479

From"Clyde W. Phillips Jr." <cwpjr02@gmail.com>
Date2013-03-08 20:10 -0800
Message-ID<420f0302-da08-4865-aece-5a5c7f4abab6@googlegroups.com>
In reply to#20143
Ok fellow forthers! Isee all good people and am on my way!

Port 80 gci posts should be the simplest in this scheme.

Now looks like I'll be doing a dongle app client side that will have an option of participating in posting to a net hosted aggregation server.

I hope to dissuade architects by simple assingning dongles to location based server node that are essentially doing a local approximate of the real aggregate.

Wish me luck eh?

Thanks again, Clyde

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.forth

csiph-web