LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Making A Reminder Function

Hi suba,

 


@suba_25 wrote:

I understand that we could use array but I am not sure on how to start with multiple alarms within the array.


Before starting with "multiple alarms" you should handle a single alarm! Did you already solve that problem?

 

What have you tried so far? Why don't you attach your VI?

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
0 Kudos
Message 11 of 15
(710 Views)

For this to work you need code that will run on server somewhere so that it can send emails based on some date / time trigger. If you get this code to run in LabVIEW the application will need to be running all the time for it to take the action to email a reminder. Maybe look at https://ifttt.com/explore/new_to_ifttt 

 

LabVIEW is awesome but there is a learning curve to it and there are easier ways to do what you are trying to do. 

______________________________________________________________
Have a pleasant day and be sure to learn Python for success and prosperity.
0 Kudos
Message 12 of 15
(683 Views)

this is what i tired so far, I couldn't set 2 or more alarms.

0 Kudos
Message 13 of 15
(647 Views)

If your code is scalable, creating the code for one alarm is sufficient, then you and use an array of alarms of any size.

 

You really need to simplify your code. An event structure with a 1ms timeout is just plain silly, unless you want your reminders with that kind of precision (will not work anyway, because these notification will be much slower!). Since you are spinning the loop anyway, a simple case structure would be sufficient. Decide on a reasonable loop rate and place a wait.

 

Hours and minutes are integers. Don't make them orange!

 

It is confusing to have a boolean labeled "x". Give it a name that hints at the function! Since you use it as a "fake variable", it probably should not be a control unless you want the operator to be able to change it any time he wants.

 

You have a glaring race condition due to blatant overuse of local variables. Your "x" terminal will get read way before the local receives a new value from inside the event. 

 

Back to the drawing board!!!

0 Kudos
Message 14 of 15
(643 Views)

See if this can give you some ideas. No, it is not finished but you can easily expand it for more functionality!

0 Kudos
Message 15 of 15
(631 Views)