Hello,

I figured out how to program a fast up/down counter, but am wondering if there is an easier way. (file attached) Basically to increment a variable while holding a key down, I created a state machine with 2 states, transitions between the 2 states, and a 3rd transition connection state to self. Key press enters state with continuous loop, start timer, increment variable, key up exits state.

Is this a good way to do this or is there an easier way? I have a lot of these to do, and I know I cannot copy/paste state machines. I am also quite unfamiliar with scripting (I knew Pascal and Fortran back a number of years...)

Attached file demonstrates up only.

Thanks,
Phil

You have the right idea drphil69.

There is something you can do to avoid creating a lot of state machines but it involves scripting.
You can make generic state machines and instead of calling calculation events you call scripts and the scripts call the appropriate calculation event or modifiy the parameter directly.
For the scripts to know which one is the parameter you want to change you need to keep track using a global script variable or a user defined variable.

Here is some sample code:

Decrement Fast Decrement Fast Increment Increment Select Appropriate Parameter

Thanks ksaenz. I appreciate your help. I'm not sure how you connect the proper parameter to the subroutine within the program... would you happen to have a sample program to share? After reading through the manuals I am basically learning by pouring through programs.

You mentioned creating a generic state machine... presumably this means I can manipulate many parameters with this one machine... I know how to call a state machine, but how do I "select appropriate parameter?" For example, if I wanted to use the same state machine to increment brightness, speed, quantity, how do I tell it which param I am working on?

Thanks!
Phil

Be cautious with using key down / key up combinations. I have sucessfully gotten systems stuck in the endless loop. There are at least 2 ways this can happen, and you can only safeguard against 1.

1) If the screen changes views (state change, alarm, button press, etc.), then the key will become mapped to the new screen, making the key up event not happen (unless that screen also supports key up). You can safegaurd against this my forcing the same event as the key up on a screen change.

2)Due to the button matrix design of the display, if a button is being held, then a second buton is pressed in the same row or column is pressed and held, and the the original button is released, the system will not capture the key up. This is because of the interference between t buttons in the matrix. Operator education is the only way I know to safegaurd against this.

I modified your test configuration to change the value of two different variables using the same state machines.

• When you enter a view it calls the script to select the calculation events for the parameter you want to change. (To fire an event/script when you enter a view right click on the view and select "Advanced").
• When you press the "inc" button, it calls the generic "inc" script that calls the calculation event for the parameter you want to change.
• When you press the "dec" button, it calls the generic "dec" script that calls the calculation event for the parameter you want to change.

ksaenz,

Thank you thank you thank you!!!!

One thing more I hope you can answer, I see that the event "Select B" is fired when showing the view "MainPageView\B." I cant seem to figure out how.. or where.. that is done...


mbowdich,

Thanks for the warning - I read that in previous posts, I think from you. It is good to know and I will warn my customers not to push multiple buttons.

Phil

ksaenz,

I found where you fired SelectA on view. I did not know that it was there (right under my nose)! That is a very helpful find for me!

Thanks again!

Phil