Searching \ for '[PIC]: PIC16F877 and 186 solenoids' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/ios.htm?key=solenoid
Search entire site for: 'PIC16F877 and 186 solenoids'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: PIC16F877 and 186 solenoids'
2000\11\07@191152 by Brent Brown

picon face
Hi,

I'm just sketching up an interesting looking project at the moment
that some of you might be able to offer advice on.

A PC in a machine needs to control a whole heap of 24V DC
miniature compressed air solenoid valves. There can be up to 186
of these solenoids in one machine. Only a few valves will be on
simultaneously, and they draw about 300mA each. Worst case
scenario is 20% of the valves on at the same time. Prime
objectives are speed of control by the PC (minimum software
overhead and time delay before valve actuation.) There might be
1000 valve operations per second.

My ideas so far:-

- PC parallel printer port connected to PSP on PIC16F877 for fast
byte-wise transfer of data from the PC.

- PIC stores an image of valve data in RAM.

- PIC drives a whole bunch of TPIC6A595 8 bit serial input DMOS
power driver shift register IC's, connected in series, with clock and
data line from the micro's synchronous serial port. 20MHz PIC can
clock data at 1.25 or 5MHz.

- Might arrange the power shift registers in groups with a strobe line
per group to speed up the process.

My questions?:-

- Can the PC parallel port in a fancy mode like ECP or EPP or
something automatically generate a strobe pulse when 8 bits of
data are output? This would reduce the PC overhead.

- Has anyone used the TPIC6A595 from TI, or the A6A595 from
Allegro with good or bad comments, hints or tips? Is the built in
protection any good?

- Any comments welcome.

Brent Brown
Electronic Design Solutions
16 English Street
Hamilton, New Zealand
Ph/fax: +64 7 849 0069
Mobile/text: 025 334 069
eMail:  spam_OUTbrent.brownTakeThisOuTspamclear.net.nz

--
http://www.piclist.com hint: To leave the PICList
.....piclist-unsubscribe-requestKILLspamspam@spam@mitvma.mit.edu




2000\11\07@193728 by Tony Nixon

flavicon
picon face
Brent Brown wrote:
>
> My questions?:-
>
> - Can the PC parallel port in a fancy mode like ECP or EPP or
> something automatically generate a strobe pulse when 8 bits of
> data are output? This would reduce the PC overhead.
>
> - Has anyone used the TPIC6A595 from TI, or the A6A595 from
> Allegro with good or bad comments, hints or tips? Is the built in
> protection any good?
>
> - Any comments welcome.


You would still be limited by the OS of the PC as to how much data
transfer comes in/out of the parallel port.

186 bits, 1 for each solenoid = 24 bytes (worst case) of data to send
plus handshaking. Multiply this by 1000 changes / second and perhaps the
PC will not be able to cope reliably.

--
Best regards

Tony

mICro's
http://www.picnpoke.com
salesspamKILLspampicnpoke.com

--
http://www.piclist.com hint: To leave the PICList
.....piclist-unsubscribe-requestKILLspamspam.....mitvma.mit.edu




2000\11\08@044349 by Brent Brown

picon face
{Quote hidden}

Yep, thats what I'm afraid of. 1000 might be too high a figure to put
on it, don't know exactly what it will be. To write one byte of a data
to a standard parallel port you need one instruction to put out the
data and two more instructions to toggle the strobe line. 3
instructions where 1 could do.

I have been looking at EPP and ECP all day. Does pretty much
what I want - at this stage it all looks a bit too complicated, but I'm
keen to hear from anyone thats done this on a PIC.

Another option is just writing 7 bits of data to a standard parallel
port, with the 8th bit being 1 and 0 on alternate writes. From this
changing bit I can generate a logic pulse to strobe the data into the
latch (PSP port). One instruction on the PC and 7 bits of data is
transferred.

Solenoids will usually change one at a time, so rather than dump
24 bytes of data for all 186 solenoids in one go I'll just send the
address of the solenoid that needs to be turned on. One mode of
operation is to then get the PIC to turn off the solenoids a certain
period of time after each one gets turned on. This cuts data traffic
by a half. Think I can do that by having a one byte for each
solenoid, counting down every millisecond until it gets to zero and
the valve is turned off. Probably will have one PIC for each bank of
64 valves.

Brent Brown
Electronic Design Solutions
16 English Street
Hamilton, New Zealand
Ph/fax: +64 7 849 0069
Mobile/text: 025 334 069
eMail:  EraseMEbrent.brownspam_OUTspamTakeThisOuTclear.net.nz

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:","[SX]:","[AVR]:" =uP ONLY! "[EE]:","[OT]:" =Other "[BUY]:","[AD]:" =Ads




2000\11\08@045906 by Michael Rigby-Jones

flavicon
face
{Quote hidden}

I haven't yet seen the original post (delayed I guess) but 24bits x 1000
=24000 bits/sec which is < 3Kbytes sec. 100Kbytes/sec is fairly easily
obtainable on even a standard parallel port with a relatively modern CPU.

Mike

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:","[SX]:","[AVR]:" =uP ONLY! "[EE]:","[OT]:" =Other "[BUY]:","[AD]:" =Ads




2000\11\08@094116 by Olin Lathrop

