DMX Clock

[lighters]

I'm looking to build a DMX controllable clock as a practical project for my course, but need to do a bit of research before I dive in.

 

I would love to have something that you could set the time on to any time, and then set running (with a variable speed), but I have a limited budget and limited time so I am aiming to do one or the other. What I would like to know would be:

 

Would people prefer to have a clock that you could set to any time with ease, but would then not run (without constant updates of information setting it to the next position).

 

OR - would people prefer to have a clock that you can't set the time on (without running it all the way round and round to get there) but you can run forwards/backwards at variable speeds.

 

I think the latter would be easier to build, but I need to work more on both ideas.

[MarkPAman]

Having once spent 5 nights with my almost only job being to set a clock at every scene change, :( if you can only do one, then it must be set the time.

[roryfm]

Set the time.

Shouldn't be too tough - 2 channels (one for Minutes, one for Hours), a PIC or similar to decode the DMX and output PWM to 2 servos. Your biggest problem is likely to be the concentric drives required which I believe has been discussed in the other topic of this name.

 

Good luck

 

ror

[LeeStoddart]

Set the time.

 

That would allow you to do either because a set of cues from the desk would achieve the movement. I would assume this would need to drive a traditional clock with hour and minute hands rather than a digital clock.

 

Do we really need two channels? 12 hours * 60 minutes = 720 increments. 256 values in a DMX channel would give us a resolution of two and a half minutes - probably not, especially if we wanted the hands to be able to change in view.

 

But if using two channels with one as hours and the other as minutes the clock circuitry would have to be clever enough to interpret the minutes with the hour so that 3:15 properly places the hour hand 1/4 of the way between 3 and 4.

[pyromonkey]

Might be worth looking Gobo Indexing. as channel layouts allow you to index or rotate.

[mark_s]

Set the time. If you can set the time then you can (theoretically) set the speed too just by updating the channel value at the desired rate. Whereas if you can only set the speed, you're a bit screwed when you want it to show a specific time :(

[Wuddy]

Hi,

 

This topic has cropped up elsewhere on here quite recently but I can't find the thread.

 

Brian posted details and links of how to build a DMX clock, his device used a DMX to stepper driver and the mechanics were made from Meccano.

[mark_s]

He isn't looking for instructions to build one; he wants to know what we'd like said DMX clock to do, given a choice of one or the other.

[Wuddy]

He isn't looking for instructions to build one; he wants to know what we'd like said DMX clock to do, given a choice of one or the other.

 

I'm looking to build a DMX controllable clock as a practical project for my course, but need to do a bit of research before I dive in.

 

I would love to have something that you could set the time on to any time, and then set running (with a variable speed),but I have a limited budget and limited time so I am aiming to do one or the other. What I would like to know would be:

 

My Blue just thought that with limited time and budget an already published and working design, which I think will fulfill both objectives, might be a help.

[mark_s]

But nicking someone elses work and using it for a project might not be too wise ;)

[Tomo]

Set the time using a 16-bit attribute, and possibly a 'mode' attribute that chooses between index and continuous rotation.

 

- The last bit is purely software, so you can start with telling the time and expand functionality if time permits.

[dbuckley]

Having thought long and hard about this recently, I determined that DMX512 wasn't the best thing to control a clock.

 

