LabVIEW
Automating Button Clicks
If you mean the Read button, then yes.
Inside the Event Structure that handles the button press, all it's doing is sending a User Event.
Create a timeout case in the same Event Structure, then send the same user event. Set the timeout to 1000ms and you're done 🙂
Edit: in fact, just go to the Read case, then right click on the border and choose "Edit Events handled by this case" then on the left, click "Add Event". Select "Application" from the middle column then Timeout from the right column. Complete by wiring a 1000 to the hourglass at the top-left of the event structure.
Hi,
@jackson040 wrote:
VISA Write in MB Serial Transmit.vi:630007->MB Serial Master Query.vi:1850006->MB Serial Master Query Read Holding Registers (poly).vi->Platinum_MB_SerRead.vi->Platinum_MB_Example Serial Master.vi
So that's not really an error code, it's the call chain for the error - i.e. it tells you where the error occurred. If you go through those VIs (from right to left, starting at your main VI then working into the subVI in the bottom loop's Read case and then into their subVIs) you could see where the error originates.
What was the error code? (i.e. not just the top bit of the message, but the number and perhaps the explanation text?)
@jackson040 wrote:
Does the timeout set for the read button also impact the write button?
No. The write button is separate. Do you need both to happen once per second?
@cbutcher wrote:
If you mean the Read button, then yes.
Inside the Event Structure that handles the button press, all it's doing is sending a User Event.
Create a timeout case in the same Event Structure, then send the same user event. Set the timeout to 1000ms and you're done 🙂
Edit: in fact, just go to the Read case, then right click on the border and choose "Edit Events handled by this case" then on the left, click "Add Event". Select "Application" from the middle column then Timeout from the right column. Complete by wiring a 1000 to the hourglass at the top-left of the event structure.
This approach assumes that no other events occur during the 1 second. I think that in this case it will generally work - but if, for instance, the user were pressing Clear Error once every second then the timeout will never occur. For this reason I don't like using the timeout for timing. I would just send the Read command every 1 second in its own loop - it's just sent via a queue.
@johntrich1971 wrote:
This approach assumes that no other events occur during the 1 second. I think that in this case it will generally work - but if, for instance, the user were pressing Clear Error once every second then the timeout will never occur. For this reason I don't like using the timeout for timing. I would just send the Read command every 1 second in its own loop - it's just sent via a queue.
OP mentioned 'about once a sec', so it might be enough. I'd probably use the timeout, but set it to 100 and use Elapsed time instead.
/Y
@johntrich1971 wrote:
I would just send the Read command every 1 second in its own loop - it's just sent via a queue.
Whilst it's true that this is a better approach from the point of view of ensuring a read, I figured an extra loop would perhaps overcomplicate the situation.
OP, if you anticipate pressing lots of other buttons frequently, but don't want to press the read button, you will need to use the idea suggested by johntrich, and add a 3rd loop with timing that enqueues the Read command.
I also wasn't a huge fan of the code duplication inherent in adding either another case or another loop...
@cbutcher wrote:
@johntrich1971 wrote:
I would just send the Read command every 1 second in its own loop - it's just sent via a queue.Whilst it's true that this is a better approach from the point of view of ensuring a read, I figured an extra loop would perhaps overcomplicate the situation.
OP, if you anticipate pressing lots of other buttons frequently, but don't want to press the read button, you will need to use the idea suggested by johntrich, and add a 3rd loop with timing that enqueues the Read command.
I also wasn't a huge fan of the code duplication inherent in adding either another case or another loop...
As I stated, it will probably work in this case although @Yameada's idea to use a shorter timeout with an elapsed time improves upon it (if the timeout is 1 sec then a button press just before the 1 sec is up will cause that iteration to be nearly 2 sec). I was just pointing out the pitfall with this approach that could cause trouble down the road (plus could cost points on the CLD-R exam https://forums.ni.com/t5/Certification/CLD-R-Question-6-paper-1/m-p/2590721) when more complex programs require more precise timing. I generally just use the timeout case for indicator updates or other things for which precise timing is not a requirement.
First time I've seen a question for CLD-R, so that's interesting to know the sort of level/topic.
That aside, I guess it's dependent on the situation. Of course you're clearly right that timeout doesn't guarantee timing (or even occurrence, in principle), and Yamaeda gives a nice alternative to reduce the impact of other events whilst also avoiding too much added complexity (although probably that solution requires two separate cases rather than one case with two conditions).
I felt this was more or less for "indicator updates" but I may well have been wrong. Hopefully the OP can give some clarity 🙂
