More questions about Webbot's library

[Cristi_Neagu]

Hello.

I wanted to ask two things:

1. Where can i declare persistent variables?
I need some variables that don't change from iteration to iteration of appcontrol. Also i need them to be accessible from other procedures. Which brings us to the next question:

2. Where can i declare procedures and functions?

I tried declaring them in appinitsoftware, but in the case of the variables i get "unused variable" in appinitsoftware and "variable not declared" in appcontrol. I expect this is normal behavior. And, yes, i have the latest version of the library and i use webbot's project designer to generate the hardware.h file

Thanks.

Thanks.

[Webbot]

The use of the library doesn't change how you do this - you just do it like you always would in a C program - ie define any global variables and functions outside of any other function.

[Cristi_Neagu]

I see. Thanks for the reply

[Cristi_Neagu]

Back again with one more question:

In the documentation for the library, it says that the PWM timer frequency can only be set once. I am using an Axon. Is this because of how the ATmega 640 works, or is it because of the library? Is there a way to get around this?

Also, has anyone developed a procedure to output variable frequency signals? I'm trying to do one just now, but since i'm new at programming with AVR studio, i'd rather be spoon fed for once

Thanks.

[jackp]

Probably not the most efficient, accurate or eloquent but can't you drive variable freq signals in appcontrol.  Set the pin high/low depending on the frequency you want with clockGetus(..) and a pre-cached CLOCK_TICK value?

You can probably also use the timer.h routines as well.

Jack

[Webbot]

PWM is exactly that - Pulse WIDTH modulation.

Its almost impossible to satisfactorily add Frequency Modulation on top of Pulse Width Modulation as a generic routine. Why? Well a given timer only has one pre-scaler but may have say 3 output channels. Since all channels share the same pre-scaler then all the channels would need to generating 'roughly' the same frequency range.

But here's the big problem. The same timer could be used for other things as well - say like a measured pulse to a servo, or as the system clock. These are all happy co-existing but then you say multiply the frequency by 1000. This would need a timer pre-scaler change and, in turn, this would mess up everything else.

So its 'easy in theory' but complex in practice.

However: I think you may be asking this question with regard to driving stepper motors via an L297 where one pulse = one step. In which case, IMHO, you shouldn't be using PWM or any other form of automatic signal generation to drive the motors anyway-  particularly if you don't have encoders. As this means you have no idea how many pulses have been sent. You are far better off just toggling the output pin yourself. You could of course do this via the scheduler if you want it to keep happening in the background.

[Cristi_Neagu]

Thanks for the replies.

But here's the big problem. The same timer could be used for other things as well - say like a measured pulse to a servo, or as the system clock. These are all happy co-existing but then you say multiply the frequency by 1000. This would need a timer pre-scaler change and, in turn, this would mess up everything else.

So its 'easy in theory' but complex in practice.

I see... Changing the prescaler of one timer could mes everything up...

Probably not the most efficient, accurate or eloquent but can't you drive variable freq signals in appcontrol.  Set the pin high/low depending on the frequency you want with clockGetus(..) and a pre-cached CLOCK_TICK value?

You can probably also use the timer.h routines as well.

Jack

However: I think you may be asking this question with regard to driving stepper motors via an L297 where one pulse = one step. In which case, IMHO, you shouldn't be using PWM or any other form of automatic signal generation to drive the motors anyway-  particularly if you don't have encoders. As this means you have no idea how many pulses have been sent. You are far better off just toggling the output pin yourself. You could of course do this via the scheduler if you want it to keep happening in the background.

Yes, I am trying to drive a stepper with the L297 And i'm trying to do exactly what you two suggested. The procedure goes like this:

Code: [Select]

-set the pin to high and get current time and store it in variable t1;
-set a variable t2 = t1 + duty period(us);
-set a variable t2 = t1 + period(us);
-if current time >= t2 then pin_low;
-if current time >= t3 then goto top;

Of course, i mean to implement this in a procedure, something on the lines of motor1.refresh(). It would get called up from time to time, while other thigs are happening in the background. I don't think it will be an issue, because i plan to run my motors at a top frequency of 500-600Hz. More than that and they stall.
I will also look into the scheduler idea.

