@ James -
If each relay is opto protected, the 12V support the receiver transistor and so the Relay primary, while the board supply support the emitter…Finally Relays ouput are dry contacts…In that case, I guess also that color LED are on the primary (emitter).
Knowing the number of opto on the module, is it possible that USB power is not sufficient to power the whole board and module ?
i have a new interesting bahavior to show to you.
see for yourself (i’m still uploading the video )! :
- YouTube
i simply let my application goes on for many seconds.
here is the only and entire code :
//This method is run when the mainboard is powered up or reset.
void ProgramStarted()
{
this.relayISOx16.DisableAllRelays();
GT.Timer timer = new GT.Timer(1000); // every second (1000ms)
timer.Tick += new GT.Timer.TickEventHandler(timer_Tick);
timer.Start();
// Use Debug.Print to show messages in Visual Studio's "Output" window during debugging.
Debug.Print("Program Started");
}
void timer_Tick(GT.Timer timer)
{
ledStatus = !ledStatus;
Mainboard.SetDebugLED(ledStatus);
Debug.Print("Timer");
this.relayISOx16.EnableRelay(RelayISOx16.Relay.Relay_10);
Thread.Sleep(1000);
this.relayISOx16.DisableRelay(RelayISOx16.Relay.Relay_10);
}
the debug led is blinking but the relays and the leds are not switching the same way at all. (look at 45s)
@ SENSEI -
Something is strange in you code !
You timer has a tick of 1 second, and you do a sleep of 1 second in your event, without managing re-entering of the event !
Try to encapsluate your event in e lock(object) to avoid anoher thread to enter it while one is already in !
It can explain why you have this situtation !!!
Or increase you initial tick to 5 seconds, and let you sleep to 1 second…
good idea, but exactly same behavior with
GT.Timer timer = new GT.Timer(5000)
;
In the video, I see that you USB module is red, so meaning that it can be plugged to an external supply. Can you try with !
I am having the exact same problem - my code executes for about 2 seconds and then the relay board freezes just like Sensei’s - exact same pattern of LEDs.
I have also tested with the USB module having external power.
@ Louis, even after powering the mainboard with a dedicated 5V 500ma power supply, the led is still red and global behavior remains the same…
@ nicholas.goodman : I LOVE YOU !!!
do you have the same mainboard ?
Yes. I have a Cerberus with a relayISOx16 board.
I just got the board today, and performed all the recommended firmware update procedures earlier:
SDK v 4.2, TinyBooter 4.2.3.3, Non Ethernet Firmware - modified 29-Nov-2012
@ nicholas.goodman : exactly the same for me except the Ethernet Firmware
@ Everybody : anyone has a relayISOx16 working ? please, tell us how ?? which hardware, firmware, software, powering, wiring ???
@ SENSEI -
As I see in your video, the Y socket yu use is on socket N°5. Did you try on other Y sockets ?
Ahah… it seems to be a problem with using sockets 5 & 6.
I have the relay board working and have tested that it works as expected on sockets 2, 3, 4, and 7.
Unfortunately, the configuration file that comes during install (C:\Program Files (x86)\GHI Electronics\GHI .NET Gadgeteer SDK\Modules\RelayISOx16\GadgeteerHardware.xml) incorrectly labels this device as a type S - socket.
This means the designer (by-default) only lets you attach the board to the two sockets which do not work for it.
Editing the TypesLabel attribute and from S to Y fixes this.
@ nicholas.goodman - You’re welcome !
Is there a bug-tracker for this software to check if the GadgeteerHardware.xml bug has been reported?
try this : http://gadgeteer.codeplex.com/
Will be interesting to see why it doest work on 5 & 6 as they are also Y as well as S etc.
This is not the appropriate site to report this, as the XML file is an issue covered by us, and was discovered today while working with the relays. It has been fixed and will be available in the next release of the SDK.
@ Justin - Because they are ‘S’, which is what the designer is waiting for, but which is not the module socket, that is Y !
But on the other Y socket, there are no ‘S’ at all !
It is a pure designer mapping problem !
Perhaps it has something to do with the rest of the socket definition:
<Sockets>
<!-- This example socket is compatible with socket type S, and it has electrical connections to pins 3,4,5,7,8,9, with 7,8,9 being shareable (SPI bus) -->
<Socket Left="70" Top="49" Orientation="180" ConstructorOrder="1" TypesLabel="Y">
<Types>
<Type>Y</Type>
</Types>
<Pins>
<Pin Shared="false">3</Pin>
<Pin Shared="false">4</Pin>
<Pin Shared="false">5</Pin>
<Pin Shared="true">7</Pin>
<Pin Shared="true">8</Pin>
<Pin Shared="true">9</Pin>
</Pins>
</Socket>
</Sockets>
I am too new at this to know any better, but apart from the Type and TypesLabel originally being S, it looks like the remainder of the settings are for S-usage.