flavicon
face
> A PC in a machine needs to control a whole heap of 24V DC
> miniature compressed air solenoid valves. There can be up to 186
> of these solenoids in one machine. Only a few valves will be on
> simultaneously, and they draw about 300mA each. Worst case
> scenario is 20% of the valves on at the same time. Prime
> objectives are speed of control by the PC (minimum software
> overhead and time delay before valve actuation.) There might be
> 1000 valve operations per second.

You didn't say what your target latency actually is, but your data rate isn't
that high.  You have 186 bits to control, which comes out to 24 bytes.  So
let's say 32 bytes need to be sent to define the desired state of all
valves.  At 115.2Kbaud, that's less than 3mS.  I'm guessing that is
acceptable, in which case RS-232 is a reasonable option.

I also don't know how much you can dedicate the solution to just this exact
task, or if you need to leave room in the architecture for some changes to
the requirements.  If you only need to sovle this specific problem, then you
could use a bunch of PICs in parallel as RS-232 to output bit converters.
Since communication is one way, all the PICs could listen to all the data,
then just react to the bits they control individually.  You need some scheme
so that the PICs can sync to the host data stream, but I doubt you will need
as many as 32 bytes to get 186 bits of payload.


*****************************************************************
Olin Lathrop, embedded systems consultant in Devens Massachusetts
(978) 772-3129, KILLspamolinKILLspamspamcognivis.com, http://www.cognivis.com

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:","[SX]:","[AVR]:" =uP ONLY! "[EE]:","[OT]:" =Other "[BUY]:","[AD]:" =Ads




2000\11\08@094738 by staff

flavicon
face
Brent Brown wrote:
{Quote hidden}

Brent, there are a LOT of pins on a parallel port;
data port:      8 lines bi-direction
status port:    5 input lines
control port:   6 output lines

That is from memory, I use the parallel port to control a few
things with projects. See:
http://www.senet.com.au/~cpeacock
for some really good port specs stuff.

If you use the 6 output lines for decoding you get 64 "banks"
of 8 data lines. I'm sure you could get more with some clever
software. 64x8 = 512 active output lines, with a refresh/update
of 1/64.

The parallel ports are also *very* quick if you can run without
windows, ie, dos only bootup.

Hope this helps!
-Roman

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:","[SX]:","[AVR]:" =uP ONLY! "[EE]:","[OT]:" =Other "[BUY]:","[AD]:" =Ads




2000\11\08@095602 by Bob Ammerman

picon face
There are many ways of doing this. As Olin's message indicated we could help
a lot more if we had more details:

You say about 1000 'events' per second. Is that an average or a max.

How much delay is allowable between the time the PC wants to turn on an
output and when it actually happens. How much 'jitter' in that delay is
acceptable?

If the PC wants to turn on several outputs at once, how much difference in
the actual time they are turned on is acceptable?

What environment is the PC program running in (DOS, WIN9x WINnt, Linux,
???). This has a _huge_ bearing on attainable performance/latency.

Is this a one-off, or a production item?

How cost sensitive?

Anything else you can think of that might help us?

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:","[SX]:","[AVR]:" =uP ONLY! "[EE]:","[OT]:" =Other "[BUY]:","[AD]:" =Ads




2000\11\08@095605 by Don Hyde

flavicon
face
My personal bias would be to put as much of the time-critical operation as
possible into the PIC, and let the PC mostly do slow and operator-interface
stuff.

I would go for higher-level commands going between the PC and the PIC.
Stuff like "turn on #43 for 27 mS".

For communications, unless you want to get into a lot of work qualifying
PC's, and messing with writing PC drivers and stuff, the only I/O you can
really count on is the serial port.  PC's pretty much always have serial
ports that will go to 115.2K, and Windoze exposes fairly usable API's for
them.  I've found the Windoze API's for the parallel port to be much less
friendly -- they distinctly assume that you have a printer hooked up to it,
with a printer driver for it.

Unless you're planning to run some non-M$ realtime OS on the PC, you have
absolutely no guarantees for timing, so I would put anything time- or
safety-critical into the PIC, where you have much more control over what is
going on.

> {Original Message removed}

2000\11\08@100215 by Bob Ammerman

picon face
Yep, Roman got me to thinking, this application don't need no stinkin' PIC
;-)

Just tie a bunch of TPIC6B595 serial power shift registers directly to the
parallel port.

One chain of shift registers on each data pin.

Use the other parallel port pins to clock in the data and strobe the shift
regs load input.

Done!

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:","[SX]:","[AVR]:" =uP ONLY! "[EE]:","[OT]:" =Other "[BUY]:","[AD]:" =Ads




2000\11\08@100340 by Bob Ammerman

picon face
Yes, of course, the NO PIC idea I just posted assumes that you are running
Windowsless (and for really good time resolution DOSLESS).

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

----- Original Message -----
From: Don Hyde <RemoveMEDonHTakeThisOuTspamAXONN.COM>
To: <spamBeGonePICLISTspamBeGonespamMITVMA.MIT.EDU>
Sent: Wednesday, November 08, 2000 9:54 AM
Subject: Re: [PIC]: PIC16F877 and 186 solenoids


> My personal bias would be to put as much of the time-critical operation as
> possible into the PIC, and let the PC mostly do slow and
operator-interface
{Quote hidden}

it,
> with a printer driver for it.
>
> Unless you're planning to run some non-M$ realtime OS on the PC, you have
> absolutely no guarantees for timing, so I would put anything time- or
> safety-critical into the PIC, where you have much more control over what
is
> going on.
>
> > {Original Message removed}

