01-03-2018 09:28 AM
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.
01-03-2018 09:43 AM
@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.
01-03-2018 09:44 AM
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
01-03-2018 09:57 AM
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!
01-03-2018 01:12 PM - edited 01-03-2018 01:15 PM
I was thinking something like this....
A lot of "Inside Out" from your approach
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.
01-03-2018 01:32 PM
@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!)
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.
01-03-2018 03:03 PM
Hi
Just a quick question : how about to use these new tools ?
01-04-2018 04:29 AM
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?
01-04-2018 04:47 AM
01-04-2018 04:56 AM
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.