Searching \ for '[PIC] question from someone new to the list' 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/devices.htm?key=pic
Search entire site for: 'question from someone new to the list'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] question from someone new to the list'
2006\02\09@135315 by William Killian

flavicon
face
I've inherited a board developed by an outside contractor that uses a
PIC16F874.  I've lots of time on other processors but this is the first
I've really dealt with a PIC up close and personally.



We make slot machines and this board is the reel controller.  Almost all
the time it happily runs along take commands from what amounts to a PC
running DOS that is the main computer in the machine.  One of the
functions that the reel controller has is sending the reels (stepper
motors with 200 steps but 22 stops or symbols on the reel strips) to a
known safe losing position if there is a game failure.  A goof early on
before I was at the company was that the reel strips were designed with
no thought to where a bad hardware failure would tend to send them.  So
on one game family ( and yeah our most popular) if all reels go to motor
step 0 the top prize is displayed on the reels.



To get around that the PC sends a command to the PIC to change the home
or fault positions to some known safe point with a different stop on
each reel.  The values are stored in the internal EEPROM.  Again almost
all the time - well over 99.99% of the time this is all cool.



BUT some times the game is happily chugging along and the reel
controller apparently loses its mind.  It decides there was a failure
and the reels get sent to home positions (the going home action is a
slower spin so we know it is a sent home problem not a bad decision
about where to send them) but for some reason the reels all go to step 0
with is 4 steps off of the stop for top prize.  Not good for a slot
machine to fail and display what looks like a big win.  Not good to the
tune of some half a million in payouts a year.



Okay amusing story done, does anyone know under what conditions a PIC
might have trouble reading the internal EEPROM?  Design decisions in
making the board were some I would not have made and the programming
style is not one I would have used but I see no failure mode in the code
that would lead to this.



The original contractor told me that a colleague told him that there was
a known problem with the PIC16F87x and EEPROM that was fixed in the
PIC16F87xA but I've not seen that anywhere else so far.  Anyone else
know something like that?  White wiring an RC network to the board to
let us use the A part (a change to MCLR/Vpp) is fine but changing
thousands of board on the chance it might fix something is a tad
expensive.  If it saves a half mill a year it is a great investment
though.



Any PICophile knowledge that could help me here?



Bill Killian





-------------------------------------  Notice of Confidentiality ----------------------------------------------------------
This email and any files transmitted with it are confidential and intended solely for the use of the
individual or entity to whom they are addressed. If you have received this email in error please notify
spam_OUTpostmasterTakeThisOuTspamvgt.net. This message contains confidential information and is intended only for the
individual named. If you are not the named addressee you should not disseminate, distribute or
copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by
mistake and delete this e-mail from your system. If you are not the intended recipient you are notified
that disclosing, copying, distributing or taking any action in reliance on the contents of this information
is strictly prohibited.

2006\02\09@141307 by David VanHorn

picon face
>
> machine to fail and display what looks like a big win.  Not good to the
> tune of some half a million in payouts a year.


Ouch..

Okay amusing story done, does anyone know under what conditions a PIC
> might have trouble reading the internal EEPROM?


Are you sure it's a problem on the read side?
Write is normally the more "delicate" operation.

Does the code actually observe all the timing requirements for EE
operations?

2006\02\09@143059 by Spehro Pefhany

picon face
At 01:55 PM 2/9/2006 -0500, you wrote:

>Okay amusing story done, does anyone know under what conditions a PIC
>might have trouble reading the internal EEPROM?  Design decisions in
>making the board were some I would not have made and the programming
>style is not one I would have used but I see no failure mode in the code
>that would lead to this.

It sounds like some kind of issue with electrical noise or reset circuitry.
Make sure BOR is enabled. Consider external supervisory circuitry.
Test with LEDs in place of the coils to see if
it's electrical noise (in which case a new PCB layout may be your fix).

But.. keep in mind that there is a financial reward for failure in this
case, and people have been known to secret on their persons devices which
deliberately cause electrical noise in order to collect a jackpot. This
is common knowledge in the gaming industry, and countermeasures must be
taken.

Best regards,

Spehro Pefhany --"it's the network..."            "The Journey is the reward"
.....speffKILLspamspam@spam@interlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com
->> Inexpensive test equipment & parts http://search.ebay.com/_W0QQsassZspeff


2006\02\09@143814 by William Killian

flavicon
face
> -----Original Message-----
> From: piclist-bouncesspamKILLspammit.edu [.....piclist-bouncesKILLspamspam.....mit.edu] On
Behalf
> Of David VanHorn
> Sent: Thursday, February 09, 2006 2:13 PM
> To: Microcontroller discussion list - Public.
> Subject: Re: [PIC] question from someone new to the list
>
> >
> > machine to fail and display what looks like a big win.  Not good to
the
{Quote hidden}

I haven't verified that but it is correct far far more than not correct.
I will look into this now.

I'm guessing heat or power has something to do with this.  Happens more
in the summer that the winter (anecdotally) and we have many issues with
the cheesy power in the casinos we have these in.  Well and it is H/W
designed by programmers instead of real EE types.  Everything is running
off the PC power supply instead of solid power supplies.

Would heat and/or power issues affect the timing so it would fail rarely
and inconsistently?





-------------------------------------  Notice of Confidentiality ----------------------------------------------------------
This email and any files transmitted with it are confidential and intended solely for the use of the
individual or entity to whom they are addressed. If you have received this email in error please notify
EraseMEpostmasterspam_OUTspamTakeThisOuTvgt.net. This message contains confidential information and is intended only for the
individual named. If you are not the named addressee you should not disseminate, distribute or
copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by
mistake and delete this e-mail from your system. If you are not the intended recipient you are notified
that disclosing, copying, distributing or taking any action in reliance on the contents of this information
is strictly prohibited.

2006\02\09@144638 by Bob Axtell

face picon face
I know your business well. I designed an early player card system for
Deadwood.

- - -

