Function Block / Schematic Editor

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Hi :

I am writing a software system that is configured by the user using function
block diagram - basically a schematic.

I will provide a library of blocks, then compile the net list into a list of
pointer assignments and function calls - you get the idea.

What I need is a relatively simple and cheap schematic capture package, that
can generate a netlist of "parts", their arbitary attributes and the

Does anyone have any suggestions of a program I could use ?


Re: Function Block / Schematic Editor

I have come across a product called SoftWIRE which may be what you ar
looking for. I have only paged through a manual so I cannot answer an
questions. The URL is /
It does require a VB environment (although perhaps not at run time) and i


Quoted text here. Click to load it

This message was sent using the comp.arch.embedded web interface o

Re: Function Block / Schematic Editor

Quoted text here. Click to load it

gEDA/gschem? Has a whole bunch of developer tools for massaging
netlists, attributes, schematics;  is GPL, so you can modify it to fit
your presentation goals.

cheers, Rich.

rich walker         |  Shadow Robot Company |
technical director     251 Liverpool Road   |
We've slightly trimmed the long signature. Click to see the full one.
Re: Function Block / Schematic Editor
LabView perhaps ?

AFAIK, SoftWire is still not released, but the guy is very willing to
help, and it's running, so ask him.

Another package could be KiCAD (free).

At the moment I'm testing Diagram Designer from MeeSoft (free),
for generating code (JAL, PICbsc and Delphi) from graphical Statemachine
designs and probably also from flowcharts.

(For the other thread, Flowcharts are just as structured as NS-diagrams,
and not only technician can read them, but every human being ;-) ;-)

My first attempts for statemachine design, can be seen here:

Stef Mientki

Gary Pace wrote:
Quoted text here. Click to load it

Re: Function Block / Schematic Editor
Quoted text here. Click to load it

I've done almost exactly this using Eagle.  I used the schematic to
develop a communication flow with the built in check making sure that
inputs and output were properly matched.  The built in scripting language
was used to generate an output table of the netlist.  The netlist was
parsed to produce an XML description that contained additional
information and finally the XML was parsed to produced C code.

The XML intermediate step allowed combining multiple sources and the
equivalent of an include facility.


Re: Function Block / Schematic Editor
Quoted text here. Click to load it

I would be interested to hear your experiences with
this approach.

As one of those guys that started as a digital hardware
engineer during the early days of schematic capture and
then moved later into the software (dark ;-) side of the
game, the thought of a component based approach to software
development and visual modeling has always been appealing.
(purty picture envy probably ;-)

Seems to me that the digital hardware world benefited
greatly from the use/reuse of standard components and

As a start:

Did you find this approach useful?

Can you describe the "communication flow" across a "wire"?

Did you model a wire as a fifo byte stream or what?

What kind of semantics were associated with the "wire"?
  o Flow control
  o Delivery (Exactly Once, At Least Once, At Most Once?)

How did you implement the broadcast semantics of a "wire"
(one output to many inputs?)

Are components/blocks independent in time (threads?)

How do you contrast your approach to UML?

What did you learn?

Maybe I ask too many questions ;-)

Michael N. Moran           (h) 770 516 7918
5009 Old Field Ct.         (c) 678 521 5460
We've slightly trimmed the long signature. Click to see the full one.
Re: Function Block / Schematic Editor says...
Quoted text here. Click to load it

I had two goals when I started with it.  
    - The first was to come up with a way of showing the internal
logic in a way that would allow non-programmers to follow it and maybe
suggest flaws.  It wasn't necessary for them to be able to use it but if
they could read it feedback on behaviour might be available earlier.  On
this front it was a resounding failure.  It ended up that the main reason
no-one would comment on the code before they could see it operating was
not because they didn't understand the code well enough for a simple
review but that they simply couldn't be bothered.  So much for early

    - The second was to provide a way of abstracting the data flow
from external sensors and actuators to/from the control logic including
over the network.  This was a qualified success but needed some more work
and refinement.  Before moving on from the company I had enough
experience with it to be intrigued at the possibilities but hadn't had
enough time to rework it into a more usable form.

Quoted text here. Click to load it

A fairly simple model.  The output/source was simple scalar value that
the attached inputs used as needed.  There was no attempt to deal with
streams of data, although I had support for arrays and booleans.  The
arrays were used as lookup/calibration tables.  On a rewrite I'd probably
dispense with the arrays since they were used in the logic rather than

Quoted text here. Click to load it

See above.  Really I thought of it a piece of Cu carrying a voltage :)  
On a programming level it ended up being a reference to a value in a

Quoted text here. Click to load it

No flow control, the value was simply there as far as the program was
concerned.  In fact that was more or less part of the abstraction.  It
removed any considerations of delivery to outside of the context of the
schematic.  Delivery was similarly outside of the scope of the schematic
but was effectively at least once.  The schematic would execute in a
cyclic timed fashion using whatever inputs were there and propagating
them through to the outputs.  The outputs would then end up either
operating physical outputs or travelling via a network to some other
process.  The underlying network was CAN based so it had at-least once
characteristics and critical values could be watchdogged although I
hadn't got as far as testing that.

Quoted text here. Click to load it

Ah, but if a wire ends up simply being a value in a table anything can
just read the value.  Simplicity itself.

Quoted text here. Click to load it

Schematics are.  Components were generally not nearly complex enough for
that to be useful in any case.

Quoted text here. Click to load it

It bore much the same relationship that ladder diagrams do.

Quoted text here. Click to load it

- Many who specify a system don't care to check your understanding of the
specification until they see it (not) working.  I'd still like to find a
way of getting this feedback back I'm a lot less optimistic about it.  It
appears to be less a technical problem than a human one.  Basically "Just
go away and make it do what I want and don't bother me until you're
done."  It's not really that they don't care, it's just they don't see
the need to repeat what they believe they've already told you.

- If you want to have a simply programmable core for the logic it makes
sense to invest (time and/or money) in a PLC core rather than re-invent
the wheel.  I knew that going in but didn't have the go-ahead to buy the
core and tried to work around it.

- I think this would have been a reasonble way of setting up
communication over a network for control purposes but I didn't get enough
systems up to give it a try.

- Error handling doesn't fit in very well.  In fact the only way I could
get real error handling was to hide it behind the scenes.  Luckily in the
abstraction I was using the only real place for run time errors was in
the communications layer and most of them could be watchdogged, i.e. if
critical values didn't arrive quickly enough go to some sort of safe

Quoted text here. Click to load it

Well, I wasn't going to volunteer without some sort of expression of
interest.  This post is all your fault for asking ;)

It sounds like you are looking to set up a more complex abstraction than
I attempted.  Good luck.


Re: Function Block / Schematic Editor

Quoted text here. Click to load it

As I see it, it looks like a function diagram, what you
find in the IEC 1131 standard for function blocks.

This is often used in industrial control, technicians
can read it easily.

This is, IMHO, very different from UML which has a
OOps approach. Components in UML are objects, not
functions, and from what they say this is a different

It should not be really impossible to do in softawre
what you can do in hardware with components. You
need well defined protocols.

NI Labviews has achieved something similar.

Quoted text here. Click to load it

Re: Function Block / Schematic Editor
Not really an answer to your question, but an example of a similar approach
is LabView from National Instruments.  Worth having a play with the free
demo, at least, to get an idea of how to hang things together.


Site Timeline