Bob, from 360 Systems web site: "It also supports Peripheral Bus "E-Mem" commands, giving DigiCart/E direct control by popular video switchers. " Tavi, from 360's site as well, the rs-422 port can be used either with PBus or ES-Bus. You do have to change a config in the Digicart/E to tell it what protocol you are using. One client has both a Sony and a Digicart/E but I will not be near either for at least a month.

If you are trying to connect a Digicart via RS 422, then it sounds like you are attempting to control the Digicart via PBus. The Digicarts that I am aware of do not have a direct PBus interface built into the machine...you must first connect a PBus controller, such as a DNF, Lance, or Buff to the switcher via RS 422, and then connect the Digicart to the controller - the switcher will "talk" to the controller, which then translates the control signals to the native Digicart commands. If you're trying to connect the Digicart to be used as direct machine control, this won't work either, as the Digicart would have to be capable of "talking to the switcher" in BVW-75 or VDCP protocol - again, I am not aware of any Digicarts that have this software built in.

Hi all, I am Tavi from Romania Please help I try to connect a sound device (Digicart/E from 360 Systems) to a DVS 9000 with MKS 2700. I connect the machines with RS 422 cable. As far as I know I have sat the ports well, but it dosen't work. Could someone explain me the exact procedure. I am positive I miss something. Regards to all.

Thanks to all for the help. Mike, putting a 0 pause after the first cue command and using take for the macro solved the problem. Thanks a million. Joe N.

Okay, I'll take the bait (see below): Bottom line, I agree with Todd2. You aren't giving the DSR enough time to cue (step 2). That's why you get inconsistent results. The reason you were having success when you ran the thing upstream is your "cue" command at the end of the macro. The second time you'd recall/trigger this effect, it would work because you probably already had the clip cued, so your 3 frame delay wasn't handcuffing you...(Just my opinion). What we used to do was hit the macro to cue the clips, then the 0 pause in step 2 would halt the macro in progress, awaiting another trigger or "take". So the desired clip was on standby, awaiting your "take" command. When you hit "take", steps 3-9 occur. Once cued, you don't have to wait __ frames to see your transition. It's on the air as soon as you hit "take". Not a perfect system though: You always have to be cued in advance, so you have to know which transition you're going to need before your director does...Also, you have to endure the 0 pause. The trouble with this is, while sitting on a 0 pause, you can't use other macros or macro attachments. (I'm told in a later version of software, by hitting another macro while sitting on a 0 pause, you've effectively aborted the original, paused macro...true or false, anyone?) 1. Cue both dsr's. 2. 0 duration pause. 3. Play the dsr's, 4. key the dsr downstream. 5. Pause __ frames (variable...not all clips required the same delay before under-transition). 6. Execute the wipe, dissolve, or undercut on the PGM/PST bus. 7. Pause __ frames until clip runs its course. 8. Lose the key 9. Stop the dvr's.... or something like that...now CNN's DSRs are toast (I think), and Nexios are in place. Nexios cue faster and you can gang two clips in the nexio itself so you don't have to wait for two dsrs to cue (I don't recall what the feature is called)...Sony speaks quickly and directly to Nexio via VDCP. I have a feeling I should proofread this...Nah...

[quote="JNewberry"]Bill and Matt, The macro is to best of my memory as follows: 1. Cue both dvr's. 2. Pause 3 frames. 3. Play the dvr's. 4. Pause 8 frames. 5. Execute the wipe on the ME (delayed 8 frames to match the mask) 6. Pause 38 frames. (about the time it takes for the wipe to execute) 7. Stop the dvr's. 8. Cue the dvr's. I have tried extending the pause between cue'ing and playing (up to about 30 frames just to see if this was the problem), and it did not give me any solution. I am going to try cueing the dvr's, pausing, playing them, pausing, and then cueing again when I go back to work on wednesday, any other ideas? If I start putting to many pauses in I'm going to have a 2 second delay before the effect happens. Thanks for the responses. Joe N.[/quote] The one thing that sticks out a little is the cue at the end of the macro. Do you run this same effect over and over, or is this one of many effects that run the same way. Some DDR's, when it is cued and you send out another Cue, it cues it again, creating untimely plays, this would seem to more of a problem with clips rather then timecode based DDR's, which is what I think the DSR's are. Maybe easy thing to check is to try a zero pause after the re-cue. Then it waits for you to hit macro take to play the DSR and run the effect. Worth a shot. Also in this scenario get rid of the re-cue. I know CNN uses this setup, sony DSR's with 8K under device control.. I think they built them with zero pauses. Maybe one of them can chime in. Or any former CNN TD's :) Bill

Bill and Matt, The macro is to best of my memory as follows: 1. Cue both dvr's. 2. Pause 3 frames. 3. Play the dvr's. 4. Pause 8 frames. 5. Execute the wipe on the ME (delayed 8 frames to match the mask) 6. Pause 38 frames. (about the time it takes for the wipe to execute) 7. Stop the dvr's. 8. Cue the dvr's. I have tried extending the pause between cue'ing and playing (up to about 30 frames just to see if this was the problem), and it did not give me any solution. I am going to try cueing the dvr's, pausing, playing them, pausing, and then cueing again when I go back to work on wednesday, any other ideas? If I start putting to many pauses in I'm going to have a 2 second delay before the effect happens. Thanks for the responses. Joe N.

[quote="Bill D"]Not sure why wrong time code would cue. But this would be one place to start first I think.[/quote] I used to use a DD-35 hooked up to a Sony MAV-555 through the device control. Same thing would happen if the MAV was not stopped before the next clip was cued (although it did not happen all of the time). On the DD, I had a macro that would cue the MAV to timecode. Then I used another to roll the 2 channels (key and fill), transition the ME, and then stop the MAV on a delay after the effect cleared. Never had a problem that way, only if I recued the effect with the MAV still rolling. Like Bill D said, though, if you want a one button execution, build a macro that cues effect, pauses a few frames to allow the DSR to cue, play, transition, then stop DSR after effect clears. Same deal with not giving channels enough time to cue... channels would not roll, roll out of sync, or play late. We had a 3 channel out MAV, and 1 and 3 were the fill and matte, respectively. Since channel three was a card swap (originally the MAV was 2 in, 2 out that we changed to 1 in, 3 out) it always seemed to lag a couple of extra frames behind whatever channel 1 was doing. So whatever you decide, make sure you give your DSR plenty of time to cue and then go into stop (or standby if that is how you have it set up). Hope this helps... Todd

Does your play command have a delay after the cue command? I would ideally put a zero pause in there after the cue. Then hit take to finish your effect, play undercut, etc. If you want a one button solution try playing around with some 5-10 frame pauses before the play command. This will give them time to recue and be ready to be played. Not sure why wrong time code would cue. But this would be one place to start first I think. Bill

Matt, We are controlling them through the device menu. I beleive engineering told me these particular machines won't work with pbus. Our fill is device 5 and our key is device 6 (I beleive). I'm not sure what you mean by port, does that answer your question? Thanks, Joe

Joe... How are you controling the DSR? P-Bus or DEV? If you are using DEV, are both your key and fill controlled by the same device port? Matt