About a month or so ago you tried to help me with event
programming. I eventually gave up and used To Do Loops figuring I was
just too dumb to figure it out.
I have another situation that requires Event programming. I took
the code below from the manual. I changed it so I could see leds in
different parts of the program but I did not change the event part.
I would expect the code below to delay 5 seconds turn on the
green led, go to the event subroutine, turn on the red led wait 1
second and turn it off. From there blink the red led every 1 second.
What happens is there is a delay of 5 seconds the green led comes
on and goes out after a second or so then delays 5 seconds and comes
back on. Like it is rebooting. This time I have nothing connected to
the board.
I tried the virtual circuit in chapter 7. That works as expected.
Could I get you to run this code and see if it works correctly
please? another question that might be related. Pin 21 is supposed to
be 5 volt pwr I get 6.49 volts. Is that correct?

c 1.1 + board v 6.1.1 compiler

Dim BLINK As New oEvent
Dim WIRE As New oWire
Dim led7 As New oLED
Dim led5 As New oLED

Sub Main()
ooPIC.Delay = 5000
led5.IOLine = 5
led5.TurnOn
led7.IOLine = 7
WIRE.Input.Link(ooPIC.Hz1)
WIRE.Output.Link(BLINK.Operate)
WIRE.Operate = cvTrue
End Sub

Sub BLINK_Code()
led7.TurnOn
ooPIC.Delay =1000
led7.TurnOff
End Sub



(You need to be a member of oopic -- send a blank email to oopic-subscribe@yahoogroups.com )

--- In o...@yahoogroups.com, "dldlhfd" wrote:
>
> About a month or so ago you tried to help me with event
> programming. I eventually gave up and used To Do Loops figuring I
was
> just too dumb to figure it out.
> I have another situation that requires Event programming. I
took
> the code below from the manual. I changed it so I could see leds in
> different parts of the program but I did not change the event part.
> I would expect the code below to delay 5 seconds turn on the
> green led, go to the event subroutine, turn on the red led wait 1
> second and turn it off. From there blink the red led every 1 second.
> What happens is there is a delay of 5 seconds the green led
comes
> on and goes out after a second or so then delays 5 seconds and
comes
> back on. Like it is rebooting. This time I have nothing connected
to
> the board.
> I tried the virtual circuit in chapter 7. That works as
expected.
> Could I get you to run this code and see if it works correctly
> please? another question that might be related. Pin 21 is supposed
to
> be 5 volt pwr I get 6.49 volts. Is that correct?
>
> c 1.1 + board v 6.1.1 compiler
>
> Dim BLINK As New oEvent
> Dim WIRE As New oWire
> Dim led7 As New oLED
> Dim led5 As New oLED
>
> Sub Main()
> ooPIC.Delay = 5000
> led5.IOLine = 5
> led5.TurnOn
> led7.IOLine = 7
> WIRE.Input.Link(ooPIC.Hz1)
> WIRE.Output.Link(BLINK.Operate)
> WIRE.Operate = cvTrue
> End Sub
>
> Sub BLINK_Code()
> led7.TurnOn
> ooPIC.Delay =1000
> led7.TurnOff
> End Sub
>

You need to STOP and find out what is causing the above normal
voltages. Are you talking about some PIN 21 or IOLine 21? What
board do you have? Always put that info in your postings. Just the
chip version and compiler version is not sufficient.

You should never see a voltage above 5V on any IOLine.
Change the ooPIC.Delay = 1000 in Sub BLINK_Code() to ooPIC.Delay =
500 and the code will work.

You are calling the event every second and delaying one second in the
event code. Something is likely to get jammed up.

I see that not only doesn't V6 bother to document ooPIC.Delay but
that the units have been changed from 1/100 second to 1/1000 second.
At first I thought you were delaying 50 seconds at startup!

As a practical matter, your code has an issue You are spending more
than 50% of the processor time waiting on a delay. Maybe some
virtual circuits will still be running but mainline code will not.

You can use Hz60 and a counter to get a similar effect:

Dim BLINK As New oEvent
Dim WIRE As New oWire
Dim led7 As New oLED
Dim led5 As New oLED
Dim counter As New oByte

Sub Main()
counter = 0
ooPIC.Delay = 5000
led5.IOLine = 5
led5.TurnOn
led7.IOLine = 7
WIRE.Input.Link(ooPIC.Hz60)
WIRE.Output.Link(BLINK.Operate)
WIRE.Operate = cvTrue
End Sub

Sub BLINK_Code()
counter = counter + 1
If counter = 30 Then
led7.TurnOn
ElseIf counter = 59
counter = 0
led7.TurnOff
End If

End Sub

This has the advantage of no delays but the disadvantage of executing
the event code 60 times per second. I don't seem to get 1 flash per
second, I'll look in to that some day. It's as though Hz60 is really
Hz30!

Richard



(You need to be a member of oopic -- send a blank email to oopic-subscribe@yahoogroups.com )

I am sorry you must have missed my explanation on the voltage. In my last
response, just below your snip that you cut from my response, I put in that the
voltage reading was from a bad meter. I have tested it with another meter
and it does read 5 volts at pin 21. I put it in bold type so you could see it.
Sorry to get you side tracked and waste your time on that track.
I tried your code and again it does not go to the sub routine. The
green led blinks and changes from high to low intensity (I know it is not it the
code to do that) it goes through that pattern 3 or four times then the green
led comes on and stays on. but it never lights the red led as you have
specified in your subroutine code.
If I make the assumption that something is broken where do I go from
here? As I said before it controls the H bridge that runs the motors on my
robot. It runs the sound card. Using todo loops it responds to bumper switches. It
is so darn frustrating that everything that I have tried works except the
events.
How do I determine if it is the processor or the carrier board? What
could be broken that would allow the other program parts to work and not let
events work?
I know it is grasping at straws but is there any chance someone has a
C.1.1+ chip and a C carrier board that they could run this program on and see
if it is just the combination of board and chip that doesn't like events.

**************Biggest Grammy Award surprises of all time on AOL Music.
(http://music.aol.com/grammys/pictures/never-won-a-grammy?NCID=aolcmp003000000025
48)
[Non-text portions of this message have been removed]



(You need to be a member of oopic -- send a blank email to oopic-subscribe@yahoogroups.com )

OK, I missed that (I read in regular text, not HTML so bold won't show
up.) One more test, use IOline 6 instead of 7 and see what happens.
I'm suspecting that oEvent is working, but that there may be a short
between IOLine 5 and 7 or something similar. It sounds like your ooPIC
C is bad. To replace it contact the retailer that you got it from and
explain to them that it doesn't work properly, they should replace it.

DLC

d...@aol.com wrote:
> I am sorry you must have missed my explanation on the voltage. In my last
> response, just below your snip that you cut from my response, I put in that the
> voltage reading was from a bad meter. I have tested it with another meter
> and it does read 5 volts at pin 21. I put it in bold type so you could see it.
> Sorry to get you side tracked and waste your time on that track.
> I tried your code and again it does not go to the sub routine. The
> green led blinks and changes from high to low intensity (I know it is not it the
> code to do that) it goes through that pattern 3 or four times then the green
> led comes on and stays on. but it never lights the red led as you have
> specified in your subroutine code.
> If I make the assumption that something is broken where do I go from
> here? As I said before it controls the H bridge that runs the motors on my
> robot. It runs the sound card. Using todo loops it responds to bumper switches. It
> is so darn frustrating that everything that I have tried works except the
> events.
> How do I determine if it is the processor or the carrier board? What
> could be broken that would allow the other program parts to work and not let
> events work?
> I know it is grasping at straws but is there any chance someone has a
> C.1.1+ chip and a C carrier board that they could run this program on and see
> if it is just the combination of board and chip that doesn't like events.
>
>
>
> **************Biggest Grammy Award surprises of all time on AOL Music.
> (http://music.aol.com/grammys/pictures/never-won-a-grammy?NCID=aolcmp003000000025
> 48)
> [Non-text portions of this message have been removed]
>
>
>



(You need to be a member of oopic -- send a blank email to oopic-subscribe@yahoogroups.com )

Oopic C.1.1+ Oopic C Carrier board 6.1.1 compiler
To refresh your memory, I have been having trouble getting the events to
work. We have sent email back and forth You sent this program saying that if
it did not work then you thought my chip was broken.
I tried the program and the results were:
The green led comes on flashes and changes intensity and then stays on.
It never goes to the subroutine to turn on the red led as it should.
So I talked to the people at the Bot Shop and they arranged with Savage
and sent me a new chip. The very first thing I did was put the chip on my
board and try the program. It did exactly the same thing with the new chip as it
did with the old. Just to make sure it was not the carrier board I took the
chip off the board, put the chip on my proto board and put the 9 volt
battery to pins 24 and 23. I got he exact same reaction. The red led in the sub
routine never comes on.
This is very frustrating. Every thing else that I have tried works. Do
you have any suggestions for me?

