Puzzling differences between PUB / PRI variables

lardom

"Global variables initialize to zero." I read that rule yesterday and moved all my local variables to the VAR block because I was seeing strange values displayed on the PST. I then lost the ability to make my steppers start and stop at the same time. I didn't see why I was having problems right away because I rename objects "V1, V2 and so on whenever I add new features and I was looking for a typo. I eventually made the variables local again.
I'm working on differentially steering two steppers and I was trying to add a ramping feature. It appears that if you use cognew then you should stick with local variables if timing is important.
Can anyone explain why local variables are not zero by default?

Phil Pilgrim (PhiPi)

Global variables exist in fixed locations and are initialized during upload or when EEPROM data is transferred to hub RAM upon reset. Local variables exist on the stack, and their locations change dynamically as a result. It would take extra program steps for the interpreter to re-zero them every time a method is called.

-Phil

lardom

@Phil Pilgrim, Thanks. It was frustrating because the values were clearly not clocks or bytes.

Dave Hein

lardom wrote: »

It appears that if you use cognew then you should stick with local variables if timing is important.

I don't undertand that statement. You can do accurate timing with VAR variables, just like you can with local variables. The first 8 longs in VAR space can be accessed with a more compact bytecode versus the rest of VAR space. This is true of local variables as well, where RESULT is one of the 8 variables. And I don't see how it relates to cognew.

Heater.

I was wondering what goes on here as well.

My guess is that the same method is being started in the same object more than once. As such the variables being moved out of local (to the method) now exist in one instance in VAR and the two running instances of the method are fighting over them.

This is probably nothing to do with initializing to zero or not.

Can't tell unless we see the code.

lardom

@Dave and Heater, it made no sense to me either. I modified what I wrote but I'll try to reproduce both cases. It would be better if I zip the two files. I'll post them in a bit.
My object causes two steppers with a wheelbase of 13" to travel in an arc of a given radius. Pi (Tau) is used in the equation and the two steppers start and stop at the same time. I used cognew for both motors. I tried to add a ramping feature in "Version 3" which I'm working on right now.

lardom

I attached the two files. In the file that does not work properly pins [12..15] run a while longer. I couldn't duplicate it but pins [8..11] sped up when [12..15] had completed. I wondered if it was because variables were being shared. (I call the methods 'Ray...' because Rayman wrote a stepper object that did not require coils to be pulsed in multiples of four. I have to give him credit.) I commented out the ramping code since the main snippet didn't work right.

Dave Hein

I don't see anything wrong with the stack version, except that the cog variable used by Stop is never set to anything. The VAR version has problems because both cogs are using the same variables. VAR variables are allocated for each instance of the object, and not for each cog.

lardom

@Dave Hein, thanks for taking a look at them.

The VAR version has problems because both cogs are using the same variables. VAR variables are allocated for each instance of the object, and not for each cog.

I didn't know that. That is major information.
I don't follow what you mean by "...cog variable isn't set to anything". I do remember an issue where the motor pulses seemed to get weaker and I thought a value was overflowing but I couldn't find the source of the problem. I wonder if that was the cause.

Dave Hein

You have a VAR variable named "cog". It is tested in the Stop method, and if it is nonzero you do a cogstop(cog). Since "cog" is a VAR variable it is initialized to zero, and there is no where in your code where you set it to any other value. So the Stop method doesn't really do anything because of this. The "cog" variable has nothing to do with the motor pulses.

lardom

@Dave Hein, Thanks for your patience! I never copied the cog id to the cog variable when I made the cognew command and in the Stop method I should've written "(cog~ - 1)".

Dave Hein

Yes, that makes sense. You will need 2 different cog variables, and 2 different Stop methods.

lardom

@Dave Hein, I'll name the methods "DHLS" and "DHRS". (Left Stop, Right Stop)