Pulsing a pin

Newzed · 2006-06-25 19:43

I hve hopes of using the Propeller to run my little SuperMill which is presently controlled by a BS2E.

I modified my frequency generator program as follows:

cycle:= 500
travel = 100
· DirA[noparse][[/noparse]OutPin] := Out
· Repeat travel
·· repeat 104
··· !OutA[noparse][[/noparse]OutPin]·········· 'Toggles at cycle rate
··· WaitCNT(cycle + CNT)

I·ran it four times and got answers of 5107, 5236, 5209 and 5198 pulses.· My mill must receive a pulse train of 5156 pulses, plus or minus 2 pulses, to travel 100 mils, which makes the Propeller output I am getting unacceptable.· Is there any way to get a very precise and consistent number of pulses for what ever travel I enter?

Thanks

Sid

CJ · 2006-06-25 19:55

the number of pulses is mathematically generated, and shouldn't change,

What are you using to measure the pulses, and is there a specific timeframe in which the pulses are to be delivered?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Who says you have to have knowledge to use it?

I've killed a fly with my bare mind.

Newzed · 2006-06-25 20:32

The pulses are generated on Pon 6.· Pin 6 is tied to Pin 5.· Here is the sequence that counts the pulses received on Pin 5:

term.out(13)·························
· DirA[noparse][[/noparse]InPin] := In·················
· CTRA := 0································ 'Clear CTRA settings···········································
· CTRA := (%01010 << 26 ) | (%001 << 23) | (0 << 9) | (InPin) 'Trigger to count
··························································· 'rising edge on InPin······································· ' edge on pin
· FRQA := 1000····························· 'Count 1000 each trigger
·
··· term.Str(string("Travel of "))················ 'Display string on LCD
··· PHSA := 0································ 'Clear accumulated value
··· WaitCNT( clkfreq + CNT )·············· 'Wait for 1 second
··· Frequency := PHSA / 1000················· 'Calculate···frequency·
··· term.Dec(travel)······························ 'based on duration
··· term.str(string(" = "))
··· term.dec(frequency)
··· term.Str(string(" pulses"))··················· 'Display string on LCD
··· term.out(13)

The time frame is determined in part by the number of pulses I want to generate.· On the BS2E I wrote:

pulsout pin, 10

which is 20us for each pulse.··With code overhead it takes about 3 seconds to travel 100 mils.· Time frame is also dependent on the rotational speed of my stepper.

Sid

CJ · 2006-06-25 21:02

could you post your code, I have an idea what might be going on and would like to poke at it a bit

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Who says you have to have knowledge to use it?

I've killed a fly with my bare mind.

Newzed · 2006-06-25 21:51

CJ, i cleaned everything up and created a new program which I have attached.· Now if I enter a travel of 100 I always get 5049.· However, if I enter 200 I get 10249 instead of the·10098 I was expecting.· If I enter 300 I get 15449 instead of the 15147 I was expecting.· It would be great if you can help.· I could never run my mill with the pulse count I am getting.

Sid

Post Edited (Newzed) : 6/25/2006 10:10:25 PM GMT

Newzed · 2006-06-25 23:43

CJ, here is something else.

A cycle of 500 = clkfreq/160_000.· This tells me I should be able to get a max of 160_000 toggles per second which is equivalent to a max pulse count of 80_000 Hz.· The max number of pulses I can get if the program counts for "waitcnt(clkfreq + cnt)" is about 22455, which is equivalent to about 44910 toggles per second.· Is this correct or am I missing something?

Sid

CJ · 2006-06-26 00:18

that should be about the right number of toggles per second taking into account the program overhead,

I think the angle of attack needed for this problem is getting the right formula for calculating the correct number of pulses total rather than a given freq

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Who says you have to have knowledge to use it?

I've killed a fly with my bare mind.

CJ · 2006-06-26 00:47

I think I have it straightened out using the floatmath object, attached is the code I came up with

edit: have not actually tested the code, as I don't yet have a keyboard attached

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Who says you have to have knowledge to use it?

I've killed a fly with my bare mind.

Post Edited (CJ) : 6/26/2006 12:57:02 AM GMT

pjv · 2006-06-26 02:27

Hi Newzed;

