PE6.2.0.0 hanging up

D

dgc188

New Member
I've recently upgraded from PE6.1.0.0 to 6.2.0.0 and find that on my somewhat old laptop that, when running a listing with numerous trace events to be output, the trace window is very jerky - often pausing before listing a bunch of trace lines - and then totally becoming unresponsive and the entire PE6.2 has to be terminated.

Yet on my more modern (but still not very recent) laptop, it appears to be much better

No problems at all on either laptop when running PE6.1. Both are running up-to-date Windows 10 Pro.

At the moment I have PE6.2 on my main "writing" and SIM testing laptop and PE6.1 on the operational laptop. Are there any compatibility issues between the (non-fancy listing - just simple commands) code being generated between the two versions of PE?

Did the upgrade to PE6.2 add so much more that older "kit" (with maybe less RAM on-board) can no longer cope when running loads of trace?
Or is there something else that needs to be upgraded along with the move to PE6.2?

It's just a bit annoying to have to move the "writing" laptop into the "operational" position to totally debug the running program.
 
Change log between versions are given here:

PICAXE-Editor-6 - Software - PICAXE

PICAXE Editor 6 is the recommended Windows software for programming, testing and simulating BASIC, Blockly and flowchart programs for PICAXE.
www.picaxe.com www.picaxe.com

Nothing in simulation has changed between 6.1 and 6.2
 
Thanks, but the hangups using PE6.2 occur during run-time on the project with plenty of trace enabled, not in SIM mode, and only on the "old" laptop - 4MB RAM (64% utilised) but with the CPU running at or very close to 100%. It's obviously an under-powered CPU but it was (and still is) able to cope when running 6.1.0.0. There doesn't appear to be any problems when running the project without the trace activated on either 6.1 or 6.2.
 
Does it still lock up if you move the sim speed slider to 100mS or greater ?.
( Or put a #simspeed 100 at the start of your code. )

I've had the same sort of problem. It's not so much due to underpowered computers, but to the way the PE app is structured.

I'm currently working on a project where the only I/O is via the terminal. There are no pauses or other instructions that could release time for the display. When I run this in the simulator at #simspeed 0, PE appears to lock up, but it actually hasn't. After a few seconds the PE terminal opens, and I can interact with the programme. However, there are no highlights on the listing screen, and the code explorer values are slow to catch up.
 
We all seemed to have hooked onto the problem being with the simulation mode of PE.

No, there is no issue with SIM - therefore adding SIMSPEED would have no effect on the problem. 'Tis fine, works well. The issue is the change from PE6.1 to PE6.2 during live running and utilising diagnostic feedback via the Terminal window. Apologies if I didn't make that 100% clear previously.

It's the reporting back on the terminal window from the live kit with a fair amount of included SERTXD commands showing quite a few variables for final elusive bug finding when the SIM doesn't bring that elusive problem up.

The SIM uses an added/included script (a series of statements at the top of the program loop that indicates that one simulated change or another has occurred that would otherwise be normally picked up from the live kit) that says that this or that happened, and what happens further down the program as a result. This aspect works fine in SIM mode. It's when the program is running live (without that added script) that it hangs on the terminal window - and only on PE6.2.

The program runs on a model railway and governs the signals and pseudo sections of track between the signals and is dependant upon a number of sensors and points around the layout that causes the signals to change accordingly, i.e. from a green to a red aspect (at signal1) and blocks that section of track just entered. That block is then released and that signal (signal1) goes to a yellow aspect once the next signal (signal2, which goes to a red aspect) and sensor is passed and the previous section becomes clear. The first signal (signal1) then goes to a green aspect once the block further down the track is also cleared (by signal3). The first train through appeared to retain a block on one section of track thus causing the following train to have the signals wrong for it's (safe) passing. Hence all the trace was put in to find what was going on and where in the listing that the SIM couldn't find the reasons for.

The program allows me to concentrate on running the trains without having to worry about manually changing signals at an appropriate time. I, and any visitor to the layout, like to see it run like a proper railway where I'm the engine driver and some other guy somewhere else does the signalling for the safe running of my train(s). That's the background.

SIM works ok (even if it doesn't find all the problems! That's more my fault than PE).
During live running, the monitor window is jerky (due to the amount of reporting being done) - at 19200bd - and eventually it - and PE6.2 - hangs - PE6.1 does not hang under the same circumstances.

PICAXE 40X2 (setfreq m16) with a program length (without sertxd commands) of just 1746bytes out of the 4096 allowed (52 of the 55 variables in use) and using i2c without an interrupt.

Basically, I'm just puzzled as to why the new PE6.2 version appears to be worse - in this one respect - than the previous PE6.1 version under the same circumstances - just in case there's a tweak that my Windows 10 Pro, or some other aspect the the OS support stuff on the oder laptop, that needs changing or possibly updating.
 
Thanks Phil for your response.

I'm not sure about your symptoms or what your program is doing - do you have a lot of user input or is it like mine, all generated by sensors, etc. and then outputting a high or low to a given port depending on those sensors (sensors reading either ON or OFF, no in-between values to be decoded)? Your PE version does seem to be slightly older than 6.1 (which is fine for me) or 6.2 (which isn't).

