Hi guys, i am using the 3 way header intended normally for servo to
drive one of my external driver for my stepper motor, for the i/o 8-15
rows... my first IOpack which is 1 in the oopic compiler works
perfectly fine but when i specified the iopack to be 5 (which is
suppose to be from I/O 12-15.) The logic doesnt come out? Using a
multimeter i tested the ports for port 8-11 it is changing, but for 12-
15 its not. Did i specify the wrong IOpack?

Minghui
------------------------------------



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

Can you post code?

DLC

minghui1984 wrote:
> Hi guys, i am using the 3 way header intended normally for servo to
> drive one of my external driver for my stepper motor, for the i/o 8-15
> rows... my first IOpack which is 1 in the oopic compiler works
> perfectly fine but when i specified the iopack to be 5 (which is
> suppose to be from I/O 12-15.) The logic doesnt come out? Using a
> multimeter i tested the ports for port 8-11 it is changing, but for 12-
> 15 its not. Did i specify the wrong IOpack?
>
> Minghui
> ------------------------------------



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

Dim A As New oStepper
Dim B As New oStepper
Sub Main()

A.IOPack = 1
B.IOPack = 5
A.Rate = 10
B.Rate = 10
A.Operate = 1
B.Operate = 1
Do
A.Distance = 100
B.Distance = 30
Wait Until A.NonZero = 0
Wait Until B.NonZero = 0
ooPIC.Delay = 1000
A.Distance = -100
B.Distance = -30
Wait Until A.NonZero = 0
Wait Until B.NonZero = 0
ooPIC.Delay = 1000
Loop

End Sub

--- In o...@yahoogroups.com, ooPIC Tech Support
wrote:
>
> Can you post code?
>
> DLC
>
> minghui1984 wrote:
> > Hi guys, i am using the 3 way header intended normally for servo
to
> > drive one of my external driver for my stepper motor, for the i/o
8-15
> > rows... my first IOpack which is 1 in the oopic compiler works
> > perfectly fine but when i specified the iopack to be 5 (which is
> > suppose to be from I/O 12-15.) The logic doesnt come out? Using a
> > multimeter i tested the ports for port 8-11 it is changing, but
for 12-
> > 15 its not. Did i specify the wrong IOpack?
> >
> > Minghui
> >
> >
> > ------------------------------------
> >
> >



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

SO anyone knows whats is wrong with the Iopack specifications? i
specified iopack 5 but it would not work. Other IOPacks also do not
apply

Minghui
--- In o...@yahoogroups.com, "minghui1984" wrote:
>
> Dim A As New oStepper
> Dim B As New oStepper
> Sub Main()
>
> A.IOPack = 1
> B.IOPack = 5
> A.Rate = 10
> B.Rate = 10
> A.Operate = 1
> B.Operate = 1
> Do
> A.Distance = 100
> B.Distance = 30
> Wait Until A.NonZero = 0
> Wait Until B.NonZero = 0
> ooPIC.Delay = 1000
> A.Distance = -100
> B.Distance = -30
> Wait Until A.NonZero = 0
> Wait Until B.NonZero = 0
> ooPIC.Delay = 1000
> Loop
>
> End Sub
>
> --- In o...@yahoogroups.com, ooPIC Tech Support
> wrote:
> >
> > Can you post code?
> >
> > DLC
> >
> > minghui1984 wrote:
> > > Hi guys, i am using the 3 way header intended normally for
servo
> to
> > > drive one of my external driver for my stepper motor, for the
i/o
> 8-15
> > > rows... my first IOpack which is 1 in the oopic compiler works
> > > perfectly fine but when i specified the iopack to be 5 (which
is
> > > suppose to be from I/O 12-15.) The logic doesnt come out? Using
a
> > > multimeter i tested the ports for port 8-11 it is changing, but
> for 12-
> > > 15 its not. Did i specify the wrong IOpack?
> > >
> > > Minghui
> > >
> > >
> > > ------------------------------------
> > >
> > >



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

--- In o...@yahoogroups.com, "minghui1984" wrote:
>
> SO anyone knows whats is wrong with the Iopack specifications? i
> specified iopack 5 but it would not work. Other IOPacks also do not
> apply

I have no idea what is wrong but I can't get it to work under V6
either. It does work with V5 as:

Dim A As New oStepper
Dim B As New oStepper

Sub Main()

A.IOGroup = 1
A.Nibble = 0
B.IOGroup = 1
B.Nibble = 1
A.Rate = 100
B.Rate = 100
A.Operate = 1
B.Operate = 1
Do
A.Value = 100
B.Value = 30
Wait Until A.NonZero = 0
Wait Until B.NonZero = 0
'ooPIC.Delay = 1000
A.Value = -100
B.Value = -30
Wait Until A.NonZero = 0
Wait Until B.NonZero = 0
'ooPIC.Delay = 1000
Loop

End Sub
I changed the rates (short attention span) and commented out the
delays.

If you are using an older chip (< C.1.1) then use V5. If you have
the newest chip, you have a problem. Perhaps someone else can get it
to work.

Richard

------------------------------------



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

minghui1984 wrote:
> SO anyone knows whats is wrong with the Iopack specifications? i
> specified iopack 5 but it would not work. Other IOPacks also do not
> apply
>
> Minghui
> --- In o...@yahoogroups.com, "minghui1984" wrote:
>
>> Dim A As New oStepper
>> Dim B As New oStepper
>> Sub Main()
>>
>> A.IOPack = 1
>> B.IOPack = 5
>> A.Rate = 10
>> B.Rate = 10
>> A.Operate = 1
>> B.Operate = 1
>> Do
>> A.Distance = 100
>> B.Distance = 30
>> Wait Until A.NonZero = 0
>> Wait Until B.NonZero = 0
>> ooPIC.Delay = 1000
>> A.Distance = -100
>> B.Distance = -30
>> Wait Until A.NonZero = 0
>> Wait Until B.NonZero = 0
>> ooPIC.Delay = 1000
>> Loop
>>
>> End Sub
>>
>>
Minghui

I have just checked your code on my Oopic B 2.2+ chip on a S board and
it is working as expected.
Have you checked the actual outputs of Pack1 and pack2 with a meter or a
scope?
If you are reading a pulsed output (5 volts) on your Oopic on the
relative Pack outputs, then your problem lies in the wiring to or from
your Motor Driver hardware.

Ian
------------------------------------



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

> If you are using an older chip (< C.1.1) then use V5. If you have
> the newest chip, you have a problem. Perhaps someone else can get it
> to work.

I am getting to the point where I am wondering if it is worth it to=20=20
keep going with the OOPic. For all the effort we are having to go=20=20
through to get the new versions to work it might be better to bite the=20=20
bullet and switch to something more stable. I really like the OOPic=20=20
and it makes a wonderful stepping-stone for my kids learning=20=20
programming but if they write code that doesn't work, that interferes=20=20
with their learning. Running programs are a reward. If it is too hard=20=20
they don't get enough reward and abandon the projects as being no fun.

So to the folks at Savage Innovations:

HELLO! ARE YOU LISTENING?

You have released a faulty product and your slow response time is very=20=20
likely to lose customers who will most likely never come back. Doesn't=20=20
this bother you? If it were my company it would bother the hell out of=20=20
me, that's for sure!

--

Brian Lloyd Granite Bay Montessori
brian AT gbmontessori DOT com 9330 Sierra College Blvd.
+1.916.367.2131 (voice) Roseville, CA 95661, USA
http://www.gbmontessori.com

I fly because it releases my mind from the tyranny of petty things . . .
=97 Antoine de Saint-Exup=E9ry

PGP key ID: 12095C52A32A1B6C
PGP key fingerprint: 3B1D BA11 4913 3254 B6E0 CC09 1209 5C52 A32A 1B6C

------------------------------------



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

