ScratchCrumble testing release

[Simon]

ScratchCrumble syntax
Simon

[Simon]

@drkempton
Ran fine all last night (in my PyCharm development setup)
So I’ve release V.0.1.2 and running the ScratchCrumbleDev.exe in a cmd window to see what happens

[Simon]

Version 0.1.3 – should have fixed the crash when loading/saving projects

Simon

[Simon]

That didn’t last long 🙁
Try 0.1.4
Version = ‘v0.1.4’ #Error raised from CrumCon and loop delay set to 0.5 sec

[Simon]

Version = ‘v0.1.5‘ #9Jul15 Bug in reading Input C fixed

🙁 Still crashes out on me when I run the exe but fine in Pycharm dev setup – going to try a different .py -> exe prog

[Simon]

Version v0.1.6 #12Jul – different installer used

I’ve switched to using CXFreeze which produces an MSI
Please let me know how you get on with this one and hopefully the crashing bug will have gone!

[drkempton]

Hi Simon,

It is certainly a lot better. But it still crashes eventually. This time after tens of minutes rather than just a minute or two. Also the input sensing is not robust. Input A tied high still gets sensed as low intermittently. I also had trouble getting the other B,C,D inputs to work at all.

It will be interesting to see what other testers find.

David.

[Simon]

Can you run this script with Pin D tied to A – no extermal power apart from USB

[Simon]

Mines made up to a count of 5 since 7pm – 5 in 2hrs 20 mins
Just tested B and C inputs and they’ve responded fine (within the current limits of only sampling twice per second)

Simon

[Simon]

Ran fine all night (12hours) but there is a noticable lag on detecting B & C changes so going to look into that

Simon

[Simon]

mm – just tried it on one of my schools on the w2k8 server (as thats the machine I sit at) and it did perculier things

Starts off ok with D connected to A -leave it a few minutes – fine
But very shortly after connecting B to D as well, it starts thinking A is LO and then just stops responding

I think I’ve have to do some native Python tests (without Scratch) just to make sure the basics are working

Simon

[Simon]

Nah – just leaving it alone and it goes off-piste!
Lets try using this as test routine – out of 4 runs – maximum time it lasted was 80 secs

[Simon]

OK ran same Scratch routine but running ScratchCrumble.py direct from my Pycharm IDE and it lasted till 1500 secs before exceeding the 100 count.

I’m thinking that could just be an accumulation of 100 blips rather than a fail at 1500 sec – I’ll need to write a better Scratch logger to see if that’s true

[Simon]

OK this is now test script to record events
http://snag.gy/7dsRf.jpg

and export of record list which shows about 4/5 events

2039.567
2039.592
2039.616
2039.648
2039.669
2039.694
2039.722
2039.754
2039.773
2039.798
2039.825
2039.867
2039.88
2039.905
2039.93
2039.962
2039.981
2040.006
2040.032
2112.123
2322.772
2322.816
2322.823
2322.85
2322.876
2322.917
2322.925
2322.953
2322.975
2323.009
2323.025
2323.05
2323.075
2323.107
2323.126
2323.153
2323.176
2323.215
2323.227
2323.252
2537.984
2538.01
2538.043
2538.06
2538.087
2538.112
2538.15
2538.162
2538.188
2538.214
2538.248
2538.264
2538.289
2538.314
2538.349
2538.364
2538.389
2538.414
2538.445
2927.353
2927.36
2927.384
2927.41
2927.451
2927.462
2927.487
2927.515
2927.547
2927.562
2927.586
2927.611
2927.641
2927.662
2927.688
2927.716
2927.745
2927.766
2927.791
2927.816
2941.36
2941.373
2941.398
2941.424
2941.468
2941.475
2941.499
2941.529
2941.56
2941.575
2941.6
2941.624
2941.654
2941.674
2941.699
2941.726
2941.754
2941.774
2941.799
2941.825
3424.308
3424.333

[Simon]

Ok – I had a thought that it might be clashing between threads so I’ve added some locks to the I/O routines and it lasted up to 4700 on my setup here without any errors (but of course I may have just been lucky)

Anyway – its back to the old packaging system for V0.2.1

Try it and see what happens please

Simon

[Author]

Posts