In several designs, I experienced problems with the PIC16Fxxx EEPROM's. No,
the -A version is just as bad. So much so that I try NOT to use them.
But, if I have
to...

what works is to write an algorithm that writes the variable in 3 places
in EEPROM,
then when one of them has a dropped bit (best 2 of 3) when the variable
is read out,
I rewrite all 3. It increases a 20 word routine to about 50 words, but
it works well.

On the other hand, if you can store the variables in program space, you
only need
to do it once. THAT flash array always works fine.

--Bob

William Killian wrote:

{Quote hidden}

--
Note: To protect our network,
attachments must be sent to
@spam@attachKILLspamspamengineer.cotse.net .
1-520-850-1673 USA/Canada
http://beam.to/azengineer

2006\02\09@144638 by David VanHorn

picon face
>
>
> But.. keep in mind that there is a financial reward for failure in this
> case, and people have been known to secret on their persons devices which
> deliberately cause electrical noise in order to collect a jackpot. This
> is common knowledge in the gaming industry, and countermeasures must be
> taken.


Well, I get paid for finding bugs, but I prefer the conventional
employer/employee or contractor methods :)

2006\02\09@145659 by David VanHorn

picon face
I'm guessing heat or power has something to do with this.  Happens more
> in the summer that the winter (anecdotally) and we have many issues with
> the cheesy power in the casinos we have these in.



Everything about being in a casino is fun!
I had some early educational experiences in Reno and Vegas concerning their
carpeting, which I think is made by Wimshurst and VanDeGraff.

Running LAN cables under this carpeting was also pretty amusing, and coin
carts weigh a lot more than you'd think.

 Well and it is H/W designed by programmers instead of real EE
> types.  Everything is running
> off the PC power supply instead of solid power supplies.


:) Sounds like you need a crossover guy.. I happen to know one.

Would heat and/or power issues affect the timing so it would fail rarely
> and inconsistently?


Something to check: Oscillator fuse programming.
If you have the wrong mode selected, you could be skipping clock cycles in
part of the chip.
I posted something about this on the AVR platform recently involving their
CKOPT fuse.
The default state sets the oscillator running at 0V to about 1/2VCC and
causes BIZARRE problems. Worse, it frequently seems to cause no problems.

Skipping cycles internally could cause problems reading the EE, or damn near
anything else, but these problems typically will "cluster" around the
internal peripheral with the least margin for clock amplitude.

2006\02\09@151850 by William Killian

flavicon
face


> -----Original Message-----
> From: KILLspampiclist-bouncesKILLspamspammit.edu [RemoveMEpiclist-bouncesTakeThisOuTspammit.edu] On
Behalf
> Of David VanHorn
> Sent: Thursday, February 09, 2006 2:57 PM
> To: Microcontroller discussion list - Public.
> Subject: Re: [PIC] question from someone new to the list
>
> I'm guessing heat or power has something to do with this.  Happens
more
> > in the summer that the winter (anecdotally) and we have many issues
with
> > the cheesy power in the casinos we have these in.
>
>
>
> Everything about being in a casino is fun!
> I had some early educational experiences in Reno and Vegas concerning
> their
> carpeting, which I think is made by Wimshurst and VanDeGraff.
>
> Running LAN cables under this carpeting was also pretty amusing, and
coin
> carts weigh a lot more than you'd think.

I came here to a Class II bingo based company after working in Vegas for
Class III companies.  Whole different worlds: Vegas versus Indian Class
II versus Indian Class II.


>   Well and it is H/W designed by programmers instead of real EE
> > types.  Everything is running
> > off the PC power supply instead of solid power supplies.
>
>
> :) Sounds like you need a crossover guy.. I happen to know one.

So is it easy for me to guess his name? <g>

>
> Would heat and/or power issues affect the timing so it would fail
rarely
> > and inconsistently?
>
>
> Something to check: Oscillator fuse programming.
> If you have the wrong mode selected, you could be skipping clock
cycles in
> part of the chip.
> I posted something about this on the AVR platform recently involving
their
> CKOPT fuse.
> The default state sets the oscillator running at 0V to about 1/2VCC
and
> causes BIZARRE problems. Worse, it frequently seems to cause no
problems.

And what is this and how do I check it?

This that fuse word?

>From the contractor over a year ago I got
       On the programmer setting, set code protect on, wdt on, low
voltage
       programming (if that is an option) off, brown out detect on,
power up
       time enabled, XT (crystal).

Most of the chips come preprogrammed from him since he supplies us the
board that he designed.

> Skipping cycles internally could cause problems reading the EE, or
damn
> near
> anything else, but these problems typically will "cluster" around the
> internal peripheral with the least margin for clock amplitude.

Sounds like this is what I need to check then.



-------------------------------------  Notice of Confidentiality ----------------------------------------------------------
This email and any files transmitted with it are confidential and intended solely for the use of the
individual or entity to whom they are addressed. If you have received this email in error please notify
spamBeGonepostmasterspamBeGonespamvgt.net. This message contains confidential information and is intended only for the
individual named. If you are not the named addressee you should not disseminate, distribute or
copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by
mistake and delete this e-mail from your system. If you are not the intended recipient you are notified
that disclosing, copying, distributing or taking any action in reliance on the contents of this information
is strictly prohibited.

2006\02\09@152822 by William Killian

flavicon
face


> -----Original Message-----
> From: TakeThisOuTpiclist-bouncesEraseMEspamspam_OUTmit.edu [RemoveMEpiclist-bouncesspamTakeThisOuTmit.edu] On
Behalf
> Of David VanHorn
> Sent: Thursday, February 09, 2006 2:13 PM
> To: Microcontroller discussion list - Public.
> Subject: Re: [PIC] question from someone new to the list
>
> >
> > machine to fail and display what looks like a big win.  Not good to
the
{Quote hidden}