--- In o...@yahoogroups.com, Brian Lloyd wrote:
>
> > If you are using an older chip (< C.1.1) then use V5. If you have
> > the newest chip, you have a problem. Perhaps someone else can get it
> > to work.
>
> I am getting to the point where I am wondering if it is worth it to
> keep going with the OOPic.

Don't take my test of V6 and oStepper as the gospel. I tried it and
it didn't work immediately. I gave up and tried V5. Since I have
only B.2.2+ there no reason for me to bother with V6. And I haven't...

It is likely that someone else can get this to work. It's just that I
have a short attention span - kind of like a 3d grader in that regard.
If it doesn't work, I take a different approach.

I really believe the Stamp is a better developed platform and there is
no question that the documentation is orders of magnitude better. But
there are issues: the servo pulses are not continuous and don't run in
the background. Same with PWM. The chip has to take a very bizarre
approach to doing analog input. Given a few moments, I could come up
with a long list of warts. But the warts are documented and working
examples are given.

With both devices there is a tradeoff between ease of programming and
sophistication of operation. There is nothing either of these devices
can do that can't be done a lot better with the same underlying chip
and 100 times as much programming effort.

As I mentioned much earlier in your posts, there is no motivation for
moving to C.1.1 or V6. It is much better to search around for B.2.2+
chips (www.junun.org?) and work with V5.

In terms of breadboarding an idea, nothing beats the OOPic. Whether
it sees the light of day in the final design is another issue. I have
3 or 4 OOPics (2 in Mark III controllers) and I play with them when I
want something down and dirty. When I want it to work, I move to the
ATmega128 or one of the ARM7 devices. But this isn't feasible for
your classes.

In my view, all of these controllers would be outgunned with one of
the high end Z80 clones running an enhanced version of Palo Alto Tiny
Basic. A few functions need to be written to interface with the
hardware gadgets and the rest of the programming is just like
timeshare Basic. It would be blistering fast (50 MHz, 1 clock per
simple instruction), interpreted and able to handle all of the IO
gadgets. Unfortunately, I am not motivated enough to do the work. I
did get PATB running on an EZ80F91 board but then moved on to
implement CP/M 2.2. CP/M would be an even better platform!

In the end, I just use the OOPic within its' limitations and am quite
happy with B.2.2+ and V5.

Richard

------------------------------------



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

On Apr 13, 2008, at 1:41 PM, rtstofer wrote:

> --- In o...@yahoogroups.com, Brian Lloyd wrote:
>>
>>> If you are using an older chip (< C.1.1) then use V5. If you have
>>> the newest chip, you have a problem. Perhaps someone else can get=20=20
>>> it
>>> to work.
>>
>> I am getting to the point where I am wondering if it is worth it to
>> keep going with the OOPic.
>
> Don't take my test of V6 and oStepper as the gospel. I tried it and
> it didn't work immediately. I gave up and tried V5. Since I have
> only B.2.2+ there no reason for me to bother with V6. And I=20=20
> haven't...
>
> It is likely that someone else can get this to work. It's just that I
> have a short attention span - kind of like a 3d grader in that regard.
> If it doesn't work, I take a different approach.

It wasn't your posting other than it is yet another data point for the=20=20
problems with the OOPic. We *KNOW* there are problems with the OOPic=20=20
and its development environment. How much have we gone over the=20=20
problems with events? And still there is no fix. I don't know about=20=20
you but if something of that magnitude had escaped from my shop, I=20=20
would have had the dev team set aside everything to get that fixed so=20=20
my customers could get back to work. And I would have kept my=20=20
customers apprised every step along the way so they would have some=20=20
visibility into both the importance and timeliness of the fix.

> I really believe the Stamp is a better developed platform and there is
> no question that the documentation is orders of magnitude better. But
> there are issues: the servo pulses are not continuous and don't run in
> the background. Same with PWM. The chip has to take a very bizarre
> approach to doing analog input. Given a few moments, I could come up
> with a long list of warts. But the warts are documented and working
> examples are given.

And I agree with you 100%. As an architecture, the BS2 is, well,=20=20
suboptimal. Integral A:D is really important to me and RCTIME is a=20=20
real hack as far as I am concerned. I am teaching kids about voltages=20=20
and turning them into numbers. Doing that with the BS2 is, well,=20=20
RCTIME sure gets in the way. I was teaching them about how capacitors=20=20
work and we did write a program to charge and discharge capacitors=20=20
through a resistor and measure voltage and time on a 'scope. (Yes, I=20=20
have 5th-8th graders breadboarding circuits and then watching how they=20=20
behave using an analog oscilloscope.) But doing A:D using RC timing is=20=20
just too much to digest at one time. True A:D where a given voltage is=20=20
a number is actually easy to understand and to do something with.

So I agree. As an *architecture* I *LIKE* the OOPic a lot more.

But can I trust it? When there are problems I need them to be the=20=20
student's problems, not the sytem's.

> With both devices there is a tradeoff between ease of programming and
> sophistication of operation. There is nothing either of these devices
> can do that can't be done a lot better with the same underlying chip
> and 100 times as much programming effort.

That I understand. No argument. I have written code in darned near=20=20
every programming language and assembler on a LOT of machines.

> As I mentioned much earlier in your posts, there is no motivation for
> moving to C.1.1 or V6. It is much better to search around for B.2.2+
> chips (www.junun.org?) and work with V5.

I know. But it is unfortunate that I ended up with almost all C.1.1+=20=20
chips. Frankly there wasn't anything to say, "DON'T GET THE NEW CHIPS;=20=20
THEY ARE BROKEN."

> In terms of breadboarding an idea, nothing beats the OOPic.

So far, I agree.

> Whether
> it sees the light of day in the final design is another issue. I have
> 3 or 4 OOPics (2 in Mark III controllers) and I play with them when I
> want something down and dirty. When I want it to work, I move to the
> ATmega128 or one of the ARM7 devices. But this isn't feasible for
> your classes.

Nope.

> In my view, all of these controllers would be outgunned with one of
> the high end Z80 clones running an enhanced version of Palo Alto Tiny
> Basic. A few functions need to be written to interface with the
> hardware gadgets and the rest of the programming is just like
> timeshare Basic. It would be blistering fast (50 MHz, 1 clock per
> simple instruction), interpreted and able to handle all of the IO
> gadgets. Unfortunately, I am not motivated enough to do the work. I
> did get PATB running on an EZ80F91 board but then moved on to
> implement CP/M 2.2. CP/M would be an even better platform!

I would tend to disagree. I come from that age, having actually=20=20
written a full emulation of the Z-80 on a Nanodata QM-1 (we needed it=20=20
to test the UCSD P-system on a Z-80) and built several working systems=20=20
from scratch using the M6800 (a much better chip than the 8080 in my=20=20
estimation and the equal to the Z-80 but I digress). OS-8, RT-11, CPM,=20=20
and then MS-DOS were all jokes insofar as operating systems were=20=20
concerned. (I list them together because that is their lineage.) If=20=20
you are going to do that then it is time to talk about a real OS that=20=20
provides preemptive task scheduling and decent message-passing=20=20
interprocess communications.

But this has nothing to do with the OOPic.

> In the end, I just use the OOPic within its' limitations and am quite
> happy with B.2.2+ and V5.

At this point I wish I had the option. My point is one about customer=20=20
service and support. I just don't see a lot of motion on Savage's part=20=20
to solve this problem. Sure we can change chips and work around the=20=20
problem but aren't we the customers? What happened to "customer=20=20
support?"

I was pondering the possibility of replacing the BS2's with OOPics in=20=20
some or all of our BoeBots. Not now.

I guess I am just frustrated by once again having to work around=20=20
someone else's problems.



--

Brian Lloyd Granite Bay Montessori
brian AT gbmontessori DOT com 9330 Sierra College Blvd.
+1.916.367.2131 (voice) Roseville, CA 95661, USA
http://www.gbmontessori.com

I fly because it releases my mind from the tyranny of petty things . . .
=97 Antoine de Saint-Exup=E9ry