2000\11\08@101413 by staff

flavicon
face
Bob Ammerman wrote:
>
> Yes, of course, the NO PIC idea I just posted assumes that you are running
> Windowsless (and for really good time resolution DOSLESS).
>

Actually dos doesn't chew timeslice unless you press a key or wiggle the
mouse. I have done a lot of testing and use home made dos programs
for port control with 100% timing accuracy. You can check the PIT chip
in the PC by passively polling it (3.?? MHz) to get ticks and use these
to
time events on the ports. I even check things like vertical retracing of
the video driver to give flicker free animation and stuff. The PC will
perform as accurately as a big PIC if you lose windows!!
-Roman

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:","[SX]:","[AVR]:" =uP ONLY! "[EE]:","[OT]:" =Other "[BUY]:","[AD]:" =Ads




2000\11\08@161118 by Brent Brown

picon face
> Yep, Roman got me to thinking, this application don't need no stinkin' PIC
> ;-)
>
> Just tie a bunch of TPIC6B595 serial power shift registers directly to the
> parallel port.
>
> One chain of shift registers on each data pin.
>
> Use the other parallel port pins to clock in the data and strobe the shift
> regs load input.
>
> Done!
>
> Bob Ammerman

Hmmm, maybe. Might be too much PC software overhead, but I'll
think about that one some more though. Thanks.

You said TPIC6B595 and I said TPIC6A595 - does that mean you
have some experience with these things or was it just a typo?

Brent Brown
Electronic Design Solutions
16 English Street
Hamilton, New Zealand
Ph/fax: +64 7 849 0069
Mobile/text: 025 334 069
eMail:  TakeThisOuTbrent.brownEraseMEspamspam_OUTclear.net.nz

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:","[SX]:","[AVR]:" =uP ONLY! "[EE]:","[OT]:" =Other "[BUY]:","[AD]:" =Ads




2000\11\08@161130 by Brent Brown

picon face
> My personal bias would be to put as much of the time-critical operation as
> possible into the PIC, and let the PC mostly do slow and operator-interface
> stuff.
>
> I would go for higher-level commands going between the PC and the PIC.
> Stuff like "turn on #43 for 27 mS".

Me too. I'm most concerned about getting the data out of the PC
with minimum effort and in a reasonably elegant kind of way. The
PIC side will be a bit of a challenge, but I'm still happier to be
programming on the PIC side!

Brent Brown
Electronic Design Solutions
16 English Street
Hamilton, New Zealand
Ph/fax: +64 7 849 0069
Mobile/text: 025 334 069
eMail:  RemoveMEbrent.brownspamTakeThisOuTclear.net.nz

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:","[SX]:","[AVR]:" =uP ONLY! "[EE]:","[OT]:" =Other "[BUY]:","[AD]:" =Ads




2000\11\08@161322 by Brent Brown

picon face
Hi,

So many replies while I was asleep!...[warning]: long post follows,
read at your own risk!

OK, I'm not doing the whole project, but a few more details:-

- It's for a commercial product not a one off. The prototype WILL be
the released version!

- Cost is not too critical, balance with low component count, ease
of assembly, reliability etc. Eg. the TPIC6A595 is more expensive
than some options but is supposed to have short circuit protection.
One less failure in the field, for any reason, is a huge saving.

- Running Windows 95 on a Pentium III big something. Large
application that is very CPU and I/O intensive (not my
programming, thank goodness). Runs a huge number of analog
inputs. Uses one or two huge analog multiplexing boards that I laid
out (hooray!). Samples at 333kHz, I think anywhere from 150-
550'ish analog inputs. Pretty sure this keeps the PC busy.

- The main output of all this is up to 186 air valves. High speed is
the issue, my client wants something better than 250us latency
when switching on any single valve. Because of this speed
requirement the program will access the valves one at a time rather
than "send all 24 bytes" approach. I think this almost rules out
RS232 also. Two bytes at 115.2kbaud is around 175us, getting
close.

- Not sure exactly of the number of outputs that need to be
changed per second. I'm using 1000 per second as a maximum.

- CPU time for the output task should be minimized. Something
like 1 or 2% of total time would be nice.

The first design idea used a 24 bit parallel I/O card connected to a
whole bunch of address decode logic and latches and stuff. Very
cunning design - it could switch any valve in a single 8 bit write to
one of the 3 8 bit ports. I'm told it takes about 1.5us to write to an
ISA card. Only problem with this design is that it is very big - over
50 chips per board (two boards), and requires an I/O card. I think
we can come up with a more elegant solution, here goes!:-

What I am planning at the moment is the following: Up to 4 PIC
boards of 64 valves each (64,128,192 or 256 valves total), all
sharing the same standard parallel port, same lines. Probably hang
them all off a ribbon cable.

PC writes a control byte with 2 address bits to select one of the
four PIC boards, and a command. The PIC board that has the
matching 2 bit address (set by DIP switches?) then pays attention.
The PC then writes one or more address bytes, each of which
contains a 6 bit address which is the address of one of the 64
valves on the selected PIC board to turn on. The PIC sets a
software timer for this valve and turns it on.

