Re: "Multithreaded" tcl/tk problem?

It is clear you know what you're doing; but just for my culture I'd be
curious to know how you get to be doing fine-grained intertask
transfers and switches between independent GUI apps.

System (called ANT Insight, webpage www.ant-iss.com, I'm afraid is in
Polish thought :-( ) is intended to be Swiss Army knife for industrial
automation monitoring purposes. Usually, everything (from simple
electric meters to big production machines) in modern industrial
plants (power plants, automobile factories, breweries, etc) has it's
own electronic interface. Trouble is, they usually adhere to different
standards (MODBUS, M-BUS, ProfiBus, to name only a few) or to no
standard at all (looks like it's, for example, compressor
manufacturers delight to come up with new and completely different
protocol of communication). Of course protocol is only one of
problems, you also have different interconnects (RS-232, RS-485, TCP/
IP, TCP/UDP, etc, etc), various databases, etc, etc.

So, should one want to write code that handles _all_ cases possible,
one would get lost between thousands of specific combinations, f.e.
MODBUS on TCP/IP being something completely different to both MODBUS
on RS-485 and, say, MODBUS on GPRS modem. And we're quite small
company. So we sliced up functionality in smalles chunks possible (we
call them modules), for example we have "MODBUS driver", which don't
care where bytes come from and where they go, it just sends them
"out", or gets them "in". We have several modules for various types of
connections, like "serial" or "tcp" or "udp", or...you get the point.

Now where Tcl/Tk comes from? Well, one cannot write C drivers for all
strange protocols, or different visualization needs that one can
encounter in todays industry. So we have "popular", high performance
code written in C, and generic "Tcl/Tk" module for handling special
cases. And please note that in big factory you can get "many special
cases", for example, one hudred modules of type "WeirdMeter1", and
several tens of types "WeirdMeter2 and 3". Or perhaps someone wants to
have special graphic report (this is where Tk comes in handy) or
control. Now, person which does "integration" (configuration of
software in the field) is usually electric engineer, and not software
specialist like you. You said "idiom for thread programming". He
doesn't know what thread is! It's pretty easy for him to write small,
isolated module and then make one hundred instances of such module.
It'd be pretty hard for him to create big module handling everything,
using I/O multiplexing or worker threads to diverge interest between
all peers. Now he can safely block one thread (waiting for I/O, for
example) and all other modules (tcl/tk interpreters in different
threads) are running in independent way.

And that's why we did it. Based on our experience (had some successes
where companies using "serious" software by General Electric failed),
it kind of works :-) Hope that answers your question.

Regards
Michal
.

Relevant Pages

  • Re: Need a simple protocol
    ... communications protocol which will allow a master to reliably ... The "MODBUS over Serial ... Line" protocol looks a good example of this. ... difficulty of marking the frame boundaries. ...
    (comp.arch.embedded)
  • Re: modbus and iec 870-5-102
    ... Modbus is another communication protocol used in automation business. ... These protocols don't have much in common. ... Schneider Electric/Telemechanique. ...
    (sci.engr.control)
  • Re: Need a simple protocol
    ... Rather than implementing a custom protocol I'm keen to use something ... The "MODBUS over Serial ... difficulty of marking the frame boundaries. ... The packet parsing requirement forces the serial receive ...
    (comp.arch.embedded)
  • Re: About Controller Area Network
    ... protocol, think Ethernet and the various implementations there, like ... ethernet IP, TCP/IP, IPX/SPX, Modbus TCP, and so forth. ... a converter. ...
    (comp.os.linux.misc)