PGP key ID: 12095C52A32A1B6C
PGP key fingerprint: 3B1D BA11 4913 3254 B6E0 CC09 1209 5C52 A32A 1B6C

------------------------------------



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

Hei guys thanks for the advice, but its kinda late for me to change=20
the chip, hmm i am indeed using the C.1.1+ version with the V6 oopic=20
compiler. I have checked the output with a multimeter, sometimes it=20
doesnt give me the logic that i want, if it does the only pin that=20
has the changing logic is the I/O port 12 the rest doesn't have any=20
change in their logic.

Anyone else tried with V6 and gotten a diff results? >.< My=20
presentation is tomorrow, so far only managed to get one of the=20
motors to move. izzit the board's problem or the software problem? I=20
did get a PIC16F877 from Oricom but i would have to start from=20
scratch again if the oopic doesn't work. >.< anyone got any better=20
solution?

Thanks for answering my enquries. Sorry if my online time is weird=20
due to the difference in timezone. Thanks in advance.

Minghui

--- In o...@yahoogroups.com, Brian Lloyd wrote:
>
>=20
> On Apr 13, 2008, at 1:41 PM, rtstofer wrote:
>=20
> > --- In o...@yahoogroups.com, Brian Lloyd wrote:
> >>
> >>> If you are using an older chip (< C.1.1) then use V5. If you=20
have
> >>> the newest chip, you have a problem. Perhaps someone else can=20
get=20=20
> >>> it
> >>> to work.
> >>
> >> I am getting to the point where I am wondering if it is worth it=20
to
> >> keep going with the OOPic.
> >
> > Don't take my test of V6 and oStepper as the gospel. I tried it=20
and
> > it didn't work immediately. I gave up and tried V5. Since I have
> > only B.2.2+ there no reason for me to bother with V6. And I=20=20
> > haven't...
> >
> > It is likely that someone else can get this to work. It's just=20
that I
> > have a short attention span - kind of like a 3d grader in that=20
regard.
> > If it doesn't work, I take a different approach.
>=20
> It wasn't your posting other than it is yet another data point for=20
the=20=20
> problems with the OOPic. We *KNOW* there are problems with the=20
OOPic=20=20
> and its development environment. How much have we gone over the=20=20
> problems with events? And still there is no fix. I don't know=20
about=20=20
> you but if something of that magnitude had escaped from my shop, I=20=20
> would have had the dev team set aside everything to get that fixed=20
so=20=20
> my customers could get back to work. And I would have kept my=20=20
> customers apprised every step along the way so they would have=20
some=20=20
> visibility into both the importance and timeliness of the fix.
>=20
> > I really believe the Stamp is a better developed platform and=20
there is
> > no question that the documentation is orders of magnitude=20
better. But
> > there are issues: the servo pulses are not continuous and don't=20
run in
> > the background. Same with PWM. The chip has to take a very=20
bizarre
> > approach to doing analog input. Given a few moments, I could=20
come up
> > with a long list of warts. But the warts are documented and=20
working
> > examples are given.
>=20
> And I agree with you 100%. As an architecture, the BS2 is, well,=20=20
> suboptimal. Integral A:D is really important to me and RCTIME is a=20=20
> real hack as far as I am concerned. I am teaching kids about=20
voltages=20=20
> and turning them into numbers. Doing that with the BS2 is, well,=20=20
> RCTIME sure gets in the way. I was teaching them about how=20
capacitors=20=20
> work and we did write a program to charge and discharge capacitors=20=20
> through a resistor and measure voltage and time on a 'scope. (Yes,=20
I=20=20
> have 5th-8th graders breadboarding circuits and then watching how=20
they=20=20
> behave using an analog oscilloscope.) But doing A:D using RC timing=20
is=20=20
> just too much to digest at one time. True A:D where a given voltage=20
is=20=20
> a number is actually easy to understand and to do something with.
>=20
> So I agree. As an *architecture* I *LIKE* the OOPic a lot more.
>=20
> But can I trust it? When there are problems I need them to be the=20=20
> student's problems, not the sytem's.
>=20
> > With both devices there is a tradeoff between ease of programming=20
and
> > sophistication of operation. There is nothing either of these=20
devices
> > can do that can't be done a lot better with the same underlying=20
chip
> > and 100 times as much programming effort.
>=20
> That I understand. No argument. I have written code in darned near=20=20
> every programming language and assembler on a LOT of machines.
>=20
> > As I mentioned much earlier in your posts, there is no motivation=20
for
> > moving to C.1.1 or V6. It is much better to search around for=20
B.2.2+
> > chips (www.junun.org?) and work with V5.
>=20
> I know. But it is unfortunate that I ended up with almost all=20
C.1.1+=20=20
> chips. Frankly there wasn't anything to say, "DON'T GET THE NEW=20
CHIPS;=20=20
> THEY ARE BROKEN."
>=20
> > In terms of breadboarding an idea, nothing beats the OOPic.
>=20
> So far, I agree.
>=20
> > Whether
> > it sees the light of day in the final design is another issue. I=20
have
> > 3 or 4 OOPics (2 in Mark III controllers) and I play with them=20
when I
> > want something down and dirty. When I want it to work, I move to=20
the
> > ATmega128 or one of the ARM7 devices. But this isn't feasible for
> > your classes.
>=20
> Nope.
>=20
> > In my view, all of these controllers would be outgunned with one=20
of
> > the high end Z80 clones running an enhanced version of Palo Alto=20
Tiny
> > Basic. A few functions need to be written to interface with the
> > hardware gadgets and the rest of the programming is just like
> > timeshare Basic. It would be blistering fast (50 MHz, 1 clock per
> > simple instruction), interpreted and able to handle all of the IO
> > gadgets. Unfortunately, I am not motivated enough to do the=20
work. I
> > did get PATB running on an EZ80F91 board but then moved on to
> > implement CP/M 2.2. CP/M would be an even better platform!
>=20
> I would tend to disagree. I come from that age, having actually=20=20
> written a full emulation of the Z-80 on a Nanodata QM-1 (we needed=20
it=20=20
> to test the UCSD P-system on a Z-80) and built several working=20
systems=20=20
> from scratch using the M6800 (a much better chip than the 8080 in=20
my=20=20
> estimation and the equal to the Z-80 but I digress). OS-8, RT-11,=20
CPM,=20=20
> and then MS-DOS were all jokes insofar as operating systems were=20=20
> concerned. (I list them together because that is their lineage.)=20
If=20=20
> you are going to do that then it is time to talk about a real OS=20
that=20=20
> provides preemptive task scheduling and decent message-passing=20=20
> interprocess communications.
>=20
> But this has nothing to do with the OOPic.
>=20
> > In the end, I just use the OOPic within its' limitations and am=20
quite
> > happy with B.2.2+ and V5.
>=20
> At this point I wish I had the option. My point is one about=20
customer=20=20
> service and support. I just don't see a lot of motion on Savage's=20
part=20=20
> to solve this problem. Sure we can change chips and work around=20
the=20=20
> problem but aren't we the customers? What happened to "customer=20=20
> support?"
>=20
> I was pondering the possibility of replacing the BS2's with OOPics=20
in=20=20
> some or all of our BoeBots. Not now.
>=20
> I guess I am just frustrated by once again having to work around=20=20
> someone else's problems.
>=20
>
>=20
> --
>=20
> Brian Lloyd Granite Bay Montessori
> brian AT gbmontessori DOT com 9330 Sierra College Blvd.
> +1.916.367.2131 (voice) Roseville, CA 95661, USA
> http://www.gbmontessori.com
>=20
> I fly because it releases my mind from the tyranny of petty=20
things . . .
> =97 Antoine de Saint-Exup=E9ry
>=20
> PGP key ID: 12095C52A32A1B6C
> PGP key fingerprint: 3B1D BA11 4913 3254 B6E0 CC09 1209 5C52 A32A=20
1B6C
>

------------------------------------



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

