Understanding P-Bus

The Peripheral Bus protocol is a beautiful thing! Simple and flexible, it provides a way to control a fairly wide variety of devices from almost any switcher produced in the last 15 years. Utilizing a serial interface and just a few simple commands, P-Bus has become one of the most prominent standards for device control.

The hardware hookup is a simple serial line running from the switcher to the peripheral device (such as a DVE or Lance controller). The serial ports can be RS-232 or RS-422 as long as both devices agree on it. Also, many peripheral devices can be looped together on the same switcher P-Bus port yet individually addressed. Of course this means that ALL of them must use the same serial port setup (baud, parity, etc).

P-Bus is a one-way protocol, meaning that data flows only from the switcher to the peripheral devices. Further, there are only a very few commands that are sent. We will examine three of them: Recall, Learn and Trigger.

"Learn" is used to tell a device that the switcher is learning a particular E-mem register and it would like for the peripheral device to associate its current effect, register, still etc with that register number. In the case of a DVEous, if a "Learn register 06" command is issued by the switcher and effect 19 is currently recalled on the DVEous, the DVE will associate it's effect #19 with any reference to "register 06" from the switcher. Of course some P-Bus devices (like the Lance controller) are not that smart and will not make any such associations. These devices will simply assume their own registers by the same number.

"Recall" is used to tell a peripheral device that the switcher intends to recall a particular register and that it expects that device to recall one of its registers too. In the case of a DVEous, a recall request will cause the DVEous to recall the effect that it had associated with the register number the switcher delivers in the recall request. Of course a device like the Lance will only recall it's own register of the same number.

"Trigger" tells the peripheral device to perform a function such as "play", "rewind", "pause" and much more. Functions all have numbers, starting at 0 and there is not a standard definition for number to function correspondence. That is, function "0" on one device may not do the same thing as function "0" on a different kind of peripheral. When in doubt, start by assuming that "0" means "rewind" or "recue" and "1" means "run" or "play". It is up to the manufacturer of a peripheral device to determine how many functions will be implemented and how they will be numbered so check any documentation you have.

Each peripheral device must have an ID or Address. Since there can be lots of devices on a single P-Bus all listening at once, the switcher needs to let them know WHICH one it is talking to. Whether by DIP switches, jumpers or (more commonly) setup parameters, each device should be set to a different address. Truth be told, you could have two devices at the same address if you wished them to work exactly in parallel. For example, if I was producing two identical shows but with different DVE effects and I had two DVEouses (DVEoui?) then I COULD address them the same and load their corresponding effects each time I learned a new effect based timeline. Of course I doubt it'll ever happen and even in that instance it isn't advisable. But in any case, a command from the switcher is received by ALL peripheral devices on the P-Bus chain but ONLY the one(s) with the ID specified in the command will respond.

The actual data stream of a Recall command looks something like this: R 01 07

The first character is the command (Learn, Recall, Trigger), the second field is the ID of the device that is supposed to care and the third field is the E-mem register number that the switcher is claiming to recall.

The Learn Command looks the same way (except with "L" instead of "R").

The trigger also looks the same except that NO register number is given. Instead, that third parameter is the number of the function that the switcher would like to have executed by the addressed peripheral device.

I used the words "something like: The actual character string (you will NOT be tested on this part) is more like: R0020007

I'm just recalling that from vague memory and might be off by a couple "0"s so don't use it if you are interfacing your laptop to the switcher (yes, you can... I've done it).

Here is an example of what might transpire while you set up P-Bus function in your E-mems. We'll assume that you are working with device #1, a DVEous and device #2 a DNF controlled Digicart and that you do these things in order:

What you do	What the switcher sends	What the DVE does	What the digicart does
Recall effect 12 on the DVE	(nothing)	Effect 12 is recalled	(nothing)
Save E-mem 03 with Peripheral Learn State On for device #1, off for #2	L 01 03	Associates effect 12 with switcher register 03	(nothing)
Recall effect 11 on the DVE	(nothing)	Effect 11 is recalled	(nothing)
Recall sound file 5 on the DNF	(nothing)	(nothing)	Sound 5 is recalled
Save E-mem 04 with Peripheral Learn State On for devices #1 and #2	L 01 04 L 02 04	Associates effect 11 with switcher register 04	Associates sound 5 with switcher register 04
Recall E-mem 03	R 01 03	Recalls effect 12	(nothing)
Save E-mem 08 with Trigger #1 attached for both device #1 and device #2	(nothing)	(nothing)	(nothing)
Recall E-mem 08	T 01 01 T 02 01	DVE runs	Digicart plays

That's the gist of it! P-Bus is really simple once you understand what it's doing and now you know enough to hook up a Fast Forward device AND help your EIC troubleshoot it!