[firefly2280]

Did you put the custom primers into the appropriate wells with the Illumina primers and make sure you didn't indicate in your worksheet that you used custom primers?

Thanks, yes the primers were in the right wells and Im not using the experiment manager so I dont think that was it either.

[kcchan]

Thanks, yes the primers were in the right wells and Im not using the experiment manager so I dont think that was it either.

If you were using custom primers, did you have the proper fields defined on your sample sheet? It should looks something like this:

[Settings]	
CustomRead1PrimerMix	C1
CustomIndexPrimerMix	C2
CustomRead2PrimerMix	C3

[firefly2280]

Thanks for your reply, yes, all ok. My colleague runs the same primers all the time and he helped me set up the run, so all was in order. It really seems sample related

[pmiguel]

The error message

"Object reference not set to an instance of an object”

came up and that was it, so didnt even get as far as cluster densities.

Illumina thought it was the concentration of my library but It was definately at 2nM to start with then denatured and diluted correctly as per their protocol

To add to what McNelson wrote upthread, note that this error is actually a software bug, presumably in the error reporting code for MCS. So you should interpret it as "there has been an error, and MCS has stopped the run, but I can't report the error here because the code that should propagate that error from the sub-system that generated it, is broken. If you are really curious you can see the actual error out of the instrument run log."

Recently we had a bad piercing motor that was ending runs when the straws met the least resistance. When I dug down into the log file I found the following cogent message:

13-05-24 12:21:47.780 -04 000000101 INF: FPGA: Recv ^SIPDOWN sip: down sensor error
13-05-24 12:21:47.788 -04 000000110 WRN: FPGA: The FPGA reported an error while executing command "SIPDOWN"; error message: "sip: down sensor error"
13-05-24 12:21:47.788 -04 000000110 WRN: !!!!! Exception occurred, base exception type = "Illumina.Instrument.Bolt.Logic.Mainboard.FPGAErrorResponseException"
13-05-24 12:21:47.788 -04 000000110 WRN: !!!!! The FPGA reported an error while executing command "SIPDOWN"; error message: "sip: down sensor error"
13-05-24 12:21:47.789 -04 000000110 WRN: !!!!! Stack trace for exception type "Illumina.Instrument.Bolt.Logic.Mainboard.FPGAErrorResponseException":
13-05-24 12:21:47.803 -04 000000110 WRN: !!!!! at Illumina.Instrument.Bolt.Logic.Mainboard.FPGA.SendCommandGetResponse(), file FPGA.cs, line 1189
13-05-24 12:21:47.806 -04 000000110 INF: =================== Error, Exiting Run ===================

Note that the problem is clearly noted! So if you have written a bit of code yourself, it is immediately apparent that the error message being produced refers to the code itself, rather than the actual issue. Nevertheless, the tendency is to think "must be some sort of computer issue". Many a wild goose chase ensues. Up to an including engineers being sent on-site only to discover that the piercing motor is the culprit (in our case) and having to stay an extra day waiting for the necessary parts to be FeExed to him.

I finally decided to write the issue up and email it to Illumina Tech support with a request that it be submitted as a bug report to MCS. Am hoping it will be fixed in the next version...

--
Phillip

[firefly2280]

To add to what McNelson wrote upthread, note that this error is actually a software bug, presumably in the error reporting code for MCS. So you should interpret it as "there has been an error, and MCS has stopped the run, but I can't report the error here because the code that should propagate that error from the sub-system that generated it, is broken. If you are really curious you can see the actual error out of the instrument run log."

Recently we had a bad piercing motor that was ending runs when the straws met the least resistance. When I dug down into the log file I found the following cogent message:



Note that the problem is clearly noted! So if you have written a bit of code yourself, it is immediately apparent that the error message being produced refers to the code itself, rather than the actual issue. Nevertheless, the tendency is to think "must be some sort of computer issue". Many a wild goose chase ensues. Up to an including engineers being sent on-site only to discover that the piercing motor is the culprit (in our case) and having to stay an extra day waiting for the necessary parts to be FeExed to him.

I finally decided to write the issue up and email it to Illumina Tech support with a request that it be submitted as a bug report to MCS. Am hoping it will be fixed in the next version...

--
Phillip

Phillip, Thanks so much, Im going to get someone to help me take a look!

thanks again

[mcnelson.phd]

Hey Phillip, can you list which specific files you dug through to find that error message? We just had a run fail and I can't find anything that gives an error message like you showed in the log files that I looked through.

[GenoMax]

Hey Phillip, can you list which specific files you dug through to find that error message? We just had a run fail and I can't find anything that gives an error message like you showed in the log files that I looked through.

Most likely "Flow_Cell_Folder/Logs/*.log" files. There is one log for each cycle but you can quickly "grep" through the files.

[mcnelson.phd]

Most likely "Flow_Cell_Folder/Logs/*.log" files. There is one log for each cycle but you can quickly "grep" through the files.

Ok, I found it. Was looking through the logs in the MCS folder, which do indicate errors, but just that "object not set to an instance of an object" line.

For future reference for others, I found what I wanted in

 D:/Illumina/MiSeqTemp/<RunFolder>/Logs/<Cycle_that_run_failed_at.log>

[Proksima]

Maybe someone tried to use flow-cell and reagents from run that failed again?
Over run failed before before any clustering begin, so maybe we could use reagents again?

[Vesperholly2]

I've gotten that error a few times, right at the beginning. We've usually been able to 1) take out our essentially 'unused' flow cell and replace it with a used one 2) run the post run wash 3) power cycle the machine 4) successfully re-start the run with the same reagents/flowcell. Now, this happened a few times and we eventually had the hard drive replaced in our Miseq, but this did seem to be a fairly non-specific software related error, as mentioned above.