A control byte is recognised by bit 6 being 1, and an address byte
is recognised by bit 6 being 0. Either byte is identified as being
sent by bit 7 toggling. (The PC does this in software, inverting bit 7
each time it writes anything out). Bit 7 is decoded by a simple gate
circuit to generate a /WR strobe pulse for the PIC PSP port. Thus
the PC can send either byte in just 1 I/O write (1.5us), and can turn
on any valve on any board with just 2 I/O writes (3us).

The Control byte has a command in it that sets the mode of
operation of the PIC board, eg. an address instruction turns the
valve on, or off, or toggles it, or turns it on for a predefined period of
time, or turns it on for a specified period of time. Additionally the
control byte can set the value of the timer.

Each PIC controls 64 valves using 8 x TPIC6A595 power shift
registers in series. To update the outputs the PIC clocks out 64
bits of data using the MSSP. At 1.25MHz this woud take about
50us plus overheads, lets say <100us anyway. I intend to reserve 1
byte of RAM for each valve, 64 bytes total. When a valve is required
to be turned a timer value is placed into it's shadow RAM location.
This is decremented every millisecond. The main line code scans
through the shadow RAM and makes a 64 bit word that repesents
the on/off state for all the valves and this is the data that is clocked
out. The PIC repeats this as fast as possible, and maybe only
clocks the data out if it has changed since last time.

Not sure if that's clear or not! Still would like to hear from someone
that has used the TPIC IC's or has experience with EPP or ECP.

Thanks, Brent.

Brent Brown
Electronic Design Solutions
16 English Street
Hamilton, New Zealand
Ph/fax: +64 7 849 0069
Mobile/text: 025 334 069
eMail:  brent.brownEraseMEspam.....clear.net.nz

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:","[SX]:","[AVR]:" =uP ONLY! "[EE]:","[OT]:" =Other "[BUY]:","[AD]:" =Ads




2000\11\08@171506 by Dwayne Reid

flavicon
face
At 10:11 AM 11/9/00 +1300, Brent Brown wrote:

>You said TPIC6B595 and I said TPIC6A595 - does that mean you
>have some experience with these things or was it just a typo?

I thought that I'd jump in here for a moment - just how much current to you
really need, Brent?  I use a *LOT* of TPIC6B595 chips - the nice thing
about them is that they are pin compatible with the TPIC6595 (note the lack
of the 'B') if you connect pins 1 & 20 to pins 10 & 11 (power GND).  They
are fairly robust - I've never killed an output stage but they are *VERY*
sensitive to over-voltage on the logic supply.

I like them a lot.  I tend to mix them and 74HC595s as needed on my SPI busses.

dwayne



Dwayne Reid   <EraseMEdwaynerspamplanet.eon.net>
Trinity Electronics Systems Ltd    Edmonton, AB, CANADA
(780) 489-3199 voice          (780) 487-6397 fax

Celebrating 16 years of Engineering Innovation (1984 - 2000)

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Do NOT send unsolicited commercial email to this email address.
This message neither grants consent to receive unsolicited
commercial email nor is intended to solicit commercial email.

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:","[SX]:","[AVR]:" =uP ONLY! "[EE]:","[OT]:" =Other "[BUY]:","[AD]:" =Ads




2000\11\08@172312 by Bob Ammerman

picon face
----- Original Message -----
From: Brent Brown <RemoveMEbrent.brownEraseMEspamEraseMECLEAR.NET.NZ>
To: <RemoveMEPICLISTspam_OUTspamKILLspamMITVMA.MIT.EDU>
Sent: Wednesday, November 08, 2000 4:11 PM
Subject: Re: [PIC]: PIC16F877 and 186 solenoids


> > Yep, Roman got me to thinking, this application don't need no stinkin'
PIC
> > ;-)
> >
> > Just tie a bunch of TPIC6B595 serial power shift registers directly to
the
> > parallel port.
> >
> > One chain of shift registers on each data pin.
> >
> > Use the other parallel port pins to clock in the data and strobe the
shift
> > regs load input.
> >
> > Done!
> >
> > Bob Ammerman
>
> Hmmm, maybe. Might be too much PC software overhead, but I'll
> think about that one some more though. Thanks.

There should be no more overhead here than banging the bits out to a PIC.
You should be able to output 21 bytes of data (ie: 21*8 = 168) in 100 or at
most 200 microseconds.

You would chain 3 '595s off of each data bit.

> You said TPIC6B595 and I said TPIC6A595 - does that mean you
> have some experience with these things or was it just a typo?

Um, no. Just the number I grabbed out of my Digikey catalog. There are
apparently several flavors of this in the world.

{Quote hidden}

"[BUY]:","[AD]:" =Ads
>
>
>
>

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:","[SX]:","[AVR]:" =uP ONLY! "[EE]:","[OT]:" =Other "[BUY]:","[AD]:" =Ads




2000\11\08@172930 by Bob Ammerman

picon face
----- Original Message -----
From: Brent Brown <EraseMEbrent.brownspamspamspamBeGoneCLEAR.NET.NZ>
To: <RemoveMEPICLISTKILLspamspamMITVMA.MIT.EDU>
Sent: Wednesday, November 08, 2000 4:11 PM
Subject: Re: [PIC]: PIC16F877 and 186 solenoids


{Quote hidden}

What do you mean 250 uS 'latency'. You are going to have perhaps many
milliseconds or more of jitter/latency introduced by Windows.

Is it the on-time that must be strictly controlled?

{Quote hidden}

Watch out: you will be simultaneously changing /WR and data bits on the PSP
port. Check you setup and hold requirements!

