DMX vs CAN as Control Bus

[movax]

Hey all,

Designing a little control system for a NDA'd project. Basically, have 6 "projectors" that take the following inputs, as of now:
- Laser Brightness (via I2C DAC)
- Motor Speed / Direction (up to 3)

Right now, my design has them networked via CAN, and each node is powered by a dsPIC MCU. The dsPIC sports an integrated CAN controller, so I just need a cheap xcvr, like the MCP2551 also from Microchip. Using Rohm motor drivers, and the dsPIC comes in handy because of it's Motor Control PWM outputs (the Rohm IC is a bit funky when it comes to direction control as well).

Planning on using a standard USB<->CAN adapter with a good SDK, like something from Kvaser to interface with the PC. I've only got 3 CAN messages atm to carry all the data needed, and I think I can run the bus at pretty high data-rates, around 1Mbps because the cable length will be so short.

CAN has the benefit of being rated for "safety-critical" apps too which is nice, although regardless the protocol my firmware will kill off laser emission upon loss-of-communication. Would use Cat5(e) to run the CAN...with 8 wires in Cat5e, I wonder if I could carry CAN + 2 DMX channels in the same wire.

DMX would be around the same cost to implement, I'd just use a RS-485 transceiver like the SN75176B to interface with the bus. Right now I think I will leave room on the PCB for both interfaces (the dsPIC has enough pins to support both anyways) for flexibilities sake, but I'm curious to hear about members' here experiences with either protocol.

e: I don't think ILDA is applicable here, because these projectors have no XY control, etc, just what is described above. Perhaps projector is a misnomer.
e2: I think I'll leave DMX on there as well, as I may use these for some of the other laser units I have that are currently all analog, and would be interfaced via DMX in the future. Cheaper to make only one PCB and selectively populate it.

secondary questions
DAC IC - Laser has a 0V-5V modulation input. Is a 8-bit DAC granular enough, or should I look at 10-bit+ DACs?

[Solarfire]

Hi movax,

I work with and program CAN-Bus systems om a daily basis. I have also thought about CAN in laser systems but quickly discarded the idea due to the lack of support (if any) in show system software such as LD2000, Mamba, LSX ect., many already have DMX implemented.

8 bit for the modulation is sufficient, this is standard as far as I know.

[Picasso]

Ether Dream for the DAC (12-bit) http://ether-dream.com/ Could also use it for your motor control, if you want to go with say serial motor control from pololu.com as it has no CAN support or DMX at this time.

I'm a CAN fan myself. DMX is kind of sad for lasers from the safety stand point as you pointed out. I've even seen it used on a shutter.....to me not a good idea.

[movax]

Hi movax,

I work with and program CAN-Bus systems om a daily basis. I have also thought about CAN in laser systems but quickly discarded the idea due to the lack of support (if any) in show system software such as LD2000, Mamba, LSX ect., many already have DMX implemented.

8 bit for the modulation is sufficient, this is standard as far as I know.

CAN on a daily basis, my condolences (a professor of mine had this unhealthy...fascination with CAN, shoehorning it everywhere, even when not appropriate). CAN software support is definitely poor in show system SW, I agree, but this particular installation would not be driven by show software at all. This is more of an art installation, and let's just say the inputs to the system are provided by passerby/ambient noise. So there will be a application on the PC processing input data (video, audio, etc), and then using whatever USB/CAN SDK to turn them into CAN messages to drive the projectors.

Good to hear about the 8-bit though. I'm trying to condense into as few CAN messages as possible; right now I'm down to 3, which should result in low bus utilization, especially since the projectors will not transmit themselves, aside from the occasional heartbeat message.

Ether Dream for the DAC (12-bit) http://ether-dream.com/ Could also use it for your motor control, if you want to go with say serial motor control from pololu.com as it has no CAN support or DMX at this time.

I'm a CAN fan myself. DMX is kind of sad for lasers from the safety stand point as you pointed out. I've even seen it used on a shutter.....to me not a good idea.

That looks like a pretty beefy platform (skimmed the thread describing it over in the Adv. forum), but I think a custom application here would be better, especially since the # of motors could grow. Depending on how the project turns out, I may be able to release the hardware/software as open-source for people to start building CAN-based laser equipment. Is the HW for that open-source as well? Curious if it is 2-layer or 4-layer PCB-wise.

And definitely agree with you on the safety standpoint, DMX is just not a good idea for anything where safety is even remotely a factor.

[mixedgas]

Can being bidirectional and faster, and a "little" safer are its only saving graces. Having just spent six months working on a CT machine where everything but the data pipe (5.56 Gbits per second) was CAN, I see little difference in the physical layer over DMX, its just slightly more robust, but much faster. This is from a entertainment industry view, as up until now, there has been little need for bidirectional communications in the theatre/entertainment world. Few lighting fixtures have anything useful to convey back to the lighting desk. Winches and smoke machines on the other hand, have things to say.

Its all in the protocol, how collisions are avoided etc.

DMX was NEVER intended to be expanded to what it has become.