I'm not positive of this as I don't profess to be an expert in the Spin language, but I suspect that interfacing reasonably fast real life signals is somewhat incompatible with the relatively slow and unpredictable timing of executing Spin code.

What I am positive of is that an assembly routine, while more complicated to write, is able to perform the required functions accurately and repeatedly.

If you could run one Cog in assembler to measure the pulses, and one assembler Cog to generate the pulses, all can be perfect. The other Cogs could be used to do non-realtime things like your display etc.

Let us know if you need some help creating the assembly routines.

Cheers,

Peter (pjv)

Newzed · 2006-06-26 14:40

For CJ and pjv -

CJ, I ran the program you attached and it seems to work.· A couple of things - when I ran the program the screen displayed:

Travel of 1120403456 = 5156 pulses

The pulse count is OK but I have no idea where that big number came from.· So.......i changed the program as follows:

·'floatmath to use the per mil value of 51.56
· y := travel····· 'inserted this line
· travel := fp.ffloat(travel)
· 'term.out(13)

and

PHSA := 0································ 'Clear accumulated value
··· WaitCNT( clkfreq*4 + CNT )·············· 'Wait for·4 seconds
··· Frequency := PHSA / 1000·················
··· term.str(string("Y travel of· "))
··· term.Dec(y)························· ·'y was travel
··· term.str(string(" mils = "))········ 'added mils
··· term.dec(frequency)
··· term.Str(string(" pulses"))

Now the TV displays:

Y travel of· 100 mils = 5156 pulses

Also please note that I had to increase the count time to 4 seconds to display the pulses for a travel of 1000 mils.

Peter, if you could·change whatever is necessary to assembly, that would be fantastic.· I do not understand assembly so·any sequence where I choose an option or where I have to control the keyboard or TV would have to be in Spin.· I have attached the program and all the objects it uses for your convenience and·to make sure we are working with the same code.

Sid

Newzed · 2006-06-26 14:49

CJ and Peter - I forgot to mention.

I have changed the program as follows:

DirA[noparse][[/noparse]OutPin] := Out
·· repeat pulsetrain
··· !OutA[noparse][[/noparse]OutPin]·········· 'Toggles at cycle rate
··· WaitCNT(cycle + CNT)
··· !OutA[noparse][[/noparse]OutPin]······
··· WaitCNT(cycle + CNT)
· if kb.getkey······················· 'added this line
··· waitcnt(clkfreq/100 + cnt)· 'changed waitcnt

Now the TV displays until I press any key, then it clears the screen and goes back to the first repeat after start and displays the starting menu again.

Sid

CJ · 2006-06-26 19:33

the large number is from the conversion to floating point, and reusing the same variable

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Who says you have to have knowledge to use it?

I've killed a fly with my bare mind.

SSteve · 2006-06-26 20:43

Newzed said...
My mill must receive a pulse train of 5156 pulses, plus or minus 2 pulses, to travel 100 mils, which makes the Propeller output I am getting unacceptable. Is there any way to get a very precise and consistent number of pulses for what ever travel I enter?

It sounds like it's the number of pulses that is critical, not the frequency. Is that correct? Creating a specific number of pulses is easy. You've already done it. This code:

repeat pulsetrain
    !OutA[noparse][[/noparse]OutPin]           'Toggles at cycle rate
    WaitCNT(cycle + CNT)
    !OutA[noparse][[/noparse]OutPin]       
    WaitCNT(cycle + CNT)

will generate a number of pulses equal to pulsetrain. All you need to do is find a value for cycle that generates a frequency that's acceptable to your mill. I think the errors you are seeing are related to the measurement, not the generation. The measurement routine you're using was created to measure frequency, not count, so it's not the appropriate tool to use in your situation.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
OS-X: because making Unix user-friendly was easier than debugging Windows

links:
My band's website
Our album on the iTunes Music Store

Newzed · 2006-06-27 14:57

I have mentioned that I was concerned about the difference in time ibn the output of the Stamp and the Propeller when they are both given the same travel values.

This morning I hooked up my Optascope and took a screen shot of the Stamp output and the Prop output.· The pictures are attached.· Settings on the scope were the same for both.· The width of the pulse on the Stamp output as about 29us and the delay between pulses was about 1330us.· I do not know what generates the delay - maybe that is code overhead.· Obviously, I could not measure the Prop output