{Quote hidden}

Use 8 PIC outputs and feed them into 8 '595s at once (each one does 8
outputs).

Now your output is something like:

   movf        outs_0,w
   movwf     PORTB
   bsf           PORTA,TPIC_CLOCK
   bcf           PORTA,TPIC_CLOCK

repeat the above 8x to output all 64 bits then

   bsf           PORTA,TPIC_LOAD
   bcf           PORTA,TPIC_LOAD


{Quote hidden}

"[BUY]:","[AD]:" =Ads
>
>
>
>

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:","[SX]:","[AVR]:" =uP ONLY! "[EE]:","[OT]:" =Other "[BUY]:","[AD]:" =Ads




2000\11\08@184828 by Brent Brown

picon face
> There should be no more overhead here than banging the bits out to a PIC.
> You should be able to output 21 bytes of data (ie: 21*8 = 168) in 100 or at
> most 200 microseconds.

Yes, I know 100us doesn't sound much, but repeated 1000 times
per second (worst case) is 10% CPU time, way too much.

Think of a field of 186 valves. Any one could be activated at
random, and it basically has to turn off a fixed time period later. It
makes sense to only send the minimum data required to turn on
that one valve, and then get the PIC to turn it off later.

As for the 250us I referred to as latency. Maybe not the right word.
The most important thing is that the valve turns on at the right time,
second most important, only slightly less important, is that it turns
off at the right time. My client wants no more than a maximum of
250us variation in the delay from instruction issued till event
happening. I don't know (and don't want to know) all the Windows
issues, that's his problem, but I want the hardware to be the
smallest possible factor in it.

Have been talking to my client since recent postings, and we have
decide to try out EPP mode on the parallel port. Sounds like you
can send or receive 8, 16 or 32 bits in one PC instruction, and the
EPP port takes care of all the handshaking. We will knock up a
test board to try it out in 16 bit mode. I have a max of 10us
between bytes before the EPP port times out. That's 50
instructions with a 20MHz clock right? What am I letting myself in
for...

Brent Brown
Electronic Design Solutions
16 English Street
Hamilton, New Zealand
Ph/fax: +64 7 849 0069
Mobile/text: 025 334 069
eMail:  spamBeGonebrent.brownSTOPspamspamEraseMEclear.net.nz

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:","[SX]:","[AVR]:" =uP ONLY! "[EE]:","[OT]:" =Other "[BUY]:","[AD]:" =Ads




2000\11\08@190722 by Tony Nixon

flavicon
picon face
Brent Brown wrote:

> What am I letting myself in for...

Fun :-)

--
Best regards

Tony

mICro's
http://www.picnpoke.com
KILLspamsalesspamBeGonespampicnpoke.com

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:","[SX]:","[AVR]:" =uP ONLY! "[EE]:","[OT]:" =Other "[BUY]:","[AD]:" =Ads




2000\11\08@214757 by Bob Ammerman

picon face
----- Original Message -----
From: Brent Brown <EraseMEbrent.brownspamEraseMECLEAR.NET.NZ>
To: <@spam@PICLIST@spam@spamspam_OUTMITVMA.MIT.EDU>
Sent: Wednesday, November 08, 2000 6:47 PM
Subject: Re: [PIC]: PIC16F877 and 186 solenoids


> > There should be no more overhead here than banging the bits out to a
PIC.
> > You should be able to output 21 bytes of data (ie: 21*8 = 168) in 100 or
at
{Quote hidden}

I hope it isn't BIG TROUBLE. Make sure your customer understands the
implications of trying to do submillisecond hard real-time on an operating
system where you'd be lucky to manage 50 milliseconds.

Or alternately, make sure that you don't get the blame when the thing
doesn't work very well.

Watch out!

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

{Quote hidden}

"[BUY]:","[AD]:" =Ads
>
>
>
>

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:","[SX]:","[AVR]:" =uP ONLY! "[EE]:","[OT]:" =Other "[BUY]:","[AD]:" =Ads




2000\11\08@223036 by Olin Lathrop

flavicon
face
> My client wants no more than a maximum of
> 250us variation in the delay from instruction issued till event
> happening.

This is simply not possible with Windows.  I've measured NT 4 on quite a
fast Pentium going out to lunch for well over 100mS on occasion for no
apparent reason.  I could greatly increase the frequency of these NT
lunchtimes by just moving the mouse.  I've seen similar issues with Windows
95/98, but have never tried to carefully measure them.

The bottom line is that Windows is not a real time system.  To be fair to
Microsoft, they have never claimed Windows to be real time.  If you truly
need 250uS response from when a decision is made to open a valve until the
valve is commanded to open, then you need a real time OS.

Just out of curiosity, how fast do these valves respond?  Do they really
fast enough so that 250uS makes a relevant difference?


*****************************************************************
Olin Lathrop, embedded systems consultant in Devens Massachusetts
(978) 772-3129, .....olinspam_OUTspamcognivis.com, http://www.cognivis.com

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:","[SX]:","[AVR]:" =uP ONLY! "[EE]:","[OT]:" =Other "[BUY]:","[AD]:" =Ads




2000\11\09@040620 by Alan B. Pearce

