Millisecond Forums

These are the errors we are getting. 

These errors point to an issue with the 4th script. Specifically, it points to a graphics issue. Reasons could be:
- Some misspecification of stimulus size / position, or canvas size position in the 3rd or 4th script.
- An issue with the system's display driver.
- The system running out of graphics memory.

I'm having trouble locating the relevant files in the Box link you posted since there's so much extraneous stuff.

Would it be possible for you to just upload a _clean_ copy somewhere, i.e. just the batch script, the scripts (+ any files the scripts require such as images) the batch attempts to run, all in the expected directory structure with names etc. matching what's in the batch? Please leave out all extraneous stuff such as Word or Excel documents, data files, and other scripts not required by the batch at issue. Thanks.

Sorry for the mess, Dave. It's all cleaned out now, and the batch file is also in the root folder. Thanks! 

Jeff

We've been doing some testing and figured out a few things.

• The batch file seems to work if you remove the EMATHFR test from the batch code, which is the only test that uses a second monitor. Currently, we're using this monitor. 
• If you run the EMATHFR code by itself, it also seems to work, but embedding it in the middle of the test like it is now does not. 
• If you start the test with EMATHFR (IDInfo is a one-pager that we don't remove because it's where we input the batch-level parameter, age), then it will run and so will the remaining tests.

Thanks, this is very helpful. Based on what you describe, the switch from single-monitor to dual-monitor in the middle of things is what throws things off (not sure yet whether the problem originates in Inquisit itself or the graphics card driver refusing to switch / returning an error).

A workaround might be to put a small script that uses both monitors at the very start of the batch -- that script need not do anything, need not take any input or last long (it can just time out after a second or two). I'll be looking into your files later on (the download is taking a while) and let you know what I find.

We tried to add a second monitor to our first file (IDInfo), and I'm afraid that didn't work. 

Hi Dave, 
Would you happen to know anything about batch file discrepancies between different types of computers (if that even exists)? At the moment our batch file runs through most of the files when we run it on our desktops. However, on our surface pros they crash somewhere in the middle. Let me know if you have any ideas, thank you!

Assuming the scripts are those available under the Box link, the only thing I can think of would be resource-exhaustion on the Surface Pros. The scripts involve lots and lots of files, so I can imagine that the Surface devices *might* for example run out of memory somewhere along the way whereas more powerful desktop machines can cope with the overall load. Can you give me a better sense of when / where crashes occur, i.e. is it always during a particular script or even a particular trial or block in a script, or does it seem somewhat random, i.e. sometimes happens sooner in script X, other times it happens later in a different script Y? The latter would support the idea that the Surface devices can't quite cope with the combined load imposed by the scripts.

I think you're right, Dave. We were just about to post with some tests we've run. When we first posted, the script would run if only MATHFR were removed. We added a very small script at the end to collect the timing of the last test, and that was too much. So we then tried breaking up the batch file even further; roughly half of the tests in one batch, half in another, and MATHFR by itself. So far, this is the only way that it works. Am I understanding correctly that Inquisit needs memory for the entire series of tests, not just the one it is currently running? This is unfortunate because one of the key reasons why we purchased Inquisit 5 was for the ability to pass a common, randomly-generated code across all tests administered during a batch. Every time we break up the batch file means it's harder to merge a participant's individual tests back together when there's a problem with the subject id.