With the half hearted approach the casino and our slot tech take they
don't remove and replace the whole machine for me to examine.  I got
only the PIC chips sent back to me.  I believe I checked them right off
and the EEPROM read correctly and not as all zero for those three bytes.
With code protect on that meant I believe I put the chips in a board and
homed the reels and they didn't go to zero.

But yeah I better check to make sure I did that right.

> Does the code actually observe all the timing requirements for EE
> operations?

Checking that now.  I've gotten to used to being able to just set wait
states.

I appreciate the help guys even if I forget to say it in each
message....


-------------------------------------  Notice of Confidentiality ----------------------------------------------------------
This email and any files transmitted with it are confidential and intended solely for the use of the
individual or entity to whom they are addressed. If you have received this email in error please notify
postmasterEraseMEspam.....vgt.net. This message contains confidential information and is intended only for the
individual named. If you are not the named addressee you should not disseminate, distribute or
copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by
mistake and delete this e-mail from your system. If you are not the intended recipient you are notified
that disclosing, copying, distributing or taking any action in reliance on the contents of this information
is strictly prohibited.

2006\02\09@152837 by Peter Todd

picon face
On Thu, Feb 09, 2006 at 03:20:03PM -0500, William Killian wrote:
> > Running LAN cables under this carpeting was also pretty amusing, and
> coin
> > carts weigh a lot more than you'd think.
>
> I came here to a Class II bingo based company after working in Vegas for
> Class III companies.  Whole different worlds: Vegas versus Indian Class
> II versus Indian Class II.

I'm curious, what do you mean by "Class II" and "Class III" companies?

--
EraseMEpetespampetertodd.ca http://www.petertodd.ca

2006\02\09@153044 by William Killian

flavicon
face


> -----Original Message-----
> From: RemoveMEpiclist-bouncesEraseMEspamEraseMEmit.edu [RemoveMEpiclist-bouncesspam_OUTspamKILLspammit.edu] On
Behalf
> Of Bob Axtell
> Sent: Thursday, February 09, 2006 2:47 PM
> To: Microcontroller discussion list - Public.
> Subject: Re: [PIC] question from someone new to the list
>
> I know your business well. I designed an early player card system for
> Deadwood.

It's a fun industry.  I was in telecomm mostly for some 15 years but
that is really pretty boring.  "Whee the LED is on!"  

> - - -
>
> In several designs, I experienced problems with the PIC16Fxxx
EEPROM's.
> No,
> the -A version is just as bad. So much so that I try NOT to use them.
> But, if I have
> to...
>
> what works is to write an algorithm that writes the variable in 3
places
> in EEPROM,
> then when one of them has a dropped bit (best 2 of 3) when the
variable
> is read out,
> I rewrite all 3. It increases a 20 word routine to about 50 words, but
> it works well.

Same approach was used by our contractor on another product he did.  And
we use it on the NVRAM of the main processor.

If it was only a dropped bit or two, I'd go with this but it is turning
three bytes into all zeros not just a corruption of the byte.

>
> On the other hand, if you can store the variables in program space,
you
> only need
> to do it once. THAT flash array always works fine.

It might come to that but we are apparently running out of code space
according the contractor.

But can you change three bytes in Flash while the chip is running?  I
gotta learn more about these processors.

Thanks,
Bill


-------------------------------------  Notice of Confidentiality ----------------------------------------------------------
This email and any files transmitted with it are confidential and intended solely for the use of the
individual or entity to whom they are addressed. If you have received this email in error please notify
RemoveMEpostmasterTakeThisOuTspamspamvgt.net. This message contains confidential information and is intended only for the
individual named. If you are not the named addressee you should not disseminate, distribute or
copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by
mistake and delete this e-mail from your system. If you are not the intended recipient you are notified
that disclosing, copying, distributing or taking any action in reliance on the contents of this information
is strictly prohibited.

2006\02\09@153654 by David VanHorn

picon face
> > :) Sounds like you need a crossover guy.. I happen to know one.
>
> So is it easy for me to guess his name? <g>


Dave something or other.. :)



> And what is this and how do I check it?
> This that fuse word?


Yes.  I'd pull the data sheets on the pic and crystal, and schematics, and
sit down with the board and a scope.


>From the contractor over a year ago I got
>        On the programmer setting, set code protect on, wdt on, low
> voltage
>        programming (if that is an option) off, brown out detect on,
> power up
>        time enabled, XT (crystal).


Sounds basically right.. It may also be a problem with drive level or cap
selection on the crystal caps.  Xtals have a drive level spec that you need
to observe, and I would also check oscillation margin, though that's more of
a startup thing.

Then of course walking through the code, looking for timing issues, or maybe
an int that happens during a read, or someone stepping on the data after
it's been read.



>
> Sounds like this is what I need to check then.


If the clock dosen't sing right, then nothing else is dependable.

2006\02\09@155056 by David VanHorn

picon face
>
> With the half hearted approach the casino and our slot tech take they
> don't remove and replace the whole machine for me to examine.  I got
> only the PIC chips sent back to me.  I believe I checked them right off
> and the EEPROM read correctly and not as all zero for those three bytes.
> With code protect on that meant I believe I put the chips in a board and
> homed the reels and they didn't go to zero.



You have me curious.. This home location parameter sounds like something
that dosen't change, but it's in EE?   If it dosen't change, it should be
hardcoded.

2006\02\09@155634 by William Killian

flavicon
face
> -----Original Message-----
> From: EraseMEpiclist-bouncesspamspamspamBeGonemit.edu [RemoveMEpiclist-bouncesKILLspamspammit.edu] On
Behalf
> Of Peter Todd
> Sent: Thursday, February 09, 2006 3:44 PM
> To: Microcontroller discussion list - Public.
> Subject: Re: [PIC] question from someone new to the list
>
> On Thu, Feb 09, 2006 at 03:20:03PM -0500, William Killian wrote:
> > > Running LAN cables under this carpeting was also pretty amusing,
and
> > coin
> > > carts weigh a lot more than you'd think.
> >
> > I came here to a Class II bingo based company after working in Vegas
for
> > Class III companies.  Whole different worlds: Vegas versus Indian
Class
> > II versus Indian Class II.
>
> I'm curious, what do you mean by "Class II" and "Class III" companies?


