mLink 1ch (HCMODU00182), 2ch (HCMODU0183), And 4ch (HCMODU0184) I2C / Parallel Relay Modules

[lewsut]

Thanks Andrew,

Unfortunately this pushes me into using the mLink library that currently doesn't support alternative i2C busses? (I'm using C/C++ not python currently)

I guess I'll either have to edit the lib or scrape out the bits I require to make this work.

Yes in principal what you have suggested would solve my problem, however I had not read too much into the library as I can't currently easily make use of it.

However you do state this time is stored via NVM so perhaps I could programme it separately via the default wire on another MCU then hit the relays via Wire.write. I'll have a play around and report back

[andrew]

Unfortunately this pushes me into using the mLink library that currently doesn't support alternative i2C busses? (I'm using C/C++ not python currently)

I guess I'll either have to edit the lib or scrape out the bits I require to make this work.

However you do state this time is stored via NVM so perhaps I could programme it separately via the default wire on another MCU then hit the relays via Wire.write.

Quoted from a different thread...

I'm mostly a C/C++ guy I'm unlikely to use this board with Rpi and thus Python so I'll whip something up to utilise wire1.

Sorry, I forgot about our previous conversation and so was assuming you were using an Arduino. So am I correct in assuming you're using the module with a Raspberry Pi but your current plan is to use C++, not python (so that you can use it with an alternate I2C port) ?

[lewsut]

Hi Andrew,

Sorry I didn't make it clear there is no PI involved in this project, purely "Arduino" (ESP32).

I thought you said in the previous post that there was no easy way of using the library with a different bus in C++?

I think I have this issue sorted, I'll add timers to all relays via a different Arduino, then use my code that currently works to switch the relays.

Update: Tested and almost working, it seems I can't override the timer with Wire.write, rather annoyingly. So i am sending a command to open the relay and it just waits for the timer to finish, that's not ideal.

[andrew]

Sorry I didn't make it clear there is no PI involved in this project, purely "Arduino" (ESP32).

I thought you said in the previous post that there was no easy way of using the library with a different bus in C?

My apologies also, for some reason I was under the impression that you were using a Raspberry Pi. But that said, the issue is the same for the Arduino mLink library. For I2C communication It makes use of the standard Arduino wire library. This library (AFIK) does not have any option to specify an alternate I2C port.

Update: Tested and almost working, it seems I can't override the timer with Wire.write, rather annoyingly. So i am sending a command to open the relay and it just waits for the timer to finish, that's not ideal.

I would not recommend making repeated writes to the timer registers anyway. Although it is quite high, the NVM that is used to store the timer value only has a limited number of writes.

Each time you retrigger the relay it resets the timer even if it is currently running; so, would setting the timer to say 5 seconds then just repeatedly re-triggering the relay within that 5 seconds period work for your application? I.e. a dead man's switch?

[lewsut]

I would not recommend making repeated writes to the timer registers anyway. Although it is quite high, the NVM that is used to store the timer value only has a limited number of writes.

I am only setting the timer once using another MCU that I can use the standard bus, it is not being repeatedly written. This was just for testing of how the timer worked.

Each time you retrigger the relay it resets the timer even if it is currently running; so, would setting the timer to say 5 seconds then just repeatedly re-triggering the relay within that 5 seconds period work for your application? I.e. a dead man's switch?

Not in this instance, consider my application. I have a valve that is automatically, or manually overridden. I would like to be able to turn on and off these valves as I please (I can do this without the library obviously). I pulse the relay board with a byte every second, it's nice to see the relay board flash and I can implement any missed state changes, and when used, to refresh the countdown timer.

Now the issue comes when or if there is a loss of comms, that's where the library's timer is seemingly perfect... unless you wish to turn it off within that timing to off's time. I have a GUI where I can (could) open and close the valves as fast as I would like, however this ability is lost with the timer. I believe this timer should have an interrupt to cancel if a new command is received (I believe) .