I've not dug down as far as you seem to have done with sysinternals - I'm not that aufait with what I should be expecting to see being reported. All I can say, at this stage is, yes it perhaps does seem to slow down, certainly with regard to the amount of data being put to the terminal window at any one time with increasing amounts of data being 'block outputted' to the window until such times as it totally stops reporting. I do, however, get the impression that the program maybe still running (although I cannot be 100% certain of this - I'm too busy trying to read the terminal window for on-the-fly answers), maybe it is running slower and slower although, until the terminal window ceases reporting and I can move no further with PE I cannot be certain. Task Manager is the only, certainly the easiest cure I've found - "end task", restart PE.

I know the CPU time being shown is 100%, with the vast majority of it down to PE. I can't vouch for disk access % as I'm trying to debug the program and downgrading to PE6.1 is good enough for me - at least in the short term. No other user programs are running and nothing much as background processes other than the normal Win10 stuff.

I hope this maybe puts your problem into the "I'm not the only one" category, but apologies, I can't be of much more help without more knowledge of what I should be doing and what I should be observing.

Dave
 
dgc188 said:
All I can say, at this stage is, yes it perhaps does seem to slow down, certainly with regard to the amount of data being put to the terminal window at any one time with increasing amounts of data being 'block outputted' to the window until such times as it totally stops reporting.
Click to expand...

The "Terminal" will try to store all data that it receives. It continues to do this, regardless of the serious depletion of system resources that can ensue. The solution, is to use something like Putty, (which allows you to set the size of the screen buffer, to some finite size).
 
Thanks Phil, but having read (or tried to read/understand) about Putty, I think I'll give it a miss. It's all a bit much for my 76 year old grey cell to comprehend when a simple downgrade to PE6.1 does the job for me.

Sysinternals is something I used many (many) years ago but I've forgotten what it did, let alone what the newer versions can do.

The upshot of it all - the original post - was to at least flag this problem up with PE6.2, running live with loads of trace in the terminal window.

I'm quite content to run 6.1 while debugging the running program. And now that it has been debugged (until something else crops up) I essentially don't need 6.2 other than, maybe, for the auto backup that 6.1 was flakey with while developping some newer version of my software.

So thanks for your responses and again apologies for not being able to try sysinternals or Putty

Hopefully, someone who is in the development area for PE can implement a fix for this issue of (maybe) buffer space on the terminal window during live debug running.
 
dgc188 said:
Hopefully, someone who is in the development area for PE can implement a fix for this issue of (maybe) buffer space on the terminal window during live debug running.
Click to expand...

Or produce a 64 bit version of PE so it could have access to ever how many GB of RAM your PC is capable of holding?
How long could the terminal window run if it had access to 8GB or more of RAM?
 
I think the problem might well turn out to be a 'memory leak' of some description. It seems to use resources far in excess of what you would imagine it capable of :unsure: ...
 
It won't be the first piece of commercially available software that did not get absolutely total testing. I'm trying to get Cura 5.6.0 running on this laptop so I'll have some software that can create gcode files from stl files for the 3d printer kit I plan to tackle next week. I've managed to crash the software twice in two days - pretty good for a guy who's 70+. FATAL crash - as in it no longer works correctly on ANY file after the crash unless I uninstall it, clean all easily removable references to it from the registry and then re-install the software. I'll try it again after I've slept a while - better to be somewhat fresh when trying to catch bugs ;-) I do have the bug report almost finished - just need to add a couple more references to it. They may also want me to upload the file that killed it.
 
The laptop is old, but it's specs are better than the minimums and I've not (yet) tried to use a 3D view - but I did include the "yet" ;-) Just trying to see if it can process the mostly small and simple pieces needed to reduce the flex in the plastic frame of the 3D-printer-to-be.
Regardless of the PC's specs, the software SHOULD be aware of the limits it is working in and detect when it needs more RAM or better graphics than are available but BEFORE it dies. It should recognize when it's about to reach those limits and stop with a "XXX limit reached. You need YYYY to fix it" - not have a silent hard crash and be unusable when it is restarted. On the other hand, my background might have me expecting too much of the developers - years of testing new operating system releases (UNIX), doing software development and then of being part of the region's "skunkworks" that got the calls when the users of system X or system Y or system Z kept getting "That can't be done" responses from their normal support people about their requests for whatever they needed. Most of our "fixes" were done with "outside the box" thinking because most of the groups we assisted had near-zero money for immediate equipment upgrades. Just like real life when you're retired...
 
