Power saving strategy

I'm doing hourly measurements WEBGETING them, what method would save more energy
LOOP or LOOP having long WAITs, or other?
thanks

Because Ethernet can only work on fixed speed, we can not lower the clock frequency.  Without lowering clock frequency, there is not much power saving other than not do any IO activities.

CAI_Support said:

Because Ethernet can only work on fixed speed, we can not lower the clock frequency.  Without lowering clock frequency, there is not much power saving other than not do any IO activities.

Click to expand...

ok thanks, my questions was if you consider a longer wait in the PLC programm as chance to put (part of ) the system to sleep. Nothing we can do on the user side. For testing that I have now introduced a DELAY 3000000 after the measurement and upload has taken place, this should give enough time to wake up for the next Event one hour later.
My alternative would be an external relais switching the whole thing on and off.

Efried said:

My alternative would be an external relais switching the whole thing on and off.

Click to expand...

A lot depends on if there is anything else that needs to be done during the hour.

If not then an external timer would work well. In addition to the timer function your
hardware can monitor important external stimuli and control power to the WebControl.
Have the WC force power on in case the stimuli goes away before the software has done
what it needs to do. Once the important stuff is down have the WC kill power waiting for
the next important event.

I've done several WC projects, most run 24/7 since I want to be able to access the web
Interface. The one I use with our wood stove has external hardware to wake it up under
different conditions.

/tom

Tschmidt said:

A lot depends on if there is anything else that needs to be done during the hour.

If not then an external timer would work well. In addition to the timer function your
hardware can monitor important external stimuli and control power to the WebControl.
Have the WC force power on in case the stimuli goes away before the software has done
what it needs to do. Once the important stuff is down have the WC kill power waiting for
the next important event.

I've done several WC projects, most run 24/7 since I want to be able to access the web
Interface. The one I use with our wood stove has external hardware to wake it up under
different conditions.

/tom

Click to expand...

 
I agree, Tom.
I have a couple in service where power is at a premium. I have a tiny little PIC as a "power manager" and watchdog. One output drives a high-side switch (basically emitter-follower) that turns on the WC board. Other inputs come from an output on the WC (an edge-triggered "keep-alive") and a couple of stimulus inputs that represent conditions that the WC must turn on to handle.
 
The PIC and it's regulator take about 2mA (99% of that is the regulator). When the WC is finished doing its task, it sends several pulses in rapid succession, which the watchdog takes as a "power-off". If the watchdog doesn't see a pulse in a defined time, it turns the power off and back on. If a stimulus input changes state, it turns the WC on. Otherwise, the PIC leaves the power off for a set period and then turns the power on anyway. The PIC is a tiny 8-pin device that can do long time delays with reasonable accuracy, with no big timing capacitors, and can be quickly re-programmed for different times.

WC8 power usage is directly related to the CPU frequency. When lower its CPU frequency, its network interface will not work, temperature sensor will not work. If those are not a problem, we could introduce a PLC command to lower CPU clock.  In that mode, majority CPU time probably wasted in waiting for network timeout.  REBOOT PLC command can bring the board out of from that state.  However, since CPU may wait for network timeout, it may take a long long time before executing the REBOOT command.

CAI_Support said:

WC8 power usage is directly related to the CPU frequency. When lower its CPU frequency, its network interface will not work, temperature sensor will not work. If those are not a problem, we could introduce a PLC command to lower CPU clock.  In that mode, majority CPU time probably wasted in waiting for network timeout.  REBOOT PLC command can bring the board out of from that state.  However, since CPU may wait for network timeout, it may take a long long time before executing the REBOOT command.

Click to expand...

no worries, I'm aware of the relationship between MHz and power demand. If others see a demand I would opt for two PAUSE commands.
One putting the WC into sleep (SLEEP) and one lowering frequency (IDLE) to that point so WEBGETS from other WC may wake up the called idling WC. 

@Efried,
If network is disabled, it could not get wake up by WEBGET, since it does not receive it.  It has to be something else to wake up it.

Our developer is working on adding a PLC data type LSLEEP to enable low speed sleep mode. The thinking is to let user's PLC code to make WebControl enter low speed mode that only check for certain IO during sleeping and execute PLC code without network enabled.
 
However, there is one problem with that is: if user wrote PLC code wrong, he has no choice but hardware reset the board to wipe out all configuration then reconfigure everything, since that user can no longer through web interface to reload PLC code until that board is reset.
 
Any suggestion on that?

I don't see that annoyance as a critical issue.The problem will only occur during development/debug so losing the config is not a huge problem. Just be sure to document the feature well, warn of the side effects, and make the default power management state disabled.
 
/tom