Slot machine Types history and definitions:

Class III gaming is the Las Vegas/Atlantic City/Cruise Ship type.
The machine has its own internal RNG (Random number generator) and all
game results are based on pulling numbers from the RNG.  The oldest
machines were literally mechanical devices that like a roulette wheel
relied on the spinning of the device to have a random characteristic.
You couldn't theoretically know how to pull the handle to get them to
stop anywhere in particular.  Results were paid on the random patterns
arising from three reels ending up on random places.

Later the mechanical reels were replaced by electro-mechanical where a
microprocessor would use an RNG to get a random number and from that
number send the reel to that position.  So three random numbers would
yield the same random patterns of the mechanical reels.  BTW true
mechanical reels are now illegal for casinos in Nevada.

With the limited number of patterns on these reels you couldn't afford
to design a top prize all that high because the number of stops
determined how many possibilities there were.  Say you had 22 stops per
reel there are only 10,648 combinations so top prize couldn't be higher
than 10,648 or you lose money as the casino.  And with wanting lower
prizes as well and them more common you end up with top prizes no higher
than say 2,500 or 5,000 of your coin.  So adding reels was done.  But
also you could use the processor to with an virtual reel having far more
stops than physical stops.  You'd map more possibilities into spaces or
less valuable stops and fewer into more valuable stops (this is an IGT
patent btw)

So Class III games are defined as these games where an internal RNG
determines where the reels go.  The player is competing only against
math.

Another form of Class III is skill based games.  Video poker for
example.  Rather than a result purely based on random numbers you get a
preliminary result but based on your 'brains' you can choose something
to modify the results.  You can choose which cards to keep and which to
throw away in video poker and can thus affect your final results though
random numbers are still a big part of it.  Video version of blackjack
are usually in this category too.

Class II gaming is one where a player is competing with other players.  

Like lottery tickets where you are trying to buy the best ticket before
someone else does.  A pull tab machine is just like that.  When you buy
a pull tab you get a number that is worth some prize.  A pull tab type
slot machine lets you buy a number but rather than just give you a slip
of paper it takes that number and maps it into a pattern on the reels.
Once someone gets the best prize no one else can until all pull tabs are
gone and the pool is replaced.

The other style of class II is bingo style.  I work on bingo machines
here.  You are literally playing bingo with the machine doing most of
the work on buying the card, checking the called balls and daubing your
card for you.  The results of your bingo game are then translated into a
pattern displayed on the reels.

But about what I said on skill based video blackjack.  We have a bingo
based blackjack.  It looks like blackjack and you can hit or stay and
feel like you are doing something but well not really.  The result was
determined by bingo so if you stay with a deuce and trey but bingo said
you win the dealer will end up going bust.  If you keep hitting trying
to go bust but bingo says you win you will hit 21 instead.

So that make sense?  Prolly more than you really wanted to know.

Bill


-------------------------------------  Notice of Confidentiality ----------------------------------------------------------
This email and any files transmitted with it are confidential and intended solely for the use of the
individual or entity to whom they are addressed. If you have received this email in error please notify
postmasterSTOPspamspamspam_OUTvgt.net. This message contains confidential information and is intended only for the
individual named. If you are not the named addressee you should not disseminate, distribute or
copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by
mistake and delete this e-mail from your system. If you are not the intended recipient you are notified
that disclosing, copying, distributing or taking any action in reliance on the contents of this information
is strictly prohibited.

2006\02\09@160525 by David VanHorn

picon face
>
>
> It might come to that but we are apparently running out of code space
> according the contractor.


:)  I took a Z8 design that was supposedly maxed out, and ended up with
about half the rom space free, and running so much faster I was able to take
it down from 12.288 MHz (overclocked!) to 3.575 MHz.   Didn't bother pushing
any further, as cheaper chips didn't exist.

Still, I know the feeling, sometimes I've been a few words away from full as
well.



I would like to see more of the system.. The fact that it's pulling up three
zeroes is very interesting.
I'd need to know more about what's going on in there to go much further
though.

2006\02\09@161024 by David VanHorn

picon face
>
> But about what I said on skill based video blackjack.  We have a bingo
> based blackjack.  It looks like blackjack and you can hit or stay and
> feel like you are doing something but well not really.  The result was
> determined by bingo so if you stay with a deuce and trey but bingo said
> you win the dealer will end up going bust.  If you keep hitting trying
> to go bust but bingo says you win you will hit 21 instead.


So in that case, the future really is pre-determined! :)

But if you play really badly at that point, can you still loose?

2006\02\09@163226 by William Killian

flavicon
face


> -----Original Message-----
> From: spamBeGonepiclist-bouncesSTOPspamspamEraseMEmit.edu [KILLspampiclist-bouncesspamBeGonespammit.edu] On
Behalf
> Of David VanHorn
> Sent: Thursday, February 09, 2006 4:10 PM
> To: Microcontroller discussion list - Public.
> Subject: Re: [PIC] question from someone new to the list
>
> >
> > But about what I said on skill based video blackjack.  We have a
bingo
> > based blackjack.  It looks like blackjack and you can hit or stay
and
> > feel like you are doing something but well not really.  The result
was
> > determined by bingo so if you stay with a deuce and trey but bingo
said
> > you win the dealer will end up going bust.  If you keep hitting
trying
> > to go bust but bingo says you win you will hit 21 instead.
>
>
> So in that case, the future really is pre-determined! :)
>
> But if you play really badly at that point, can you still loose?


If Bingo says you win you win.  If bingo says you lose you lose.
Nothing you do can affect it other than leading to very weird scenarios.

No skilled involved in bingo blackjack.




