Fezz Hydra with IO60P16

Archive
1

I’m using a fezz hydra powered by external powersupply conected with an enc28, relayx16 and io60p16 module. Through the network i send messages to the Hydra and start a relay after a delay of x seconds. I’m using the io60p16 with Interrups to start the relays directly when the interrupt is fired–> GitHub - ianlee74/IO60P16: Custom driver for the GHI IO60P16 Gadgeteer module.

I have connected the GND of the io60p16 to my external powersupply GND, this should set all components on the same GND.
The problem that occurs is that after a few days, the interrupts are not being triggered. After resetting the board, interrupts work again. Is this still related to software issues with I2C in NETMF?

The code I use to work with the triggers


private void ProgramStarted()
        {
            // Logger
            _logger.PrintSDCartContent();

            // Init network
            try
            {
                _client.InitNetworkCard();
                _client.MessageReceived += ClientMessageReceived;
                _client.StartListening();
            }
            catch (Exception e)
            {
                _logger.WriteMessage(e.Message);
            }

            // Init IO60P16
            _ioModule.Reset();

            new InterruptPort(_ioModule, IOPin.Port4_Pin0, ResistorMode.ResistivePullDown, InterruptMode.RisingEdge);
            new InterruptPort(_ioModule, IOPin.Port4_Pin1, ResistorMode.ResistivePullDown, InterruptMode.RisingEdge);
            new InterruptPort(_ioModule, IOPin.Port4_Pin2, ResistorMode.ResistivePullDown, InterruptMode.RisingEdge);
            new InterruptPort(_ioModule, IOPin.Port4_Pin3, ResistorMode.ResistivePullDown, InterruptMode.RisingEdge);
            new InterruptPort(_ioModule, IOPin.Port4_Pin4, ResistorMode.ResistivePullDown, InterruptMode.RisingEdge);
            new InterruptPort(_ioModule, IOPin.Port4_Pin5, ResistorMode.ResistivePullDown, InterruptMode.RisingEdge);
            new InterruptPort(_ioModule, IOPin.Port4_Pin6, ResistorMode.ResistivePullDown, InterruptMode.RisingEdge);
            new InterruptPort(_ioModule, IOPin.Port4_Pin7, ResistorMode.ResistivePullDown, InterruptMode.RisingEdge);

            _ioModule.Interrupt += IoModuleOnInterrupt;
        }

        private void IoModuleOnInterrupt(object sender, InterruptEventArgs args)
        {
            if (args.PinState == true) return;
            _logger.WriteMessage("Interrupt triggered " + args.PinId + " " + args.PinState + " " + args.Timestamp);
            _parser.QuickStart((byte)args.PinId);

        }

        private void ClientMessageReceived(object sender, MessageEvent e)
        {
            _parser.Run(e.Message);
            Debug.Print(e.Message);
        }

Is there something I’m missing, or should I read the register by using polling and not the interrupts? Or do I need to use another component to get 30-40 interrupt inputs?

I have seen the DL40 io on codeplex but is this working stable on Hydra?

2

When you say interrupts, I assume you mean directly connected switches or similar? So does that mean the device still responds to the network?

Have to attached a debugger and seen what is going on? Use MFDeploy and connect to the device, and see what is being reported; you may have missed an exception or have something else causing the issue, and attaching a debugger is usually a great start.

3

I have used a 24V DC power supply that is connected to a switch and the 24V is converted to 3.3V to trigger the pins on the IO60P16.

But I have read the forums that alot of people had issues with the IO60p16 with interrupts on a Hydra, regarding softwareI2C etc. So I was wondering if this setup is ready to be used in a production envrionment?

I did have problems with my prototype when the IO60P16 was not connected correctly to GND, when I connected the GND to the ground the interrupts worked stable, But it seems it is very sensitive for GND fluctiations, when being used with sunbeds…

So the interrupts are triggered by the sunbed when a person presses a button to start the sunbed lamps sooner than the default delay of x minutes.

I was not aware that the MFDeploy could be used to read logs or debug information on the fly, I can try that when the problem occures… But what I see with the floating GND is that the relays and io60p16 start to flip and toggle relays @ random or interrups are not firing again or they fire the wrong pin… So it seems difficult to detect by a debugger I believe…

I also have an SDcard that I can use to write the logging to aswell but I don’t get any exceptions in there…

4

make sure in all your handlers you have debug.print output telling you why you got there. Then connecting via mfdeploy will show you that info and you can tell if the interrupts are spurious or not.

Fundamentally, the question on IO60P16 is one only you can answer. Personally, to go to a real production quality I’d want to create a real relay driver board myself.

I still don’t really understand what your interrupt inputs are nor why/how you’re using relays. I assume you’re not triggering a relay and expecting that to then trigger an interrupt on the IO60p? It’d be great if you could elaborate, if possible, but I realise it seems like this might be for a “product” and you may not be able to - if at least you can generally describe the hookup that would help.

5

Have you tried just sending a reset to the IO60P16 occasionally? Depending on your situation, this may not be an option.

I think GHI finally squashed those bugs but you can always try setting the HARDWARE_I2C compile option in my driver. It’s the only way I was ever able to get that chip to be reliable. It’s been quite a while since I’ve touched it, though.

I don’t think the GHI driver supports interrupts.

6

I will double check the DL40IO firmware with the Hydra over the weekend, but if I recall correctly I originally developed the firmware using the Hydra as the primary mainboard and interrupts where the first thing that I implemented and tested, so I believe they should be stable with the Hydra.

7

Ok a good tip to use the Debug.Print with mfdeploy thanks.

The setup I’m using for the product is → that I use the Relay ISOx16 (https://www.ghielectronics.com/catalog/product/391) to connect the sunbeds. These sunbeds get a 230V AC trigger from the relay to start the sunbed. So the common is connected with L from wall socket. The NO is connected to the wire of the sunbed. the sunbeds on there own are connected to a different power circuit (3phase 380V ac). So they are totally seperated.

I also placed a VDR to protect the relay contacts from peak current when closing the contact.

My computer program sends a message to the Hydra which contains a startup delay in MS and how long the sunbed should be turned on. Then I use a timer with a cycle of 250ms to check if one of the sunbeds is ready to be started. If the startup delay is met the relay will be started for the period defined in the message. After that the relay is being turned off. Why I use the IO60P16 is to let the customer start the sunbed sooner than the startup delay. (else they would get a cold :-))
The sunbeds have a button that just closes the circuit from the 24V DC power supply to the IO60P16 port (there I use some 24v dc to 3.3V dc convertor port with some Z diodes and resistor and capacitors) So these interrupts are read from the Hydra to set the startup delay to 0 so the next timer trigger the sunbed would start.

8

I think this would be OK todo on a low level frequency, if the customer notices that the sunbed does not turn on, he or she will trigger the button again. I presume that the reset command does not take more than a few miliseconds?

I can also try to use the hardware I2C as well.