Is it ready? Would someone build them that I could purchase? What OS would the software work on?
That will be all based on the software controlling the card plus the actual wiring and where it connects too, also dont forget that just because the card has 8 relays doesnt mean 8 outputs think of it more or 8x8 = 64 if the card can source enough current then we could have 64 outputs, am i right in saying this ricky?Originally Posted by kingtut
Also if this is the case then i would fit a 8 way connector on the card that is connected to the drive circuitry before the relays that way we could just use the signal lines rather than relay outputs, you could fit jumpers to enable the relay outputs or diable them for example
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
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.Example :
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
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.
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.
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 thatOriginally Posted by Curiosity
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 Jeep
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 itOriginally Posted by TruckinMP3
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?