06-30-2015 03:02 AM
i'm doing in this way:
main thread -> numeric dial callback -> event val changed -> get lock -> set value to device -> release lock
second thread -> get lock -> read request -> read response -> release lock
06-30-2015 03:10 AM
What happens if you change from val changed to commit event?
06-30-2015 03:17 AM
is the same.
now i have a lock that don't process event and the software freeze for a while and sometime doesn't change the value,
if i change the lock to process event the software don't freeze and sometime doesn't change the value
06-30-2015 03:23 AM
it's not working bad with the process event lock, it's happen rarely. i think i can keep it in this way
06-30-2015 03:59 AM
still have problem, i have this idea:
in the second thread create a switch case statement with this case:
request_value
wait_value
send_setpoint
in the main thread if i want to send the setpoint i set a flag and get in the right case
06-30-2015 05:45 AM
holly7787 ha scritto:
still have problem, i have this idea:
in the second thread create a switch case statement with this case:
request_value
wait_value
send_setpoint
in the main thread if i want to send the setpoint i set a flag and get in the right case
I don't understand exactly what you are saying with that: can you explain it a bit more detailed?
I would try changing the UI function this way:
Loop { TryToGetLock Exit if lock acquired ProcesSystemEvents Sleep (10) } Send command to device
Keep this function to the shortest possible.
This way the user interface remains responsive and you should be able to send the command to the remote device. It can be a problem if the user hits the dial too frequently.
06-30-2015 06:17 AM
tried your way, i have to test it more but seems ok.
i was thinking to do something like this
while(quit) { switch(function) { case request_read: comwrite go to wait_value function break; case wait_value: comread go to request_read break; case setpoint: break; } } UI callback { go to setpoint function }