face picon face
>A control byte is recognised by bit 6 being 1, and an address byte
>is recognised by bit 6 being 0. Either byte is identified as being
>sent by bit 7 toggling. (The PC does this in software, inverting bit 7
>each time it writes anything out). Bit 7 is decoded by a simple gate
>circuit to generate a /WR strobe pulse for the PIC PSP port. Thus
>the PC can send either byte in just 1 I/O write (1.5us), and can turn
>on any valve on any board with just 2 I/O writes (3us).


This has the advantage that you could set the port up as a generic text only
printer, and print characters to the port as an initial "get you going" scheme
as you do not worry about the handshake lines on the port. I like it.

Later when you need the speed you can worry about bypassing the underlying code
and access the port direct.

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics




2000\11\09@041721 by Alan B. Pearce

face picon face
>Have been talking to my client since recent postings, and we have
>decide to try out EPP mode on the parallel port. Sounds like you
>can send or receive 8, 16 or 32 bits in one PC instruction, and the
>EPP port takes care of all the handshaking. We will knock up a
>test board to try it out in 16 bit mode. I have a max of 10us
>between bytes before the EPP port times out. That's 50
>instructions with a 20MHz clock right? What am I letting myself in
>for...

Is it worth checking out the parallel port interface on some pics to see if it
will interface to an EPP. The 16F87x family has this port with the handshake
lines as one of its features. Have not looked at it myself, just a thought.

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics




2000\11\09@050957 by Brent Brown

picon face
Thanks everyone for the replies. I'll pass these comments about
Windoze on to my client. He does have an existing product
working though, driving the valves directly from an ISA card. Makes
me wonder how good it actually works. I can see that variations of
several milliseconds would cause imperfect operation of the
machine.

I know that a solenoid valve won't respond in 250us, but I guess the
idea we are working on here is trying to keep all the variables at
least one order of magnitude below that where they start causing
concern. I'll ask a few more questions.

The EPP port looks quite cool now (a bit scary at first), lots of good
web sites around for info. At first look the PSP port doesn't seem
to have the right kind of logic to make it suitable for this use. I
wondered about just an 8 bit port and an interrupt line, but I'm not
sure if handling nested interrupts is feasible on the PIC (eg.
allowing for EPP interrupt to occur during a timer interrupt or MSSP
interrupt). I'll persist with the PSP a bit more.

Brent Brown
Electronic Design Solutions
16 English Street
Hamilton, New Zealand
Ph/fax: +64 7 849 0069
Mobile/text: 025 334 069
eMail:  TakeThisOuTbrent.brown.....spamTakeThisOuTclear.net.nz

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics




2000\11\09@064039 by mike

flavicon
face
On Wed, 8 Nov 2000 21:51:48 -0500, you wrote:

>> My client wants no more than a maximum of
>> 250us variation in the delay from instruction issued till event
>> happening.
>
>This is simply not possible with Windows.  I've measured NT 4 on quite a
>fast Pentium going out to lunch for well over 100mS on occasion for no
>apparent reason.  I could greatly increase the frequency of these NT
>lunchtimes by just moving the mouse.  I've seen similar issues with Windows
>95/98, but have never tried to carefully measure them.
>
>The bottom line is that Windows is not a real time system.  To be fair to
>Microsoft, they have never claimed Windows to be real time.  If you truly
>need 250uS response from when a decision is made to open a valve until the
>valve is commanded to open, then you need a real time OS.
>
>Just out of curiosity, how fast do these valves respond?  Do they really
>fast enough so that 250uS makes a relevant difference?
One other option would be to make the PIC more responsible for timing
- the PIC keeps a 'master clock' and you send it timestamped data in
advance- e.g. 'turn on device x at time t for duration y'. The PC
would then only need to keep 'loose' synchronisation with the PIC, and
as long as you could send data long enough in advance (e.g. a second
or two) momentary time glitches on the PC would not affect overall
system timing accuracy. The only possible problem here is you might
not have enough RAM in the PIC to hold enough queued requests.
To get millisecond-scale timing on the PC you would certainly have to
do much of it under interrupts. If you have more data than the PIC
could store, It may be possible to implement the above event-queueing
type system on the PC as a timer interrupt task and get reasonable
accuracy, or maybe use a hybrid of the two systems - say a 100mS PC
interrupt that sends all the required changes for the next 100mS
period to the PIC, and the PIC then schedules the events within that
100mS window.  Obviously this all hinges on how far in advance the PC knows it will
need to operate the outputs.
--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics




2000\11\09@065320 by Alan B. Pearce

face picon face
The more of see of this thread, the more I get the feeling that the project
should really be done with PLC's, but any further comment along this line will
need to be done as [OT]:

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics




2000\11\09@074442 by Bob Ammerman

picon face
----- Original Message -----
From: Alan B. Pearce <TakeThisOuTA.B.PearceKILLspamspamspamRL.AC.UK>
To: <.....PICLISTspamRemoveMEMITVMA.MIT.EDU>
Sent: Thursday, November 09, 2000 4:06 AM
Subject: Re: [PIC]: PIC16F877 and 186 solenoids


> >A control byte is recognised by bit 6 being 1, and an address byte
> >is recognised by bit 6 being 0. Either byte is identified as being
> >sent by bit 7 toggling. (The PC does this in software, inverting bit 7
> >each time it writes anything out). Bit 7 is decoded by a simple gate
> >circuit to generate a /WR strobe pulse for the PIC PSP port. Thus
> >the PC can send either byte in just 1 I/O write (1.5us), and can turn
> >on any valve on any board with just 2 I/O writes (3us).
>
>
> This has the advantage that you could set the port up as a generic text
only
> printer, and print characters to the port as an initial "get you going"
scheme
> as you do not worry about the handshake lines on the port. I like it.

