Laser emergency stop over ethernet

[mccarrot]

With your solution you will need extra LAN cable to the projector for the shutter/power control.

The advantage is you do not need to modify the switch and QM.net, but I have allready put the QM and switch in a box with Neutrik RJ45 sockets (good stuff) and a DOUBLE ILDA port with XY invert switches so this modification was easy for me.

I do not have the knowledge to mak a IP polling switch, and I also like to keep it simple.
But the idea is good, but will it affect the network if you need to poll 10 or more QM.nets?

[andyf97]

It will not effect the network as all the devices are all slaves that respond to the same IP source. Ie they are all waiting for the same info, keyswitch, power on/off.

the idea is they only sit there listening and dont send any data.

[andyf97]

An interestimg site full of litte modules that I suspect could be a starting point

http://blog.makezine.com/archive/200...ce_hardwa.html

[aijii]

It will not effect the network as all the devices are all slaves that respond to the same IP source. Ie they are all waiting for the same info, keyswitch, power on/off.

the idea is they only sit there listening and dont send any data.

Okay.. so the master control box sends multicast packets out... the recievers listen for them..

pretty easy. the only problem is, even THIS is a little complex.. i mean, you're relying on software being coded in such a way that will never result in the reciever mistakenly believing it's receiving the watchdog codes when it ain't...

The other thing, i think turning off a projector is a little over kill, i think hitting hte shutter button should just drop the shutters int he lasers...

turning off teh qmnets when you hit the stop button is bad becuase it may crash livepro... or make it a little unhappy

[andyf97]

Hi Aijii

The idea here is to have a kill all "option" and I think in Europe it must be like that.

The shutter will be off anyway if you activate it from live pro.

The key switch is a manual operation that usually doesn’t take off the main power to a projector so it can be like a function of the remote power unit that means just replacing the projector key switch with a socket and the remote power has a relay to toggle the key switch input.

Also with this system, you can add other features, maybe turning off specific parts of the projector. It should never be used as a show function selector as that should be done with DMX, but for a few features that are required for every projector, it could be handy, just as a thought during setup and alignment of zones you might want to use 10% power on all projectors for safety especially if many CCD devices are in the Hall.

In the code for the master module it could be coded based on option switches that are fixed on the main PCB. Like DMX address switches.

Based on what option switches are set, what actions do we take when the red button is pressed, power off all, power off just the QMNET, power off only the projector, when the key is switched, what to do , re-boot all QMNET, key switch off the projectors, the possibilities are endless as the code is quite simple.


Regarding what the master sends out, this needs to be a very short packet almost like a ping, but in this case the remotes do not reply, I think they can even all have the same IP but as they do not broadcast there presence on the LAN. I am not so sure about this part but if I remember, you can have many simple coded microchips connected to a LAN that sit there only listening for specific data. Don’t think that is too complex for a coder and there is tons of packet sniffing code out there.

So the system I believe will be very safe, as safe as using your QMNET on the LAN is.

[heroic]

You can't give them all the same IP address since that will upset the switch. IP addresses are resolved to MAC addresses by a thing called an ARP table. Multiple MAC addresses for a single IP address will lead to the switches getting confused, desynced, and either delivering all the traffic to one host or not delivering it at all.

However, there's no real reason to use IP at all in a product like this. Why not just use raw ethernet frames? They are not routable, but if you're routing this traffic you need to think seriously about end-to-end reliability anyway.

[andyf97]

I suppose its actually cleaner to give them there own IPs. I guess that way will result in less overall network traffic or collisions. I think also the wiznet modules in QMnets can have all there IPs set easy enough so why not. At least then its all a standard on the LAN.

The idea is the projectors do not work unless correct data is being received by the remotes. So when we think like this, its harder to make them work than to not work.

Just had another thought, this can also help to check the LAN, lets say that master pings these remotes now and then for a LAN health check. A simple LED on the master control can show if any packets were lost and also from which remote. This would be great as it could help to identyfy dodgy connections in the installation.

Oh here we go, and now we need a small lcd to show connected remote power controllers, then a touch screen to switch individual projectors off.

You know you could have several estop switches located around an arena, maybe one on the stage.

I smell a new product in the air.

[aijii]

ip multicast will solve the issue. so have the transmitter transmit multicast packets, and the receivers listen out for the specific multicast address. That is if the wiznets support multicast.

which they should

[aijii]

ftp://ftp.efo.ru/pub/wiznet/HowtoMul...ng_En_v2.0.pdf

yep... they do easy peasy

[aijii]

Just had another thought, this can also help to check the LAN, lets say that master pings these remotes now and then for a LAN health check. A simple LED on the master control can show if any packets were lost and also from which remote. This would be great as it could help to identyfy dodgy connections in the installation.

this is easy to achieve... i have a few ideas

I smell a new product in the air.

so do i nice...