LabVIEW
Serial Write ... end of transmission indication
I have a simple requirement... I want to know when all the bytes in the buffer have been sent during a Serial Write. Refer the simplified VI below showing only the basics for this requirement.
If I can somehow know the end of transmission , I can use that signal to change teh State of QSM and get back to the INIT state and wait there. I searched the Serial property nodes but could not locate a suitable one for this .. Any ideas ??
( I tried to alter the loop delay ... low values means some bytes dont get sent; high values means a repeated trasnmission; difficult to control based on this )
The Write function returns when it's done writing to the VISA buffers, which is as low-level as I think you can get. Once it's in the VISA buffers it's getting sent to your device. I think your code may have some other issues if a low loop delay means some values don't get sent- your "SEND TO MCU" case will fully send the "Profile data" out the serial port each time it's called. You only need to call it once.
Also, a few thoughts on your coding in general:
-I don't think your Loop Delay is helping you here. Do you have a reason you need to clock it to 50 ms? (By the way that's a Wait Until Next ms Multiple function, not a Wait, so the delay in each case execution will vary from 0 to 50 ms.) The Queue will be your timing speed limiter, as it will block execution until you get a new message.
-Your structure is actually a QMH (Queued Message Handler) not a QSM (Queued State Machine). It's a fine architecture for what you're doing, just wanted to point it out in case you were looking for further reading on the subject.
Wait until Next ms Multiple will wait until the next time the system clock hits a multiple of 50 ms. So if you call it when the system clock is at xxxxxxx34, it will wait another 16 ms before returning.
Your issue is that your Init state keeps putting another Init back into the queue. In other words, when Init is called, it itself calls Init, which calls Init, and so on repeatedly. This is a mistake. Remove the Enqueue function from your Init case and the loop will now only execute the states that you DO call. When you enqueue Send to MCU, it will call that case once, then wait at the while loop before doing anything else. Right now, the only option is Send to MCU, so it will do nothing until you tell it to Send to MCU again.
Also, I'd suggest getting rid of the Flush Buffer in your Event handler. That's guaranteed to cause you headaches in the future. This function will get rid of everything in the queue, and should generally be used in the "shutdown" or "abort" sequences.
The bottom loop will not execute at 50 ms. It will execute each time the Dequeue function gets a message. If you are sending repeated INIT's, it'll hit every 50 ms, but if you take that out, the Wait until... will wait its 50 ms, but then the loop will wait on the Dequeue function, since there's nothing in the queue.
"Cases lurking in the pipeline" is a sign of poor programming architecture- if you're getting cases you don't need, eliminate the source of the extra cases. If you have enqueued cases that you've decided you don't actually need, you can discard anything already queued up (hence why they're used in Abort or Stop scenarios).
There is a possibility you could hit the "Send" button for some piece of code multiple times resulting in multiple triggers, but a better way to handle that is to prevent the bad user interface from happening in the first place. Set Busy will make the cursor unable to click anything until Unset Busy is called, and it gives your user an indication that "something's happening".