This will not work unless his device returns 'acks' to the PC.

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

>
> Later when you need the speed you can worry about bypassing the underlying
code
> and access the port direct.
>
> --
> http://www.piclist.com hint: The list server can filter out subtopics
> (like ads or off topics) for you. See http://www.piclist.com/#topics
>
>
>
>

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics




2000\11\09@081842 by Alan B. Pearce

face picon face
>This will not work unless his device returns 'acks' to the PC.

Probably not hard to do from my memory of looking at the described waveforms
from many cheap printers. some form of one shot signal derived from the strobe
line would probably do it, and it could probably be done with a CMOS dual one
shot that could raid its power from the port. Hide it all inside the plug.

This would rely on the port being used in basic mode, not EPP or ECP, or any of
the other fancy modes. The handshake signals then may get more stringent.

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics




2000\11\09@084744 by mike

flavicon
face
On Thu, 9 Nov 2000 23:09:45 +1300, you wrote:

>Thanks everyone for the replies. I'll pass these comments about
>Windoze on to my client. He does have an existing product
>working though, driving the valves directly from an ISA card. Makes
>me wonder how good it actually works. I can see that variations of
>several milliseconds would cause imperfect operation of the
>machine.
>
>I know that a solenoid valve won't respond in 250us, but I guess the
>idea we are working on here is trying to keep all the variables at
>least one order of magnitude below that where they start causing
>concern. I'll ask a few more questions.
>
>The EPP port looks quite cool now (a bit scary at first), lots of good
>web sites around for info. At first look the PSP port doesn't seem
>to have the right kind of logic to make it suitable for this use. I
>wondered about just an 8 bit port and an interrupt line, but I'm not
>sure if handling nested interrupts is feasible on the PIC (eg.
>allowing for EPP interrupt to occur during a timer interrupt or MSSP
>interrupt). I'll persist with the PSP a bit more.
You can't do nested ints, but you don't really need to. It seems you
basically have 2 tasks - pc comms and timed operation of the
solenoids. Only one of these tasks (the most time-critical) needs to
run on ints - probably the PC comms. The timer stuff can run polled in
the foreground - the few microseconds' jitter caused by doing this
should not be an issue in this appliction.
If you can make your interface look like a printer to the PC this will
certainly simplify things - this can be easily done on the PIC with an
interrupt line from /strobe. I believe one feature of the various
enhanced parallel ports on PCs is a transmit FIFO - if you pretend to
be a printer you can make use of this functionality to ease the timing
burden on the PC. It would also allow more hardware flexibility, and
be likely to work on different PCs.  
--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics




2000\11\09@115102 by jamesnewton

face picon face
Please let me know if you learn anything about ECP or EPP operation of the
PC Parallel port. I'm keenly interested in this and have not been able to
get anything to work correctly under MS Windows.... in DOS, simple tests
seem to work, but not under Windows. I have a page of info at
http://www.piclist.com/../io/parallel/port.htm
which describes all the signals and how they are used in various modes with
links to documents about the modes themselves. Please don't hesitate to fill
out the little form so you can post questions, ideas or comments directly to
these pages.

To my knowledge, there is no open source documentation of this
functionality. You would be opening new ground if you release what you
discover.