Thanks for the help.

[Admin]

Webbot, did you ever implement the software PWM in the library?

Basically the software PWM for servos, but allowing the option to fully modify the square wave (frequency and duty cycle).

[Webbot]

Webbot, did you ever implement the software PWM in the library?

Basically the software PWM for servos, but allowing the option to fully modify the square wave (frequency and duty cycle).

Quick answer is 'no' - See my previous post in this thread 

Its easy enough to do, and could be achieved by anyone using the lower level calls in timer.h for their specific needs - but trying to make it generic is a bit more tricky. For example: you would not be able to have two such outputs, on the same timer, if one was a very high frequency and the other was a very low frequency since the outputs use the same timer and hence the same prescaler. So in order for the lib to know how best to set up the timer(s), prescaler(s) etc in 'appInitHardware' you would need to declare the min and max frequencies you are expecting to use on each channel in the MAKE constructor.

There are other nuances. Such as: if you change the frequency would you want the duty cycle to remain as the same percentage or would you want the 'on', or the 'off', time to remain the same (where possible) or should it cope with all 3 situations?

Finally (and since this thread was originally talking about stepper motors) then I think you be able add a 'count down' counter. ie if you want to send 1000 pulses to the motor to make it turn a given angle then it should stop sending any more pulses once its done 1000.

[Cristi_Neagu]

Things to consider:
1. Depending on the stepper motor, you can rarely get it past 1000Hz (1000 steps per second). With my steppers, the most i got was 500Hz. Is 0Hz-500Hz too wide of a frequency range for starters?

2. I don't know how easy it would be for, say, me to do it using lower level calls. I just got started programing after a 2 year break. And back then i was programming in Pascal, so i'm also learning C at the moment.

3. If the L297 is used for generating the stepping sequence, as in my case, you only need to vary the period of the signal. The duty cycle can remain constant (as a percent), or the high time of the pin can remain constant (in useconds). The minimum up time for the L297 is 0.5us, according to the datasheet.
It is irrelevant for the L297 what happens with the duty cycle. The step occurs on the rising edge of the signal. So as long as the duty cycle is above 0.5us, it doesn't matter.
If you're not using an L297, and use 4 pins on the controller to drive the windings directly... Then you need a fix percentage duty cycle (i guess about 85-90% or whereabouts). But driving a stepper like this requires at least 2 timers to work in relationship. I don't even want to think what that involves.
For starters, one can focus on the L297.

4. The counter idea is a good one, but it represents the reason why steppers aren't used in industrial robotics applications. You would thing that if you send 20 impulses to a stepper, it does 20 steps. It could... It definitely should. The fact is that it sometimes slips. So in power applications you need to add encoders. And if you add encoders, you might as well use brushless DC servos, as they're easier to control (although they require a breaking system). But for our normal everyday use, it should work perfectly.

I'd like to see something like this implemented. But i am being realistic. I know that i don't yet have the skills to write something like that, and that you people probably have better things to do than write code all day long. But if either you, Webbot, or somebody else, starts working on such a procedure, i'd be glad to assist with whatever i can do, as well as testing.

Thanks.

[Webbot]

@Cristi - Thanks for the comments. Will add to my 'list'.

I think that Admins request to have variable frequency and variable duty cycle was for another reason - not stepper motors.

Hence the problem of one code solution for 'all' problems. But then thats my problem....

[Admin]

4. The counter idea is a good one, but it represents the reason why steppers aren't used in industrial robotics applications. You would thing that if you send 20 impulses to a stepper, it does 20 steps. It could... It definitely should. The fact is that it sometimes slips. So in power applications you need to add encoders. And if you add encoders, you might as well use brushless DC servos, as they're easier to control (although they require a breaking system). But for our normal everyday use, it should work perfectly.

Steppers skip because the person who selects the stepper didn't bother determining the required torque first

They also avoid steppers because of the vibration.

And yea, Webbot is right - it'll be too much work to make a 'one size fits all' software PWM.