In a message dated 2/4/2008 12:09:35 A.M. Eastern Standard Time,
d...@oopic.com writes:

This code works, but it flashes at a .5Hz rate, I wasn't interested in a
1Hz flash so much as working event code.

---------------------------------------------------
Dim BLINK As New oEvent
Dim WIRE As New oWire
Dim led7 As New oLED
Dim led5 As New oLED
Dim flag As New oByte

Sub Main()
flag = 0
ooPIC.Delay = 500
led5.IOLine = 5
led5.TurnOn
led7.IOLine = 7
WIRE.Input.Link(WIRE.Input
WIRE.Output.WIRE.Output
WIRE.Operate = cvTrue
End Sub

Sub BLINK_Code()
If flag = 1 Then
led7.TurnOn
flag = 0
Else
led7.TurnOff
flag = 1
End If

End Sub
----------------------------------------------

If this code doesn't work for you then your ooPIC is broken.

**************The year's hottest artists on the red carpet at the Grammy
Awards. Go to AOL Music.
(http://music.aol.com/grammys?NCID=aolcmp00300000002565)
[Non-text portions of this message have been removed]



(You need to be a member of oopic -- send a blank email to oopic-subscribe@yahoogroups.com )

Yes,

Replace the ooPIC C, it must have a bad version of the code in it.
The code that I sent you works perfectly here.

DLC

d...@aol.com wrote:
>
> Oopic C.1.1+ Oopic C Carrier board 6.1.1 compiler
> To refresh your memory, I have been having trouble getting the events to
> work. We have sent email back and forth You sent this program saying that if
> it did not work then you thought my chip was broken.
> I tried the program and the results were:
> The green led comes on flashes and changes intensity and then stays on.
> It never goes to the subroutine to turn on the red led as it should.
> So I talked to the people at the Bot Shop and they arranged with Savage
> and sent me a new chip. The very first thing I did was put the chip on my
> board and try the program. It did exactly the same thing with the new chip as it
> did with the old. Just to make sure it was not the carrier board I took the
> chip off the board, put the chip on my proto board and put the 9 volt
> battery to pins 24 and 23. I got he exact same reaction. The red led in the sub
> routine never comes on.
> This is very frustrating. Every thing else that I have tried works. Do
> you have any suggestions for me?
>
> In a message dated 2/4/2008 12:09:35 A.M. Eastern Standard Time,
> d...@oopic.com writes:
>
> This code works, but it flashes at a .5Hz rate, I wasn't interested in a
> 1Hz flash so much as working event code.
>
> ---------------------------------------------------
> Dim BLINK As New oEvent
> Dim WIRE As New oWire
> Dim led7 As New oLED
> Dim led5 As New oLED
> Dim flag As New oByte
>
> Sub Main()
> flag = 0
> ooPIC.Delay = 500
> led5.IOLine = 5
> led5.TurnOn
> led7.IOLine = 7
> WIRE.Input.Link(WIRE.Input
> WIRE.Output.WIRE.Output
> WIRE.Operate = cvTrue
> End Sub
>
> Sub BLINK_Code()
> If flag = 1 Then
> led7.TurnOn
> flag = 0
> Else
> led7.TurnOff
> flag = 1
> End If
>
> End Sub
> ----------------------------------------------
>
> If this code doesn't work for you then your ooPIC is broken.
> **************The year's hottest artists on the red carpet at the Grammy
> Awards. Go to AOL Music.
> (http://music.aol.com/grammys?NCID=aolcmp00300000002565)
> [Non-text portions of this message have been removed]
>
>
>



(You need to be a member of oopic -- send a blank email to oopic-subscribe@yahoogroups.com )

Maybe I did not make myself clear. I got a new OOpic C from the Bot shop.
Are you saying that you think there is a whole batch of bad ones?

**************The year's hottest artists on the red carpet at the Grammy
Awards. Go to AOL Music.
(http://music.aol.com/grammys?NCID=aolcmp00300000002565)
[Non-text portions of this message have been removed]



(You need to be a member of oopic -- send a blank email to oopic-subscribe@yahoogroups.com )

I just got a bunch of these too and thought I would see what mine
would do with this code.

exactly as you stated. green blinks twice. then starts blinking med
to full intensity the comes on and stays on.

using the 6.1.1 compiler and the c1.1+ chip. I bought 10 of these
wonder if they all have the glitch

some other interesting test:

added line led7.TurnOn after the led7.ioline=7 and then the red one
comes on but not as it should green still turns off and on too. both
stop and stay on after about 6 seconds

moved the oopic.delay to before the sub main() and the leds continue
to blink, in sync then out. blinking doesn't stop however. this is
doing something to the rx line too as the led in the usb cable rxled
has a short flash now and then.

remove the oopic.delay all together and the leds blink fast then
stay on.
--- In o...@yahoogroups.com, ooPIC Tech Support
wrote:
>
> Yes,
>
> Replace the ooPIC C, it must have a bad version of the code in
it.
> The code that I sent you works perfectly here.
>
> DLC
>
> dldlhfd@... wrote:
> >
> > Oopic C.1.1+ Oopic C Carrier board 6.1.1 compiler
> > To refresh your memory, I have been having trouble getting
the events to
> > work. We have sent email back and forth You sent this program
saying that if
> > it did not work then you thought my chip was broken.
> > I tried the program and the results were:
> > The green led comes on flashes and changes intensity and
then stays on.
> > It never goes to the subroutine to turn on the red led as it
should.
> > So I talked to the people at the Bot Shop and they arranged
with Savage
> > and sent me a new chip. The very first thing I did was put the
chip on my
> > board and try the program. It did exactly the same thing with
the new chip as it
> > did with the old. Just to make sure it was not the carrier
board I took the
> > chip off the board, put the chip on my proto board and put the
9 volt
> > battery to pins 24 and 23. I got he exact same reaction. The
red led in the sub
> > routine never comes on.
> > This is very frustrating. Every thing else that I have
tried works. Do
> > you have any suggestions for me?
> >
> > In a message dated 2/4/2008 12:09:35 A.M. Eastern Standard
Time,
> > dennis.clark@... writes:
> >
> > This code works, but it flashes at a .5Hz rate, I wasn't
interested in a
> > 1Hz flash so much as working event code.
> >
> > ---------------------------------------------------
> > Dim BLINK As New oEvent
> > Dim WIRE As New oWire
> > Dim led7 As New oLED
> > Dim led5 As New oLED
> > Dim flag As New oByte
> >
> > Sub Main()
> > flag = 0
> > ooPIC.Delay = 500
> > led5.IOLine = 5
> > led5.TurnOn
> > led7.IOLine = 7
> > WIRE.Input.Link(WIRE.Input
> > WIRE.Output.WIRE.Output
> > WIRE.Operate = cvTrue
> > End Sub
> >
> > Sub BLINK_Code()
> > If flag = 1 Then
> > led7.TurnOn
> > flag = 0
> > Else
> > led7.TurnOff
> > flag = 1
> > End If
> >
> > End Sub
> > ----------------------------------------------
> >
> > If this code doesn't work for you then your ooPIC is broken.
> >
> >
> >
> >
> > **************The year's hottest artists on the red carpet at
the Grammy
> > Awards. Go to AOL Music.
> > (http://music.aol.com/grammys?NCID=aolcmp00300000002565)
> >
> >
> > [Non-text portions of this message have been removed]
> >
> >
> >
> >
> >



(You need to be a member of oopic -- send a blank email to oopic-subscribe@yahoogroups.com )

I will check out the rest of my units tomorrow. A couple are in use
but don't use the event object, so I should be able to check out the
rest of them at least

In the code below it will not compile

I have this in the wire vc instead

WIRE.Input.Link(ooPIC.Hz60)
WIRE.Output.Link(BLINK.Operate)

everything else is as below

--- In o...@yahoogroups.com, ooPIC Tech Support
wrote:
>
> Now we have the makings of a batch problem. It sure looks like
a
> batch issue since there are at least two of you that have the
problem on
> multiple parts. I've raised the flag at manufacturing and I'll
get back
> to you on how to get the units swapped for working ones as soon as
the
> information gets to me.
>
> ***
> If anyone else has C1.1+ ooPIC parts please use this program
below to
> check to see if it works properly. If you get the symptoms that
have
> been stated here then contact the list and I'll get you in touch
with
> replacements too.
> ***
> DLC
>
> ************** Program to check ooPIC C1.1+ devices
> This code flashes LED 7 at a .5Hz rate if all is right..
>
> Dim BLINK As New oEvent
> Dim WIRE As New oWire
> Dim led7 As New oLED
> Dim led5 As New oLED
> Dim flag As New oByte
>
> Sub Main()
> flag = 0
> ooPIC.Delay = 500
> led5.IOLine = 5
> led5.TurnOn
> led7.IOLine = 7
> WIRE.Input.Link(WIRE.Input
> WIRE.Output.WIRE.Output
> WIRE.Operate = cvTrue
> End Sub
>
> Sub BLINK_Code()
> If flag = 1 Then
> led7.TurnOn
> flag = 0
> Else
> led7.TurnOff
> flag = 1
> End If
>
> End Sub
>
> s.k.f. wrote:
> > I just got a bunch of these too and thought I would see what
mine
> > would do with this code.
> >
> > exactly as you stated. green blinks twice. then starts blinking
med
> > to full intensity the comes on and stays on.
> >
> > using the 6.1.1 compiler and the c1.1+ chip. I bought 10 of
these
> > wonder if they all have the glitch
> >
> > some other interesting test:
> >
> > added line led7.TurnOn after the led7.ioline=7 and then the red
one
> > comes on but not as it should green still turns off and on too.
both
> > stop and stay on after about 6 seconds
> >
> > moved the oopic.delay to before the sub main() and the leds
continue
> > to blink, in sync then out. blinking doesn't stop however. this
is
> > doing something to the rx line too as the led in the usb cable
rxled
> > has a short flash now and then.
> >
> > remove the oopic.delay all together and the leds blink fast then
> > stay on.
> >
> >
> > --- In o...@yahoogroups.com, ooPIC Tech Support
> > wrote:
> >
> >> Yes,
> >>
> >> Replace the ooPIC C, it must have a bad version of the code
in
> >>
> > it.
> >
> >> The code that I sent you works perfectly here.
> >>
> >> DLC
> >>
> >> dldlhfd@ wrote:
> >>
> >>>
> >>> Oopic C.1.1+ Oopic C Carrier board 6.1.1 compiler
> >>> To refresh your memory, I have been having trouble
getting
> >>>
> > the events to
> >
> >>> work. We have sent email back and forth You sent this program
> >>>
> > saying that if
> >
> >>> it did not work then you thought my chip was broken.
> >>> I tried the program and the results were:
> >>> The green led comes on flashes and changes intensity and
> >>>
> > then stays on.
> >
> >>> It never goes to the subroutine to turn on the red led as it
> >>>
> > should.
> >
> >>> So I talked to the people at the Bot Shop and they
arranged
> >>>
> > with Savage
> >
> >>> and sent me a new chip. The very first thing I did was put
the
> >>>
> > chip on my
> >
> >>> board and try the program. It did exactly the same thing with
> >>>
> > the new chip as it
> >
> >>> did with the old. Just to make sure it was not the carrier
> >>>
> > board I took the
> >
> >>> chip off the board, put the chip on my proto board and put
the
> >>>
> > 9 volt
> >
> >>> battery to pins 24 and 23. I got he exact same reaction. The
> >>>
> > red led in the sub
> >
> >>> routine never comes on.
> >>> This is very frustrating. Every thing else that I have
> >>>
> > tried works. Do
> >
> >>> you have any suggestions for me?
> >>>
> >>> In a message dated 2/4/2008 12:09:35 A.M. Eastern Standard
> >>>
> > Time,
> >
> >>> dennis.clark@ writes:
> >>>
> >>> This code works, but it flashes at a .5Hz rate, I wasn't
> >>>
> > interested in a
> >
> >>> 1Hz flash so much as working event code.
> >>>
> >>> ---------------------------------------------------
> >>> Dim BLINK As New oEvent
> >>> Dim WIRE As New oWire
> >>> Dim led7 As New oLED
> >>> Dim led5 As New oLED
> >>> Dim flag As New oByte
> >>>
> >>> Sub Main()
> >>> flag = 0
> >>> ooPIC.Delay = 500
> >>> led5.IOLine = 5
> >>> led5.TurnOn
> >>> led7.IOLine = 7
> >>> WIRE.Input.Link(WIRE.Input
> >>> WIRE.Output.WIRE.Output
> >>> WIRE.Operate = cvTrue
> >>> End Sub
> >>>
> >>> Sub BLINK_Code()
> >>> If flag = 1 Then
> >>> led7.TurnOn
> >>> flag = 0
> >>> Else
> >>> led7.TurnOff
> >>> flag = 1
> >>> End If
> >>>
> >>> End Sub
> >>> ----------------------------------------------
> >>>
> >>> If this code doesn't work for you then your ooPIC is broken.
> >>>
> >>>
> >>>
> >>>
> >>> **************The year's hottest artists on the red carpet at
> >>>
> > the Grammy
> >
> >>> Awards. Go to AOL Music.
> >>> (http://music.aol.com/grammys?NCID=aolcmp00300000002565)
> >>>
> >>>
> >>> [Non-text portions of this message have been removed]
> >>>
> >>>
> >>>
> >>>
> >>>



(You need to be a member of oopic -- send a blank email to oopic-subscribe@yahoogroups.com )

Now we have the makings of a batch problem. It sure looks like a
batch issue since there are at least two of you that have the problem on
multiple parts. I've raised the flag at manufacturing and I'll get back
to you on how to get the units swapped for working ones as soon as the
information gets to me.

***
If anyone else has C1.1+ ooPIC parts please use this program below to
check to see if it works properly. If you get the symptoms that have
been stated here then contact the list and I'll get you in touch with
replacements too.
***
DLC

************** Program to check ooPIC C1.1+ devices
This code flashes LED 7 at a .5Hz rate if all is right..

Dim BLINK As New oEvent
Dim WIRE As New oWire
Dim led7 As New oLED
Dim led5 As New oLED
Dim flag As New oByte

Sub Main()
flag = 0
ooPIC.Delay = 500
led5.IOLine = 5
led5.TurnOn
led7.IOLine = 7
WIRE.Input.Link(WIRE.Input
WIRE.Output.WIRE.Output
WIRE.Operate = cvTrue
End Sub

Sub BLINK_Code()
If flag = 1 Then
led7.TurnOn
flag = 0
Else
led7.TurnOff
flag = 1
End If

End Sub

s.k.f. wrote:
> I just got a bunch of these too and thought I would see what mine
> would do with this code.
>
> exactly as you stated. green blinks twice. then starts blinking med
> to full intensity the comes on and stays on.
>
> using the 6.1.1 compiler and the c1.1+ chip. I bought 10 of these
> wonder if they all have the glitch
>
> some other interesting test:
>
> added line led7.TurnOn after the led7.ioline=7 and then the red one
> comes on but not as it should green still turns off and on too. both
> stop and stay on after about 6 seconds
>
> moved the oopic.delay to before the sub main() and the leds continue
> to blink, in sync then out. blinking doesn't stop however. this is
> doing something to the rx line too as the led in the usb cable rxled
> has a short flash now and then.
>
> remove the oopic.delay all together and the leds blink fast then
> stay on.
> --- In o...@yahoogroups.com, ooPIC Tech Support
> wrote:
>
>> Yes,
>>
>> Replace the ooPIC C, it must have a bad version of the code in
>>
> it.
>
>> The code that I sent you works perfectly here.
>>
>> DLC
>>
>> dldlhfd@... wrote:
>>
>>>
>>> Oopic C.1.1+ Oopic C Carrier board 6.1.1 compiler
>>> To refresh your memory, I have been having trouble getting
>>>
> the events to
>
>>> work. We have sent email back and forth You sent this program
>>>
> saying that if
>
>>> it did not work then you thought my chip was broken.
>>> I tried the program and the results were:
>>> The green led comes on flashes and changes intensity and
>>>
> then stays on.
>
>>> It never goes to the subroutine to turn on the red led as it
>>>
> should.
>
>>> So I talked to the people at the Bot Shop and they arranged
>>>
> with Savage
>
>>> and sent me a new chip. The very first thing I did was put the
>>>
> chip on my
>
>>> board and try the program. It did exactly the same thing with
>>>
> the new chip as it
>
>>> did with the old. Just to make sure it was not the carrier
>>>
> board I took the
>
>>> chip off the board, put the chip on my proto board and put the
>>>
> 9 volt
>
>>> battery to pins 24 and 23. I got he exact same reaction. The
>>>
> red led in the sub
>
>>> routine never comes on.
>>> This is very frustrating. Every thing else that I have
>>>
> tried works. Do
>
>>> you have any suggestions for me?
>>>
>>> In a message dated 2/4/2008 12:09:35 A.M. Eastern Standard
>>>
> Time,
>
>>> dennis.clark@... writes:
>>>
>>> This code works, but it flashes at a .5Hz rate, I wasn't
>>>
> interested in a
>
>>> 1Hz flash so much as working event code.
>>>
>>> ---------------------------------------------------
>>> Dim BLINK As New oEvent
>>> Dim WIRE As New oWire
>>> Dim led7 As New oLED
>>> Dim led5 As New oLED
>>> Dim flag As New oByte
>>>
>>> Sub Main()
>>> flag = 0
>>> ooPIC.Delay = 500
>>> led5.IOLine = 5
>>> led5.TurnOn
>>> led7.IOLine = 7
>>> WIRE.Input.Link(WIRE.Input
>>> WIRE.Output.WIRE.Output
>>> WIRE.Operate = cvTrue
>>> End Sub
>>>
>>> Sub BLINK_Code()
>>> If flag = 1 Then
>>> led7.TurnOn
>>> flag = 0
>>> Else
>>> led7.TurnOff
>>> flag = 1
>>> End If
>>>
>>> End Sub
>>> ----------------------------------------------
>>>
>>> If this code doesn't work for you then your ooPIC is broken.
>>>
>>>
>>>
>>>
>>> **************The year's hottest artists on the red carpet at
>>>
> the Grammy
>
>>> Awards. Go to AOL Music.
>>> (http://music.aol.com/grammys?NCID=aolcmp00300000002565)
>>>
>>>
>>> [Non-text portions of this message have been removed]
>>>
>>>
>>>
>>>
>>>



(You need to be a member of oopic -- send a blank email to oopic-subscribe@yahoogroups.com )

Thanks,

What is weird is that what you see there is NOT what I posted! I
don't know what munged it, but something did! It SHOULD have read:

"Wire.input.link(oopic.hz1)"
"Wire.output.link(BLINK)"

I don't know what got weirded out there...

DLC

s.k.f. wrote:
> I will check out the rest of my units tomorrow. A couple are in use
> but don't use the event object, so I should be able to check out the
> rest of them at least
>
> In the code below it will not compile
>
> I have this in the wire vc instead
>
> WIRE.Input.Link(ooPIC.Hz60)
> WIRE.Output.Link(BLINK.Operate)
>
> everything else is as below
>
> --- In o...@yahoogroups.com, ooPIC Tech Support
> wrote:
>
>> Now we have the makings of a batch problem. It sure looks like
>>
> a
>
>> batch issue since there are at least two of you that have the
>>
> problem on
>
>> multiple parts. I've raised the flag at manufacturing and I'll
>>
> get back
>
>> to you on how to get the units swapped for working ones as soon as
>>
> the
>
>> information gets to me.
>>
>> ***
>> If anyone else has C1.1+ ooPIC parts please use this program
>>
> below to
>
>> check to see if it works properly. If you get the symptoms that
>>
> have
>
>> been stated here then contact the list and I'll get you in touch
>>
> with
>
>> replacements too.
>> ***
>> DLC
>>
>> ************** Program to check ooPIC C1.1+ devices
>> This code flashes LED 7 at a .5Hz rate if all is right..
>>
>> Dim BLINK As New oEvent
>> Dim WIRE As New oWire
>> Dim led7 As New oLED
>> Dim led5 As New oLED
>> Dim flag As New oByte
>>
>> Sub Main()
>> flag = 0
>> ooPIC.Delay = 500
>> led5.IOLine = 5
>> led5.TurnOn
>> led7.IOLine = 7
>> WIRE.Input.Link(WIRE.Input
>> WIRE.Output.WIRE.Output
>> WIRE.Operate = cvTrue
>> End Sub
>>
>> Sub BLINK_Code()
>> If flag = 1 Then
>> led7.TurnOn
>> flag = 0
>> Else
>> led7.TurnOff
>> flag = 1
>> End If
>>
>> End Sub
>>
>> s.k.f. wrote:
>>
>>> I just got a bunch of these too and thought I would see what
>>>
> mine
>
>>> would do with this code.
>>>
>>> exactly as you stated. green blinks twice. then starts blinking
>>>
> med
>
>>> to full intensity the comes on and stays on.
>>>
>>> using the 6.1.1 compiler and the c1.1+ chip. I bought 10 of
>>>
> these
>
>>> wonder if they all have the glitch
>>>
>>> some other interesting test:
>>>
>>> added line led7.TurnOn after the led7.ioline=7 and then the red
>>>
> one
>
>>> comes on but not as it should green still turns off and on too.
>>>
> both
>
>>> stop and stay on after about 6 seconds
>>>
>>> moved the oopic.delay to before the sub main() and the leds
>>>
> continue
>
>>> to blink, in sync then out. blinking doesn't stop however. this
>>>
> is
>
>>> doing something to the rx line too as the led in the usb cable
>>>
> rxled
>
>>> has a short flash now and then.
>>>
>>> remove the oopic.delay all together and the leds blink fast then
>>> stay on.
>>>
>>>
>>> --- In o...@yahoogroups.com, ooPIC Tech Support
>>> wrote:
>>>
>>>
>>>> Yes,
>>>>
>>>> Replace the ooPIC C, it must have a bad version of the code
>>>>
> in
>
>>>>
>>>>
>>> it.
>>>
>>>
>>>> The code that I sent you works perfectly here.
>>>>
>>>> DLC
>>>>
>>>> dldlhfd@ wrote:
>>>>
>>>>
>>>>>
>>>>> Oopic C.1.1+ Oopic C Carrier board 6.1.1 compiler
>>>>> To refresh your memory, I have been having trouble
>>>>>
> getting
>
>>>>>
>>>>>
>>> the events to
>>>
>>>
>>>>> work. We have sent email back and forth You sent this program
>>>>>
>>>>>
>>> saying that if
>>>
>>>
>>>>> it did not work then you thought my chip was broken.
>>>>> I tried the program and the results were:
>>>>> The green led comes on flashes and changes intensity and
>>>>>
>>>>>
>>> then stays on.
>>>
>>>
>>>>> It never goes to the subroutine to turn on the red led as it
>>>>>
>>>>>
>>> should.
>>>
>>>
>>>>> So I talked to the people at the Bot Shop and they
>>>>>
> arranged
>
>>>>>
>>>>>
>>> with Savage
>>>
>>>
>>>>> and sent me a new chip. The very first thing I did was put
>>>>>
> the
>
>>>>>
>>>>>
>>> chip on my
>>>
>>>
>>>>> board and try the program. It did exactly the same thing with
>>>>>
>>>>>
>>> the new chip as it
>>>
>>>
>>>>> did with the old. Just to make sure it was not the carrier
>>>>>
>>>>>
>>> board I took the
>>>
>>>
>>>>> chip off the board, put the chip on my proto board and put
>>>>>
> the
>
>>>>>
>>>>>
>>> 9 volt
>>>
>>>
>>>>> battery to pins 24 and 23. I got he exact same reaction. The
>>>>>
>>>>>
>>> red led in the sub
>>>
>>>
>>>>> routine never comes on.
>>>>> This is very frustrating. Every thing else that I have
>>>>>
>>>>>
>>> tried works. Do
>>>
>>>
>>>>> you have any suggestions for me?
>>>>>
>>>>> In a message dated 2/4/2008 12:09:35 A.M. Eastern Standard
>>>>>
>>>>>
>>> Time,
>>>
>>>
>>>>> dennis.clark@ writes:
>>>>>
>>>>> This code works, but it flashes at a .5Hz rate, I wasn't
>>>>>
>>>>>
>>> interested in a
>>>
>>>
>>>>> 1Hz flash so much as working event code.
>>>>>
>>>>> ---------------------------------------------------
>>>>> Dim BLINK As New oEvent
>>>>> Dim WIRE As New oWire
>>>>> Dim led7 As New oLED
>>>>> Dim led5 As New oLED
>>>>> Dim flag As New oByte
>>>>>
>>>>> Sub Main()
>>>>> flag = 0
>>>>> ooPIC.Delay = 500
>>>>> led5.IOLine = 5
>>>>> led5.TurnOn
>>>>> led7.IOLine = 7
>>>>> WIRE.Input.Link(WIRE.Input
>>>>> WIRE.Output.WIRE.Output
>>>>> WIRE.Operate = cvTrue
>>>>> End Sub
>>>>>
>>>>> Sub BLINK_Code()
>>>>> If flag = 1 Then
>>>>> led7.TurnOn
>>>>> flag = 0
>>>>> Else
>>>>> led7.TurnOff
>>>>> flag = 1
>>>>> End If
>>>>>
>>>>> End Sub
>>>>> ----------------------------------------------
>>>>>
>>>>> If this code doesn't work for you then your ooPIC is broken.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> **************The year's hottest artists on the red carpet at
>>>>>
>>>>>
>>> the Grammy
>>>
>>>
>>>>> Awards. Go to AOL Music.
>>>>> (http://music.aol.com/grammys?NCID=aolcmp00300000002565)
>>>>>
>>>>>
>>>>> [Non-text portions of this message have been removed]
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>



(You need to be a member of oopic -- send a blank email to oopic-subscribe@yahoogroups.com )

Dennis,

OOPic III+ Ver C.1.1+ Compiler 6.1.1

I'm seeing similar squirrly behavior. I have a complex program that
used an event triggered by a bumper switch. When the switch was
activated the event handler did not execute but the main loop stopped
executing as well. To track down what is wrong, I started out with the
sample code in "Chapter 9 - Event Driven ProgrammingC". It didn't work.
I was reading this thread and I wrote the following test program which
is very similar to your test:

Dim BLINK As New oEvent
Dim WIRE As New oWire
Dim LED As New oDIO1

Sub Main()
LED.IOLine = 20
LED.Direction = cvOutput
' Call BLINK_Code()
WIRE.Input.Link(ooPIC.Hz1)
WIRE.Output.Link(BLINK.Operate)
WIRE.Operate = cvTrue
Do
Loop
End Sub

Sub BLINK_Code()
LED = cvOn
ooPIC.Delay = 500
LED = cvOff
ooPIC.Delay = 500
End Sub
When I run it as is, nothing happens. The led does not light up. I put
in the extra line to prove to myself that the problem was not in the led
and wierd behavior ensued. The led flashed on and off exactly ten times
with a little pause during the eighth off period. The tenth on period
stays on contiuously. After the tenth flash, one of the servos moves
slightly. At this point, I have to reset the OOPic to reprogram it.
This behavior is repeatable.

In my original complex program, everything execpt the event works fine.



(You need to be a member of oopic -- send a blank email to oopic-subscribe@yahoogroups.com )

--- In o...@yahoogroups.com, "dogulas" wrote:
> Dennis,
>
> OOPic III+ Ver C.1.1+ Compiler 6.1.1
>
> I'm seeing similar squirrly behavior. I have a complex program that
> used an event triggered by a bumper switch. When the switch was
> activated the event handler did not execute but the main loop
stopped
> executing as well. To track down what is wrong, I started out with
the
> sample code in "Chapter 9 - Event Driven ProgrammingC". It didn't
work.
> I was reading this thread and I wrote the following test program
which
> is very similar to your test:
>
> Dim BLINK As New oEvent
> Dim WIRE As New oWire
> Dim LED As New oDIO1
>
> Sub Main()
> LED.IOLine = 20
> LED.Direction = cvOutput
> ' Call BLINK_Code()
> WIRE.Input.Link(ooPIC.Hz1)
> WIRE.Output.Link(BLINK.Operate)
> WIRE.Operate = cvTrue
> Do
> Loop
> End Sub
>
> Sub BLINK_Code()
> LED = cvOn
> ooPIC.Delay = 500
> LED = cvOff
> ooPIC.Delay = 500
> End Sub
> When I run it as is, nothing happens. The led does not light up.
I put
> in the extra line to prove to myself that the problem was not in
the led
> and wierd behavior ensued. The led flashed on and off exactly ten
times
> with a little pause during the eighth off period. The tenth on
period
> stays on contiuously. After the tenth flash, one of the servos
moves
> slightly. At this point, I have to reset the OOPic to reprogram
it.
> This behavior is repeatable.
>
> In my original complex program, everything execpt the event works
fine.
>

Yes but... Do you know if event code is reentrant? Assuming your
version of the compiler has OOPic.Delay in mS (it used to be 0.01
second in V5) then your event code COULD take longer than the
OOPic.1Hz trigger interval.

I haven't made the transition to V6 so I don't know a lot about the
issues but if I were doing the code above, I would start by cutting
the delays to 250 to be absolutely certain the event code was
complete before the next trigger.

Richard



(You need to be a member of oopic -- send a blank email to oopic-subscribe@yahoogroups.com )

BLINK_code is supposed to be an *event handler* that does something
fast and gets out, not a piece of code that takes its sweet time
doing whatever it feels like.

If you want to play around with event handling, do something fast,
like toggle the LED's state (LED = 1 - LED)

At 02:23 PM 2/15/2008, dogulas wrote:

>Dennis,
>
>OOPic III+ Ver C.1.1+ Compiler 6.1.1
>
>I'm seeing similar squirrly behavior. I have a complex program that
>used an event triggered by a bumper switch. When the switch was
>activated the event handler did not execute but the main loop stopped
>executing as well. To track down what is wrong, I started out with the
>sample code in "Chapter 9 - Event Driven ProgrammingC". It didn't work.
>I was reading this thread and I wrote the following test program which
>is very similar to your test:
>
>Dim BLINK As New oEvent
>Dim WIRE As New oWire
>Dim LED As New oDIO1
>
>Sub Main()
> LED.IOLine = 20
> LED.Direction = cvOutput
>' Call BLINK_Code()
> WIRE.Input.Link(ooPIC.Hz1)
> WIRE.Output.Link(BLINK.Operate)
> WIRE.Operate = cvTrue
> Do
> Loop
>End Sub
>
>Sub BLINK_Code()
> LED = cvOn
> ooPIC.Delay = 500
> LED = cvOff
> ooPIC.Delay = 500
>End Sub
>When I run it as is, nothing happens. The led does not light up. I put
>in the extra line to prove to myself that the problem was not in the led
>and wierd behavior ensued. The led flashed on and off exactly ten times
>with a little pause during the eighth off period. The tenth on period
>stays on contiuously. After the tenth flash, one of the servos moves
>slightly. At this point, I have to reset the OOPic to reprogram it.
>This behavior is repeatable.
>
>In my original complex program, everything execpt the event works fine.



(You need to be a member of oopic -- send a blank email to oopic-subscribe@yahoogroups.com )

--- In o...@yahoogroups.com, "rtstofer" wrote:
>
> --- In o...@yahoogroups.com, "dogulas" wrote:
> >
> >
> > Dennis,
> >
> > OOPic III+ Ver C.1.1+ Compiler 6.1.1
> >
> > I'm seeing similar squirrly behavior. I have a complex program
that
> > used an event triggered by a bumper switch. When the switch was
> > activated the event handler did not execute but the main loop
> stopped
> > executing as well. To track down what is wrong, I started out
with
> the
> > sample code in "Chapter 9 - Event Driven ProgrammingC". It
didn't
> work.
> > I was reading this thread and I wrote the following test program
> which
> > is very similar to your test:
> >
> > Dim BLINK As New oEvent
> > Dim WIRE As New oWire
> > Dim LED As New oDIO1
> >
> > Sub Main()
> > LED.IOLine = 20
> > LED.Direction = cvOutput
> > ' Call BLINK_Code()
> > WIRE.Input.Link(ooPIC.Hz1)
> > WIRE.Output.Link(BLINK.Operate)
> > WIRE.Operate = cvTrue
> > Do
> > Loop
> > End Sub
> >
> > Sub BLINK_Code()
> > LED = cvOn
> > ooPIC.Delay = 500
> > LED = cvOff
> > ooPIC.Delay = 500
> > End Sub
> >
> >
> > When I run it as is, nothing happens. The led does not light
up.
> I put
> > in the extra line to prove to myself that the problem was not in
> the led
> > and wierd behavior ensued. The led flashed on and off exactly
ten
> times
> > with a little pause during the eighth off period. The tenth on
> period
> > stays on contiuously. After the tenth flash, one of the servos
> moves
> > slightly. At this point, I have to reset the OOPic to reprogram
> it.
> > This behavior is repeatable.
> >
> > In my original complex program, everything execpt the event works
> fine.
> > Yes but... Do you know if event code is reentrant? Assuming your
> version of the compiler has OOPic.Delay in mS (it used to be 0.01
> second in V5) then your event code COULD take longer than the
> OOPic.1Hz trigger interval.
>
> I haven't made the transition to V6 so I don't know a lot about the
> issues but if I were doing the code above, I would start by cutting
> the delays to 250 to be absolutely certain the event code was
> complete before the next trigger.
>
> Richard
>

Richard,

Thanks for the reply.

Excellent point! The event must be taking slightly longer than one
second. I changed the delays to 250 and guess what? It now flashes
in one second cycles indefinately.

While that mystery is solved, the bigger question is: Why do I have
to call the BLINK_Code() as a subroutine first? Remember, when I
have that call statement commented out, the event handler is not
firing. Any thoughts on that?

Thanks,
Dogulas



(You need to be a member of oopic -- send a blank email to oopic-subscribe@yahoogroups.com )

--- In o...@yahoogroups.com, Andrew Porrett wrote:
>
> BLINK_code is supposed to be an *event handler* that does something
> fast and gets out, not a piece of code that takes its sweet time
> doing whatever it feels like.
>
> If you want to play around with event handling, do something fast,
> like toggle the LED's state (LED = 1 - LED)
>
> At 02:23 PM 2/15/2008, dogulas wrote:
>
> >Dennis,
> >
> >OOPic III+ Ver C.1.1+ Compiler 6.1.1
> >
> >I'm seeing similar squirrly behavior. I have a complex program
that
> >used an event triggered by a bumper switch. When the switch was
> >activated the event handler did not execute but the main loop
stopped
> >executing as well. To track down what is wrong, I started out
with the
> >sample code in "Chapter 9 - Event Driven ProgrammingC". It didn't
work.
> >I was reading this thread and I wrote the following test program
which
> >is very similar to your test:
> >
> >Dim BLINK As New oEvent
> >Dim WIRE As New oWire
> >Dim LED As New oDIO1
> >
> >Sub Main()
> > LED.IOLine = 20
> > LED.Direction = cvOutput
> >' Call BLINK_Code()
> > WIRE.Input.Link(ooPIC.Hz1)
> > WIRE.Output.Link(BLINK.Operate)
> > WIRE.Operate = cvTrue
> > Do
> > Loop
> >End Sub
> >
> >Sub BLINK_Code()
> > LED = cvOn
> > ooPIC.Delay = 500
> > LED = cvOff
> > ooPIC.Delay = 500
> >End Sub
> >
> >
> >When I run it as is, nothing happens. The led does not light up.
I put
> >in the extra line to prove to myself that the problem was not in
the led
> >and wierd behavior ensued. The led flashed on and off exactly ten
times
> >with a little pause during the eighth off period. The tenth on
period
> >stays on contiuously. After the tenth flash, one of the servos
moves
> >slightly. At this point, I have to reset the OOPic to reprogram
it.
> >This behavior is repeatable.
> >
> >In my original complex program, everything execpt the event works
fine.
>

Andrew,

Thanks for the reply.

I agree with you fully. In the original program I am merely flipping
a bit flag. I was just trying a test where I could see some activity
in the handler. I went back and changed the code to be like this:

Dim BLINK As New oEvent
Dim WIRE As New oWire
Dim LED As New oDIO1

Sub Main()
LED.IOLine = 20
LED.Direction = cvOutput
Call BLINK_Code()
WIRE.Input.Link(ooPIC.Hz1)
WIRE.Output.Link(BLINK.Operate)
WIRE.Operate = cvTrue
Do
Loop
End Sub

Sub BLINK_Code()
LED.Toggle
End Sub
When I run it like this, the led flashes so fast, I'm beginning to
think that ooPic.Hz1 alternates ten time a second instead of one.
But at least it works. As pointed out in another branch, the
original handler took a little over a second to run.

Now for the bigger question. If I comment out the Call statement,
the handler never fires and the led stays dark. Why would I need to
call the handler like a subroutine first to make it work correctly?

Thanks,
Dogulas



(You need to be a member of oopic -- send a blank email to oopic-subscribe@yahoogroups.com )

> Richard,
>
> Thanks for the reply.
>
> Excellent point! The event must be taking slightly longer than one
> second. I changed the delays to 250 and guess what? It now
flashes
> in one second cycles indefinately.
>
> While that mystery is solved, the bigger question is: Why do I have
> to call the BLINK_Code() as a subroutine first? Remember, when I
> have that call statement commented out, the event handler is not
> firing. Any thoughts on that?
>
> Thanks,
> Dogulas
>

Beats me! For V6 and an OOPic II+ (B2.2+) the following code works
fine:

' Code for V6 of compiler

Dim BLINK As New oEvent
Dim WIRE As New oWire
Dim LED As New oDIO1

Sub Main()
LED.IOLine = 7
LED.Direction = cvOutput
WIRE.Input.Link(ooPIC.Hz1)
WIRE.Output.Link(BLINK.Operate)
WIRE.Operate = cvTrue
End Sub

Sub BLINK_Code()
LED = cvOn
ooPIC.Delay = 250
LED = cvOff
ooPIC.Delay = 250
End Sub

I had to change the IOLine, I have a permanent LED on IOLine 7 and I
got rid of the useless DO...LOOP construct.

Pay heed to what Andrew said earlier, you don't want to hang around
in an event handler. Toggle the LED, use a counter, anything EXCEPT
OOPic.Delay.

The same code works in V5 if the OOPic.Delay values are set to 25.

Richard



(You need to be a member of oopic -- send a blank email to oopic-subscribe@yahoogroups.com )

We are suspecting that the C1.1+ firmware or the compiler that compiles
to the C1.1+ firmware is wrong. My posted event code (that simply flips
the bit) works fine on B2.2+, but acts weird on C1.1+ code. We've found
it in ooPIC C boards, ooPIC R boards and ooPIC S boards. The factory is
looking into where the problem lies.

DLC

rtstofer wrote:
>> Richard,
>>
>> Thanks for the reply.
>>
>> Excellent point! The event must be taking slightly longer than one
>> second. I changed the delays to 250 and guess what? It now
>>
> flashes
>
>> in one second cycles indefinately.
>>
>> While that mystery is solved, the bigger question is: Why do I have
>> to call the BLINK_Code() as a subroutine first? Remember, when I
>> have that call statement commented out, the event handler is not
>> firing. Any thoughts on that?
>>
>> Thanks,
>> Dogulas
>>
>>
>
> Beats me! For V6 and an OOPic II+ (B2.2+) the following code works
> fine:
>
> ' Code for V6 of compiler
>
> Dim BLINK As New oEvent
> Dim WIRE As New oWire
> Dim LED As New oDIO1
>
> Sub Main()
> LED.IOLine = 7
> LED.Direction = cvOutput
> WIRE.Input.Link(ooPIC.Hz1)
> WIRE.Output.Link(BLINK.Operate)
> WIRE.Operate = cvTrue
> End Sub
>
> Sub BLINK_Code()
> LED = cvOn
> ooPIC.Delay = 250
> LED = cvOff
> ooPIC.Delay = 250
> End Sub
>
> I had to change the IOLine, I have a permanent LED on IOLine 7 and I
> got rid of the useless DO...LOOP construct.
>
> Pay heed to what Andrew said earlier, you don't want to hang around
> in an event handler. Toggle the LED, use a counter, anything EXCEPT
> OOPic.Delay.
>
> The same code works in V5 if the OOPic.Delay values are set to 25.
>
> Richard
>
>



(You need to be a member of oopic -- send a blank email to oopic-subscribe@yahoogroups.com )

--- In o...@yahoogroups.com, "rtstofer" wrote:
> Beats me! For V6 and an OOPic II+ (B2.2+) the following code works
> fine:
>
> ' Code for V6 of compiler
>
> Dim BLINK As New oEvent
> Dim WIRE As New oWire
> Dim LED As New oDIO1
>
> Sub Main()
> LED.IOLine = 7
> LED.Direction = cvOutput
> WIRE.Input.Link(ooPIC.Hz1)
> WIRE.Output.Link(BLINK.Operate)
> WIRE.Operate = cvTrue
> End Sub
>
> Sub BLINK_Code()
> LED = cvOn
> ooPIC.Delay = 250
> LED = cvOff
> ooPIC.Delay = 250
> End Sub
>
> I had to change the IOLine, I have a permanent LED on IOLine 7 and
I
> got rid of the useless DO...LOOP construct.
>
> Pay heed to what Andrew said earlier, you don't want to hang around
> in an event handler. Toggle the LED, use a counter, anything
EXCEPT
> OOPic.Delay.
>
> The same code works in V5 if the OOPic.Delay values are set to 25.
>
> Richard
>

Richard,

Thanks for the reply.

In my response to Andrew I replaced the wordy handler with one that
simply toggles the led. I got the same response. It only works if I
call the handler as a subroutine first.

I am using ooPic III+ instead of II+ and C.1.1+ instead of B.2.2+.
IN another post Dennis suspects the C.1.1+ compiler.

By the way, thanks for pointing out that you don't need to keep the
main thread alive with an endless loop like you do in higher multi-
threaded environments. Good to know.

Thanks,
Dogulas



(You need to be a member of oopic -- send a blank email to oopic-subscribe@yahoogroups.com )

--- In o...@yahoogroups.com, ooPIC Tech Support
wrote:
>
> We are suspecting that the C1.1+ firmware or the compiler that
compiles
> to the C1.1+ firmware is wrong. My posted event code (that simply
flips
> the bit) works fine on B2.2+, but acts weird on C1.1+ code. We've
found
> it in ooPIC C boards, ooPIC R boards and ooPIC S boards. The
factory is
> looking into where the problem lies.
>
> DLC
> --
> ------------------------------------------------------
> Dennis Clark ooPIC Tech Support
> www.oopic.com
> ------------------------------------------------------
>

Dennis,

Thanks for the reply.

Now I can stop suspecting my sanity. Can I assume that when you know
something for sure about C.1.1+ and a possible solution or timetable
for a solution that someone will post another response in this group?

In the meantime, I'll continue my project with the extra subroutine
call. I hope that is all that is wrong. :-)

Thanks,
Dogulas



(You need to be a member of oopic -- send a blank email to oopic-subscribe@yahoogroups.com )

Hmm. Do you mean that if you call the event as a subroutine once then
the event will work as expected? It could be the temporary workaround
until the compiler is fixed.

DLC

dogulas wrote:
> --- In o...@yahoogroups.com, ooPIC Tech Support
> wrote:
>
>> We are suspecting that the C1.1+ firmware or the compiler that
>>
> compiles
>
>> to the C1.1+ firmware is wrong. My posted event code (that simply
>>
> flips
>
>> the bit) works fine on B2.2+, but acts weird on C1.1+ code. We've
>>
> found
>
>> it in ooPIC C boards, ooPIC R boards and ooPIC S boards. The
>>
> factory is
>
>> looking into where the problem lies.
>>
>> DLC
>> --
>> ------------------------------------------------------
>> Dennis Clark ooPIC Tech Support
>> www.oopic.com
>> ------------------------------------------------------
>>
>>
>
> Dennis,
>
> Thanks for the reply.
>
> Now I can stop suspecting my sanity. Can I assume that when you know
> something for sure about C.1.1+ and a possible solution or timetable
> for a solution that someone will post another response in this group?
>
> In the meantime, I'll continue my project with the extra subroutine
> call. I hope that is all that is wrong. :-)
>
> Thanks,
> Dogulas
>
>
>



(You need to be a member of oopic -- send a blank email to oopic-subscribe@yahoogroups.com )

didn't work for my units, I read this before and tried it to see. I
have both the c1.1+ and b2.2+. the 'b' unit works fine in all cases
with or without calling the event first.
the 'c' units (all 12 of them) refuse to work either way.
there may be another batch of 'c' units that this fix does work on
but not mine, unfortunatly.

scott
--- In o...@yahoogroups.com, ooPIC Tech Support
wrote:
>
> Hmm. Do you mean that if you call the event as a subroutine
once then
> the event will work as expected? It could be the temporary
workaround
> until the compiler is fixed.
>
> DLC
>
> dogulas wrote:
> > --- In o...@yahoogroups.com, ooPIC Tech Support
> > wrote:
> >
> >> We are suspecting that the C1.1+ firmware or the compiler that
> >>
> > compiles
> >
> >> to the C1.1+ firmware is wrong. My posted event code (that
simply
> >>
> > flips
> >
> >> the bit) works fine on B2.2+, but acts weird on C1.1+ code.
We've
> >>
> > found
> >
> >> it in ooPIC C boards, ooPIC R boards and ooPIC S boards. The
> >>
> > factory is
> >
> >> looking into where the problem lies.
> >>
> >> DLC
> >>
> >>
> >> --
> >> ------------------------------------------------------
> >> Dennis Clark ooPIC Tech Support
> >> www.oopic.com
> >> ------------------------------------------------------
> >>
> >>
> >
> > Dennis,
> >
> > Thanks for the reply.
> >
> > Now I can stop suspecting my sanity. Can I assume that when you
know
> > something for sure about C.1.1+ and a possible solution or
timetable
> > for a solution that someone will post another response in this
group?
> >
> > In the meantime, I'll continue my project with the extra
subroutine
> > call. I hope that is all that is wrong. :-)
> >
> > Thanks,
> > Dogulas
> >
> >
> >
> >
> >



(You need to be a member of oopic -- send a blank email to oopic-subscribe@yahoogroups.com )

I've talked to the developer, the problem lies with the compiler. He
has identified a workaround with the current compiler, but it is
painful. I'm awaiting a patch.

DLC

s.k.f. wrote:
> didn't work for my units, I read this before and tried it to see. I
> have both the c1.1+ and b2.2+. the 'b' unit works fine in all cases
> with or without calling the event first.
> the 'c' units (all 12 of them) refuse to work either way.
> there may be another batch of 'c' units that this fix does work on
> but not mine, unfortunatly.
>
> scott
> --- In o...@yahoogroups.com, ooPIC Tech Support
> wrote:
>
>> Hmm. Do you mean that if you call the event as a subroutine
>>
> once then
>
>> the event will work as expected? It could be the temporary
>>
> workaround
>
>> until the compiler is fixed.
>>
>> DLC
>>
>> dogulas wrote:
>>
>>> --- In o...@yahoogroups.com, ooPIC Tech Support
>>> wrote:
>>>
>>>
>>>> We are suspecting that the C1.1+ firmware or the compiler that
>>>>
>>>>
>>> compiles
>>>
>>>
>>>> to the C1.1+ firmware is wrong. My posted event code (that
>>>>
> simply
>
>>>>
>>>>
>>> flips
>>>
>>>
>>>> the bit) works fine on B2.2+, but acts weird on C1.1+ code.
>>>>
> We've
>
>>>>
>>>>
>>> found
>>>
>>>
>>>> it in ooPIC C boards, ooPIC R boards and ooPIC S boards. The
>>>>
>>>>
>>> factory is
>>>
>>>
>>>> looking into where the problem lies.
>>>>
>>>> DLC
>>>>
>>>>
>>>> --
>>>> ------------------------------------------------------
>>>> Dennis Clark ooPIC Tech Support
>>>> www.oopic.com
>>>> ------------------------------------------------------
>>>>
>>>>
>>>>
>>> Dennis,
>>>
>>> Thanks for the reply.
>>>
>>> Now I can stop suspecting my sanity. Can I assume that when you
>>>
> know
>
>>> something for sure about C.1.1+ and a possible solution or
>>>
> timetable
>
>>> for a solution that someone will post another response in this
>>>
> group?
>
>>> In the meantime, I'll continue my project with the extra
>>>
> subroutine
>
>>> call. I hope that is all that is wrong. :-)
>>>
>>> Thanks,
>>> Dogulas
>>>
>>>
>>>
>>>
>>>



(You need to be a member of oopic -- send a blank email to oopic-subscribe@yahoogroups.com )

C.1.1+ 6.1 compiler 00pic C carrier board.
Calling the subroutine first does not make mine work either.

Another point: I have been trying to follow the thread on this and it
sounds like what you are saying is that with events you need to execute the
subroutine and get back out before the routine is called again. but I was reading
the manual on events and it says:

While the Sub procedure is executing the oEvent Object ignores the Operate
property and waits for the program flow to return from the Sub procedure. When
the program flow returns from the Sub procedure the oEvent Object resumes
watching for the Operate property to transition from 0 to 1.

As I understand this, it does not matter how long you are in the subroutine
it will not re-execute until it the subroutine is complete. On the other hand
a different event can interrupt the first event subroutine.

Am I reading the correctly?

**************Ideas to please picky eaters. Watch video on AOL Living.
(http://living.aol.com/video/how-to-please-your-picky-eater/rachel-campos-duffy/
2050827?NCID=aolcmp00300000002598)
[Non-text portions of this message have been removed]



(You need to be a member of oopic -- send a blank email to oopic-subscribe@yahoogroups.com )

You are reading it correctly. The oEvent will only trigger on a
"low-to-high" transition of the .Operate flag. And only when it is not
currently executing that event. However, if your transitions occur
while you are in the circuit, it will cause odd behavior because the
timing will be off. It behooves you to do what you want to do and get
out so you don't miss transitions or end up with back-to-back event calls.

DLC

d...@aol.com wrote:
> C.1.1+ 6.1 compiler 00pic C carrier board.
> Calling the subroutine first does not make mine work either.
>
> Another point: I have been trying to follow the thread on this and it
> sounds like what you are saying is that with events you need to execute the
> subroutine and get back out before the routine is called again. but I was reading
> the manual on events and it says:
>
> While the Sub procedure is executing the oEvent Object ignores the Operate
> property and waits for the program flow to return from the Sub procedure. When
> the program flow returns from the Sub procedure the oEvent Object resumes
> watching for the Operate property to transition from 0 to 1.
>
> As I understand this, it does not matter how long you are in the subroutine
> it will not re-execute until it the subroutine is complete. On the other hand
> a different event can interrupt the first event subroutine.
>
> Am I reading the correctly?
>
> **************Ideas to please picky eaters. Watch video on AOL Living.
> (http://living.aol.com/video/how-to-please-your-picky-eater/rachel-campos-duffy/
> 2050827?NCID=aolcmp00300000002598)
> [Non-text portions of this message have been removed]
>
>
>



(You need to be a member of oopic -- send a blank email to oopic-subscribe@yahoogroups.com )

--- In o...@yahoogroups.com, ooPIC Tech Support
wrote:
>
> Hmm. Do you mean that if you call the event as a subroutine once
then
> the event will work as expected? It could be the temporary
workaround
> until the compiler is fixed.
>
> DLC
> --
> ------------------------------------------------------
> Dennis Clark ooPIC Tech Support
> www.oopic.com
> ------------------------------------------------------
>

Dennis,

I thought that was happening, but I wrote another simple test program
that included an LCD so I could tease out some info to help with
debugging and this one behaves completely wierd. It randomly drives
servos that I have hooked up but am not referencing in code and spits
garbage to the LCD in between the diagnostics that it is correctly
printing. Also, the "calling of the event handler first" trick does
not work in this program.

The results are so erratic, I suspect it is a memory overrun or some
similar type of error in the compiler. This means there is nothing
we can do to help or work around until we hear from the guys in the
lab.

Thanks for all your feedback. I'll be watching here for news.

Dogulas



(You need to be a member of oopic -- send a blank email to oopic-subscribe@yahoogroups.com )

--- In o...@yahoogroups.com, ooPIC Tech Support
wrote:
>
> I've talked to the developer, the problem lies with the compiler. He
> has identified a workaround with the current compiler, but it is
> painful. I'm awaiting a patch.
>
> DLC
> --
> ------------------------------------------------------
> Dennis Clark ooPIC Tech Support
> www.oopic.com
> ------------------------------------------------------
>

Dennis,

Do you have an ETA on that patch? My project is on a timetable.
Should I start looking at an earlier compiler?

Thanks,
Dogulas



(You need to be a member of oopic -- send a blank email to oopic-subscribe@yahoogroups.com )

I haven't gotten a date yet, but I'm pressing for one and will let you know.

DLC

dogulas wrote:
> --- In o...@yahoogroups.com, ooPIC Tech Support
> wrote:
>
>> I've talked to the developer, the problem lies with the compiler. He
>> has identified a workaround with the current compiler, but it is
>> painful. I'm awaiting a patch.
>>
>> DLC
>> --
>> ------------------------------------------------------
>> Dennis Clark ooPIC Tech Support
>> www.oopic.com
>> ------------------------------------------------------
>>
>>
>
> Dennis,
>
> Do you have an ETA on that patch? My project is on a timetable.
> Should I start looking at an earlier compiler?
>
> Thanks,
> Dogulas
>
>
>



(You need to be a member of oopic -- send a blank email to oopic-subscribe@yahoogroups.com )

At 10:46 AM 2/20/2008, dogulas wrote:
>Do you have an ETA on that patch? My project is on a timetable.
>Should I start looking at an earlier compiler?

Yes. You should not rely on a timely update. The regulars here
learned that a long time ago. Your timetable is not Scott's
timetable. V5 is simple enough to work with.
...Andy



(You need to be a member of oopic -- send a blank email to oopic-subscribe@yahoogroups.com )

--- In o...@yahoogroups.com, Andrew Porrett wrote:
>
> At 10:46 AM 2/20/2008, dogulas wrote:
> >Do you have an ETA on that patch? My project is on a timetable.
> >Should I start looking at an earlier compiler?
>
> Yes. You should not rely on a timely update. The regulars here
> learned that a long time ago. Your timetable is not Scott's
> timetable. V5 is simple enough to work with.
> ...Andy
>

Ah... But what if the OP has C.1.1 firmware? I'm not certain than V5
will generate code for it.

I like my B.2.2+ S board with V5 more and more...

Richard



(You need to be a member of oopic -- send a blank email to oopic-subscribe@yahoogroups.com )

--- In o...@yahoogroups.com, "rtstofer" wrote:
>
> --- In o...@yahoogroups.com, Andrew Porrett wrote:
> >
> > At 10:46 AM 2/20/2008, dogulas wrote:
> > >Do you have an ETA on that patch? My project is on a timetable.
> > >Should I start looking at an earlier compiler?
> >
> > Yes. You should not rely on a timely update. The regulars here
> > learned that a long time ago. Your timetable is not Scott's
> > timetable. V5 is simple enough to work with.
> >
> >
> > ...Andy
> > Ah... But what if the OP has C.1.1 firmware? I'm not certain than
V5
> will generate code for it.
>
> I like my B.2.2+ S board with V5 more and more...
>
> Richard
>
My v5 doesn't list the c - devices at all. I thought I had a BETA
version of 6.something complier that had the capability there but
don't know what happened to it. It had other issues though as I
recall. Will just have to wait for the fix for this one. I don't
have any of the 24pin chips in the b+ ver.



(You need to be a member of oopic -- send a blank email to oopic-subscribe@yahoogroups.com )

At 06:14 PM 2/20/2008, rtstofer wrote:
>Ah... But what if the OP has C.1.1 firmware? I'm not certain than V5
>will generate code for it.

Uh oh...

> --- In o...@yahoogroups.com, "dogulas" wrote:
> >
> >
> > Dennis,
> >
> > OOPic III+ Ver C.1.1+ Compiler 6.1.1

No V5 for him.
...Andy



(You need to be a member of oopic -- send a blank email to oopic-subscribe@yahoogroups.com )

At 06:05 PM 2/20/2008, dogulas wrote:
>I wrote my code against 6.1.1. Will my objects work as recently as
>v5, or am I looking at a re-write?

I see you have a new OOPic - you're stuck with V6.
>It makes me nervous because the other half of the application runs on
>a server and communicates with SCP. Therefore changes object
>addresses and expected functionality will affect the server code as
>well.

I guess you don't have to worry about those issues any more...
...Andy



(You need to be a member of oopic -- send a blank email to oopic-subscribe@yahoogroups.com )

--- In o...@yahoogroups.com, Andrew Porrett wrote:
> Yes. You should not rely on a timely update. The regulars here
> learned that a long time ago. Your timetable is not Scott's
> timetable. V5 is simple enough to work with.
> ...Andy
>

Thanks Andy,

I wrote my code against 6.1.1. Will my objects work as recently as
v5, or am I looking at a re-write?

It makes me nervous because the other half of the application runs on
a server and communicates with SCP. Therefore changes object
addresses and expected functionality will affect the server code as
well.

Dogulas



(You need to be a member of oopic -- send a blank email to oopic-subscribe@yahoogroups.com )

--- In o...@yahoogroups.com, ooPIC Tech Support
wrote:
>
> You are correct. C1.1 firmware isn't a valid target for the V.5
> compiler. I'm awaiting information on a patch for the V.6 compiler
to
> fix this bug.
>
> DLC
> --
> ------------------------------------------------------
> Dennis Clark ooPIC Tech Support
> www.oopic.com
> ------------------------------------------------------
>

Dennis,

Ok, as I understand it, if the patch is not going to arrive in a
timely fashion, I need to get an older chip with B firmware, get a
copy of the V5 compiler, and rewrite all my code.

Before I start down this road, do you have any insight into OOPic's
timetable? Would you guess that it will be greater or lesser than a
month? Your best guess, I'll not hold you to it.

Thanks,
Dogulas



(You need to be a member of oopic -- send a blank email to oopic-subscribe@yahoogroups.com )

You are correct. C1.1 firmware isn't a valid target for the V.5
compiler. I'm awaiting information on a patch for the V.6 compiler to
fix this bug.

DLC

rtstofer wrote:
> --- In o...@yahoogroups.com, Andrew Porrett wrote:
>
>> At 10:46 AM 2/20/2008, dogulas wrote:
>>
>>> Do you have an ETA on that patch? My project is on a timetable.
>>> Should I start looking at an earlier compiler?
>>>
>> Yes. You should not rely on a timely update. The regulars here
>> learned that a long time ago. Your timetable is not Scott's
>> timetable. V5 is simple enough to work with.
>> ...Andy
>>
>>
>
> Ah... But what if the OP has C.1.1 firmware? I'm not certain than V5
> will generate code for it.
>
> I like my B.2.2+ S board with V5 more and more...
>
> Richard
>
>



(You need to be a member of oopic -- send a blank email to oopic-subscribe@yahoogroups.com )