Renard with talk back -- Brain storm

[holtm]

I've been thinking of working on a controller design that can talk back to the computer. I use addressable Renards (all boards receive the same signal) have the RS485 chip that can receive and transmit, but only the receive side is being used. I've been thinking that if the controller could talk back it could help identify comm issues, and potentially other issues such as power used, bad zero cross etc while they are in the field. I also realize that with comm speeds required to run a show, this would be a "mode" the controller would be put into and not used during the show times, but only during the testing or nightly at startup.

I'm just in the brain storming part of this activity, and thought maybe this excellet group could provide some input on what would be nice/fun to report back. Some/most may not be possible, but it's ok to dream isn't it?
Here is what I've come up with so far:

1. quality of packet received, (checksum?)
2. DC voltage on the board (volts)
3. current required to operate the SSRs (amps)
3. if AC power is to the SSR's (yes/no)
4. zero cross (Hz)

What else do you think I could look at?

[dirknerkle]

The idea of a bidirectional status update is pretty cool but it obviously wouldn't work in "show" mode since the Renard firmware is timed so darn close. But it would be slick as a special diagnostic chip. The other issue is that most Renard boards have two communication ports -- to rj45 jacks -- one IN and one OUT. To create the duplex communication needed you'd have to consider that circuitry, too.

Idunbenhad came up with an idea to make a Ren-W into a bidrectional "explorer" board, and I cobbled together a little adapter/dongle that would accommodate that. You could do a similar thing and with your proposed diagnostic code, it could be a nifty remote diagnostic tool, although it sounds like it would require replacing or reflashing at least one PIC on the controller.

[P. Short]

You also need to come up with some method of multiplexing the output from all of the PICs together. This needs to be done on both the hardware level (new boards, probably) and on a protocol/software level (so the boards don't all attempt to talk at the same time), and some piece of software needs to be designed to process the reverse-channel info and display it in some meaningful way.

Not impossible, just work.

[P. Short]

Also, the timing on the basic Renard firmware is not all that tight. The timing for Ren-C and the 'Simple' Renard firmware is much tighter.

[frankv]

If the Renard boards are daisy-chained, then each board/PIC would take information from its downstream feed and add it when it feeds it back upstream, the same but opposite of what happens when channel data gets sent out.

One potentially useful thing might be the addition of sensors, e.g pushbutton or other simple switches, movement sensors, ambient light level) which would allow for a more interactive display.

[ebrady]

If the Renard boards are daisy-chained, then each board/PIC would take information from its downstream feed and add it when it feeds it back upstream, the same but opposite of what happens when channel data gets sent out.

One potentially useful thing might be the addition of sensors, e.g pushbutton or other simple switches, movement sensors, ambient light level) which would allow for a more interactive display.

I was thinking along these same lines also. It would be a much simpler solution then implementing transmit and receive on the same pair of wires. Also,it allows for a more deterministic timing of the communication bus and lead to a simpler software implementation.

[IdunBenhad]

Hi:
As long as modifications have to be made, you might consider a "polled network" type of response back from the controllers. Software asks each controller in the system if it has any problems, waits for the reply and then goes to the next. As there is "no hurry" about the polls, it could fit in between packets or possibly use up a "channel".

Again, there are modifications to be made, both to hardware and software, but Phils addressable scheme for the controllers could also work in talk-back.

[dirknerkle]

Hi:
As long as modifications have to be made, you might consider a "polled network" type of response back from the controllers. Software asks each controller in the system if it has any problems, waits for the reply and then goes to the next. As there is "no hurry" about the polls, it could fit in between packets or possibly use up a "channel".

Again, there are modifications to be made, both to hardware and software, but Phils addressable scheme for the controllers could also work in talk-back.

Isn't it usually somewhat obvious that something is wrong when a string of lights doesn't operate properly? Does a person need "register polling" to confirm that the light is not working? What if the problem is with the COM section of the board -- you wouldn't get the polled information back if that's not working...

Maybe I'm not looking at this whole concept right, but I'm not sure what I'd do with the returned information anyway.

We had a guy who worked for us and he was always writing reports based on audit files our software would make, and he was always telling our coders we had this problem, or that problem and it was causing our guys to spend a lot of time trying to fix things. It didn't make sense to me so I looked at how he developed the reports, discovered he had an internal logic problem and the reports themselves were wrong while the audit data was correct. Needless to say he doesn't work for us anymore, but the point is that auditing systems must be very carefully crafted if they're to be of value.

And geez, this is Christmas lights. Is it the end of the world if a string or two don't light up some night?

[WireWrap]

With the cost of fiber-optic cable coming down, soon you can put a strand by each bulb and have the other end light up in your control room so that you can verify each bulb!!!

I'm not too far gone... gone... gone... :confused: :D :confused: :D

[BF210]

And then you need a way to detect when the detector circuit failed, and then detect the detector detector failure, and then detect the.....