pulsin question

[69-cat]

I am working on a 3 position switch to control a few devices on an RC plane and I can only get 2 out of 3 to work. What ever I do, the pulsing 150 will not work. I am sure it is something simple that I am over looking, any help would be great. Don't let the file name fool you......
Dave

View attachment simpleswitch.b.bas

 

[premelec]

main:

Not sure what you are up to - but you likely want to use a range If >X AND <Y THEN sort of thing... 

'debug
pulsin 3,1,w0

if w0> 120 then
	high 4
else
	low 4
endif
if w0> 150 then
	high 0
else
	low 0
endif
if w0> 180 then
	high 1
else
	low 1
	endif
goto main

 

[hippy]

The way you have your code, if w0 > 180 and that works, the IF w0 > 150 condition would also have been met so output 0 should have been set high. If that's not being observed then it may be related to what your circuit is.

Output 0 will not go high and remain high if you are using an 08M2 and have the DEBUG included, as that uses Pin 0 ( Serial Out ) for communicating with the PC.

 

[69-cat]

Yes, the code that was posted was my last save but I tried all of the other outputs and monitored the serial through Pin 0, this was just one of those tries to see. The data that was being monitored and the action on the outputs were working great with the exception of the 150 condition. I even tried other outputs on the receiver knowing that was not the problem but wanted to make sure.
Dave

 

[hippy]

I would suggest making the IF w0 > 150 set pin 2 high or low, and check if that works as expected.

Include the DEBUG command to check that w0 is greater than 150. If pin 2 is going high when w0 is greater than 150 the code is working as expected. If pin 2 isn't going high then there is something very odd going on.

 

[69-cat]

I am using this code to turn on sections of a nav light system for rc airplane that I designed and this part of the code will be controlling the lighting with resume/restart/suspend. I guess the thing that has me puzzled, to test my control part of the code I used READADC with the same setup just changing the type of input and it works fine, but when I changed to the PULSIN, that is where I lost my W0>150 condition
Dave

 

[srnet]

Always helpful to explain what is actually happening.

You say "the pulsing 150 will not work", but what do you mean, what does or does not happen ????

 

[hippy]

to test my control part of the code I used READADC with the same setup just changing the type of input and it works fine, but when I changed to the PULSIN, that is where I lost my W0>150 condition

Perhaps the PULSIN is wrong. You are reading active high pulses; perhaps you should be reading active low. What values does the DEBUG command report ? Are they as expected ?

 

[69-cat]

Yes they are, I am currently working with the code now and the values read 96 to 207 and are correct when the 2 conditions are met but what ever I do, the middle value does not work. I even entered a fourth value and the only condition that works is the lowest and the highest value!
Dave

 

[rossko57]

Perhaps if you detailed what pattern you expect to see on the output pins, and what you get instead.
The code snippet gives me four different output combinations for values of w0. Did you take in premelec's and hippy's comment that w0 > 150 also satisfies w0 > 120 and so both output conditions will be applied in turn?

 

[premelec]

@69-cat Have you got an actual chip in play where you can put an LED on each pin and check that? In the past I've found debug not giving me what I expect... Ed#5

 

[69-cat]

The code is only the "logic" part of the whole code and the whole code works great using the READADC input but I loose that one logic control once I convert over to the PULSIN inputs.

Yes, I am using a proto board with LEDs as the outputs. I have tried other LEDs, used my scope to check if there is any activity on the output and even a different 08m2 chip. I might try a 14m2 later today just for fun. The debug data is correct when running the code and it is spot on when the other 2 outputs come on. I have moved the values to other pins, changed values and even changed the high-low state and still nothing on the middle condition. Just don't get it!
Dave

 

[hippy]

Just don't get it!

It does appear you have an "impossible situation". There has to be some systemic issue which is causing the behaviour but it's not easy to see what that may be.

You can try running this which will check which parts of the code are being executed ...

#Picaxe 08M2
#Terminal 4800
main:
pulsin 3,1,w0
SerTxd(CR,LF,"w0=",#w0,9)
if w0> 120 then
	SerTxd(">  120",9)
else
	SerTxd("<= 120",9)
endif
if w0> 150 then
	SerTxd(">  150 **",9)
else
	SerTxd("<= 150   ",9)
endif
if w0> 180 then
	SerTxd(">  180")
else
	SerTxd("<= 180")
endif
goto main

Run that and check it does show "> 150 **" when w0 is greater than 150.

 

[hippy]

I used my scope to check if there is any activity on the output and even a different 08m2 chip.

So what did the scope show ? And which pin were you testing ?

Try running the following code with 'X' replaced by the pin number. Does the scope show that pin toggling ? Is a connected LED+R flashing ?

Do
  Pause 250 : Toggle X
Loop

Test for all pins; 0, 1, 2 and 4. Do they all work, all flash a LED+R ?

 

[69-cat]

I was testing the output pin in question and no activity. I did quickly check the working outputs and was getting voltage. I will try both of your test code later today and give you the findings.
Dave

 

[rossko57]

You're going to have to give us more, we cannot see what you see. "no activity" - so was that steady high or low? "getting voltage" - we can guess that might mean a steady high - perhaps - guessing doesn't help though.

It might be significant that the 'problem' output is also the serial output of an 08M2. "Out/Prog" Link on the proto board?

 

[69-cat]

I have used all of the output pins and still get the same response. The code that was posted using c.0 was the last change before I saved. The original code used c.o tied into the jack for programming, c.1, c.2 and c.4 as outputs and c.3 as the input. Only 2 outputs go high/enable while using the PULSIN control while changing the values/condition at the input. I only changed and used the c.0 just to see if that output would go high/enable but turned off the debug option but still only 2 outputs went high/enable.
Dave

 

[hippy]

I have used all of the output pins and still get the same response.

So what is the result of the test code suggested in posts #13 and #14 ?

We are not going to get anywhere fast going round the "does not work, tried changing things, still does not work" loop. We have to discover what exactly does or does not work, need to focus on isolating where the problem is.

There is nothing wrong with the program I can see, unless you are expecting only one LED to ever be on at a time, so it should be working.

 

[69-cat]

For good or bad, here it goes.....OK here is the outcome.......ran hippy's test using the serial feedback and all 3 outputs responded with each condition.
Decided to try 14m2 just for grins, raised the lever on my ZIF socket and 2 of the pins fell off the chip. I would have never thought a brand new chip would have broken legs!!!!!! No I am not joking, I was so pissed off I spent 4 days playing with this before I even posted anything on the forum because I like to learn from my mistakes well I learned a big one here. I installed a new chip and it works just like I and all of you thought it should. I feel so stupid! I could have just said "IT WORKS" but thought I would state my errors to the world!
Thanks to all that gave me feedback
Dave

 

[premelec]

@69-cat - sorry about all the wasted time - however I'm a guy who likes to know how things fail - did the pins break at the skinny to fat place or the fat to plastic package? I've seen both at times - usually from excessive flexing but not impossible as a manufacturing defect... Thanks...

 

[69-cat]

Both were the leg meets the wider part of the leg. That was the reason why I build my proto board with that socket due to the fact of chips being inserted and removed. Funny thing is when I have a code that works I use another chip for that project so the same chip stays in the socket for most of the time. I guess the intermitting connection was just enough and my pin outs go to a header so if I had just pressed the probe on the leg in the socket, the connection would have been made and I would found the problem day one or day two.
Dave