--- In o...@yahoogroups.com, Ian Drennan wrote:
>
> minghui1984 wrote:
> > SO anyone knows whats is wrong with the Iopack specifications? i
> > specified iopack 5 but it would not work. Other IOPacks also do
not
> > apply
> >
> > Minghui
> > --- In o...@yahoogroups.com, "minghui1984" wrote:
> >
> >> Dim A As New oStepper
> >> Dim B As New oStepper
> >>
> >>
> >> Sub Main()
> >>
> >> A.IOPack = 1
> >> B.IOPack = 5
> >> A.Rate = 10
> >> B.Rate = 10
> >> A.Operate = 1
> >> B.Operate = 1
> >> Do
> >> A.Distance = 100
> >> B.Distance = 30
> >> Wait Until A.NonZero = 0
> >> Wait Until B.NonZero = 0
> >> ooPIC.Delay = 1000
> >> A.Distance = -100
> >> B.Distance = -30
> >> Wait Until A.NonZero = 0
> >> Wait Until B.NonZero = 0
> >> ooPIC.Delay = 1000
> >> Loop
> >>
> >> End Sub
> >>
> >>
> Minghui
>
> I have just checked your code on my Oopic B 2.2+ chip on a S board
and
> it is working as expected.
> Have you checked the actual outputs of Pack1 and pack2 with a meter
or a
> scope?
> If you are reading a pulsed output (5 volts) on your Oopic on the
> relative Pack outputs, then your problem lies in the wiring to or
from
> your Motor Driver hardware.
>
> Ian
>
I have checked the outputs for pack 1 and its working, but for the
pins on pack 5 its not.... i measured using a multimeter, there is no
pulse from the pin 13-15 but there is one on pin 12 ... The pack 5
consists of pin 12-15

Minghui
------------------------------------



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

--- In o...@yahoogroups.com, Ian Drennan wrote:
>
> minghui1984 wrote:
> > SO anyone knows whats is wrong with the Iopack specifications? i
> > specified iopack 5 but it would not work. Other IOPacks also do not
> > apply
> >
> > Minghui
> > --- In o...@yahoogroups.com, "minghui1984" wrote:
> >
> >> Dim A As New oStepper
> >> Dim B As New oStepper
> >>
> >>
> >> Sub Main()
> >>
> >> A.IOPack = 1
> >> B.IOPack = 5
> >> A.Rate = 10
> >> B.Rate = 10
> >> A.Operate = 1
> >> B.Operate = 1
> >> Do
> >> A.Distance = 100
> >> B.Distance = 30
> >> Wait Until A.NonZero = 0
> >> Wait Until B.NonZero = 0
> >> ooPIC.Delay = 1000
> >> A.Distance = -100
> >> B.Distance = -30
> >> Wait Until A.NonZero = 0
> >> Wait Until B.NonZero = 0
> >> ooPIC.Delay = 1000
> >> Loop
> >>
> >> End Sub
> >>
> >>
> Minghui
>
> I have just checked your code on my Oopic B 2.2+ chip on a S board and
> it is working as expected.

With which compiler? I tried V6 and it didn't seem to work. It does
work with V5 and B.2.2+.

Richard

------------------------------------



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

There is nothing special about those IO lines. Try using oStepperSP
(which uses URCP) and see if that makes any difference. If you are on
C1.1+ firmware you are stuck with V.6, if you are on B2.2+ firmware then
you can try the V.5. I have escalated this problem to Scott as a
compiler bug.

DLC

minghui1984 wrote:
> --- In o...@yahoogroups.com, Ian Drennan wrote:
>
>> minghui1984 wrote:
>>
>>> SO anyone knows whats is wrong with the Iopack specifications? i
>>> specified iopack 5 but it would not work. Other IOPacks also do
>>>
> not
>
>>> apply
>>>
>>> Minghui
>>> --- In o...@yahoogroups.com, "minghui1984" wrote:
>>>
>>>
>>>> Dim A As New oStepper
>>>> Dim B As New oStepper
>>>>
>>>>
>>>> Sub Main()
>>>>
>>>> A.IOPack = 1
>>>> B.IOPack = 5
>>>> A.Rate = 10
>>>> B.Rate = 10
>>>> A.Operate = 1
>>>> B.Operate = 1
>>>> Do
>>>> A.Distance = 100
>>>> B.Distance = 30
>>>> Wait Until A.NonZero = 0
>>>> Wait Until B.NonZero = 0
>>>> ooPIC.Delay = 1000
>>>> A.Distance = -100
>>>> B.Distance = -30
>>>> Wait Until A.NonZero = 0
>>>> Wait Until B.NonZero = 0
>>>> ooPIC.Delay = 1000
>>>> Loop
>>>>
>>>> End Sub
>>>>
>>>>
>>>>
>> Minghui
>>
>> I have just checked your code on my Oopic B 2.2+ chip on a S board
>>
> and
>
>> it is working as expected.
>> Have you checked the actual outputs of Pack1 and pack2 with a meter
>>
> or a
>
>> scope?
>> If you are reading a pulsed output (5 volts) on your Oopic on the
>> relative Pack outputs, then your problem lies in the wiring to or
>>
> from
>
>> your Motor Driver hardware.
>>
>> Ian
>>
>>
> I have checked the outputs for pack 1 and its working, but for the
> pins on pack 5 its not.... i measured using a multimeter, there is no
> pulse from the pin 13-15 but there is one on pin 12 ... The pack 5
> consists of pin 12-15
>
> Minghui
> ------------------------------------



