I use interrupts in embedded applications with small uP’s for a variety of uses. Whenever possible, I prefer to poll a condition rather than to use an interrupt. In this way, I can control exactly when in an application the action will occur, and can control when a bit of code can be insured of executing completely without being suspended. I have also used interrupt disable and enable commands to protect a bit of code, but I have found it just as effective to dispense with interrupts completely and intersperse polling commands where and when it makes best sense to do so. Xojo has its own idea of priorities and order of events that I have not been able to manage to fill the needs of my application.
[quote=“Wayne_Miller, post:97, topic:67391, full:true”]
Here’s my problem: My main thread is called upon by the user to perform a sequence of tasks that involve interrogating a piece of test equipment to deliver data, operating on that data, then instructing another piece of equipment to change the parameters of a unit under test, storing the data, getting more data, changing parameters again, and, after numerous iterations, to operate on the data and to store the results to a file. Each step must be completed in sequence, but what I find is that the main thread continues to the next step without waiting for the given step to finish, so that the main thread barrels along and finishes the sequence and then the dataavailable empties the input buffer with all of the accumulated data. This is, of course, useless because the main thread had finished operating on the data arrays that haven’t been filled. I need to have a way to tell the main thread to halt further execution and wait for the anticipated data after making a data request. I must have a way to have the main thread wait for the event to fire. In my case, the test equipment will respond to a request in roughly 200 msec, which is more that enough time for the main thread to have “completed” the task without having received any data.
My time frame is similar to yours, Matthew. I was writing test equipment software on the Apple II in the 1980, using an IEEE-488 card to talk to the test equipment. The sequencing problems that have been plaguing me here were not an issue. I talked to a piece of equipment, got a response, then moved on to the next step until the test was done. It sounds so simple, and in fact, it was. The programming was tedious, but there was never a question of whether (or when) a bit of code was going to be executed. I have had a lot of suggestions in response to my post and have tried as many as I possibly can, but have not found a way to get Xojo to execute a sequence in the order that I need it. There are delays in the communications between the PC and the test equipment. I need to be able to have the main thread wait for the anticipated response from a query. Events do not work.
Please let me ask a few questions about thread.SleepCurrent(ms).
Will it work in the main thread?
Will events (like dataavailable) fire while it is asleep?
This may be the answer I have been looking for.
The current application thread will completely sleep allowing the IDE to catch-up. Any data sent to the socket will pend at the socket datavailable event until the thread re-awakens. Keeping a short sleep time is preferable for performance.
Analogy:
TCPSockets are sort of like a gate on a dam spill-way… you can keep stacking water behind the gate, but until you open the gate (read data in our case), the water (data) will remain behind the gate to be spilled (processed). This is not true for UDP sockets - as if the data is not received immediately upon the send, then the packet is entirely missed.
Why are you doing all this hand-shaking woprk between your app and the various bits of hardware, on the main thread? You should be doing it on another thread that you dedicate for the purpose. Then that thread can send a command, wait for and process the data, decide that this particular step has completed OK, and send a command to the next bit of hardware, wait for its reponse, and so on. That arrangement cannot “barrel along” getting ahead of itself.
My app has to login to a remote host, send it questions and process the answers. I do that for several hosts simultaneously by having one thread for each host. They use the same code, of course, because they will all be doing the same thing.
Meanwhile the main thread is idle, so it can process events and any user requests in parallel.
You can’t pause the main thread.
No.
As it can’t, this question becomes moot.
You’ve had the answer before, you’re just choosing to ignore it.
1 Like
**I’ve started a private thread with Wayne regarding processing the data in cyclical or linear fashion which has not yet been answered and is a very important question to finding a working solution for his use-case. Awaiting his response to confirm configuration of the hardware and multiple sockets being used in the communications & relaying process. We should not be having to halt any operations in a DataAvailable event though. I’ve opted to provide a demo once he can confirm the communications paths for the hardware, to demonstrate processing the incoming data sequentially from both pieces of hardware (by desired order of operation) and handling the sockets between the hardware. (will share demo here also). His use case will actually require two sockets communicating and responding in harmony - whether cyclically or linearly TBD at the moment.
The point of my application is that, once the user has launched it on this particular mission to collect a series of data bundles, process them, and put the results into a file, there is nothing for the main thread to do, and there are no other users, there is nothing the single user can do while this is happening. All I want is a sequence of tasks to occur, but they must occur in order. The entire sequence should take about 6 seconds. During this period, absolutely nothing else is to happen, other than to give over to user control when the sequence is complete…
Wayne, I hope Matthew is able to work through this with you. You are fundamentally misunderstanding how threads, sockets, and event-driven programming operate in Xojo. The more you do thread manipulations like sleep to force synchronous processing, the more you are working counter to how the language is designed to work – and the less progress you’ll make.
Xojo CAN do what you’re asking of it, but only if you work within its model, which is fundamentally asynchronous. Perhaps Matthew’s solution will show you how this system can work for you.
1 Like
I am hopeful that I can find a way of accomplishing my goal. I worked on the problem for months before getting involved with the forum, and now, even with so many people trying to help, Thanks for your interest.
Wayne
I responded to this in the forum. I haven’t had a follow up, so I think I missed something. I did not receive a (private) notification outside the forum am am still wondering how to attack the problem. I have been severely warned against using doevents, however, it is the only way that I have been able to achieve my goal. The app is repeatable and is performing as intended…I’m just waiting for the other shoe to drop…
I pulled back from the thread to save causing confusion, or getting embroiled in the irrelevant minutia of interrupt handlers. As you are no further forward, I’ll give it another go.
A lot of the responses you have had are making an assumption I don’t happen to agree with. That is, that an event driven GUI application is the only or best choice you have. As I said earlier, the test procedure problem does not easily fit inside an event driven solution. You have another choice which is to use a console application for the comms. Apart from being a better fit for the problem, developing a console application has the added benefit of similarity with the single tasking development tools, like Quick Basic or whatever, you used in the past.
The dire warning about DoEvents only applies to GUI applications. In a console application, DoEvents is the only thing you got.
Application.DoEvents
Yields time back to your app when in loops. Intended for console applications in which there is no main event loop.
I have heard the term “console application” used in conjunction with the application.doevents, My application is to have a number of users and encompasses a number of separate functions. It would unthinkable to implement it with a text-only interface and no GUI. On the other hand, I could relegate individual routines to a separate bit of code that would insure sequential interface. Incidentally, the individual routines require not input from the user. Does any of this help?
Sigh… you should use the console app AS PART of the main app.
As @Beatrix_Willius says. Handle the user interface in a GUI application, handle the comms in a console application and pass data and events between the two processes.
If you post up what VNASocket and VNACmd look like and the response you expect to receive, I can get you started with a code example a lot faster than talking about it.
VNASocket.Address = ?
VNASocket.Port = ?
VNACmd = ?
VNADat = ?
TCPSocket address: 127.0.0.1
port: 5025
sample VNAcmd: “CALC1:TRAC1:DATA:FDAT?” + CHR(10)
responses are not always in the same format, but responses requiring data are in the format shown below:
Responses, like queries, always end with chr(10)
sample VNAdat:
-9414182780E00,+1.951438919E+00,
[this may be repeated any number of times from 5 to 500]
[the comma is not present the last time] + chr(10)
One other question: How do I “attach” the console application(s) to the main GUI application?
Oh, yes, Mattthew Sevens agrees with that. It sounds good. My question is how to link the two. Should I treat the console app as a method or a thread, or something else?