LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Starting events at specific times of the day?

Solved!
Go to solution

True, but it's just polling, I don't think it causes any problems - the producer sits in the timeout and the consumer sits in a wait state when nothing is going on. The clock display skips seconds if the timeout is > 1 second. 

0 Kudos
Message 11 of 21
(1,586 Views)

@grahamwebb wrote:

True, but it's just polling, I don't think it causes any problems - the producer sits in the timeout and the consumer sits in a wait state when nothing is going on. The clock display skips seconds if the timeout is > 1 second. 


If this in reply to my earlier comment regarding the timeout setting of 10 ms you may be correct for this particular example. However it is always a good practice to think about how your code is designed so that as a system expands these types of things don't byte you in th ebutt later. Given the types of events you are triggering there is absolutely no reason to check the condition 100 times a second. This wastes CPU cycles without providing any benefit at all.

 

These are the types of things to consider to make sure the code you produce is efficient, expandable and maintainable. It falls under the heading of best practices.



Mark Yedinak
Certified LabVIEW Architect
LabVIEW Champion

"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot
0 Kudos
Message 12 of 21
(1,579 Views)

This is version 2.

 

I couldn't get the time check down to milliseconds because that required a lower timeout value and it got a bit jittery. But the worst that happens is events are duplicated if a manual event is called while it is handling an automatically triggered event. 

 

Any ideas how to get LV to wake up the PC from sleep? 

 

G

0 Kudos
Message 13 of 21
(1,577 Views)

Ah yes I was originally trying to stop filling up queue when an event occurs, hence the quicker timeout value. I've added the new/old event comparison, but still, within the timeout the precision of the clock comparison is governed by the timeout value, and hence how long it sits writing to the queue. 

 

i.e if you can compare the clock to the nearest second there is one second where you can't trigger any other events (not that I want to though). If you compare to the nearest millisecond the timeout value needs to be lower otherwise it skips over the value. oh I could use greater or less than. Doh! 

 

 

0 Kudos
Message 14 of 21
(1,566 Views)

I was thinking something like this....

A lot of "Inside Out" from your approach

Capture.PNG

This snippet (using a couple of sweet VIM's) triggers an event to ring the correct number of ship's bells on time.

 

You might note: this is an Event Consumer Loop!  Powerful if used appropriately and I would argue Correct for this approach since the events trigger "On Time" regardless of whatever the User is doing.


"Should be" isn't "Is" -Jay
0 Kudos
Message 15 of 21
(1,549 Views)

@grahamwebb wrote:

 

Any ideas how to get LV to wake up the PC from sleep? 

 


Configure the computer to not sleep.

 

Looking at your code, there are some odd things, for example why do you use these unusual mechanical actions (e.g. "switch until released") and "mouse down" events. Wouldn't "latch action" and "value changed" be much more reasonable?

 

"quit LabVIEW" is like the abort button and will not allow the lower loop to complete the close state. Some of your event will lose the queue forever, because it is not wired across (e.g. "sleep"). I would probably let the program come to a normal shutdown before shutting down the computer (etc.) once all loops have completed.

 

Your upper timeout event is pure rube goldberg. An equal false and equal true is just plan silly (see also, read the entire thread!). For example an "equal TRUE" just returns the input unchanged, same as a plain green wire!

Since you reset the shift register in most other events, it is potentially possible that the scheduled action triggers multiple times within the same second.

 

To detect a raising edge, just do a comparison as follows It will return true if the current value is TRUE and the previous value was false. (there is even this function!)

 

Off-ON.png

 

 

Scheduling: Personally, I probably would use a third loop with an event structure dedicated to the scheduling where the timeout is kept in a shift register. Whenever a new Time&action is added it can figure out what should happen next and recalculate a new timeout. When a timeout occurs, it can process the action and recalculate the next timeout, etc. No polling needed.

0 Kudos
Message 16 of 21
(1,545 Views)

Hi

Just a quick question : how about to use these new tools ?

 

0 Kudos
Message 17 of 21
(1,522 Views)

With the raising edge detection, I put the various methods together to see what the fuss is all about - this illustrates how compact the feedback node is, and that there are many ways to do a task. 

 

But I can't pretend to be great at optimising code Altenbach, large sections of my code appear in that Rube Goldberg thread! 

 

 

Re. the other points, yes I haven't gone through the flow yet. 

 

It looks like no-one has used LabVIEW to wake-up a PC from sleep, perhaps it is trickier than it seems at first glance?   

0 Kudos
Message 18 of 21
(1,495 Views)

Hi Graham,

 

why do you post the same buggy VI again?

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
0 Kudos
Message 19 of 21
(1,490 Views)

grahamwebb ha scritto:
 

It looks like no-one has used LabVIEW to wake-up a PC from sleep, perhaps it is trickier than it seems at first glance?   


If the PC is sleeping, all the applications therein are sleeping too.

Only some logic into the PC BIOS is able to wake it up.

The Wake On LAN technique is an example of this; it requires an external action, i.e. something outside that sends the magic Ethernet packet to the PC NIC.

 

Paolo
-------------------
LV 7.1, 2011, 2017, 2019, 2021
0 Kudos
Message 20 of 21
(1,483 Views)