(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, Ian Drennan wrote:
> >
> > minghui1984 wrote:
> > > SO anyone knows whats is wrong with the Iopack specifications?
i
> > > specified iopack 5 but it would not work. Other IOPacks also do
not
> > > apply
> > >
> > > Minghui
> > > --- In o...@yahoogroups.com, "minghui1984"
wrote:
> > >
> > >> Dim A As New oStepper
> > >> Dim B As New oStepper
> > >>
> > >>
> > >> Sub Main()
> > >>
> > >> A.IOPack = 1
> > >> B.IOPack = 5
> > >> A.Rate = 10
> > >> B.Rate = 10
> > >> A.Operate = 1
> > >> B.Operate = 1
> > >> Do
> > >> A.Distance = 100
> > >> B.Distance = 30
> > >> Wait Until A.NonZero = 0
> > >> Wait Until B.NonZero = 0
> > >> ooPIC.Delay = 1000
> > >> A.Distance = -100
> > >> B.Distance = -30
> > >> Wait Until A.NonZero = 0
> > >> Wait Until B.NonZero = 0
> > >> ooPIC.Delay = 1000
> > >> Loop
> > >>
> > >> End Sub
> > >>
> > >>
> > Minghui
> >
> > I have just checked your code on my Oopic B 2.2+ chip on a S
board and
> > it is working as expected.
>
> With which compiler? I tried V6 and it didn't seem to work. It
does
> work with V5 and B.2.2+.
>
> Richard
>
my chip is C.1.1 and i am using V6... would the C.1.1 chip work with
the V5?
------------------------------------



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

--- In o...@yahoogroups.com, "rtstofer" wrote:

> > > SO anyone knows whats is wrong with the Iopack specifications?

I am running the code as posted.

Ver 6 Compiler.
Ver C.1.1 chip.

Works perfect!

http://www.youtube.com/watch?v=cZ-eoSWYssw

Scott Savage.
------------------------------------



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

--- In o...@yahoogroups.com, "rtstofer" wrote:
> > > SO anyone knows whats is wrong with the Iopack specifications?

I have now tested the code (as posted) with both the B.2.2+ and the
C.1.1.

Ver 6 Compiler:
Ver B.2.2+ chip: http://www.youtube.com/watch?v=ltEjI58wBE8
Ver C.1.1+ chip: http://www.youtube.com/watch?v=cZ-eoSWYssw

Works perfect!

Scott Savage.
------------------------------------



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

--- In o...@yahoogroups.com, Brian Lloyd wrote:
> If you are using an older chip (< C.1.1) then use V5. If you have
> the newest chip, you have a problem.

So far, not one error has been detected in the C.1.1 chip. In fact,
the purpose of this chip was to address the bugs identified in B.2.2.

There have been some bugs discovered in the new Ver 6 compiler, such as
the one in the event object. But these will be corrected when the
next compiler release is ready. (Expect it around May 1st.)

As for the IOPack issue in question... it appears to work just fine.
Or at least I cannot get it to NOT work. (See other posts) But since
you are advising the public: "If you have the newest chip, you have a
problem." then perhaps you can upload a youtube video showing what test
you performed to determine this, so that I can address the problem.

Scott Savage

------------------------------------



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

Scott has tested this program on both B2.2+ and C1.1+ and it works.
I'll get more details on his configuration - Is there something that you
are doing on the IOline 12-15 that you aren't on the other four IOlines,
or vice-versa? Is your V.6 the most recent release from the web site?

DLC

minghui1984 wrote:
> --- In o...@yahoogroups.com, "rtstofer" wrote:
>
>> --- In o...@yahoogroups.com, Ian Drennan wrote:
>>
>>> minghui1984 wrote:
>>>
>>>> SO anyone knows whats is wrong with the Iopack specifications?
>>>>
> i
>
>>>> specified iopack 5 but it would not work. Other IOPacks also do
>>>>
> not
>
>>>> apply
>>>>
>>>> Minghui
>>>> --- In o...@yahoogroups.com, "minghui1984"
>>>>
> wrote:
>
>>>>
>>>>
>>>>> Dim A As New oStepper
>>>>> Dim B As New oStepper
>>>>>
>>>>>
>>>>> Sub Main()
>>>>>
>>>>> A.IOPack = 1
>>>>> B.IOPack = 5
>>>>> A.Rate = 10
>>>>> B.Rate = 10
>>>>> A.Operate = 1
>>>>> B.Operate = 1
>>>>> Do
>>>>> A.Distance = 100
>>>>> B.Distance = 30
>>>>> Wait Until A.NonZero = 0
>>>>> Wait Until B.NonZero = 0
>>>>> ooPIC.Delay = 1000
>>>>> A.Distance = -100
>>>>> B.Distance = -30
>>>>> Wait Until A.NonZero = 0
>>>>> Wait Until B.NonZero = 0
>>>>> ooPIC.Delay = 1000
>>>>> Loop
>>>>>
>>>>> End Sub
>>>>>
>>>>>
>>>>>
>>> Minghui
>>>
>>> I have just checked your code on my Oopic B 2.2+ chip on a S
>>>
> board and
>
>>> it is working as expected.
>>>
>> With which compiler? I tried V6 and it didn't seem to work. It
>>
> does
>
>> work with V5 and B.2.2+.
>>
>> Richard
>>
>>
> my chip is C.1.1 and i am using V6... would the C.1.1 chip work with
> the V5?
> ------------------------------------



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

I've not tried this - But two others have and it didn't work for them
using the V.6 compiler - Is your V.6 compiler the same version as the
one on the web site?

DLC

scottmsavage wrote:
> --- In o...@yahoogroups.com, Brian Lloyd wrote:
>
>> If you are using an older chip (< C.1.1) then use V5. If you have
>> the newest chip, you have a problem.
>>
>
> So far, not one error has been detected in the C.1.1 chip. In fact,
> the purpose of this chip was to address the bugs identified in B.2.2.
>
> There have been some bugs discovered in the new Ver 6 compiler, such as
> the one in the event object. But these will be corrected when the
> next compiler release is ready. (Expect it around May 1st.)
>
> As for the IOPack issue in question... it appears to work just fine.
> Or at least I cannot get it to NOT work. (See other posts) But since
> you are advising the public: "If you have the newest chip, you have a
> problem." then perhaps you can upload a youtube video showing what test
> you performed to determine this, so that I can address the problem.
>
> Scott Savage
>
> ------------------------------------



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

On Apr 13, 2008, at 9:22 PM, scottmsavage wrote:

> --- In o...@yahoogroups.com, Brian Lloyd wrote:
>> If you are using an older chip (< C.1.1) then use V5. If you have
>> the newest chip, you have a problem.
>
> So far, not one error has been detected in the C.1.1 chip. In fact,
> the purpose of this chip was to address the bugs identified in B.2.2.

Great! But it doesn't work.

> There have been some bugs discovered in the new Ver 6 compiler, such=20=20
> as
> the one in the event object. But these will be corrected when the
> next compiler release is ready. (Expect it around May 1st.)

No doubt you are correct. Regardless, since the OOPic is a *system* it=20=20
doesn't matter where the problem is. The point is, the C.1.1+ and its=20=20
compiler do not work correctly as a system. For people trying to do=20=20
work with it, it doesn't work as it is supposed to.

> As for the IOPack issue in question... it appears to work just fine.
> Or at least I cannot get it to NOT work. (See other posts) But since
> you are advising the public: "If you have the newest chip, you have a
> problem." then perhaps you can upload a youtube video showing what=20=20
> test
> you performed to determine this, so that I can address the problem.

Well, one good thing my rant seems to have done: it seems to have=20=20
gotten your attention.

> Scott Savage

--

Brian Lloyd Granite Bay Montessori
brian AT gbmontessori DOT com 9330 Sierra College Blvd.
+1.916.367.2131 (voice) Roseville, CA 95661, USA
http://www.gbmontessori.com

I fly because it releases my mind from the tyranny of petty things . . .
=97 Antoine de Saint-Exup=E9ry

PGP key ID: 12095C52A32A1B6C
PGP key fingerprint: 3B1D BA11 4913 3254 B6E0 CC09 1209 5C52 A32A 1B6C

------------------------------------



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

snip
>> Minghui
>>
>> I have just checked your code on my Oopic B 2.2+ chip on a S board and
>> it is working as expected.
>>
>
> With which compiler? I tried V6 and it didn't seem to work. It does
> work with V5 and B.2.2+.
>
> Richard
>
>
All

My test was done using the latest Ver 6 copiler with no problem. I also
tested the code switching to all the Packs.
When Pack 6 is used, as it is only 3 bits wide, causes the classic
'Weggie' when the Phasing is NOT = 3. I can live with that even
if the IDE did not generate an error for the programming fault.

Ian

------------------------------------



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

Ian Drennan wrote:
> snip
>
>>> Minghui
>>>
>>> I have just checked your code on my Oopic B 2.2+ chip on a S board and
>>> it is working as expected.
>>>
>>>
>> With which compiler? I tried V6 and it didn't seem to work. It does
>> work with V5 and B.2.2+.
>>
>> Richard
>>
>>
> All
>
> My test was done using the latest Ver 6 copiler with no problem. I also
> tested the code switching to all the Packs.
> When Pack 6 is used, as it is only 3 bits wide, causes the classic
> 'Weggie' when the Phasing is NOT = 3. I can live with that even
> if the IDE did not generate an error for the programming fault.
>
> Ian
>
ooops!

"When Pack 6 is used, as it is only 3 bits wide, causes the classic
'Weggie' when the Phasing is NOT = 3"

This should read :

When Pack 6 is used, as it is only 2 bits wide on my chip (B2.2+),
causes the classic
'Weggie' irrespective of what Phasing Value is used. This is
understandable as it interferes with the dedicated USART pins.
I assume this would not be the case when using non SCP chips.
Ian

------------------------------------



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

hi not sure of what is wrong but when i entered the code on my C.1.1 on
the OObot from oricom tech. the output logic doesn't "come" out
properly.

Below is a video
http://www.youtube.com/watch?v=ARCwyBnGrSg

I tested the voltage output using a mulitmeter from pin 8-15 (i.e.
iopack 1 & 5) but the logic doesnt change in those pins.... anyone
knows any idea wat could be wrong?

Minghui

--- In o...@yahoogroups.com, "scottmsavage" wrote:
>
> --- In o...@yahoogroups.com, "rtstofer" wrote:
> > > > SO anyone knows whats is wrong with the Iopack specifications?
>
> I have now tested the code (as posted) with both the B.2.2+ and the
> C.1.1.
>
> Ver 6 Compiler:
> Ver B.2.2+ chip: http://www.youtube.com/watch?v=ltEjI58wBE8
> Ver C.1.1+ chip: http://www.youtube.com/watch?v=cZ-eoSWYssw
>
> Works perfect!
>
> Scott Savage.
>

------------------------------------



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

--- In o...@yahoogroups.com, "scottmsavage" wrote:
>
> --- In o...@yahoogroups.com, "rtstofer" wrote:
> > > > SO anyone knows whats is wrong with the Iopack specifications?
>
> I have now tested the code (as posted) with both the B.2.2+ and the
> C.1.1.
>
> Ver 6 Compiler:
> Ver B.2.2+ chip: http://www.youtube.com/watch?v=ltEjI58wBE8
> Ver C.1.1+ chip: http://www.youtube.com/watch?v=cZ-eoSWYssw
>
> Works perfect!
>
> Scott Savage.
>

Absolutely correct with V6 and B.2.2+. I have no explanation for why
I didn't see pulses on IOPack 5 during my brief test yesterday. I'm
using the same compiler and same Mark III board. It works perfectly
today...

Richard

------------------------------------



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

--- In o...@yahoogroups.com, Brian Lloyd wrote:
> No doubt you are correct. Regardless, since the OOPic is a *system*
it
> doesn't matter where the problem is. The point is, the C.1.1+ and
its
> compiler do not work correctly as a system.

Point taken, but in reality.... it does matter in that I can update
software via the web. Updating chips cost postage.

> Well, one good thing my rant seems to have done: it seems to have
> gotten your attention.

LOL
I suppose you are right about that.
------------------------------------



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

Hi,
It's been a while since I've used an OOPic so forgive me. I'm using the OOPic to run a DC
motor via the Magnevation dual control board. The code I'm using worked last time I used
this board. (a year ago at least) Now it's not. The motor does a small step each time I hit the
re-set on the OOPic. After testing and confirming the OOPic is working and has power etc. I
was wondering if someone could give me a clue what to check next. The mag board seems
okay and I've never had an issue with one before. I'll recompile the code again next to see if
that helps. Thanks!
D.

------------------------------------



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

Darrell,

If you are sure it is a code issue ie all connections have been checked
as well as logic and motor power then the first thing to do is post your
code here for us to see.

If this is the project I assisted you with several years ago, I may
still have source code on my PC.

A test you could perform would be to open a new code window and launch
the Sample program for the oDCMotorMGD. Alter the code to reflect your
pinouts etc.. and compile. If this is on the project I think it is
PLEASE break out a floor jack and get that thing off the ground. It
would really suck to have a several hundred pound robot on the loose in
the house...

Good Luck.

Ted Macy
Savage Innovations
www.oobug.com The next revolution in robotics...
--- In o...@yahoogroups.com, "Darrell" wrote:
>
> Hi,
> It's been a while since I've used an OOPic so forgive me. I'm using
the OOPic to run a DC
> motor via the Magnevation dual control board. The code I'm using
worked last time I used
> this board. (a year ago at least) Now it's not. The motor does a small
step each time I hit the
> re-set on the OOPic. After testing and confirming the OOPic is working
and has power etc. I
> was wondering if someone could give me a clue what to check next. The
mag board seems
> okay and I've never had an issue with one before. I'll recompile the
code again next to see if
> that helps. Thanks!
> D.
>

[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 )

Ted,
You old hamburger! Write me off list. Yes, it is the same project but OOpic will only be
used for one simple part of the bot now. A lot has changed. Everything seems to be
working so it must be the code. The motor turns but is ignoring the opto sensors. Tested
those and they're working. My next step was to try a sample program as u suggested. I'll
post the code I'm noodling.
Darrell

--- In o...@yahoogroups.com, "theo570" wrote:
> Darrell,
>
> If you are sure it is a code issue ie all connections have been checked
> as well as logic and motor power then the first thing to do is post your
> code here for us to see.
>
> If this is the project I assisted you with several years ago, I may
> still have source code on my PC.
>
> A test you could perform would be to open a new code window and launch
> the Sample program for the oDCMotorMGD. Alter the code to reflect your
> pinouts etc.. and compile. If this is on the project I think it is
> PLEASE break out a floor jack and get that thing off the ground. It
> would really suck to have a several hundred pound robot on the loose in
> the house...
>
> Good Luck.
>
> Ted Macy
> Savage Innovations
> www.oobug.com The next revolution in robotics...
> --- In o...@yahoogroups.com, "Darrell" wrote:
> >
> > Hi,
> > It's been a while since I've used an OOPic so forgive me. I'm using
> the OOPic to run a DC
> > motor via the Magnevation dual control board. The code I'm using
> worked last time I used
> > this board. (a year ago at least) Now it's not. The motor does a small
> step each time I hit the
> > re-set on the OOPic. After testing and confirming the OOPic is working
> and has power etc. I
> > was wondering if someone could give me a clue what to check next. The
> mag board seems
> > okay and I've never had an issue with one before. I'll recompile the
> code again next to see if
> > that helps. Thanks!
> > D.
> >
> [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 )

Here's what I've got.
/* Bubble Code */

oDCMotor bubble_motor = New oDCMotor;

oDIO1 bubble_fc_sensor1 = New oDIO1;
oDIO1 bubble_fc_sensor2 = New oDIO1;

Byte bubble_speed;
Byte bubble_stop_time;

Sub Void Main(Void)
{
bubble_speed = 255;
bubble_stop_time = 400;

initialize;

While(1)
{
If((bubble_fc_sensor1 == cvOn) & (bubble_fc_sensor2
== cvOn))
{
bubble_motor.Value = bubble_speed;

bubble_motor.Brake = cvOn;
ooPIC.Delay = 25;
bubble_motor.Brake = cvOff;
ooPIC.Delay = 50;
}
}
}

Sub Void initialize(Void)
{
ooPIC.Node = 3;

bubble_motor.IOLineP = 18;
bubble_motor.IOLineB = 24;
bubble_motor.IOLineD = 26;
bubble_motor.Operate = 1;
bubble_motor.Direction = 1;
bubble_motor.Unsigned = 1;
bubble_motor.Value = bubble_speed;
bubble_motor.PreScale = 3;
bubble_motor.Brake = cvOff;

bubble_fc_sensor1.IOLine = 12;
bubble_fc_sensor1.Direction = cvInput;
bubble_fc_sensor2.IOLine = 13;
bubble_fc_sensor2.Direction = cvInput;
}

--- In o...@yahoogroups.com, "Darrell" wrote:
>
> Ted,
> You old hamburger! Write me off list. Yes, it is the same project
but OOpic will only be
> used for one simple part of the bot now. A lot has changed.
Everything seems to be
> working so it must be the code. The motor turns but is ignoring the
opto sensors. Tested
> those and they're working. My next step was to try a sample program
as u suggested. I'll
> post the code I'm noodling.
> Darrell
>
> --- In o...@yahoogroups.com, "theo570" wrote:
> >
> >
> > Darrell,
> >
> > If you are sure it is a code issue ie all connections have been
checked
> > as well as logic and motor power then the first thing to do is
post your
> > code here for us to see.
> >
> > If this is the project I assisted you with several years ago, I
may
> > still have source code on my PC.
> >
> > A test you could perform would be to open a new code window and
launch
> > the Sample program for the oDCMotorMGD. Alter the code to reflect
your
> > pinouts etc.. and compile. If this is on the project I think it is
> > PLEASE break out a floor jack and get that thing off the ground.
It
> > would really suck to have a several hundred pound robot on the
loose in
> > the house...
> >
> > Good Luck.
> >
> > Ted Macy
> > Savage Innovations
> > www.oobug.com The next revolution in
robotics...
> >
> >
> > --- In o...@yahoogroups.com, "Darrell" wrote:
> > >
> > > Hi,
> > > It's been a while since I've used an OOPic so forgive me. I'm
using
> > the OOPic to run a DC
> > > motor via the Magnevation dual control board. The code I'm using
> > worked last time I used
> > > this board. (a year ago at least) Now it's not. The motor does
a small
> > step each time I hit the
> > > re-set on the OOPic. After testing and confirming the OOPic is
working
> > and has power etc. I
> > > was wondering if someone could give me a clue what to check
next. The
> > mag board seems
> > > okay and I've never had an issue with one before. I'll
recompile the
> > code again next to see if
> > > that helps. Thanks!
> > > D.
> > >
> >
> >
> >
> >
> > [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, "Darrell" wrote:
>
> Here's what I've got.
> /* Bubble Code */
>
> oDCMotor bubble_motor = New oDCMotor;
>
> oDIO1 bubble_fc_sensor1 = New oDIO1;
> oDIO1 bubble_fc_sensor2 = New oDIO1;
>
> Byte bubble_speed;
> Byte bubble_stop_time;
>
> Sub Void Main(Void)
> {
> bubble_speed = 255;
> bubble_stop_time = 400;
>
> initialize;
>
> While(1)
> {
> If((bubble_fc_sensor1 == cvOn) & (bubble_fc_sensor2
> == cvOn))
> {
> bubble_motor.Value = bubble_speed;
>
> bubble_motor.Brake = cvOn;
> ooPIC.Delay = 25;
> bubble_motor.Brake = cvOff;
> ooPIC.Delay = 50;
> }
> }
> }
>
>
>
> Sub Void initialize(Void)
> {
> ooPIC.Node = 3;
>
> bubble_motor.IOLineP = 18;
> bubble_motor.IOLineB = 24;
> bubble_motor.IOLineD = 26;
> bubble_motor.Operate = 1;
> bubble_motor.Direction = 1;
> bubble_motor.Unsigned = 1;
> bubble_motor.Value = bubble_speed;
> bubble_motor.PreScale = 3;
> bubble_motor.Brake = cvOff;
>
> bubble_fc_sensor1.IOLine = 12;
> bubble_fc_sensor1.Direction = cvInput;
> bubble_fc_sensor2.IOLine = 13;
> bubble_fc_sensor2.Direction = cvInput;
> }
>

Have you changed from V5 to V6? Those are very short delay values in
V6 which measures in milliseconds. V5 measured in 10 mS.

Richard

------------------------------------



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

Richard,
Thank you very much for responding. If you mean the newer compiler,
yes, I did. What should I put be using for the delay times? Could this
be why the sensors are being ignored?
Darrell
--- In o...@yahoogroups.com, "rtstofer" wrote:
>
> --- In o...@yahoogroups.com, "Darrell" wrote:
> >
> > Here's what I've got.
> > /* Bubble Code */
> >
> > oDCMotor bubble_motor = New oDCMotor;
> >
> > oDIO1 bubble_fc_sensor1 = New oDIO1;
> > oDIO1 bubble_fc_sensor2 = New oDIO1;
> >
> > Byte bubble_speed;
> > Byte bubble_stop_time;
> >
> > Sub Void Main(Void)
> > {
> > bubble_speed = 255;
> > bubble_stop_time = 400;
> >
> > initialize;
> >
> > While(1)
> > {
> > If((bubble_fc_sensor1 == cvOn) & (bubble_fc_sensor2
> > == cvOn))
> > {
> > bubble_motor.Value = bubble_speed;
> >
> > bubble_motor.Brake = cvOn;
> > ooPIC.Delay = 25;
> > bubble_motor.Brake = cvOff;
> > ooPIC.Delay = 50;
> > }
> > }
> > }
> >
> >
> >
> > Sub Void initialize(Void)
> > {
> > ooPIC.Node = 3;
> >
> > bubble_motor.IOLineP = 18;
> > bubble_motor.IOLineB = 24;
> > bubble_motor.IOLineD = 26;
> > bubble_motor.Operate = 1;
> > bubble_motor.Direction = 1;
> > bubble_motor.Unsigned = 1;
> > bubble_motor.Value = bubble_speed;
> > bubble_motor.PreScale = 3;
> > bubble_motor.Brake = cvOff;
> >
> > bubble_fc_sensor1.IOLine = 12;
> > bubble_fc_sensor1.Direction = cvInput;
> > bubble_fc_sensor2.IOLine = 13;
> > bubble_fc_sensor2.Direction = cvInput;
> > }
> > Have you changed from V5 to V6? Those are very short delay values in
> V6 which measures in milliseconds. V5 measured in 10 mS.
>
> Richard
>

------------------------------------



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

--- In o...@yahoogroups.com, "Darrell" wrote:
>
> Richard,
> Thank you very much for responding. If you mean the newer compiler,
> yes, I did. What should I put be using for the delay times? Could this
> be why the sensors are being ignored?
> Darrell
>

The delays are, under V6, 1/10 as long as before. We used to use
OOPic.Delay = 500 at startup to get a 5 second delay. Now the delay
is just 500 mS or 1/2 second.

Richard

------------------------------------



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

Thanks for the tip!
Darrell

--- In o...@yahoogroups.com, "rtstofer" wrote:
>
> --- In o...@yahoogroups.com, "Darrell" wrote:
> >
> > Richard,
> > Thank you very much for responding. If you mean the newer compiler,
> > yes, I did. What should I put be using for the delay times? Could this
> > be why the sensors are being ignored?
> > Darrell
> > The delays are, under V6, 1/10 as long as before. We used to use
> OOPic.Delay = 500 at startup to get a 5 second delay. Now the delay
> is just 500 mS or 1/2 second.
>
> Richard
>

------------------------------------



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

I've added longer delays but the sensors are still being ignored. Any
other suggestions anyone?

/* Bubble Code */

oDCMotor bubble_motor = New oDCMotor;

oDIO1 bubble_fc_sensor1 = New oDIO1;
oDIO1 bubble_fc_sensor2 = New oDIO1;

Byte bubble_speed;
Byte bubble_stop_time;

Sub Void Main(Void)
{
bubble_speed = 255;
bubble_stop_time = 400;

initialize;

While(1)
{
If((bubble_fc_sensor1 == cvOn) & (bubble_fc_sensor2 == cvOn))
{
bubble_motor.Value = bubble_speed;
bubble_motor.Brake = cvOn;
ooPIC.Delay = 3000;
bubble_motor.Brake = cvOff;
ooPIC.Delay = 5000;
}
} }

Sub Void initialize(Void)
{
ooPIC.Node = 3;
bubble_motor.IOLineP = 18;
bubble_motor.IOLineB = 24;
bubble_motor.IOLineD = 26;
bubble_motor.Operate = 1;
bubble_motor.Direction = 1;
bubble_motor.Unsigned = 1;
bubble_motor.Value = bubble_speed;
bubble_motor.PreScale = 3;
bubble_motor.Brake = cvOff;

bubble_fc_sensor1.IOLine = 12;
bubble_fc_sensor1.Direction = cvInput;
bubble_fc_sensor2.IOLine = 13;
bubble_fc_sensor2.Direction = cvInput;
}
------------------------------------



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

--- In o...@yahoogroups.com, "Darrell" wrote:
>
> I've added longer delays but the sensors are still being ignored. Any
> other suggestions anyone?

Maybe the & operator should be &&.

Richard
>
> /* Bubble Code */
>
> oDCMotor bubble_motor = New oDCMotor;
>
> oDIO1 bubble_fc_sensor1 = New oDIO1;
> oDIO1 bubble_fc_sensor2 = New oDIO1;
>
> Byte bubble_speed;
> Byte bubble_stop_time;
>
> Sub Void Main(Void)
> {
> bubble_speed = 255;
> bubble_stop_time = 400;
>
> initialize;
>
> While(1)
> {
> If((bubble_fc_sensor1 == cvOn) & (bubble_fc_sensor2 == cvOn))
> {
> bubble_motor.Value = bubble_speed;
> bubble_motor.Brake = cvOn;
> ooPIC.Delay = 3000;
> bubble_motor.Brake = cvOff;
> ooPIC.Delay = 5000;
> }
> } }
>
> Sub Void initialize(Void)
> {
> ooPIC.Node = 3;
> bubble_motor.IOLineP = 18;
> bubble_motor.IOLineB = 24;
> bubble_motor.IOLineD = 26;
> bubble_motor.Operate = 1;
> bubble_motor.Direction = 1;
> bubble_motor.Unsigned = 1;
> bubble_motor.Value = bubble_speed;
> bubble_motor.PreScale = 3;
> bubble_motor.Brake = cvOff;
>
> bubble_fc_sensor1.IOLine = 12;
> bubble_fc_sensor1.Direction = cvInput;
> bubble_fc_sensor2.IOLine = 13;
> bubble_fc_sensor2.Direction = cvInput;
> }
>

------------------------------------



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

Thanks Richard. I'll give it a go.
Darrell
--- In o...@yahoogroups.com, "rtstofer" wrote:
>
> --- In o...@yahoogroups.com, "Darrell" wrote:
> >
> > I've added longer delays but the sensors are still being ignored. Any
> > other suggestions anyone?
>
> Maybe the & operator should be &&.
>
> Richard
> >
> > /* Bubble Code */
> >
> > oDCMotor bubble_motor = New oDCMotor;
> >
> > oDIO1 bubble_fc_sensor1 = New oDIO1;
> > oDIO1 bubble_fc_sensor2 = New oDIO1;
> >
> > Byte bubble_speed;
> > Byte bubble_stop_time;
> >
> > Sub Void Main(Void)
> > {
> > bubble_speed = 255;
> > bubble_stop_time = 400;
> >
> > initialize;
> >
> > While(1)
> > {
> > If((bubble_fc_sensor1 == cvOn) & (bubble_fc_sensor2 == cvOn))
> > {
> > bubble_motor.Value = bubble_speed;
> > bubble_motor.Brake = cvOn;
> > ooPIC.Delay = 3000;
> > bubble_motor.Brake = cvOff;
> > ooPIC.Delay = 5000;
> > }
> > } }
> >
> > Sub Void initialize(Void)
> > {
> > ooPIC.Node = 3;
> > bubble_motor.IOLineP = 18;
> > bubble_motor.IOLineB = 24;
> > bubble_motor.IOLineD = 26;
> > bubble_motor.Operate = 1;
> > bubble_motor.Direction = 1;
> > bubble_motor.Unsigned = 1;
> > bubble_motor.Value = bubble_speed;
> > bubble_motor.PreScale = 3;
> > bubble_motor.Brake = cvOff;
> >
> > bubble_fc_sensor1.IOLine = 12;
> > bubble_fc_sensor1.Direction = cvInput;
> > bubble_fc_sensor2.IOLine = 13;
> > bubble_fc_sensor2.Direction = cvInput;
> > }
>
------------------------------------



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

Well, the double &'s didn't work. I'm going to have to try something
else. It's very odd. For a minute I thought it was working as the
motor stopped when the sensors hit a gap(s) but it turned out it was
simply a coincindence due to the delays and the motor just happened to
stop at the right place a few times in a row. I thank you again for
your suggestions though!
Darrell
--- In o...@yahoogroups.com, "Darrell" wrote:
>
> Thanks Richard. I'll give it a go.
> Darrell
> --- In o...@yahoogroups.com, "rtstofer" wrote:
> >
> > --- In o...@yahoogroups.com, "Darrell" wrote:
> > >
> > > I've added longer delays but the sensors are still being
ignored. Any
> > > other suggestions anyone?
> >
> > Maybe the & operator should be &&.
> >
> > Richard
> >
> >
> > >
> > > /* Bubble Code */
> > >
> > > oDCMotor bubble_motor = New oDCMotor;
> > >
> > > oDIO1 bubble_fc_sensor1 = New oDIO1;
> > > oDIO1 bubble_fc_sensor2 = New oDIO1;
> > >
> > > Byte bubble_speed;
> > > Byte bubble_stop_time;
> > >
> > > Sub Void Main(Void)
> > > {
> > > bubble_speed = 255;
> > > bubble_stop_time = 400;
> > >
> > > initialize;
> > >
> > > While(1)
> > > {
> > > If((bubble_fc_sensor1 == cvOn) & (bubble_fc_sensor2 == cvOn))
> > > {
> > > bubble_motor.Value = bubble_speed;
> > > bubble_motor.Brake = cvOn;
> > > ooPIC.Delay = 3000;
> > > bubble_motor.Brake = cvOff;
> > > ooPIC.Delay = 5000;
> > > }
> > > } }
> > >
> > > Sub Void initialize(Void)
> > > {
> > > ooPIC.Node = 3;
> > > bubble_motor.IOLineP = 18;
> > > bubble_motor.IOLineB = 24;
> > > bubble_motor.IOLineD = 26;
> > > bubble_motor.Operate = 1;
> > > bubble_motor.Direction = 1;
> > > bubble_motor.Unsigned = 1;
> > > bubble_motor.Value = bubble_speed;
> > > bubble_motor.PreScale = 3;
> > > bubble_motor.Brake = cvOff;
> > >
> > > bubble_fc_sensor1.IOLine = 12;
> > > bubble_fc_sensor1.Direction = cvInput;
> > > bubble_fc_sensor2.IOLine = 13;
> > > bubble_fc_sensor2.Direction = cvInput;
> > > }
> > >
>
------------------------------------



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

--- In o...@yahoogroups.com, "Darrell" wrote:
>
> Well, the double &'s didn't work. I'm going to have to try something
> else. It's very odd. For a minute I thought it was working as the
> motor stopped when the sensors hit a gap(s) but it turned out it was
> simply a coincindence due to the delays and the motor just happened to
> stop at the right place a few times in a row. I thank you again for
> your suggestions though!
> Darrell

I guess I would dump the if, endif part and see if the motor control
works at all.

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, "Darrell" wrote:
> >
> > Well, the double &'s didn't work. I'm going to have to try something
> > else. It's very odd. For a minute I thought it was working as the
> > motor stopped when the sensors hit a gap(s) but it turned out it was
> > simply a coincindence due to the delays and the motor just happened to
> > stop at the right place a few times in a row. I thank you again for
> > your suggestions though!
> > Darrell
>
> I guess I would dump the if, endif part and see if the motor control
> works at all.
>
> Richard
>

I don't have any idea how, electrically, the sensors work. If they
are just switches pulling the IOLine to ground, is there a pull-up
resistor? If not, use OOPic.PullUp = cvTrue which works on IOLines
8..15 when they are used as inputs.

So, break the problem into two pieces: test the switches and display
the results on an LED and test the motor code without the switches
being evaluated.

Richard

------------------------------------



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

May 1st has come and gone... New compiler?

--- In o...@yahoogroups.com, "scottmsavage" wrote:
>
> --- In o...@yahoogroups.com, Brian Lloyd wrote:
> > If you are using an older chip (< C.1.1) then use V5. If you have
> > the newest chip, you have a problem.
>
> So far, not one error has been detected in the C.1.1 chip. In
fact,
> the purpose of this chip was to address the bugs identified in
B.2.2.
>
> There have been some bugs discovered in the new Ver 6 compiler,
such as
> the one in the event object. But these will be corrected when the
> next compiler release is ready. (Expect it around May 1st.)
>
> As for the IOPack issue in question... it appears to work just
fine.
> Or at least I cannot get it to NOT work. (See other posts) But
since
> you are advising the public: "If you have the newest chip, you have
a
> problem." then perhaps you can upload a youtube video showing what
test
> you performed to determine this, so that I can address the problem.
>
> Scott Savage
>

------------------------------------



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