Great. If anyone else needs the driver for the composer max, please do not use the composer max driver posted on the first page of the batch ripper sticky thread but, instead, follow the instructions for the other "big" machines and contact illustrate directly - spoon will put you in contact with me:
Thank you Brendan for all your help. Things seem to be good here. Hopefully now that BatchRipper 1.0 is final spoon can implement some of the other features/flags and the power of the composermax can really be tapped!!
After ripping the first 4 discs it simply said finished batch rip. Never unloaded any discs to the output bin or got any new ones.
After each individual disc rips should it be unloaded or does the batch ripper only load/unload them all at once?
Yes, it should unload them as they finish. If more than one is queued up for unload while the robot is busy, then it will pick one of the queued ones, at random, to unload and reload a new disc and so on.
You aren't, by any chance, running the batch configuration robot tests *while* the batch ripper is running, are you? Or using the front panel buttons?
there was an error on the disc, so the batch ripper is set to reject the disc. The disc was ejected. The robot picked it up, waited, and then replaced it in the drive. Then I got an error msg that drive G was shutting down.
I've never seen an error message that a drive was shutting down (the robot, yes, but a drive?). Next time it appears try copying it to the clipboard. Typically, you can do this with an error dialog by making sure it has focus and typing ctrl-insert. It should copy the text of the error message to the clipborad.
If that fails try a screen print and crop it.
Regarding rejects, I'll see what I can do. Might be a timing error or a string match error inte the MOVE --command strings.
There's probably a typo on the pre-batch line somewhere.
-brendan
Oh, right. By crash you mean hang.
If one drive successfully ran pre-batch, then in order for other drives to successfully run pre-batch, a load must be successfully tested. This is because a successful pre-batch leaves a "reservation" for that drive waiting in the temporary directory. It tells all other pre-batches to wait until the reservation clears before trying to get their own reservation.
reject and unload also create a reservation for the drive.
Post-batch is a handy way to all reservations. You can also do that manually by looking in your account's temporary directory here...
C:\Documents and Settings\<ACCOUNT NAME>\Local Settings\Temp
...and deleting all of the ulcli related temporary files. Just don't do that while the batch ripper is running.
despite the configuration test crashing the robot seems to be running well
so far...
1) the first bin the robot goes to to get discs is suppossed to be the output bin (9 oclock bin looking at the robot)
2)how does it choose what drives to load first? it loaded A then D.
3)Any reason the robot waits for the disc to load before moving to the next step?
1) Is it possible that some drives are configured for the older driver? Try unconfiguring and reconfiguring and make sure the most recent driver is chosen. Alternately, maybe the hardware can be configured at the factory to give different disk stack numbers.
2) It's random.
3) Yes. Some ripping houses had problems with drive open/drive closed using my speed optimized methods (looks like it depended on how the drive was connected to the computer). Out of caution, I've reverted to the simplest method for the time being, that being a standard "close drive and wait for disc type recognition before exiting" approach. You can try the faster method by adding --newestdrives to the command lines, but please avoid doing so until all other issues are resolved.
dBpoweramp's batch configuration keeps crashing everytime I run the Pre-Patch test. I run the test, the robot goes through the reset motions, the window in the configuration says test running, but then it stops responding. I am not sure if this is a driver issue or a dBpoweramp issue.
There's probably a typo on the pre-batch line somewhere.
there was an error on the disc, so the batch ripper is set to reject the disc. The disc was ejected. The robot picked it up, waited, and then replaced it in the drive. Then I got an error msg that drive G was shutting down.
dBpoweramp's batch configuration keeps crashing everytime I run the Pre-Patch test. I run the test, the robot goes through the reset motions, the window in the configuration says test running, but then it stops responding. I am not sure if this is a driver issue or a dBpoweramp issue.
Leave a comment: