flowchart layout enquiry

Hi Blueteeth,

Thank you for looking over what i want to do.
I have spent a lot of time, on and off, thinking about how to do this.
Spread over a few years. I am afraid i have not found it simple,
maybe you have had formal teaching in these things. I'm just sort of
stumbling through.

The bit that i have most difficulty with is the bit about checking
the flags.

Now it is quite possible that there is some other way entirely to do
this little task, and if there is i would like to know.

But the way i see it is that 'an occurence could occur' while the
printer is busy, so therefore something has to 'latch' which can be
'unlatched' afterwards, so that items don't get missed.

And thank you for the notes on the shapes.
What i would really like to see, is how you would lay it out ...
(or anyone else ...)
so that i could see where it differs.

Regards, John

I have just noticed you are in Hertfordshire, UK.

Oo Small world eh?

Just out of interest, you're planning on printing out lines for certains events...and this thread is about 'flow diagrams'...but how exactly are you implementing it? PC? Or a seperate micro-based thing will a serial connection to a PC (and therefore printer)?

Blueteeth

I say just learn how to program. I don't care; BASIC C/C++, Perl, Pike, VB, VC/C++, C#, Java, Assembly, whatever.

To heck with "flowcharts" and pseudocode.


If you already know a programming language, THEN USE IT! There is really no point to flowcharts unless you are preforming bohemouth tasks

Hi Y'all,

Marks256 said:

I say just learn how to program. I don't care; BASIC C/C++,
Perl, Pike, VB, VC/C++, C#, Java, Assembly, whatever.

To heck with "flowcharts" and pseudocode.

If you already know a programming language, THEN USE IT! There is really no
point to flowcharts unless you are preforming bohemouth tasks

Click to expand...

Well i know a little BASIC, not much, and i know a little machine
code assembler, again not much.
But i don't think that a programming language helps to form a logical
or structured approach to any given problem.

Actually the same problem can usually be programmed for in many
different ways in any language, sometimes in clear and straightforward
ways, sometimes in convoluted and devious ways.

I had thought that finding out about flowcharts would help me to put
things into a sensible order, now i don't think thats its function.

So i am back to just pondering which way to do what i want.

*******************************

Blueteeth said:

Oo Small world eh?

Just out of interest, you're planning on printing out lines for
certains events...and this thread is about 'flow diagrams'...
but how exactly are you implementing it? PC? Or a seperate micro-based
thing will a serial connection to a PC (and therefore printer)?

Blueteeth

Click to expand...

Yes, small world. I am in the Rickmansworth area.

How am i implementing it ?
I haven't fully decided yet, there are a good few options to print a
short simple message.
I want it on paper, i had considered it on floppy driven from maybe
a micro-controller or small dedicated PC, but i've changed my mind,
i now want a simple paper print out.

Probably from a dot matrix type printer. Probably driven by selecting
a ROM chip from the incoming signal. Such a rom chip could go directly
to the seven bit head, but thats five bits per letter plus one or two
for a space, which would be a bit wasteful. So i think that the ROM
would in this case give ASCII to the printer, which would give a decent
number of letters to form a sentence. Depending on the choice of ROM.

I was just thinking of those little black TTL old style chips. Still
fairly cheap, and they have eight bit outputs, which gives me the
chance to re-use them as i would only be using seven bits thats half
of the available outputs. (ASCII being seven-bit).

But thats still undecided.

First i want to sort out the "background structure" or "overview" of
it as a form of 'b-diagram' rather than get into how the sentence
gets printed.

****************

In the initial concept, each incoming wire simply kicked the printer
into operation and printed its associated message.

It was soon realised (within a few seconds), that if another
signal came in while the printer was busy, something could be missed.

This was why the 'flags' came about.
However using flags to hold a signal request might not be the only way.
It might be possible to arrange for a subsequent signal to be dealt
with in a sequential manner. Such a subsequent signal is unlikely,
two such signals is extremely unlikely, however i would like to think
that a decent system could accomodate three or four such signals.
Just to be sure, so to speak.

Some printers have a local memory cache, it might be possible to use
this instead.
This has only just occurred to me.
If this is really a possibility then that would make my side of it a
lot easier.

Losing the 'flags' stage would make the system so very simple.
I will have to have a little think about this.

Regards, John

But i don't think that a programming language helps to form a logical
or structured approach to any given problem.

Click to expand...

Well, then we disagree. I've been programming for 30 years and find that using pseudo code to be far superior for designing code.

Use of flow charts doesn't encourage good practices. It makes it easy to create unstructured designs. pseudo code maps nicely onto programming languages so the step from design document to actual code is fairly easy.

Please tell me more about pseudo code,
it sounds like it might be just what i want

John