The Stamp output is what actually runs the mill steppers, so I have to get the Prop output looking the same as the Stamp.· This means that instead of toggling the Prop output I will have to take it high for about 25us, then low for about 1300us.· Also, I no longer need to count the output - I have counted it enough to know that the output is correct for the amount of travel entered.· So I will see if I can disable the counting function without interfering with the rest of the program.

Sid

Newzed · 2006-06-27 15:49

I took this sequence:

DirA[noparse][[/noparse]OutPin] := Out
·· repeat pulsetrain
··· !OutA[noparse][[/noparse]OutPin]·········· 'Toggles at cycle rate
··· WaitCNT(cycle + CNT)
··· !OutA[noparse][[/noparse]OutPin]······
··· WaitCNT(cycle + CNT)

and modified it to read:

DirA[noparse][[/noparse]OutPin] := Out
·· repeat pulsetrain
··· OutA[noparse][[/noparse]OutPin] := 1·········· 'Toggles at cycle rate
··· WaitCNT(cycle + CNT)
··· OutA[noparse][[/noparse]OutPin] := 0······
··· WaitCNT(cycle*178 + CNT)

A picture of the resultant Prop output is attached.· Pulse width is about 30us and the delay between pulses is about 1330us.

Sid

SSteve · 2006-06-27 15:50

Do you have any type of data sheet for the mill? It would be a lot easier to approach the problem knowing what the input specifications were. You can attempt to match the BS2 program's output, but you might be placing artificial restrictions on yourself. Maybe the mill is only looking for positive-going pulses and you don't need to worry about duty cycle.

Do you have the PBASIC code that's currently working with the mill? If so, that would also eliminate a lot of guesswork.

Newzed said...
I will see if I can disable the counting function without interfering with the rest of the program.

Just remove the lines that start and stop the MeasureFrequency cog. You can also remove or comment out the MeasureFrequency method.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
OS-X: because making Unix user-friendly was easier than debugging Windows

links:
My band's website
Our album on the iTunes Music Store

Newzed · 2006-06-27 16:31

There are no specs for the mill.· It is an MF-70 purchased from Proxxon and originally came with handwheels on the three axes.· I have modified it· by replacing the handwheels with an adapter that will receive the shaft of a stepper motor and then I wrote the program to make it do what I want.· My point is that if the Stamp outputs runs the steppers properly, then the same output from the Prop should also run the steppers properly.

Sid

SSteve · 2006-06-27 17:09

Newzed said...
My point is that if the Stamp outputs runs the steppers properly, then the same output from the Prop should also run the steppers properly.

There's no arguing that. I just thought there might be a way to generate acceptable input to the mill without having to exactly match the Stamp output that would be easier to program. But that point is moot because it looks like you've got what you need. Have you tried hooking it up to the mill yet?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
OS-X: because making Unix user-friendly was easier than debugging Windows

links:
My band's website
Our album on the iTunes Music Store

Newzed · 2006-06-27 18:00

SSteve, I'm a long way from hooking it up to the mill, which is out in the shop.· I would have to move everything out there, which could be done but I have to TV out there.· I can't move the one I'm using in here because it also monitors the little TV camera pointed at my driveway.· I still have a lot of programming to do.· Right now, I'm working on the Z axis.· When I select D(own) and enter the travel, I want it to repeat the Down/travel sequence until I press "x".· This is necessary because when I lower a cutter or drill, the final positioning is critical and sometimes I have to lower it 5 or 10 mills at a time.· I don't want to go thru the Select axis/Select direction sequences everytime I want to move it a tiny bit.

Sid

Newzed · 2006-06-28 17:39

We are making good progress with our Propeller mill program - the latest version is pulsout_F.

The entire program is now menu-driven, and we added a new cog for the Z axis.· We also added a sequence to drill a hole.· Assuming the drill is positioned where you want it and that the height of the drill above the PC board is set at about .060, if you press "d", the drill goes down 185 mils, pauses for 500ms, then goes up 185 mils and returns to the start menu.· Next effort will be to add a sequence to drill holes for a SIP or DIP, with a varying number of holes and a varying width.· I still have about 9900 bytes of memory left.

I have attached a copy of pulsout_F in case you would like to take a look at it.· You will need a keyboard and a TV connected if you want to run it.

Sid

Pulsing a pin

Comments