Editor locking up during simulation

Gramps

Gramps

Senior Member
Good morning,
Why would the Editor crash while testing code?

Code: 
#picaxe 28x2
#no_data
#no_table

symbol xb0 = b0 ' reserved for bit variables
symbol bReverseForward=bit1 ' 0=reverse,=forward
symbol bMotorState=bit0     ' 0=off,1=on
symbol REVERSE_=0
symbol FORWARD_=1
Symbol desired_pot_value = b1
Symbol feedback_pot_value = b3
Symbol diff=b4
Symbol  desired_pot = B.5
Symbol  feedback_pot = B.4
Symbol MOTOR = B.0' Energize PWM
Symbol Direction = B.7
Symbol MAXPWMVALUE = 399
Symbol bSlowState=bit2
Symbol old_feedback_value= b5
Symbol old_desired_value= b6
Symbol ENDSTOP_A  = 35 ; desired_pot MINimum value
Symbol ENDSTOP_C = 180 ; desired_pot MAXimum value
;Lower shoulder min=35 max=210
;Upper shoulder min=?? max=???

Main:
  Readadc Desired_pot, desired_pot_value
    Desired_pot_value = Desired_pot_value MIN ENDSTOP_A MAX ENDSTOP_C
    'sertxd (#desired_pot_value," ",#b1,13,10)
    Readadc feedback_pot, feedback_pot_value
   ' sertxd (#feedback_pot_value," ",#b3,13,10)
  'sertxd("Desired/Feedback: ",#desired_pot_value," ",#feedback_pot_value,13,10)
  If old_feedback_value<>feedback_pot_value or old_desired_value<> desired_pot_value then
  old_feedback_value=feedback_pot_value
  old_desired_value=desired_pot_value
  sertxd("Desired/Feedback: ",#desired_pot_value," ",#feedback_pot_value,13,10)
endif
if desired_pot_value > feedback_pot_value then
   diff=desired_pot_value - feedback_pot_value
   else
   diff=feedback_pot_value - desired_pot_value
endif
if diff < 12 then ' from 11 below a match to 11 above
  if bMotorState=1 then
    if diff > 4 then ' this value may need to be set experimentally
      if bSlowState = 0 then
        bSlowState = 1 ' note that we are in the "slow speed" state
        pwmout MOTOR, 199, 300 ' slow down to half speed (change to 100 if necessary)
      endif
    else
      pwmout MOTOR, OFF ' STOP
      bMotorState=0
      bSlowState = 0
    endif
  endif
else ' motor must be set for proper direction and then activated
  if  desired_pot_value > feedback_pot_value then
    if bReverseForward = REVERSE_ then
      high Direction ' go forward
      bReverseForward = FORWARD_
    endif
  elseif  desired_pot_value < feedback_pot_value then
    if bReverseForward = FORWARD_ then
      low Direction ' go in reverse
      bReverseForward = REVERSE_
  endif
  endif
  if bMotorState=0 then
    bMotorState=1
    pwmout MOTOR, 199, MAXPWMVALUE' rotate Reverse
  endif
endif

goto main
Hippy : Corrected the code tags
 
Last edited by a moderator:
PhilHornby

PhilHornby

Senior Member
If the problem persists (after a reboot), you can always remove Windows Updates - and they should get re-applied later. Or you can use System Restore to take the PC back to a known good point. I recently had cause to do this on my Windows 10 system, after an update broke all manner of things. It takes hours :(

Let us know if you need help tracking down these options in the GUI ...
 
K

kfjl

Member
I can't see the sense in simulation. It doesn't stop you putting wires in the wrong holes on your breadboard.
Editor 5.5 doesn't have the IL problem that Editor 6 had (and probably still does). IL is short for Intermediate Language, which is short for Microsoft Intermediate Language.
Them again....
 
lbenson

lbenson

Senior Member
kfjl said:
I can't see the sense in simulation
Click to expand...
Learning to use the simulator is probably the greatest aid for a beginning PICAXE Basic programmer--you can single step to see exactly what your program flow is, which many beginners have a poor handle on.

And if you can successfully simulate your program before you start wiring things up, you if you run into problems, it's more likely to be your wiring than your code.
 
lbenson

lbenson

Senior Member
Gramps--note that if you enclose your code in the tags, "[ code]" and "[ /code]" (with no spaces), any formatting (indenting) you had will be preserved. (And note that indenting is good to help readers understand your code--and also to help you understand it if you look at it at a later time.)
 
hippy

hippy

Technical Support
Staff member
kfjl said:
I can't see the sense in simulation. It doesn't stop you putting wires in the wrong holes on your breadboard.
Click to expand...
No it doesn't. But it's great for testing code, to see if it works as hoped for, checking outputs will be doing what they are meant to be doing, before that code is downloaded to an actual PICAXE chip. And, if it doesn't work, it helps the user figure out why not.

I find Simulation a great way to demonstrate short programs for others, showing they do work by using SERTXD, without even having a PICAXE connected.

kfjl said:
Editor 5.5 doesn't have the IL problem that Editor 6 had (and probably still does). IL is short for Intermediate Language, which is short for Microsoft Intermediate Language.
Click to expand...
I am not sure what that IL problem PE6 supposedly had but it has all worked fine for me.

I liked PE5, it took me a while to get used to PE6, but I wouldn't go back as PE6 offers far more than EP5 did.
 
K

kfjl

Member
When I was trying to get PE6 to work with linux, I got a pop-up window telling me there was an error in the IL code. I didn't get that with PE5.

As for the simulator, I wasn't expecting anyone to agree with me. But even in a classroom, it wouldn't be of much use without a teacher.
I use axepad, and if I felt the need for a simulator, it would probably mean I'm out of my depth.

No one else has posted the same problem as Gramps, so maybe a reboot did the trick for him.
 
hippy

hippy

Technical Support
Staff member
kfjl said:
When I was trying to get PE6 to work with linux, I got a pop-up window telling me there was an error in the IL code. I didn't get that with PE5.
Click to expand...
That's hardly unexpected. Windows code doesn't run on native Linux, just as Linux code doesn't run on native Windows, and it can be quite difficult to get anything to run on a non-native platform.

One could argue that it's more the fault of tools on Linux, lack of experienced know-how, which prevents PE6 running there than PE6 itself, but, no, no one so far has managed to get PE6 to run on Linux. PE5 usually can but that is because it is based upon old, deprecated technology.
 
Buzby

Buzby

Senior Member
I've got PE6 6.1.0.0 running on Win10 Pro 21H2, and get this 'simulator lock up' frequently.

It only happens when the simulation speed delay is at less than about 100mS.
This is the slider at the bottom right, only visible when simulation is running.

It appears that when the simulator delay is very low, the GUI stops working. It does seem that the code is still running, but you can't see or control it !
When it gets really bad I get the 'PE not responding, close or wait' prompt from Windows.

Because the slider is only visible when simulation is running it is possible to get in a situation where the simulation starts with a very low delay, and bcause the GUI is not working the slider can't be altered.

So now, when I'm working with code I want to run fast, but still see what it's doing, I put a #SIMSPEED directive at the beginning, just to make sure I don't try to start with no delay. ( See Picaxe manual 2, page 9, deprecated directives : #SIMSPEED - Now simply use the simulation speed slider bottom right of statusbar )

When we were asked what we wanted in PE6, I asked for 'Run with no GUI until condition met'. I was expecting run until a 'watch condition' was met, but we know the watch system has its own problems. ( See : https://picaxeforum.co.uk/threads/programming-editor-wishlist.20188/#post-192088 )

Don't hold your breath waiting for fixes.
 
Last edited:
K

kfjl

Member
Hi,
I joined the forum a few months after that thread ended, so I never saw it.
So you've been running a Microsoft-proof PE6 for 10 years with no problems? If so, I might have a go at following your instructions on an old laptop, just for the hell of it.
I still prefer the simplicity of axepad, though.
 
B

bpowell

Senior Member
kfjl said:
So you've been running a Microsoft-proof PE6 for 10 years with no problems?
Click to expand...
I'm not sure what "Microsoft-proof" means .... but I have been running PE6 on Ubuntu (most recently 22.04) using WINE (as described in my link) without any issues that I've noticed ... I'm not using it heavily, as I've been more focused on PIC and ATMega recently, but I pop into PE6 every now and then to put something together, and it works a treat ... I'm able to program chips, debug, etc.

Give it a go, you've got nothing to lose.
 
Buzby

Buzby

Senior Member
A question for those who are running PE6 on Ubuntu, or any other non-MS platform.

If you run a simple piece of code, as shown below, does it simulate properly when #simspeed is less than 20 ?

Code: 
#simspeed 100

do
    b0 = b0 + 1
    b1 = b1 + 1
    b2 = b2 + 1
loop
 
B

bpowell

Senior Member
Buzby said:
A question for those who are running PE6 on Ubuntu, or any other non-MS platform.

If you run a simple piece of code, as shown below, does it simulate properly when #simspeed is less than 20 ?

Code: 
#simspeed 100

    b0 = b0 + 1
    b1 = b1 + 1
    b2 = b2 + 1
loop
Click to expand...
On my particular setup (ubuntu, but in a docker container and streamed over HTTP (webtop)) if I set the simspead at 60, I'm unable to control PE6 ... I can see the sim is running, instructions are stepping through, but when I hover over the "stop" button, it never becomes highlighted and available to click...I need to force-quit to recover from this.

At simspeed 20, I also lost the ability to control PE6 ... I couldn't tell if the sim was running, but assume it was, and the highlights on the lines of code was just too fast to see.
 
Buzby

Buzby

Senior Member
I'm glad you have confirmed that the same fault occurs under Ubuntu as well as Windows, as that seems to indicate that the problem is in PE6, not the OS.
 
B

bpowell

Senior Member
However, *this* code works just fine all the way down to #simpseed 1 ... perhaps it's the delays that allow the main PE program to take a break from simulation and look for user input?

Edit: SimSpeed 1 - 29 results in no "code following" arrow or yellow highlight ... the simulator still runs just fine, but it's not showing the line of code it's on ... once you go to SimSpeed 30, the code-following arrow / highlight is back.

And the sample code posted above works just fine down to SimSpeed 1 if a "Pause 1000" is added. (I didn't experiment with other pause vaules)

Code: 
#simspeed 1

Symbol RED = 1    ' Output 1 (pin 6) is the RED LED
Symbol YELLOW = 2 ' Output 2 (pin 5) is the YELLOW LED
Symbol GREEN = 4  ' Output 4 (pin 3) is the GREEN LED


main:

do

' Sample program for 08M2 simulator
' Running on PE 6.1
' Running on a Linux 22.04 "webtop" docker container
' Hosted on a Linux 22.04 machine

    high RED
    pause 500
    high YELLOW
    pause 500
    high GREEN
    pause 500

    low RED
    pause 500
    low YELLOW
    pause 500
    low GREEN
    pause 500

    sertxd ("Hello there!",13,10)
    sertxd ("Working as expected ...",13,10)

    pause 1000

loop

goto main: ' Error handling ...
 
Last edited:
Buzby

Buzby

Senior Member
Any code that repeatedly executes 'pause' or 'sertxd' ( and maybe some other instructions ) will mostly run at #simspeed 1, but those are special cases. Most problems occur when trying something logically complex which doesn't need pauses or sertxd.

One project I was working on ran the first piece of code in a loop many thousands of times, then immediately dropped into further similar loops. Each loop was dependant on the results of the previous loop, so if I was testing loop 3 it had to run through 1 and 2 to make the input for loop 3.

It was way too slow to run this in the simulator, so that's why I asked for 'run with no GUI until condition met'.

PE6 as it stands now will run slow with full GUI support, run a bit faster with limited GUI, but lose control if you ask it to run as fast as possible. I think this is due to the obfustication applied to PE6. Why this has been applied I don't understand.


The Picaxe environment is built on three layers.

First is the Picaxe chips, with their custom firmware. This is the only layer that Rev-Ed make money on.

Second is the compilers. The source code for these is, understandably, not freely available, as this is the gateway to the firmware.

Third is the editor. This can be anything that generates a text file that the compiler can process. It can be as simple as Notepad, or as reliable as PE5, or as overblown as PE6. Anybody can write a tool to create the file for the compiler. It could be written in Excel VBA, or a batch file, or a Python script, or whatever the latest programming language is.

Rev-Ed don't make any money from PE6, but they have put a lot of effort into its development. ( Note : 'have put', not 'are putting' )

PE6 is the best tool for developing Picaxe programmes without a doubt, and it has the best support forum. However, its been years since the last update, and all requests for fixes or new features are now met with a wall of silence from Rev-Ed. This is a completley different attitude to when PE5 was live.

What has changed at Rev-Ed ?
 
P

papaof2

Senior Member
Perhaps there are so many competing micros with as much or more capability than the PICAXEs that Rev-Ed is now struggling to keep the doors open with educational sales and trying to keep a lock on that market?

Not that I expect to see any corporate confirmation of any of this. If they don't gut this message for mentioning competition, you might find an idea of what Rev-Ed is facing. If they can't handle the mention of competition, they need to move forward from the 1950's.

In 2015 / 2016 the $9 C.H.I.P. was crowdfunded and was a great deal more computer than any PICAXE. They advertised it as competition to the then-available version of the Raspberry Pi. I don't know what the interim iterations were, but all of the C.H.I.P. products except the C.H.I.P. itself are now sold out at https://shop.pocketchip.co/. The $9 C.H.I.P. went up to $49.99 and is now on sale for $34.99 so that crowdfunded project appears to have been a crowd dis-pleaser with its rocket up and then apparent flameout. Maybe the idea people did OK or maybe they didn't. I thought the promised C.H.I.P.s with VGA or HDMI interface were great ideas and a lot of things were promised for 2016, including a kit to build a laptop. I had other interests at that point in time (mainly getting my first book published in September of that year - that count is now at 13 ;-) so I wasn't following small micro hardware closely. C.H.I.P. seems to have failed in its early claims of how much market it would capture and how quickly... The original KickStarter pages are still up for the curious:

None of the other chips are directly programmable in a dialect of BASIC but it there are huge repositories with thousands of programs, a diligent user can probably find code to do most of what he/she wants to do. Why botherf to write from scratch if you can find something reaady made that's "good enough"?

Currently, versions of the DSP32 with WiFi and/or BT / BLE are available under $15USD so they and other similar chips are probably more than competition for the higher end PICAXEs - and there are a lot of Instructables, YouTube videos and so forth that provide public visibility and video support for those micros. The RPi Pico is occasionally available under $10USD so how does it compare?

How many PICAXE videos have you seen?

My PICAXE projects have been things that solved practical problems for me or someone in the family.
A/V cabinet overheating? An 08M2 plus a DS18B20 plus a transistor to switch a fan on when the temperature gets above some threshold and off when the temperature is lowered enough (that's been running about 15 years, just needing a new fan every 4 years or so).
An 08M2 and a float switch to trigger an alarm when the drain clogs at the bottom of the outside stairs to the basement and the water rises - and alarm early enough and loud enough that someone can clear the clog before the basement floods (I did get one complaint of how loud it was but that was the first time the drain clogged and was headed to flooding ;-) That one is 600 miles away so I only know that it worked fine the first two years, preventing at least two instances of flooding. I don't know if it's still in use.
Counting gallons of water into and out of rainwater storage tanks - although that one never made it past prototype stage with a 14M2 and the water flow sensor (816 pulses/gallon) from a common US clothes washer.

How many of those would attract attention on YouTube when other micros are running security cameras or monitoring solar charge controllers?

Any PICAXE projects with WiFi or BT or BLE interfaces to your phone?

To tap into much of the current hobbyist market, Rev-Ed would need a chip (or chips) that handle WiFi and BT / BLE with simple BASIC code or they'd have to provide bulletproof "add on" code that the user can plug the variables into - but mostly prompted, not like the days of setting up networks for PCs running Windows for Workgroups (been there, did that :-(
 
K

kfjl

Member
Hi,

I couldn't get PE6 to work.

I told one of my kids and he had PE6 up and running half an hour later! He used the arch-based endeavor OS running in virtual box.

So I installed endeavor on my old laptop and did as I was told:

Install wine and winetricks

Install Picaxe Editor: wine PEinstaller.exe

Install DOTNET40: winetricks dotnet40

I asked, "why dotnet40?" and he said, "because it usually works!" So he knew how to do it without the tuto....!
There are some buttons on the top left of the PE6 screen without anything written on them, which might be because of some missing character-set I would have got with dotnet3.5. The buttons still work, though.

Now PE6 should fire up, or if you're using an old computer like mine, it should eventually drag itself onto the screen (PE5 was miles better/faster).

I made my own download cable with an FTDI knock-off board and a hex inverter. It has the standard PID of 6001, so in linux, it just works if you belong to the right user group. If you don't:

groupadd uucp (arch-based distribution) or groupadd dialout (debian-based)

These are probably already present.

gpasswd -a <your username> uucp (or dialout)

The following was taken from here:

Starting from Wine 2.8, the simple symlink-editing method of configuration doesn't work. One has to configure COM ports by editing Wine registry. From Wine User's Guide/Other Things to Configure/Serial and Parallel Ports:

To override Wine's default device mapping, run wine regedit and create string entries in HKEY_LOCAL_MACHINE\Software\Wine\Ports where the entry name is the Windows device name and the entry value is the path to the Unix device. Continuing with the above example, to make COM1 the first USB-attached serial port, create an entry with the name COM1 and the value /dev/ttyUSB0. You might also want to create an entry named COM5 with no value to remove the COM5 device which is now a duplicate of COM1. After editing the registry, shut down Wine with wineserver -k and the next time Wine runs a program, your changes will take effect.

(Ruslan's answer).

So, in conclusion, Rev-Ed has something for everyone.
On my old computer:
PE5 works nicely
wine struggles with PE625919
Axepad rules!
 
B

bpowell

Senior Member
Nice work!

This missing / blank buttons may be a font issue? Not sure, they are all present on my install.

But still, great job!
 
K

kfjl

Member
I'm pretty sure it's a font problem too, but I'm sticking with axepad so I'll leave it there.
I hope we'll here from other linux users.
I'll give my son a high five on your behalf!
:)
 
K

kfjl

Member
I changed desktops from gnome to mate and now I have the names on the buttons!
But PE6 is too bloated and sluggish for this old computer.

25930
 
Gramps

Gramps

Senior Member
Had another incident here today. Running the simulator and could not get it to stop.
Ran avast to see if i had a virus but the system is clean.
Had to close the Editor and restarted. Now working ok.
We never had a problem till we "upgraded" to Windows 11.


Buzby said:
code in post #22 when #simspeed is less than 20 ?
Click to expand...
not sure what #simspeed is.
 
Gramps

Gramps

Senior Member
Code: 
       #simspeed 100

do
b0 = b0 + 1
b1 = b1 + 1
b2 = b2 + 1
loop
No, it crashed the editor......
 
Buzby

Buzby

Senior Member
#simspeed 100 just about runs OK on my Win 10 machine, but values less than 100 cause uncontrolability, and less than 30 causes PE to lock up.

So now we have had replies from people on Ubuntu, on Win 11, and on Win 10, all showing similar behaviour in the PE6 simulator.

Is it time for Rev-Ed to fess up about what is going on with PE6 developemt ?
 
K

kfjl

Member
On my old and slow computer, running arch-linux-based endeavor OS, the simulator works at #simspeed 100, but blocks everything else in PE6.

Maybe it's just a question of computing power and Rev-Ed are waiting for technology to catch up!
 
Technical

Technical

Technical Support
Staff member
Code: 
do
    b0 = b0 + 1
    b1 = b1 + 1
    b2 = b2 + 1
loop
If you are running an older or slower machine (or virtual machine) very tight loops such as this may struggle to simulate at very small simspeed delays, simply because the simulation is firing too rapidly for the system to keep up with. Each individual computer will be different as to how quickly it can simulate.

The very simple workaround is to 1) use a larger simspeed or 2) add a small delay in to your tight loop to give the system breathing space to 'catch up' e.g.

Code: 
do
    pause 1
    b0 = b0 + 1
    b1 = b1 + 1
    b2 = b2 + 1
loop
At simspeeds less than 30 the line highlighting is automatically disabled (as it is very gui intensive), however the simulation will still run (as long as the operating system can keep up with the loop).
 
You must log in or register to reply here.
Top