---
James Newton (PICList Admin #3)
RemoveMEjamesnewtonspamspamBeGonepiclist.com 1-619-652-0593
PIC/PICList FAQ: http://www.piclist.com or .org

{Original Message removed}

2000\11\09@200545 by Harold M Hallikainen

picon face
On Thu, 9 Nov 2000 08:49:23 -0800 James Newton <spamBeGonejamesnewton@spam@spamspam_OUTPICLIST.COM>
writes:
> Please let me know if you learn anything about ECP or EPP operation
> of the
> PC Parallel port. I'm keenly interested in this and have not been
> able to
> get anything to work correctly under MS Windows.... in DOS, simple
> tests
> seem to work, but not under Windows. I have a page of info at
> http://www.piclist.com/../io/parallel/port.htm
> which describes all the signals and how they are used in various
> modes with
> links to documents about the modes themselves.


       This page is very nice! I did a product
(http://www.dovesystems.com/starport.htm) that uses the parallel port
running under DOS. The application is written in C and twiddles the bits
of the parallel port directly. The StarPort originally used the 16c74 but
was recently changed to the 18c452 when I needed more RAM (the Dallas
DS1380 RamPort I had been using wes discontinued). The product page has a
link to a page that describes the parallel port interface. I used a
modification of the standard parallel port write, using a 1 wire
handshake (the pin changes state to acknowledge reception of the last
byte). The PIC picks up the 8 bit data using PSP mode. Data from the
StarPort back to the host uses nibble mode.
       I'm thinking of changing the interface to have it look more like a
generic printer (do they exist anymore???  My Windoze 98 doesn't have
anything for a plain text printer). Instead of having to write drivers,
it seems as though there should be a default driver where we can just
send data to it and pick data up from it (using nibble, ECP, EPP, or
whatever).

Harold


FCC Rules Online at http://hallikainen.com/FccRules
Lighting control for theatre and television at http://www.dovesystems.com

________________________________________________________________
YOU'RE PAYING TOO MUCH FOR THE INTERNET!
Juno now offers FREE Internet Access!
Try it today - there's no risk!  For your FREE software, visit:
dl.http://www.juno.com/get/tagj.

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics




2000\11\10@103947 by jamesnewton

face picon face
Having a generic driver that would allow one to send ECP or EPP data to a
hardware device from Windows AND pick up a result via any of the reverse
modes would be a great thing for PICListers and other device makers. But...
I haven't seen one. Let me know if you do run over one...

---
James Newton TakeThisOuTjamesnewtonspamspamgeocities.com 1-619-652-0593


{Original Message removed}

2000\11\10@183341 by Brent Brown

picon face
As there were so many comments about the speed of Windoze 95
for this job, I asked my client about it (he has written the PC
application).

He says he has watched his program execution time carefully, and
has not observed any major problems. The scan time of the
program is 0.6ms and he logs any exceptions to this. I don't know
how extensive this testing has been, but for example after 1 hour of
operation there were no exceptions reported.

The PC has no mouse and no keyboard, and no other applications
running, factors which no doubt reduce the number of reasons why
Windows might decide to wander off for a while.

Timing in this project is important, but not critical, in that several
crazy solenoid operations in every 500 or 1000 or so operations
wont do any harm and their effect would be insignificant in the
overall process.

I got the go-ahead to design the PIC based solution for the solenoid
driver board yesterday. Hopefully I'll be able to report in the next
week or two about our attempts at interfacing the PIC to an EPP
port.

We intend to use both address and data writes to the peripheral
(PIC board). Each PIC board will have a two bit address selectable
by hardware links, so we can have up to 4 identical boards on the
one parallel port. Each PIC board will have 18,36,54 or 72 solenoid
driver outputs. Now that there can be up to 288 solenoids I'll have to change
the subject line for this thread!

Brent Brown
Electronic Design Solutions
16 English Street
Hamilton, New Zealand
Ph/fax: +64 7 849 0069
Mobile/text: 025 334 069
eMail:  brent.brownEraseMEspamclear.net.nz

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.




2000\11\11@070809 by mike

flavicon
face
>We intend to use both address and data writes to the peripheral
>(PIC board). Each PIC board will have a two bit address selectable
>by hardware links, so we can have up to 4 identical boards on the
>one parallel port. Each PIC board will have 18,36,54 or 72 solenoid
>driver outputs. Now that there can be up to 288 solenoids I'll have to change
>the subject line for this thread!
With that number of outputs, you might want to include some fault
detection - e.g. simple current sensing on the driver commons. I
wouldn't like to try manually finding one bad connection or dead coil
out of 288!

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
use RemoveMElistservEraseMEspamspam_OUTmitvma.mit.edu?bodyT%20PICList%20DIGEST




2000\11\12@023719 by Brent Brown

picon face
> >We intend to use both address and data writes to the peripheral
> >(PIC board). Each PIC board will have a two bit address selectable
> >by hardware links, so we can have up to 4 identical boards on the
> >one parallel port. Each PIC board will have 18,36,54 or 72 solenoid
> >driver outputs. Now that there can be up to 288 solenoids I'll have to change
> >the subject line for this thread!
> With that number of outputs, you might want to include some fault
> detection - e.g. simple current sensing on the driver commons. I
> wouldn't like to try manually finding one bad connection or dead coil
> out of 288!

Me neither! The idea at the moment is to have a self test button
that makes the PIC step through all 72 valves in sequence, one at
a time. All 72 open drain power driver outputs are connected to 1
ADC input through an array of 72 diodes + 1 pull up resistor. I'm
taking advantage of the fact that the output drivers have 1 ohm on
resistance and I'm using them like current shunts. Nicer if I could
monitor current & voltage for each output individually, but hey, this
is the simplest/tidiest method I could think of... and I'm the one
that has to do the board layout!

I did think about measuring the ground current at a common point,
but these TPIC6A595's have logic and power circuit in one chip,
and I didn't want to introduce any voltage difference between logic
and power grounds. According to the application notes they are
already sensitive enough to things like poor layout.

The 72 valves are arranged in 4 banks of 18, so I use another ADC
input to monitor the circuit breaker (or polyfuse) protected +24V
feed to each bank. That way I can tell if the breaker has operated.

If any valve fails and starts to draw more or less current than
normal it should be picked up by this self test. The self test will
probably run only at power up, but the PC will have full control over
this, and can read each test result. In operation I'll just measure
the +24V to each bank occasionally to see if there are any faults
present, then if necessary do a full self test to locate the fault.

A reverse connected valve is a likely fault, during assembly, and
when this happens the built in inverse parallel diodes will conduct.

I am making the assumption (and hoping) that the TPIC6A595
drivers, which are claimed to be short circuit protected, will not be
a common cause or victim of a fault.

Brent Brown
Electronic Design Solutions
16 English Street
Hamilton, New Zealand
Ph/fax: +64 7 849 0069
Mobile/text: 025 334 069
eMail:  @spam@brent.brownRemoveMEspamEraseMEclear.net.nz

--
http://www.piclist.com hint: To leave the PICList
EraseMEpiclist-unsubscribe-requestspam@spam@mitvma.mit.edu




More... (looser matching)
- Last day of these posts
- In 2000 , 2001 only
- Today
- New search...