So my choices are, a fast and responsive GUI to valve control, with no loss of comms mitigation (this could end up with a stuck open valve and water everywhere). Or A slow GUI where I have to wait a second for my valves to close and no loss of comms fail safe... this is also annoying as it looks bad and i can easily over fill a container in just 1 second or less.

There are many boring and arduous ways to solve this, however it would be nice if the relay time could be interrupted and superseded with a command, especially an important one like deenergise.

[andrew]

Ok, I think I understand your situation. Simply you want the relays to automatically de-energise after a set period of time without any software interaction (in case the software crashes), but you also want to be able to override an energised relay at any point. Which I agree, it would be a nice feature to override an energised relay in timer mode.

I don’t think setting the timer to 0 would be a good solution though as it can encourage repeated writes to the timer register(s) and potentially wear out the NVM. Not an issue for you of course, but potentially a problem with other customers.

Another option could simply be a case of changing the firmware so that setting the relay low overrides the timer. The potential issue there is that it will change the behaviour of the relay and we already have a lot of these in the wild so I’ll need to have a think if that would be a significant enough change to cause a problem with repeat customers.

A firmware feature update of course doesn't help your current problem but I can’t think of any workaround beyond what you have already suggested.

[lewsut]

Thanks for taking the time to reply, I think that about covers it. I'm testing various i2c relay sets and this is about the most comprehensive and ultimately editable one so far.

I'm from an industrial PLC control system background so I'm probably far to cautious about loss of control and Comms... and not being able to cancel a timer on an output is a big no no.

I'll keep an eye on your products the are useful!

[lewsut]

Hi Andrew,

Finally back to this part of my project again, I assume no firmware revisions have been made in newer releases?

Is there any reason you need to have seconds rather than millis for the relay times. That would fix my issue. Entire seconds is a long time! If a float was used that would change nothing for existing applications, 0.2 / 200ms would be lovely!

Code: Select all

#define RELAY_0_ON_TIME    0
#define RELAY_1_ON_TIME    0
#define RELAY_2_ON_TIME    0
#define RELAY_3_ON_TIME    0

[andrew]

Hi Andrew,

Finally back to this part of my project again, I assume no firmware revisions have been made in newer releases?

That’s correct, there hasn’t been any firmware updates since we last spoke so operation/functionality of the modules is the same.

Is there any reason you need to have seconds rather than millis for the relay times.

Only because a relay is a relatively low speed switching device and a 1 second resolution with a 16 bit timer seemed to give a more useful range. Tbh, I really didn’t think there would be a use case for switching the relays quicker than a second.

If a float was used that would change nothing for existing applications, 0.2 / 200ms would be lovely!

I will try and pencil in some time to look at this, and the previously discussed feature. I don’t think it could be done by switching to a float though because a float is a 4 byte value compared to the current 2 byte int value. That would require changing the register map which is set in stone now. One possibility could be to add an extra register that allows the timer increment to be switched between 1 second increments or 100ms increments and have it default to the 1 second option.

I’ll check the code to see if these features can be implemented. However, I don't think I’ll be able to get to it within the next couple of weeks. It’s a busy time of year for us, and I’m currently working on a new product, but I will have a look as soon as I can and get back to you.

[lewsut]

Thanks Andrew, remember the sub 1 second is not for an actual switching of the relay it's a fail safe so that if a poll update to keep the relay activated it will deactivate as a fail safe as per my above convocations with you. (Sorry, I'm just thinking of walk-arounds without changing the base system)

In the meantime I have bought another relay from you that shall act as a "dead man's switch" the old set of 4 relays shall be powered via the new relay with a 1sec timer-off on it. Therefore if the new relay is not polled within 1 sec ("comms issue detected") it will deactivate the old 4 relays.

Currently I have a HMI screen with outputs to a solenoids, sometime increments of 10ml are required and that is absolutely sub 1 sec, it also make the interface snappy and responsive rather than waiting for 1 sec when you send a deactivation command (while keeping the fail safe, obviously).

Cheers,

Lewis