eStopping using TCP/IP for laser control?

[Sandstorm]

Ok, so I had been encouraged to start a thread about this, since it's not so obvious.

With regards to thread about extending cables (http://www.photonlexicon.com/forums/...tension-Cables) and some eStopping demand (I hope) we all are seeing (in case of smth similar to MOBO awards http://www.photonlexicon.com/forums/...jor-***FAIL***), here comes a question:

If I'm about to send signal to lasers using net cable and TCP/IP protocols to cover long distances, how should eStopping be implemented? While everything is analog (that means, having DAC at hand and extending ILDA cable in various ways), that's pretty simple, i.e. one can simply break laser modulation signal to 0V (the most straight-forward approach). Whereas if one has DAC hundreds of meters away and sending encapsulated digital packet to control it... there are 2 options: a) implement E-stop at the program level, which wouldn't work in case of jamming the line or PC crashes; b) lay one more cable to control DAC externally (MIDI or DMX signal?); c,d,e...) ...?

Which is the best way? which is most error-proof (well, Estop MUST be error proof...)? Which is least consuming (cheapest/easiest to implement)? Which is most selectable (shutting one laser while leaving others, "show must go on" etc.)

Sure the simplest non-selectable approach is having power plug at hand... but i believe there are better ways

[The_Doctor]

Sending some message to the DAC is doable, but I suspect that in addition, eventually, people may decide on a second method as backup, in case the main signals fail.

MIDI used to use (still exists, but not many instruments seem to use it now) a special 'system realtime' message called 'active sensing', one byte (I think 0xE0) every few hundred milliseconds. Not fast enough for scanfail, but likely fast enough for making a projector go dark if it loses signals from its source. As those signals arrive a lot more frequently, maybe the answer is to make them constant rate where possible, and use that as a basis for safe shutdown. The idea is that if the lack of signals can be trusted to stop it, and if the presence of some verification byte can also be trusted if it's sent with rapid periodicity, then it should be possible to trust the data stream enough to carry a shutdown signal.

What will eventually happen is anyone's guess, and it may depend on how dangerous the laser is. In a wired system (no RF, optic link), it might even be as simple as putting pure DC on the signal line, or grounding it to 0V.

[dnar]

I personally prefer a system that is fail safe, that is as soon as the cable breaks the system shuts down. I use the Stanwax ILDA board with this function and use CAT5 / RJ45 for the cabling.

[norty303]

I will probably implement estop over the cat5 unused pins using breakout boxes each end. 1 cable to do it all. Thanks to Mark Insanity for that one

[dnar]

I need to show you my control box for sats. FB3 mounted inside, parallel D25's for each Sat and a switch to flip X on sats stage left. I use the ILDA interlock pair for my shutters, so a single Estop button at FOH in the same box covers all sats. I wired the key switch and Red button in series with the FB3 interlock pair.

Room in the box to mount my other FB3's when I get off my arse.

[Sandstorm]

I will probably implement estop over the cat5 unused pins using breakout boxes each end. 1 cable to do it all. Thanks to Mark Insanity for that one

Your post made me check through TCP/IP pinout. Is it really half of wires (brown and blue) in CAT5 not used? That gives loads of potential

[The_Doctor]

Your post made me check through TCP/IP pinout. Is it really half of wires (brown and blue) in CAT5 not used? That gives loads of potential

Interesting hangover from telephone wiring maybe? That has an A wire and a B wire, in a cable of four wires. Sometimes a third wire gets uses for ground, I think, or maybe some local interphone signalling, but in most UK systems as far as I know, there is only a need for two. I never knew any definitive reason for this redundancy of wiring.

My first post mentions MIDI's active sensing, as an analog for what might be done in TCP signalling. In other words, 'not only not disconnected, but viably connected and receiving known good signals'. TCP can carry so much data that this duality of status could be explored.

No-one else has mentioned it yet. Wired lines will allow simpler means, but what will you do when you want an optical or RF link? There's no reason this can't fail safe. There may be questions about reliability of line in a noisy location, but unless the laser MUST stay on the way a hospital MUST be able to call on an ambulance, I imagine this might be worth trying. TCP/IP has a history of good signals so long as basic conditions for setting up such links are done right. A simple secured wireless link might work. In a big place, even CAT5 cable might cost more than two wireless access point boxes.

PS. Was it just me, or was PL down with some script error for about half a day?

[hitekvoop]

Your post made me check through TCP/IP pinout. Is it really half of wires (brown and blue) in CAT5 not used? That gives loads of potential

As long as you stick to 100Mb/s you're fine. Gigabit requires more than 2 pair.

[dnar]

This thread has been done before... Its groundhog day.

[Pockels]

Interesting hangover from telephone wiring maybe? That has an A wire and a B wire, in a cable of four wires. Sometimes a third wire gets uses for ground, I think, or maybe some local interphone signalling, but in most UK systems as far as I know, there is only a need for two. I never knew any definitive reason for this redundancy of wiring.

I believe the 3rd is the bell wire, which used to carry an electical signal to phones that used an old fashioned ringer and is no longer required. I disconnected mine from the engineers socket to stop some attenuation that was killing my broadband to the router in another room.

PS. Was it just me, or was PL down with some script error for about half a day?

Yeah. I tried PL most of last night and got the same script error!