In 1986, 512 basic channels was more then most desks/CPUs could output, and few installations would ever comsume more then one DMX universe. 8 bits of motion per axis was a lighting directors wet dream.

DMX is like RS232, damn useful, but never intended to be stretched the way it has.

For a one off install, or something that needs to talk back, I'd do CAN, for a commercial product, I'd stick with DMX or use ethernet on a private network.

Steve

[Solarfire]

CAN has gotten a lot safer since the creation of CAN-SIL2 components/protocol, giving a much higher level of security mainly thru redundant messaging. Due to law changes in the EU all newly developed equipment which could be a safety hazard to the public, has to comply with the new CAN-SIL2 standard. Other than CAN-Open or J1939, CAN-SIL2 properly implemented will surely qualify for laser applications.

[movax]

For a one off install, or something that needs to talk back, I'd do CAN, for a commercial product, I'd stick with DMX or use ethernet on a private network.

Steve

This is what I was thinking, it is a one-off so CAN is probably the better choice.

CAN has gotten a lot safer since the creation of CAN-SIL2 components/protocol, giving a much higher level of security mainly thru redundant messaging. Due to law changes in the EU all newly developed equipment which could be a safety hazard to the public, has to comply with the new CAN-SIL2 standard. Other than CAN-Open or J1939, CAN-SIL2 properly implemented will surely qualify for laser applications.

Are there open docs on implementing/supporting CAN-SIL2 per chance, or is it a paid spec? When I was in the auto-industry we had AUTOSAR/OSEK and such, don't recall CAN-SIL2 off-hand though.

[mixedgas]

There is also always RS485 Serial. Uses a 1.75$ 8 pin dip transceiver chip.
Cheap, works, bidirectional, and quite safe.

Steve

[FourDee]

Also, beware ...

Last time i used the Microchip framework for CAN (about 2 years ago). It was far from bug free.
Don't trust any of the Microchip to set your baud rate. Program the registers yourself ...

[movax]

Also, beware ...

Last time i used the Microchip framework for CAN (about 2 years ago). It was far from bug free.
Don't trust any of the Microchip to set your baud rate. Program the registers yourself ...

Good to know. Hopefully their CAN application notes are halfway decent; I have a framework I use for all my Microchip projects (PIC18/24x/32, dsPIC) that gets my clock/oscillator control set up properly as well. Now looking for a cheap CAN<->USB interface. I need to order one for work, so I think I'll try out the Kvaser Leaf and see what it's API is like. C# bindings would be great.

[FourDee]

I used one from NI back when I did my experiments

[movax]

I used one from NI back when I did my experiments

I looked at their options, very pricey! The Leaf is only $300, so when that gets in I'll see how it works. The SDK looks very easy to use though, which is nice.

[FourDee]

http://sine.ni.com/nips/cds/view/p/lang/en/nid/203384

This one is what I used, also around $300
The NI has a hardware time stamp with 1µs precision, it seems the kvaser only does 100µs but that's depending on your application

[movax]

http://sine.ni.com/nips/cds/view/p/lang/en/nid/203384

This one is what I used, also around $300
The NI has a hardware time stamp with 1µs precision, it seems the kvaser only does 100µs but that's depending on your application

Oops, I looked at the prices with the ~$350 breakout box/connector block included. Now to look into the NI CAN API vs. the Kvaser CANLIB SDK in terms of ease-of-use and language bindings. Did you use LabView when you were working with the NI USB CAN unit, or did you use C/C# bindings?

Any thoughts on the reliability of USB? This installation I think could be installed as a fixture at some point (not actively maintained/monitored), so perhaps a PCI(e)-based unit may be better. If I pick the right API from the start though, it should remain hardware agnostic.

e: It looks like IXXAT makes inexpensive PCIe CAN cards, even based on the same FPGA I'm using at work to implement a few SJA1000s on. Might go with them, if not only to simplify migration if it ends up going USB->PCIe.

[movax]

Began schematic capture on Wed, and decided on using some of CUI's isolated DC/DC switcher modules as my power supplies on-board. Not that important for the MCU, but the isolated 5V supply should be nice and clean for the DAC (DAC is the only 5V component on the board). Still need to wait for KVANT/CT Lasers to fill me on details on the modulation input; all I know right now is that is 0V-5V, but no idea of the effective impedance that input presents to the circuit (i.e. how much current is it going to sink).

[j4cbo]

The impedance on a modulation input is usually 10k-100k, but sometimes as low as 1k. You'll want either a buffered DAC chip or some opamps.

[movax]

The impedance on a modulation input is usually 10k-100k, but sometimes as low as 1k. You'll want either a buffered DAC chip or some opamps.

Planning on the AD5301, which has a buffered voltage output. "High-speed" I2C should be sufficient speed-wise as well. If I turn out to need more precision, the 10-bit and 12-bit big brothers are 100% footprint compatible, which is nice.

Even if the impedance really does drop down to like 1k though, then I think something like the REF195 might be suitable to power the DAC + source current to the input. Since this is a one-off project, cost isn't a huge concern and I could implement a switcher to take 12V down to around 5.2/5.3V and then feed that to the REF195.