Function Block / Schematic Editor

Gary

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 free.

-Aubrey

function

of

that

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

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 | rw@shadow.org.uk
technical director     251 Liverpool Road   |
need a Hand?           London  N1 1LX       | +UK 20 7700 2487
www.shadow.org.uk/products/newhand.shtml

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:

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.

Robert

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 interfaces.

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
Kennesaw, GA, USA 30144    http://mnmoran.org

"So often times it happens, that we live our lives in chains
  and we never even know we have the key."
The Eagles, "Already Gone"

The Beatles were wrong: 1 & 1 & 1 is 1

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 feedback.

- 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.

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 communications.

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 table.

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.

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

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

It bore much the same relationship that ladder diagrams do.

- 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 mode.

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.

Robert

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 paradigm.

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.

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.

Cheers, Alf.