parallel:22:ayp error when running two programs at the same time

Hi,

I have two frame machines (miners basically) running a program where I can queue what to do via arguments (like 'Run F 3 L 4 Q 10', moves forward 3 times, then left, then quarries a bit). Using wireless transmitter as peripheral. Heres the code for one of those, other one has similar structure, with different frequencies etc.

http://pastebin.com/nF7urpXH

When running either of those programs alone, everything works smooth and happy. But if I run them at the same time, I start to get parallel:22:ayp or parallel:22:ays errors. Usually happens when inside the "Q" loop.

Any ideas whats wrong or how to avoid this?

Thanks in advance :)/>


Hyppe

parallel:22:ayp or parallel:22:ays? Are you sure that those are the error messages you get?

Anyways… Where do you use parallel API in your programs?

LBPHacker, on 14 April 2013 - 07:49 AM said:

parallel:22:ayp or parallel:22:ays? Are you sure that those are the error messages you get?

Anyways… Where do you use parallel API in your programs?

Yes, I'm sure. And I'm not using parallel API. It throws me "error: parallel:22:ayp press any key to continue", and when continuing, it reboots the computer. It happens semirandomly, not always, but it will happen again at some point.

Oh my god. That's the parallel.waitForAny in bios.lua. Gotta take a look at rednet and shell.

I'm having the exact same problem with my frame machine. Has a solution be found yet?
(I'm using CC 1.5 for MC 1.4.7/FTB Ultimate)

Judging from what you're saying here I'm starting to think the computer is redpulsing too fast and the underlying system is perhaps getting out of sync with the redpulse requests (maybe).

My script looks a lot like yours
http://pastebin.com/m5EqNeSh
only my redstone delay is 0.4s.

ProgrammerHero, on 23 May 2013 - 11:48 AM said:

-snip-

Firstly. Thank you for searching and finding a relevant topic to post in :)/>

Secondly. I have had this particular error before in a similar circumstance to how you're having it. As far as I can tell its a problem with line 38. It seems that there is a bug in WRCBE that causes this (seemingly random bug) when you're trying to change the frequency to the frequency that is already set (I think this is the cause, maybe its just setting the frequency thats the cause).
So if you move your line 38 to outside of the for loop it should fix the problem (fingers-crossed). Also I notice, that in your case, the table of frequencies is redundant since the frequency is the same as the engine number, so you could remove the table, and just use trans.setFreq(targetEngine)