I to ma having an issue It seems to have just developed lately. I have a number of computers and laptops with different versions of the pickaxe software running. All meet the minimum requirements. My issue is after starting debug when using Picaxe editor no mater which version or computer after a few reads the program hangs. On my latest computer running picaxe editor 6.2 the program hangs but after a few seconds clears then re hangs again in a repetitive cycle. turning off the power to the Picaxe I am debugging clears the fault. This is really odd as I have a very early version of the software running on a laptop with windows XP this has never been an issue but now even that has the same problem of locking up, so that would definitely point away from the picaxe program. Something interesting though if you use the text editor version and use the debug everything is fine. Makes no sense?????

any one got any ideas? As its really annoying, I wouldn't think it was the picaxe itself but I cannot see any changes anywhere if I get a change I'll test an old chip to be sure.
 
Also just tried old program editor 5.5 and it is also ok.

Hippy something has changed may be it was a windows update but Debug most definitely doesn't work properly now even though it did before has microchip changed anything without telling you that's bugging your software? It cant be anything major if 5.5 works ok
 
Hi,

Try changing the Simulation speed (slider) to something slower. There is also a #Simspeed directive but apparently it's deprecated now. Note that PE5 (and Axepad) were built on a different software platform, so comparisons are not very relevant. A few Pauses inside any tight loops might help.

Buzby has had quite a lot to say about this in the past. ;)

Cheers, Alan.
 
#simspeed is still suported in PE6, and I still use it often !.

Some of my projects have none of the instructions, such as 'pause', 'sertxd', 'servo', etc., that give the simulator time to update the screen when running very fast. This leads to a lock-up when I reduce the slider to less than 100.

When the screen is locked it is impossible to adjust the slider, and it needs Ctl-Alt-Delete to allow access to Task Manager where I can kill PE. This usually works, but occasionally I need a re-boot.

However, the slider setting seems to be stored in the project, so when I re-open the project the speed is already set. Now the problem is that you can't change the slider until you start the simulator, and by this time it's too late.

So I use #simspeed just to make sure that the simulator starts at a reasonable speed.

Cheers,

Buzby
 
Re-reading the original posts, it looks like the OP is not using the simulator. He is using PE Terminal to show text coming from a real Picaxe. This is something I have not done much with. However I do know the PE Terminal is not a nice simple device, it's packed full of fluffy bits to make it look good in the simulator. Unfortunately the addition of these fluffy bits was at the expense of making behave like a proper terminal.

So now when working with real chips I use a proper terminal, like RealTerm or TerraTerm. It does mean swapping between programming and monitoring, but it does give me a real, reliable, and fully compliant terminal that I can trust.

Cheers,

Buzby
 
You must log in or register to reply here.
Back
Top