Paul C. Buff, Inc. Technical Forum

I had a shoot this weekend and that required tow lights relatively close to me to be set up. I set up a White Lighting x1600 and a Einstein (That I recently upgrade the firmware to v22). I was using a CST (which I can't use anymore cause I lost it that night) to trigger. Both lights were on their own Vagabond.

So I took my light meter and my CST and popped the test button and the einstein fired a full flash and went into rapid fire mode shooting in what looked like 2.5 ws pops. I turned it off and on and hit the test and it went right back into rapid fire mode. Not having a lot of time I pulled the Octobox off and put up my spare WL x1600 and had no problems. (Still using the CST and the same Vagabond for that was used for the Einstein)

I shot the entire night with the two x1600's and the CST with no problems. The next morning at home I set up the einstein set to full power and plugged into the wall and hit the test button...Full flash, no rapid mode. I let it recycle and pressed the Test a couple of times with no problems....

Any clues?

What conditions were you in? Sunny? Dark? Was the slave eye turned off on it? (it does not lock out like WL/AB does). Did the X1600 (the first one) have a receiver at the same time as the Einstein? I assume Einstein also had the CSXCV?

Just a side comment: I find it a very odd design choice to have the slave eye defaulted to enabled WHEN a CSXCV is installed in the Einstein. It seems counter-intuitive to me, and the firmware should be able to recognize that the trigger is in place, turn the slave off. Slave enabling when no trigger is detected is reasonable. If I was going to change something in the firmware, that would probably be it. Otherwise, the UI is really good.

Is there really a common situation where we would have our Einsteins set up with CSXCVs on all of them, and still want them to default to slave on?

WL x1600 had a receiver (A CSRB+ but I wasn't using the RJ11 part)

It was in the sun so the slave could have been triggering the whole thing. I would have also thought that the slave would ve deactivated when the CSXCV was installed (Yes the CSXCV was installed, Infact I never uninstall it as I tend not to use optical slaves)

On the next morning I was in my Garage testing, so no sun

yup, when I got my Einsteins and Cyber Commander, was setting up controls with the CC, I was trying to fire/meter one unit at a time (CSXCVs in each), but they would all fire. Turned out you have to go to each unit and step thru the screen to turn off the slave. Odd.

On the plus side, once you do that, the units come up that way the next time. So probably just once in a long while, after some reset or something, this problem will come up again, and maybe I'll remember quickly to go check the slave setting.

I would like the Einstein, smart as it already is, to also be smart enough to detect when I have the CSXCV installed, and disable the slave. It should also probably detect a normal trigger plugged into the sync cord jack, and disable the slave, auto enable slave if NO trigger is plugged in. The AB's work that way.

I am speculating that the CSXCV recognition change could be done via a firmware update, but the sync port recognition might be a hardware thing, so not a retroactive fix.

How come the sun triggers the slave? It's not flashing it gives continuous light. Can you guys fix it? It's not normal.

This only happens if the sun is hitting directly on the slave eye, when using a Vagabond, and when the slave eye is enabled, and I believe only after the flash fires initially. The engineers are aware that this happens. Turning off the slave eye will correct this issue.

Thanks for sharing.

__________________
Watch Piranha 3D Online Free