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.
 
Technical

Technical

Technical Support
Staff member
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
 
D

dgc188

New Member
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.
 
Buzby

Buzby

Senior Member
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.
 
D

dgc188

New Member
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.
 
D

dgc188

New Member
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
 
PhilHornby

PhilHornby

Senior Member
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).
 
D

dgc188

New Member
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.
 
P

papaof2

Senior Member
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?
 
PhilHornby

PhilHornby

Senior Member
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: ...
 
P

papaof2

Senior Member
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.
 
P

papaof2

Senior Member
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...
 
You must log in or register to reply here.
Top