Having decided that (as per Brian's design) it would be stepper motors and meccano, the challenge then was how to control the stepper motor. Brian used an off-the-shelf DMX512 to stepper module, but I took a different line of thinking, purely because having a DMX512 controlled cloock seemed "hard".

 

So I came upon the Little Step-U, available from Parallax dearlers worldwide, that has stepper motor smarts and an RS232 interface. What I started building then (until the project ran out of need) was a PowerBasic front end that basically provided a very glorified set feature, and that did all the sums that worked out how many steps per second (or seconds per step) were needed to get the clock to where it needed to be when it needed to be there.

 

And here is the older thread with the good stuff in it

[Tomo]

Having thought long and hard about this recently, I determined that DMX512 wasn't the best thing to control a clock.

Wrong.

Who is in constant communication with the DSM?

What have they got sat in front of them?

 

Most theatres already own something that has a good user interface and spits out good DMX.

They also have suitable distribution to get that signal to an onstage practical.

 

It's irrelevant that the protocol wasn't designed with clocks in mind - DMX wasn't designed with moving lights in mind either!

 

While the two best ways to control a clock are to use the NTP time protocol or the Rugby* time signal, these aren't suitable for something that is to be changed during blackout and/or at cue from the DSM.

 

(*Or other local time signal)

[dbuckley]

When the only tool you have is a hammer.....

 

You are, of course, welcome to your opinion, and I find your arguments good in parts, as DMX512 distribution is a standard. Where your arguments fail are in your choice of control tool.

 

What makes a DMX512 desk suitable for controlling movers is not the protocol per se, but that the desk has the vocabulary to control a moving light effectively. It is possible to control a moving light using a simple two preset desk, but it's hard going.

 

It is well possible to control a clock using DMX512, and it has been done, because after all DMX512 is just bytes of data, but a DMX512 console is another matter. Mover vocab is different to clock vocab, and although you can probably make it fit, it's going to be, at best, inelegant, and not operate in terms of HH:MM:SS or in terms of time compression or expansion, or even "set to real time", or "go from wherever you are now to hh:mm:ss in 90 seconds". So you are trading a poor user interface for electrical ease, and it is the natural tendency to not do that. Of course, for all I know, the Congo may have a clock module that does do all these things, in which case DMX512 may be the perfect protocol, if only every desk had a clock module.

 

Theres nothing magic about DMX512 for control of stuff; I submit that Vari*Lites didn't use DMX512, and neither originally did Martin movers. Yet both did things that we commonly do with DMX512.

 

The lack of direct support for time in any of the tools I would use to do a show is why I (started to) designed a user interface that does have the vocabulary, and that interfaced with a protocol that encapsulates a command set that is relevant to the task at hand. RS232 at 2400 baud travels for the necessary distances down standard mic cables, so infrastructure isn't an issue. Lots of stagey stuff uses RS232, so it's not like its a foreign protocol. PCs are readily available, and many shows will already have one or more to run a trivial application.

 

In terms of actually working with a protocol controlled clock; Theres'a a lot more to this malarky than one might first think. How, for example, does the clock know what time the hands are pointing to at power-up?

 

I gave this whole thing a hell of a lot of thought, and found all the pieces of the puzzle (with thanks to Brian for the pointers) for the perfect stage clock. You post here more than I do, thus I assume you follow whats going on, and thus will be aware of at least some of this, this not being the first DMX clock thread. To have you dismissing what amounts to quite a lot of investigative work it with a simple "wrong" I find quite disappointing.

 

Edited to add: One of my (currently, unsatisfied) goals of doing this clock thing was to build it in such a way and document it such that it was possible for others to build one easily, needing no special mechanical or software skills, the only hard bit being requiring knowing someone with the ability to knock up a very simple one sided PCB which is just a carrier for a off the shelf module. I still think that is a laudable aim. Thus using easily available stuff (like a PC) was part of the original constraint set.

[Tomo]

in which case DMX512 may be the perfect protocol, if only every desk had a clock module.

You don't need that - just a sufficiently flexible personality/template editor.

 

Should I feel so inclined, it would be relatively trivial (albeit extremely boring) to knock up a template that mapped the attributes to HH:MM references.

Any console that supports arbitrary named attribute ranges can do this.

 

The move you mention is again simple for any console that understands LTP attributes - and saves you (the device designer) from all the very tedious calculations for the movement.

- Unless you want to do those and have a 'movement speed' attribute, which is useful for long, smooth moves.

On the other hand, this is a clock - most real ones don't move smoothly but have a definate 'tick'.

 

Anyway - for the hardware, here's a few suggestions at various complexity:

1) Have a look at rotating gobo wheel assemblies in moving lights - these have two independant co-axial motor/gearbox assemblies and one or more sensors to find a 'zero point'.

- Very cheap ones can be had off EBay and the like, especially as the donor unit as a whole doesn't need to work!

2) Replace the control circuitry in a standard clock module - these use a two-pole stepper motor. However, finding the 'zero point' is harder!

3) The final is the Meccano method - again, finding the 'zero-point' is non-trivial.

 

Two magnets and a Hall sensor could be one approach to finding the 'zero point' - put a magnet on the Hour and Minute hands, and a Hall sensor in a position where both magnets can be waved over it.

Depending on whether you mechanically tie the hands together or not you can develop a suitable method for locating the system - it's harder if they are mechanically connected, but still perfectly possible.