-------------------------------------  Notice of Confidentiality ----------------------------------------------------------
This email and any files transmitted with it are confidential and intended solely for the use of the
individual or entity to whom they are addressed. If you have received this email in error please notify
EraseMEpostmasterspamEraseMEvgt.net. This message contains confidential information and is intended only for the
individual named. If you are not the named addressee you should not disseminate, distribute or
copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by
mistake and delete this e-mail from your system. If you are not the intended recipient you are notified
that disclosing, copying, distributing or taking any action in reliance on the contents of this information
is strictly prohibited.

2006\02\09@170341 by David VanHorn

picon face
>
>
> > But if you play really badly at that point, can you still loose?
>
>
> If Bingo says you win you win.  If bingo says you lose you lose.
> Nothing you do can affect it other than leading to very weird scenarios.


I could see it going either way.. After all, if you hose up the hand and
loose anyway, then the house wins again.. :)   Kind of like the old
jukeboxes. If two people request the same song, then it plays once, but the
machine keeps the money.

2006\02\09@171950 by William Killian

flavicon
face
The same reel controller card is used in all reel games.  But not all
reel games have the same fault/home positions.

The PC tells the reel controller (PIC) what the safe positions are when
the game starts.  

So it isn't hard coded cause the reel strips are not the same in all
games.

> {Original Message removed}

2006\02\09@172357 by William Killian

flavicon
face


> -----Original Message-----
> From: @spam@piclist-bounces@spam@spamspam_OUTmit.edu [spamBeGonepiclist-bouncesspamKILLspammit.edu] On
Behalf
{Quote hidden}

scenarios.
>
>
> I could see it going either way.. After all, if you hose up the hand
and
> loose anyway, then the house wins again.. :)   Kind of like the old
> jukeboxes. If two people request the same song, then it plays once,
but
> the
> machine keeps the money.

Law/regulation says you win by bingo not by the 'alternative
presentation'.

So if the alternative is a Blackjack video table you will win or lose
based on Bingo no matter what the player does.

So if the alternative is the reels we theoretically wouldn't have to pay
out on the cases where the problem is BUT the casinos pay anyway and
bill us.

Casino gaming is one of the most heavily regulated industries out there.
And despite reputation one of the most honest.  Well they imply you
might win.  You might.  But in the long run eventually you lose if you
keep playing.  On average the Casinos win.  Slots in Vegas are by law
required to pay out at least 75% but in general if you stay away from
the gas stations the pay out is always some 94-99%.




-------------------------------------  Notice of Confidentiality ----------------------------------------------------------
This email and any files transmitted with it are confidential and intended solely for the use of the
individual or entity to whom they are addressed. If you have received this email in error please notify
.....postmasterspam_OUTspamvgt.net. This message contains confidential information and is intended only for the
individual named. If you are not the named addressee you should not disseminate, distribute or
copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by
mistake and delete this e-mail from your system. If you are not the intended recipient you are notified
that disclosing, copying, distributing or taking any action in reliance on the contents of this information
is strictly prohibited.

2006\02\09@173341 by David VanHorn

picon face
>
>
> The PC tells the reel controller (PIC) what the safe positions are when
> the game starts.
>
> So it isn't hard coded cause the reel strips are not the same in all
> games.



I see.  And you were able to pull up that data from the PICs you got, and
it's correct, which tells us that the PC-Pic communication is working, at
least on these samples.

So, we need something that will hose up an EE read (xtal problem could do
that, or code timing problem)  or something later in that will hose the data
after it was succesfully read, which looks like a more generic code problem,
though an xtal problem could do that too..

2006\02\09@175622 by Mike Singer

picon face
William Killian  wrote:

> Casino gaming is one of the most heavily regulated industries
> out there. And despite reputation one of the most honest.

I'm not an admin, but please this is EE list

> Slots in Vegas are by law required to pay out at least
> 75% but in general if you stay away from
> the gas stations the pay out is always some 94-99%.

http://en.wikipedia.org/wiki/Casino_(movie)

2006\02\09@203519 by Rolf
face picon face
Hmmm... This strikes me as maybe the weak point.....

The PC tells the PIC on every restart? Perhaps there was a brown-out
that reset the PIC, but not the PC? Would the PIC get "Zeroed"?

Rolf


William Killian wrote:
> The same reel controller card is used in all reel games.  But not all
> reel games have the same fault/home positions.
>
> The PC tells the reel controller (PIC) what the safe positions are when
> the game starts.  
>
> So it isn't hard coded cause the reel strips are not the same in all
> games.
>
>  
>> {Original Message removed}

2006\02\10@005357 by Bob Axtell

face picon face
William Killian wrote:

>I've inherited a board developed by an outside contractor that uses a
>PIC16F874.  I've lots of time on other processors but this is the first
>I've really dealt with a PIC up close and personally.
>
>  
>
Its a good part, but the F876A is better, 'cause its easy to debug.

<respectful snip>

{Quote hidden}

My experience with PICs is that they are remarkably rugged, and getting
messed up
means something is externally causing it.

>Okay amusing story done, does anyone know under what conditions a PIC
>might have trouble reading the internal EEPROM?  Design decisions in
>making the board were some I would not have made and the programming
>style is not one I would have used but I see no failure mode in the code
>that would lead to this.
>  
>
My problems with the EEPROM section are just occasional dropped bits.  
Having a
whole byte or two be changed to 00 sounds like an unintended overwrite
of the EEPROM
itself.

My guess is that somehow the PIC is losing its way and overwriting its
own data,
probably through external stimulation, such as electrical noise from
reel motors, lighting
in the slot machine, etc.

