Thread: Anyone interested in serial controlled Relay/Input card?

Is it ready? Would someone build them that I could purchase? What OS would the software work on?

Thanks

Check this controler/relay: Parallel Relay control for XP coming soon

Whenever this does get done, as Ricky mentioned before, I'll be writing an open source windows dll plugin for it in C++ that can be called from any language. I already have a plugin format for relay controls that I used for a parallel port relay control for the output portion and is a super set of the girder plugin format, so it will be compatible with girder.

The plugin will be just a light wrapper over the actual hardware functions, it will be up to the calling program to implement the more specific things like synchronized setting off of multiple relays.

I will also release a windows service type of program that can run in the background and allow more direct access to the device without writing code.

I am also writing a commercial software program. This is what the plugin format was initially made for. The program allows you to map each relay to a relay set, when the relay set is triggered, it will set each relay to either off or on, whichever you specify, and keep at that state until a user spedified timeout for each relay is reached or you manually reset the relay set. The program will also use girder plugins, so the input portion of this device can be used to trigger events in the program.

Oh! I have another idea. Can you add an option to make it send like a 1 or 2 byte status report when an I/O changes state? I think it would give it a faster response time and cut down on traffic. Polling is outdated IMO. I'm really making this complicated huh?

Well according to Rick327, the current idea is that the hardware will send out status at 10-100Hz

Example :
$STATUS 10011001,10111001,1F,10,11,FD
$STATUS 10011011,10111011,1F,11,11,F1
$STATUS 10010001,10111011,1F,12,11,F0

I will be writing the plug-in to use a seperate thread for actually reading data from the serial port so the program will never lock because it is waiting on or reading data from the serial port, it will also only try to read data once it is recieved, although at 100Hz it should recieve data more or less continuously.

Since we need to be reading the data for the analog input ports at a pretty high refresh rate to calculate things i.e. 0-60 from a speed sensor, this is probably the best way to do things and adding the status of the relays to the status of the analog input ports should be negligible.

I will have some sort of event driven mechanism that will be triggered when either an analog input changes or the relay status changes etc sent out to the host program of the plugin. This will be calculated by the plugin, i.e. if the last value was 120 and the new value as read from the STATUS message is now 125 an event will be triggered.

I just got through reading this and I'm wondering to myself why so complicated? It seems like this is most likely going to be a get or set event right? So why not use the 8 bit nature of the pic to your advantage and make everything a bit masked event. I.E. the first 6 bits represent the io device. Bit 7 is a get or set and bit 8 would be the state. This gives you access to 64 io pins and does not require more than 1 byte per get or set. On a get for a device the reply could be the first 6 bits representing the device number and a second byte representing the state of the device. This would encompass both the digital status and analog as well.

Now you have a loop the polls each value and when a value has changed you send the device byte and the state byte out the serial port. Then a serial interupt would handle all incoming serial requests and process them accordingly. This would also increase the throughput of your application up to 7 times what I saw was possible.

Originally Posted by pauldy

I just got through reading this and I'm wondering to myself why so complicated? It seems like this is most likely going to be a get or set event right? So why not use the 8 bit nature of the pic to your advantage and make everything a bit masked event. I.E. the first 6 bits represent the io device. Bit 7 is a get or set and bit 8 would be the state. This gives you access to 64 io pins and does not require more than 1 byte per get or set. On a get for a device the reply could be the first 6 bits representing the device number and a second byte representing the state of the device. This would encompass both the digital status and analog as well.

Now you have a loop the polls each value and when a value has changed you send the device byte and the state byte out the serial port. Then a serial interupt would handle all incoming serial requests and process them accordingly. This would also increase the throughput of your application up to 7 times what I saw was possible.

The post you read is outdated

Post #46 already mentioned that and alot of things had already changed and not being posted in the thread...they go through PM


I guess god_of_cpu should have mentioned what this exactly means.

Example :
$STATUS 10011001,10111001,1F,10,11,FD


This is the format :
$STATUS [RELAYS],[DIGITAL INPUTS],[ADC0],[ADC1],[ADC2],[ADC3]

The first 8 bit binary on the left represent the current status of the 8 relays. The second set of binary represent the 8 digital inputs and the last 4 HEX represent the read analog values. This whole STATUS string is updated at 10Hz - 100Hz at always a fixed string lenght.

The status of the relays and the digital inputs is reprented in 8-bits binaries purely for human readability for easy diagnostics. The analog values is left presented in HEX, it can be made into decimal by Im not gonna bother.


Changing the state of the relays is done by sending the command as follow...it can be in this format :

Individual relay control :
$RELAY 0,1 = Turn RELAY 0 ON
$RELAY 1,0 = Turn RELAY 1 OFF

Simultanous relay control :
$RELAY A,10100111 = Turn all 8 relays ON/OFF as defined by the 8 bit binary

Again its done like this for easy operation in hyperterminal for diagnostics or experiments. Although pure binary format can be done for speed and simplicity but using the relay board with binary format can be difficult in some situations...take it as NMEA against SIRF protocol

Still nothing is 100% set at what format it should be at.

Originally Posted by Curiosity

Oh! I have another idea. Can you add an option to make it send like a 1 or 2 byte status report when an I/O changes state? I think it would give it a faster response time and cut down on traffic. Polling is outdated IMO. I'm really making this complicated huh?

Its better to update all the status in one string. The analog values need to be updated in a constant rate anyway so why not update the status of the relay and digital inputs with it. The post above explain all that

Originally Posted by Jeep

Check this controler/relay: Parallel Relay control for XP coming soon

Thats a nice piece of kit. Only if it was tailored made for car PC then I would have bough that instead. The size of the board is also a little too big for what it is.

Originally Posted by TruckinMP3

Is it ready? Would someone build them that I could purchase? What OS would the software work on?

Thanks

Its all on paper together with abit of PIC code Ill publish the whole design, schematics, PCB, source code and the documentation when done. It can be built on strip-board if you like. The idea is so that most people in here can build it...parts are easy to souce. Programming the PIC maybe the only problem for some. Danceheaven and god_of_cpu will write the software for it

Is it possible when you go over 20km/h to auto-lock the doors?? But it should then know that doors are locked so that when you stop ie. at a stoplight it shouldn't lock again!! Is this possible?