suggestions on the best design pattern for app?

[bobby light]

Hi everyone, I'm new to the board and pretty new to labview. I have a simple serial messaging protocol. I need to create a tool that will essentially be a terminal tool with buttons that will send out 5 or 6 manual commands. The commands have start character and end characters. It will also need to send a status message at some interval and be able to send the same status message on demand.

I was thinking about using a state machine for this, however the adjustable rate heartbeat message and how to handle that in statemacine is kinda jamming me up and maybe i'm trying to be too cute or am just going down the wrong path in general. also searching around i was unaware of visa events, would this be an appropriate use of visa events for the message reading or am i better off just inspecting each byte and acting accordingly?

any tips would be appreciated.

[ShaunR]

Hi everyone, I'm new to the board and pretty new to labview. I have a simple serial messaging protocol. I need to create a tool that will essentially be a terminal tool with buttons that will send out 5 or 6 manual commands. The commands have start character and end characters. It will also need to send a status message at some interval and be able to send the same status message on demand.

I was thinking about using a state machine for this, however the adjustable rate heartbeat message and how to handle that in statemacine is kinda jamming me up and maybe i'm trying to be too cute or am just going down the wrong path in general. also searching around i was unaware of visa events, would this be an appropriate use of visa events for the message reading or am i better off just inspecting each byte and acting accordingly?

any tips would be appreciated.

Use an event structure and just send the heartbeat in the timeout case (wire a value to the timeout). Your commands will map to an event case, so just send them in the appropriate case. That will achieve what you want with very little effort and you can always pull it out into a more elaborate approach later, (you will still probably use the event case for the UI regardless). A state-machine seems a bot overcomplicated for your current spec.

[bobby light]

Thanks, for the tip, but if i put my heartbeat in the timeout event, where should I be monitoring the port for received messages? I would have just put a short timer on the timout event and listened for bytes at port, and wrote them to my terminal as I saw them, is there a way to create a "bytes at port event"?

[ShaunR]

Thanks, for the tip, but if i put my heartbeat in the timeout event, where should I be monitoring the port for received messages? I would have just put a short timer on the timout event and listened for bytes at port, and wrote them to my terminal as I saw them, is there a way to create a "bytes at port event"?

Receive in a separate loop. The Event structure is your "command" loop and the receive loop is the "response".

And for extra brownie points; do all of the commands with 1 write vI.

Edited June 3, 2011 by ShaunR

[bobby light]

thanks for the response, I had already taken a stab at just throwing in a second loop like you did there, except i used "bytes at port" feeding into a case structure where 0 does nothing essentially and default does the read, which works as far as talking out of the serial port like i'd like, but the problem i'm having is syncing the trace window on my FP. in your example you just have the reads showing up in the read buffer indicator, but I'm trying to have the Tx echo in the same indicator also. That's where I was thinking originally i'd need like a qsm or something, unless there is some clever way to echo a write to "read buffer" in your bottom loop in the example you posted.

[ShaunR]

thanks for the response, I had already taken a stab at just throwing in a second loop like you did there, except i used "bytes at port" feeding into a case structure where 0 does nothing essentially and default does the read, which works as far as talking out of the serial port like i'd like, but the problem i'm having is syncing the trace window on my FP. in your example you just have the reads showing up in the read buffer indicator, but I'm trying to have the Tx echo in the same indicator also. That's where I was thinking originally i'd need like a qsm or something, unless there is some clever way to echo a write to "read buffer" in your bottom loop in the example you posted.

Nothing clever. If your device doesn't echo then you just pre-pend the command string. But the main problem has been solved, simple and took me about 10 mins (Note I am using the term char to only update the display once a whole string has been received)

-->The property node in the read loop us really a local variable. It gets converted when posting a snippet.

You could put the read vi(s) straight after the write (after the event structure) and it would work fine most of the time and be fully synchronised. But since you don't want the UI to look unresponsive whilst waiting for data; asynchronous reading is generally preferred.

State-machines come into their own when you have multiple states that can be operated in an arbitrary order. So where you might want to use one is, for example, when a response from the device dictates the next command to send.e.g authentication challenges. But for most implementations where user interaction is involved,. then an event structure is preferable since all user interaction is handled for you.

[bobby light]

Thanks for your responses i really appreciate it. This is what I worked out before, this does exactly what I want except I have separate string indicators on the front panel, one for RX one for TX. I tried making one up like your example, but I could not get it to work where a single trace updated either with RX msg or Tx msg, my problem is i guess syncing the shift registers in two different loops, which is probably not possible and why i was thinking I need a queue and then dequeue after the read to update the window with whatevers in the bottom loop....forgive the cleanliness of code, will cleanup when i figure out what I'm doing lol

[bobby light]

meh i got it working how I want by basically reinventing the wheel into a p/c. had to get all my reads and writes in the same loop for the trace to work like I wanted, and then made all cases in the consumer loop set next state to read case. Thanks.