Picaxe Editor 6.0.6.2 simulation issue

fastgrandad

New Member
Time variable doesn't seem to increment in simulation and neither does a dependant variable, suggesting that the clock isn't running. Following simple loop illustrates the problem. It runs fine in version 5.5.6

let time=0
do
b1=time
loop


Should have added, time isn't incrementing in Code Explorer

Paul
 
Last edited:

Technical

Technical Support
Staff member
Thanks, this is a known issue that has actually already been fixed for the next release.
 

hobbit

New Member
Timer variable still not fixed or new bug?

Thanks, this is a known issue that has actually already been fixed for the next release.
I found this thread which is several years old now, suggesting that there had been a problem but has since been fixed.

I've encountered exactly the same problem in version 6.0.9.3, using (simulating) a Picaxe 20M2.

(It did run briefly and intermittently, but I can't reproduce that now!)
This code shows w0 remaining at 0, the "System" variable "time" remains at 0, but w1 counts up madly.
Code:
       enabletime
x:
	w0=time
	inc w1
	goto x
 

BESQUEUT

Senior Member
I found this thread which is several years old now, suggesting that there had been a problem but has since been fixed.

I've encountered exactly the same problem in version 6.0.9.3, using (simulating) a Picaxe 20M2.

(It did run briefly and intermittently, but I can't reproduce that now!)
This code shows w0 remaining at 0, the "System" variable "time" remains at 0, but w1 counts up madly.
Code:
       enabletime
x:
	w0=time
	inc w1
	goto x
Already responded by technical :
Time is simulated by Picaxe loops count !
So, as simulation is many many times slower than real PIcaxe, Time increment but very very slowly (so you do not see it)

I have asked many many times for a parameter to chose for
- a Picaxe loops simulation (as actual)
- a real time simulation as many many hope...

hint : it "may ?" run differently if a PAUSE command is used in your code... Nonsense with the technical explanation...
 

Technical

Technical Support
Staff member
Time in incrementing fine, it just takes several hundred loops to simulate unless you also have a pause in your loop. e.g. pause 100 will mean you only need 10 loops before 1 second elapses

Code:
       enabletime
x:
    w0=time
    pause 100
    inc w1
    goto x
 

hobbit

New Member
Time in incrementing fine, it just takes several hundred loops to simulate unless you also have a pause in your loop. e.g. pause 100 will mean you only need 10 loops before 1 second elapses
Thank you, this little tip made all the difference.
My code is fairly complex, it has a great many things to do and because it is interacting with real-world events on an analog input, the code is in small blocks that run quickly, then return to the main supervisory loop.
There isn't any scope for delays in the final version (except for a few hundreds-of-microseconds delays while generating external sync and sequencing commands) - which probably explains how I got a few timer increments.

I've now added a temporary pause 100 as you suggest for the simulation and although slow, I can now confirm that my time-based code segments are running properly.

It's a big ask, and probably beyond the scope of the product, but is there a way for me to determine (short of actually building and testing real-world hardware), exactly how long a given piece of code will take to execute?
EG, if I have a section of code that executes on condition 'x', I'd like to know exactly how many microseconds that would take at a given processor clock speed.
(Knowing that, I can determine just how long I need to make a synchronising signal from another device, and be certain it will be caught - without making it any longer than necessary. I don't want to send 100ms sync if 3ms will do!)
 

Buzby

Senior Member
There's a long running thread about why it's difficult to calculate ( or even measure ) the execution times of PICAXE instructions.

See it here : http://www.picaxeforum.co.uk/showthread.php?17782-PICAXE-program-Size-Optimisations-and-Speed

OT : In that thread is this quote from hippy :
... I'm sure everyone has made some change or other that should be simple but has brought their world crashing down on them. ...
Today I had this in my inbox : https://physicsfootnotes.com/footnotes/hyatt-regency-collapse/
 

hobbit

New Member
There's a long running thread about why it's difficult to calculate ( or even measure ) the execution times of PICAXE instructions.
Thanks for that. Interesting thread, and the pdf/results.

In my (specific) case, the commands executed will be known in advance, and I would anticipate adding a margin for device variability and environmental factors anyway, so getting "close" would be enough.
I guess I'll just need to build them, add add some markers in code (assert a pin at start of code block, and clear it at end), then use the DSO to know just how long that takes to execute.
Add 20% or so for safety, then use that on the sending device.

Appreciate the assistance!
R.
 

BESQUEUT

Senior Member
In my (specific) case, the commands executed will be known in advance, and I would anticipate adding a margin for device variability and environmental factors anyway, so getting "close" would be enough.
I guess I'll just need to build them, add add some markers in code (assert a pin at start of code block, and clear it at end), then use the DSO to know just how long that takes to execute.
Add 20% or so for safety, then use that on the sending device.
R.
This is exactly what I like to do !
Main loop (and entire program) are supposed to have no pause command.
First measure mail loop time whith DSO.
Second have a main loop counter.
Then, what have to be done "as soon as possible" is done each loop.
Other "less urgents" things are done each modulo N loops.
 
Top