What I suggest you do first is to extend the PCB so that PCB is far away
(6'+) from the
slot machine itself, wrapped in a grounded faraday shield. Perform some
trials and if
possible, record the results, and see if the problem clears up. My bet
is that it will clear
up.

The inverse part of that test is to extend the PCB like before... except
this time,
you will generate a source of electrical noise and impose it on the reel
controller PCB.
You can rent an RF noisemaker from  the rental companies, or you can
build your own
for about $25 that will last 30 years (mine has). I think every engineer
needs one of
these.

{{{

I made mine from a 24VAC bell transformer and a 24VAC SPST relay. Simply
make a "buzzer"
out of the relay by powering the relay through its NC and C contacts.
For convenience,
I extended the leads from the transformer about 15', and put the relay
in a plastic box.
Do not twist the wires to the box with relay inside, simply tape them
together.

}}}

Simply lay the plastic box and about 2' of its wiring on top of the PCB.
As soon as you start
"buzzing" you will probably get scrambled operation.

To fix the problem, you will need to repetitively apply tiny caps (100pF
or less) to each PIC pin
on a trial basis until you locate the pin that is suseptible to external
noise.  Note that you MIGHT
discover another chip on the same PCB is sensitive to the external
noise.  Another way is to tack
22pF caps to all free input pins, notice that it is fixed, then remove
the caps until it becomes bad
again. The problem may simply be that more bypassing is needed.


{Quote hidden}

I wasn't aware of that.EEPROM complaint.

--Bob

--
Note: To protect our network,
attachments must be sent to
TakeThisOuTattach.....spamTakeThisOuTengineer.cotse.net .
1-520-850-1673 USA/Canada
http://beam.to/azengineer

2006\02\10@010620 by Bill & Pookie

picon face
If someone comes in with a fuffly kitty, watch them close.  Also had better
watch my Aunt Polly if she shows up.

Pookie

{Original Message removed}

2006\02\10@054813 by Alan B. Pearce

face picon face
>Well and it is H/W designed by programmers instead of
>real EE types.  Everything is running off the PC power
>supply instead of solid power supplies.

This sounds awful like mains borne spikes are coming through the power
supply into the 5V line.

I would be tempted to run a 7805 off the 12V line to power the micro, with
some extra filtering on the input side.

My suspicion is that the power spikes are upsetting the RAM locations that
the home position data is loaded into while actually using them. It may not
be hosing the actual home positions, but hosing a pointer to their location
at a critical time.

2006\02\10@090121 by Bob Axtell

face picon face
William Killian wrote:

<another respectful snip>

>
>It might come to that but we are apparently running out of code space
>according the contractor.
>
>But can you change three bytes in Flash while the chip is running?  I
>gotta learn more about these processors.
>
>  
>
Sure you can. The processor "suspends" operation for a short period,
about 3mS
while it writes a word. Works good. One of my clients uses this feature
to install
14-bit calibration tables for a load cell (measures force applied to a
crane). Switch
to the 877 instead of 874 for more space.

--Bob

--
Note: To protect our network,
attachments must be sent to
TakeThisOuTattachKILLspamspamspamengineer.cotse.net .
1-520-850-1673 USA/Canada
http://beam.to/azengineer

2006\02\10@090444 by olin piclist

face picon face
William Killian wrote:
> BUT some times the game is happily chugging along and the reel
> controller apparently loses its mind.

So the "reel controller" is the thing controlled by the PIC, not the PC,
right?

{Quote hidden}

There are various reasons the PIC might send the wheels to zero with EEPROM
failure being only one unlikely one.

I think the two most likely problems are noise spikes at the PIC or
communication errors.  Try an experiment.  Let a machine run normally, then
glitch the MCLR line low while the PIC is doing something without letting
the PC know anything happened.  All you need is a wire that you hold one end
to ground and the other end momentarily touch to the MCLR pin on the PIC.
You probably want to try this while the system is in various states.  What
happens?

Does the PIC have proper bypassing, and was proper attention paid to the PIC
ground and ground loop currents and inductive pickup paths?  You said the
circuit was designed by a software guy that knew a little digital hardware,
so chances are the answer is "no".  This is the most likely single cause of
the problems.

The next likely cause, which may well be related to the previous, is noise
on the communication channel.  After reasonable electrical steps have been
taken, this should still be dealt with by a proper protocol that wraps
everything in packets with checksums and performs ACK/NACK to eventually
guarantee reliable delivery of the data.

However to do anything more than speculate as above, I'd need to see the
schematic and board layout.  We specialize in PICs and their surrounding
circuitry and are all electrical engineers that understand analog.  We've
done somewhere between 50 and 100 PIC designs, and have been gold level
Microchip PIC consultants for something like 6 years now.  Contact me off
list if you'd like professional help to look into this further.


******************************************************************
Embed Inc, Littleton Massachusetts, (978) 742-9014.  #1 PIC
consultant in 2004 program year.  http://www.embedinc.com/products

2006\02\10@110033 by William Killian

flavicon
face
If the pic restarted but not the game - which very well could be
happening for the homing to occur - the game would not send new values,
and being eeprom would not change.  The PIC did not zero that between
restarts.

> {Original Message removed}

2006\02\10@111457 by alan smith

picon face
I wonder....if you could write some sort of log, to the EEPROM (have to be carefull how much you store of course) and when if fails, take a look at stored data.
 
 The frustrating thing is, they send you back the CHIP and say...whats wrong?  Honestly do they believe you can troubleshoot it without at least the board it plugs into, let alone the machine?  Have to have a method to try and duplicate the failures, and if its costing them, I'd think they would accomidate you.


               
---------------------------------
Brings words and photos together (easily) with
PhotoMail  - it's free and works with Yahoo! Mail.

2006\02\10@114536 by William Killian

flavicon
face
I have the equivalent "stuff" here.  We have never seen the failures
here that happen in the casinos.

I have a half dozen or more of the board that I can grab.  But they
aren't the one that failed....

Shipping the whole slot back here probably doesn't make much sense.
Failure do not seem to be specific to the same cabinet over and over but
instead across a bunch of cabinets.

In this case they are accommodating but so far I haven't proven anything
about what could cause the failures.  If I can't reproduce the problem
it's a lot harder to fix.

> {Original Message removed}

2006\02\10@121545 by Alan B. Pearce

face picon face
>Shipping the whole slot back here probably doesn't
>make much sense. Failure do not seem to be specific
>to the same cabinet over and over but instead
>across a bunch of cabinets.
>
>In this case they are accommodating but so far I
>haven't proven anything about what could cause the
>failures.  If I can't reproduce the problem
>it's a lot harder to fix.

Does seem to be the symptoms of mains interference. Doe sit happen when the
cleaning crew plug the vacuum in? Is there some other electrical appliance
nearby?

I suspect the only way to fix the problem is to go through all machines on a
rolling basis installing shielding and grounding within the machine. You
will probably need some suitable noise generators in the workshop to
ascertain the noise sensitive points.

A handful of vacuum cleaner units with universal motors and suitable arcing
brushes would probably do the trick.

You may need to go through a specimen cabinet and look at how the mains
filtering is done, how the various bits are linked together to an earth
bonding point - do the casinos even provide any sort of earthing for the
cabinet (I am thinking here that you are in 2 pin 110V territory, so maybe
unit not earthed)? If you can reproduce the apparent problem in the W/S then
you probably have a pretty good handle on sorting it out.

2006\02\10@130601 by David VanHorn

picon face
>
>
> Shipping the whole slot back here probably doesn't make much sense.
> Failure do not seem to be specific to the same cabinet over and over but
> instead across a bunch of cabinets.
>
> In this case they are accommodating but so far I haven't proven anything
> about what could cause the failures.  If I can't reproduce the problem
> it's a lot harder to fix.


I'd really want to look at all the technical info. Board, schematic, key
component data sheets.


The chip has proper home values in EE, indicating that it did get proper
comms with the PC, and should have homed to the programmed address.
Is it possible that the system was restarted AFTER the failure, which would
re-write the home values?  That would conceal a previous failure where they
were written to zero.

2006\02\10@131343 by Michael Dipperstein

face
flavicon
face
> From: .....piclist-bouncesspamRemoveMEmit.edu [RemoveMEpiclist-bouncesspamspamBeGonemit.edu] On
Behalf
> Of William Killian
> Sent: Friday, February 10, 2006 8:44 AM
>
> I have the equivalent "stuff" here.  We have never seen the failures
> here that happen in the casinos.
>
> I have a half dozen or more of the board that I can grab.  But they
> aren't the one that failed....
>
> Shipping the whole slot back here probably doesn't make much sense.
> Failure do not seem to be specific to the same cabinet over and over
but
> instead across a bunch of cabinets.
>
> In this case they are accommodating but so far I haven't proven
anything
> about what could cause the failures.  If I can't reproduce the problem
> it's a lot harder to fix.

I was just reminded of some brownout related problems that I had seen a
few years back.  Is it possible that the chip is experiencing a
brownout?

They'll do all kinds of funny things under brownout conditions.

-Mike

2006\02\10@133145 by William Killian

flavicon
face


> -----Original Message-----
> From: spamBeGonepiclist-bounces@spam@spamspam_OUTmit.edu [TakeThisOuTpiclist-bouncesspamspammit.edu] On
Behalf
{Quote hidden}

problem
{Quote hidden}

My best guess is power issues.  BOR is set in the fuse word but if there
is a point where funny things can start happening before reset -
particularly if too much power is being sucked out the DIO ports drawing
down the voltage it could explain things.

I am learning more as I read the source.  Looks like it isn't EEPROM
after all.  The program reads the EEPROM values only at boot and writes
it only when commanded.  Otherwise it uses a RAM copy of the home
positions.




-------------------------------------  Notice of Confidentiality ----------------------------------------------------------
This email and any files transmitted with it are confidential and intended solely for the use of the
individual or entity to whom they are addressed. If you have received this email in error please notify
@spam@postmasterRemoveMEspamEraseMEvgt.net. This message contains confidential information and is intended only for the
individual named. If you are not the named addressee you should not disseminate, distribute or
copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by
mistake and delete this e-mail from your system. If you are not the intended recipient you are notified
that disclosing, copying, distributing or taking any action in reliance on the contents of this information
is strictly prohibited.

2006\02\10@133151 by William Killian

flavicon
face


> -----Original Message-----
> From: EraseMEpiclist-bouncesspam@spam@mit.edu [@spam@piclist-bouncesspam_OUTspam.....mit.edu] On
Behalf
> Of Olin Lathrop
> Sent: Friday, February 10, 2006 9:07 AM
> To: Microcontroller discussion list - Public.
> Subject: Re: [PIC] question from someone new to the list
>
> William Killian wrote:
> > BUT some times the game is happily chugging along and the reel
> > controller apparently loses its mind.
>
> So the "reel controller" is the thing controlled by the PIC, not the
PC,
> right?

The little board with the PIC on it is the reel controller - sorry about
the confusion.

>
> > It decides there was a failure
> > and the reels get sent to home positions (the going home action is a
> > slower spin so we know it is a sent home problem not a bad decision
> > about where to send them) but for some reason the reels all go to
step 0
> > with is 4 steps off of the stop for top prize.
>
> > Okay amusing story done, does anyone know under what conditions a
PIC
> > might have trouble reading the internal EEPROM?  Design decisions in
> > making the board were some I would not have made and the programming
> > style is not one I would have used but I see no failure mode in the
code
> > that would lead to this.
>
> There are various reasons the PIC might send the wheels to zero with
> EEPROM
> failure being only one unlikely one.

Looking more at the code it looks like it isn't EEPROM as the PIC copies
the values into RAM.  RAM seems to be always addressed by name but I am
looking for potential overwrites.

> I think the two most likely problems are noise spikes at the PIC or
> communication errors.  Try an experiment.  Let a machine run normally,
> then
> glitch the MCLR line low while the PIC is doing something without
letting
> the PC know anything happened.  All you need is a wire that you hold
one
> end
> to ground and the other end momentarily touch to the MCLR pin on the
PIC.
> You probably want to try this while the system is in various states.
What
> happens?

Gonna have to rig the board as MCLR is tied directly to 5vdc but sounds
like something to try.

>
> Does the PIC have proper bypassing, and was proper attention paid to
the
> PIC
> ground and ground loop currents and inductive pickup paths?  You said
the
> circuit was designed by a software guy that knew a little digital
> hardware,
> so chances are the answer is "no".  This is the most likely single
cause
> of
> the problems.

I suspect that the answer is no...

>
> The next likely cause, which may well be related to the previous, is
noise
> on the communication channel.  After reasonable electrical steps have
been
> taken, this should still be dealt with by a proper protocol that wraps
> everything in packets with checksums and performs ACK/NACK to
eventually
> guarantee reliable delivery of the data.

The protocol is bad.  Very bad.  But it does have "checksums".  Well
okay an XOR of the 3 or 5 bytes in the packets.  

> However to do anything more than speculate as above, I'd need to see
the
> schematic and board layout.  We specialize in PICs and their
surrounding
> circuitry and are all electrical engineers that understand analog.
We've
> done somewhere between 50 and 100 PIC designs, and have been gold
level
> Microchip PIC consultants for something like 6 years now.  Contact me
off
> list if you'd like professional help to look into this further.

Had a similar offer already.

Let me talk to the powers that be about getting one or both of you guys
a contract to look at this board.  Well board set since the driver chips
are on another board.  The interesting part is that they are connected
using a 50 lead ribbon with ground, 5v and 12 power supplied along that
ribbon.



-------------------------------------  Notice of Confidentiality ----------------------------------------------------------
This email and any files transmitted with it are confidential and intended solely for the use of the
individual or entity to whom they are addressed. If you have received this email in error please notify
spamBeGonepostmasterEraseMEspamvgt.net. This message contains confidential information and is intended only for the
individual named. If you are not the named addressee you should not disseminate, distribute or
copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by
mistake and delete this e-mail from your system. If you are not the intended recipient you are notified
that disclosing, copying, distributing or taking any action in reliance on the contents of this information
is strictly prohibited.

2006\02\10@135627 by Spehro Pefhany

picon face
At 01:29 PM 2/10/2006 -0500, you wrote:

>My best guess is power issues.  BOR is set in the fuse word but if there
>is a point where funny things can start happening before reset -
>particularly if too much power is being sucked out the DIO ports drawing
>down the voltage it could explain things.
>
>I am learning more as I read the source.  Looks like it isn't EEPROM
>after all.  The program reads the EEPROM values only at boot and writes
>it only when commanded.  Otherwise it uses a RAM copy of the home
>positions.

Gack! Inexperienced programmer-- no defensive programming used. So the RAM
is probably getting corrupted by electrical noise or something of that ilk.

It's best to fix the noise and then use the defensive programming as
security, but that will mean hardware design changes as well as tweaking
the firmware. But I'd recommend it.

>Best regards,

Spehro Pefhany --"it's the network..."            "The Journey is the reward"
speffspamBeGonespaminterlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com
->> Inexpensive test equipment & parts http://search.ebay.com/_W0QQsassZspeff


2006\02\10@140803 by David VanHorn

picon face
>
>
> I am learning more as I read the source.  Looks like it isn't EEPROM
> after all.  The program reads the EEPROM values only at boot and writes
> it only when commanded.  Otherwise it uses a RAM copy of the home
> positions.


Hmm.. I'd wonder if there was a reason to do it that way. If not, pulling
them from EE would be more reliable.

2006\02\10@141059 by David VanHorn

picon face
>
>
> Gack! Inexperienced programmer-- no defensive programming used. So the RAM
> is probably getting corrupted by electrical noise or something of that ilk.


I tend to agree, but maybe there was some reason to have them in RAM.

It's best to fix the noise and then use the defensive programming as
> security, but that will mean hardware design changes as well as tweaking
> the firmware. But I'd recommend it.


Agreed. Patching over a problem is a great way to make sure you have to
solve it again later.

2006\02\10@144313 by Bob Axtell

face picon face
David VanHorn wrote:

>>I am learning more as I read the source.  Looks like it isn't EEPROM
>>after all.  The program reads the EEPROM values only at boot and writes
>>it only when commanded.  Otherwise it uses a RAM copy of the home
>>positions.
>>    
>>
>
>  
>
That's a surprise.

>Hmm.. I'd wonder if there was a reason to do it that way. If not, pulling
>them from EE would be more reliable.
>  
>
I agree totally. Direct from the EEPROM would be MUCH more reliable.

--Bob

--
Note: To protect our network,
attachments must be sent to
RemoveMEattach@spam@spamspamBeGoneengineer.cotse.net .
1-520-850-1673 USA/Canada
http://beam.to/azengineer

2006\02\10@150241 by William Killian

flavicon
face
I never expected him to use RAM copies.  There is some odd checksumming
thing but when that is merely XOR all bytes together.  Getting all
zeroed be a real or from chip failures would pass despite the misread.

> {Original Message removed}

2006\02\10@182409 by Peter Todd

picon face
On Thu, Feb 09, 2006 at 03:56:39PM -0500, William Killian wrote:
<snip>
> So that make sense?  Prolly more than you really wanted to know.

Wow, what can I say, makes sense all right, weird way of doing it but I
can see how it has it's advantages.

Don't worry though, that's exactly how much I wanted to know. It's so
much fun to be able to say "Well I know everything." when asked "Why the
hell do you know that?" :)

--
.....pete@spam@spamEraseMEpetertodd.ca http://www.petertodd.ca

2006\02\10@213250 by William Chops Westfield

face picon face

On Feb 10, 2006, at 10:06 AM, David VanHorn wrote:

> The chip has proper home values in EE, indicating that it did
> get proper comms with the PC, and should have homed to the
> programmed address.
>
Are there any known circumstances where a PIC CPU will run
but fail to accurately read the EEPROM?  Undervoltage or slightly
overvoltage, for example?  (one would hope BOD would prevent UV
problems, but...)

BillW

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