Psuedocode is like it sounds - scribble down anything that you like, in a syntax that is similar to your favorite programming language, but don't sweat the details. The purpose of psuedocode is just to get something nailed down, even if it is wrong - at which point you can start fixing it.

In any case, I tend to use "state transition diagrams" when I start doing anything convoluted. (Google it, you'll see some useful pictures). Alternatively a "uml sequence diagram" is useful for exploring example cases. BTW, a "uml activity diagram" is pretty much a flowchart.

One thing is that your example of the printer has two "actors" in UML terms - the printer runs asynchronous to whatever is actually detecting the events, and you need to take this into account when designing your stuff. Essentially your main loop is either going to have to be event driven - wait for a message coming back from the printer that says "I'm done printing, going idle", or it is going to have to continuously poll the printer.

Hi hjames,

I read up a bit on "state transition diagrams" in particular the
section on 'Unified Modeling Language' which does seem to fit my
particular arrangement, in that it allows the diagram to make sense
where the system is in multiple states at once.

For my particular purpose the printer may well be printing at the
same time that another signal comes in.

Which is what i think you mean by 'asynchronous',
(i should look that up) and as you say, this has to be taken into
account.

Which is when i realised that printers are meant to cope with this in
their ordinary lives.
Printers are expected to print stuff at the same time as more stuff
comes in to be printed.
They are fitted with internal memories especially to cope with that.
I think its called a cache or a buffer.

So, if i can arrange for the printer itself to accept events very
quickly, then the incidence of an 'overlap' will be greatly reduced.

This could mean that the 'loop' is actually not a 'loop' just a
sequence. If that could be arranged, it would make the setup so much
easier.

But i dunno ... that may not be possible.

John

I agree that for certain designs, a state machine approach is a superior tool. especially if the inputs/outputs are fairly deterministic. Not all problems are appropriate. For example, a PID algorithm wouldn't do but a quadrature decoder would be perfect.

the way to think about pseudo code is to pretend you are the computer and talk tourself through the algorithm. then write down what you said. Like hjames said, you ignore a lot of the details.

on your specific application, I would look for a serial printer. then your interface is very simple. I don't know if they are made anymore so you may need to use a parallel interface. not impossible, just a bit harder. A serial printer version can be debugged using the serial input on a computer. I'd structure the solution into 2 parts: printer driver and status monitor. For the first cut design, I'd skip the printer driver part - assume a routine called "print_string". Now that i better understand what you want to do, here's my PseudoCode take: note that you may not need the read status pins section, just loop looking for each status pin being set (via the if statements). this brings up the question of how the status pins get reset. you need to be sure that you only report a given status pin once.

this application is crying for interrupts, by the way.

once you get that part working, figure out how to drive the printer.

Hi Philba,

Thank you very much for laying that out.
As an illustration, your layout is easy to understand.
I am trying to write a similar bit of pseudo code,
which will fit better with the stuff i will be trying to use.
Haven't got very far yet.

You haven't mentioned anything about possibly using the
printers memory or cache.
I'm still pondering that.

John

most printers buffer so i think you don't have to worry. Even it you use one that doesn't, buffering in the printer driver is pretty easy if you use interrupts.

Yes, most printers have a buffer, even older dot matrix ones, which is
the type i will probably be using.
I have had a look through Google at the old dot matrix ones that i
have knocking about, and the most usual cache is about 8 megs, which
is more than enough for many lines of text, probably enough for a
few pages.

The reason i am so interested in the printer cache is that it could
eccept a single line(or less) message very quickly, probably in less
than half a second, if i could transfer a given message very quickly
like that, then the chances of another message being 'overlapped' is
very, very small.

In my case, these messages do not usually overlap, and i have them up,
that is - a lamp is lit, sometimes for long periods.

It is possible that the chances of an overlap would be so small, that
i could reasonably ignore it.

I am looking at this possibility because i think that it would be so
easy to lay it out in a workable order.

And of course, because i am getting stuck in awkward arrangements of
flags, re-sets, sequences, maybe counters-maybe not, its giving me a
hard time trying to sort it out.

But as a simple sequence, it would be so easy.

What do you think ... ?

Regards, John

MS Word isn't very good for flowcharting, it's a word processor not a drawing program, I wisht people would stop trying to use it as one.

Marks256 said:

and this is my favorite program to draw flowcharts in:

https://www.freewarefiles.com/program_3_36_8116.html

Best software ever made.

Click to expand...

Unfortunately it's Winwoes only, but I'll check it out, it looks like good software. I find it odd that 1.1.1 is open source but 1.17 isn't.

Really? I didn't catch that. It is still awesome software, though. Hopefully they will port it to linux...

On the assumption that i can get the printer's cache to accept ASCII
even if i have to provide it in parallel form, and also the assumption
that i can get the cache to produce ready signals, and to clear from
a signal from the 'yet to be made' electronics,

Then this is a brief form of my latest ponderings:


01 * nothing happening
02 * a wire #1 (of about 20) goes active (12v)
03 * printer turns on
04 * printer prints a short message indicating the event.
05 * short interval for any subsequent notifications.
06 * wire (#1) goes inactive, back from 12v to 0v
07 * printer prints a short message indicating the event.
08 * short interval for any subsequent notifications.
09 * after short interval, printer turns off.
10 * nothing happening again.

This is very abbreviated, and also does not allow for a signal which
may occur during the one tenth of a second (or thereabouts) that will
be taken for the 'yet-to-be-made-electronics' to dump the ASCII into
the printer's cache.
I will see if i can have the printer's cache kept 'live' separately
from the rest of the printer's electrics, so that its always ready to
accept the ASCII from the 'yet-to-be-made-electronics'.

I suspect i will find that the ASCII can be loaded into the cache much
more quickly than a tenth of a second.
The quicker this happens, the less chance of an 'overlap' of signals.
At present i have little lamps on them, and they rarely overlap, even
though they are often on for a good few minutes before i bother with
them.

I think that by using the 'rise' and the 'fall' of any given signal
as two events, this means that the system wont be 'tied up' while a
signal is present, and therefore the chances of an 'overlap' will be
reduced to such a small likelihood, that i could reasonably ignore it.

Any comments or suggestions on the above would be welcomed.
In fact i am hoping for comments or advice.
If i wasn't clear about my intentions with any of the above,
please let me know, and i will try to say it in a clearer way.

Hope you all had a Merry Christmas, and i wish you all a Happy New
Year,

Regards, John

Just get an old crappy dot-matrix printer. I think they will accept pure ascii character codes on the data lines with verry little software. I never tried it, but i know that the printers that run strictly off of SPP will accept ASCII.

The Centronics interface to a printer is simple to do using a PIC or similar (and yet again, EPE did a project on it a couple of years ago) - you just need to understand the handshaking involved.

However, it's ESSENTIAL that you don't use a 'Windows printer', these use your PC as part of the printer system - the printer itself can't work without Windows to feed it.

A 'real' printer just requires ASCII data and control codes, and can be switched to grahics mode where you can send bit mapped data - a Windows printer can't do this.

Like Marks256 says, an old dot-matrix printer would be fine, but so would any OLD inkjet or laser, but it's got to be OLD - a DeskJet 500 would be fine, that's a 'real' printer. But most recent printers tend to be Windows only (including Mac in that, as they often provide Mac drivers as well).

Hi Y'all,

Most of my small collection of printers are crappy old dot matrix types. I have a couple of old golf-ball typwriters, which can be used
as text-only printers, but i've never used them like that.
They are mostly just second or third hand unwanted old printers dragged
out of skips (dumpsters?), So yes the one that gets used for this will
be an older type.

I understand the arrangement of a 'PC dependant printer' where much of
the printer's duties are handled by its driver running on the local
computer.
The same parasitic behaviour is used by many modems, they just have a
suitable socket for the telephone, with an isolating device, and the
rest of the work is done by the modem driver running on the computer.
So, yes i will make sure that the printer has all the required
attributes.
However i may need to look up the various bytes and special 'words'
that may be needed to do some of the functions i will want.

I don't think i will be using one of my ink-jet types, simply because
they tend to dry up so quickly. The ribbon in ribbon types can dry up
too but i think it takes longer to dry up than the inkjets, and its
pretty easy to take the ribbon bits off the printer and moisten them,
well easier than inkjets anyway.

This printing the messages idea is still in the design stage, and has
been for over a year now, so its about time i did something practical
towards it.

Thank you all for your help and advice and i will get back to this as
i start to get things together on this project.
It is unlikely to be plain sailing even though i think that it should
be fairly straightforward.

Thanks again, and happy New Year,
Regards, John

Nigel Goodwin said:

However, it's ESSENTIAL that you don't use a 'Windows printer', these use your PC as part of the printer system - the printer itself can't work without Windows to feed it.

A 'real' printer just requires ASCII data and control codes, and can be switched to grahics mode where you can send bit mapped data - a Windows printer can't do this.

Like Marks256 says, an old dot-matrix printer would be fine, but so would any OLD inkjet or laser, but it's got to be OLD - a DeskJet 500 would be fine, that's a 'real' printer. But most recent printers tend to be Windows only (including Mac in that, as they often provide Mac drivers as well).

Click to expand...

Windows printers are quite frankly crap.

It makes no sense to use the main CPU for tasks like printing a time where tasks such as graphics and sound are increasingly been handeled by other processors. Also it means that people can't use them with free software.