irin command in a sub procedure

[Maleny]

I am trying to get a 14M2 to align a stepper motor based on breaking an IR beam. I am going to a sub procedure containing an irin command before each step but the stepper is not working because despite what the simulation shows the program is not returning from the sub procedure. The timeout works OK and if I replace the irin command with a pause it steps OK. If I place the gosub after each step I get the first step only then those coils remain energized. The only hint I can find is a comment under parallel tasking referring to irin as a command which uses "total core precessing".

 

[SAborn]

Post your code as there might be an problem with it.

You do have a "Return" at the end of your sub procedure, dont you?

 

[inglewoodpete]

When you need to run 2 time-critical foreground tasks, the simplest solution is to use two PICAXEs. Have one as the IR receiver/buffer and the other doing the stepper motor control. The IR receiver/buffer (Eg 08M2) would alert the motor controller when it has received an IR command. The motor controller would than request the data when it is ready and the data could be quickly transferred using serial.

As SAB has requested, post more retails of your circuit and code so that we can get a better idea of the issues.

Edit: On re-reading your post, I see that you are only using the IR as a break-beam switch. 1. You wouldn't use IRIn in that case. 2. How are you modulating the IR sender?

 

[Maleny]

When you need to run 2 time-critical foreground tasks, the simplest solution is to use two PICAXEs. Have one as the IR receiver/buffer and the other doing the stepper motor control. The IR receiver/buffer (Eg 08M2) would alert the motor controller when it has received an IR command. The motor controller would than request the data when it is ready and the data could be quickly transferred using serial.

As SAB has requested, post more retails of your circuit and code so that we can get a better idea of the issues.

Edit: On re-reading your post, I see that you are only using the IR as a break-beam switch. 1. You wouldn't use IRIn in that case. 2. How are you modulating the IR sender?

A separate Picaxe is constantly transmitting an IR signal via an LED and the timeout occurs when the beam is broken. As you say a receiver buffer may well be a better way to go but I am interested in why this doesn't work.

Here is the code.

b1 = 10				'ms pause

dirsb = %00011110						
								
				

main:
	gosub bag
	let pins = %00010010			'coils 1 and 4
	gosub bag	
	let pins = %00010000			'coil 4
	gosub bag
	let pins = %00011000			'coils 3 and 4
	gosub bag	
	let pins = %00001000			'coil 3
	gosub bag	
	let pins = %00001100			'coils 2 and 3
	gosub bag	
	let pins = %00000100			'coil 2
	gosub bag	
	let pins = %00000110			'coils 1 and 2
	gosub bag	
	let pins = %00000010			'coil 1
	goto main



bag:
	irin [10, alarm],C.1,b2
	pause b1
	return
	
	
alarm:
	high B.0
	pause 500
	low B.0
	pause 500
	goto main

 

[inglewoodpete]

A separate Picaxe is constantly transmitting an IR signal via an LED and the timeout occurs when the beam is broken.

It's still not clear to me what the transmitter is sending. Is it sending just a clean 38khz to 40khz signal (constant square wave) or is it sending 'characters'/commands via the irout or infraout command?

To answer your question, yes your code is the problem. You do a "Gosub bag" and a return when you receive an IR command but if there is a timeout, you do two gotos to get back to the main loop. This fails to clear the gosub stack.

Solution: at the end of the "Alarm" routine, replace the "Goto Main" with "Return".

 

[SAborn]

What is b2 meant to do anyway?

Should that not also be ..... let pinsB = %00010010 'coils 1 and 4 ....... and not just all pins.

Why not exit "Alarm" with a return, as why do you jump back to "main" with a goto, as that is only messing up your stepper sequence, it be better to return to the next step sequence in order.

 

[Maleny]

Thanks for your suggestions I will study them and alter my code accordingly. The answers is B2 = 100 but it doesn't matter what the digit is, the object was to test the beam and use the timeout to detect when it was broken.

What is b2 meant to do anyway?

Should that not also be ..... let pinsB = %00010010 'coils 1 and 4 ....... and not just all pins.

Why not exit "Alarm" with a return, as why do you jump back to "main" with a goto, as that is only messing up your stepper sequence, it be better to return to the next step sequence in order.

 

[SAborn]

The answers is B2 = 100 but it doesn't matter what the digit is, the object was to test the beam and use the timeout to detect when it was broken.

Ok, i had thought that might have been the case, why not use B2 and test the condition, because then you can allow for things like a tree branch blowing into the beam, or perhaps a weed growing and affected by the wind. (like happens to me)

Nothing worst than a system that just keeps beeping, and false triggering, its nice if it shuts up after a while.
Granted its a IR beam for a reason of control, but when it fails or is obstructed, it can drive you mad and do some unexpected functions like in your case with the stepper motor. (not good at 3.00am in the morning)

Another problem you might be having, is some IR detectors switch off if its a repetitive IR data stream, you havent told us what IR sensor you are using.

What distance is the IR beam monitoring.

 

[westaust55]

Keep in mind that timeout works on the basis that no signal has been received.
If the IR LED sends garbage that may still be enough to be see as a signal and prevent the timeout functioning.

 

[SAborn]

Good point Westy, as it could be just sunlight at the right angle that can cause a lockout if the IR beam, or strange readings, the 38khz carrier signal dont solve all problems in all conditions.