my network stream writer is waiting indefinitely for something.

[FyrewurX]

I wanted to stream commands from my host to a target but my writer seems to be waiting for something before it executes. I tried making localhost writer and reader and it is working properly but when im using it on host to target it doens't work. What could be the problem? I also uploaded my sample code for reference.

[Hatef.fouladi]

I think there is a problem in your event loop. could you send your vi
or show your event code

[FyrewurX]

I already attached my code. Another problem is the stop event does not occur.

[stevem181 · Accepted solution]

In your RT.vi file, if the connection is ever lost, you will never connect again. This would cause UI.vi to wait forever.

Also stopping the "LED Loop" in RT.vi would cause it to not run again without a reboot.

I did some cleanup on your files (can't help myself) and added a few notes.

(Note: I changed it to LabVIEW 2013 - I don't have 2014, just 2015 without RT).

I also modified the RT code so it can run on Windows or RT.

There is a boolean constant in "UI mod.vi" to select local or remote operation.

To run "RT mod.vi" on your host computer, open it and "UI mod.vi" by themselves (don't open the project).

This will allow you to test things much easier.

To go back to running "RT mode.vi" on your target, open the project, recompile "RT mod.vi" then

build and deploy it. (Be sure to change the select boolean in "UI mod.vi").

steve

[FyrewurX]

Thanks for the help. I would review your code so I could understand better about this. I manage to fix the stream writer problem and add some features on the code. It would be much help if you could also review my own code that I manage to create after fixing this. I'll  attached it here. Thanks.

[stevem181]

I'm glad you got it working!

I don't have time tonight, but if you wouldn't mind doing a "save for Previous version" to 2013, I'll check it out tomorrow.

steve

[FyrewurX]

I've attached the 2013 version for my code.

[stevem181]

During development, it is important to consider how the program will be used. If it is just an academic
exercise, then robust error handling may be less important. If used on a production floor or research lab
then you really should have rock solid detection and handling of errors.

In regard to your latest version:

1) UI.vi - Wait timer is not needed for UI Event or Command Sender

2) You can wire error clusters directly to boolean OR gates (unbundle status is not needed)

3) If Create Network Stream Writer Endpoint fails, program will hang with no indication of why
    Ideally, you have a loop that tries to connect, shows it's status, and can be stopped by the UI Event Loop.

4) The Watchdog reset function could be another command in the "writer" stream
     (You could feed the Queue from UI Event Timeout with a bit of timing logic)
     This would eliminate the watchdog writer stream. At some point you may want to add a stream
      from the RT device for status and error checking, so best to keep things simple.

5) You use a Type Defined enum for your "commands" (which is good), but then have to create a new string
     command for the Sender. You could use "Flatten to String" to send and "Unflatten From String" to receive.

6) Error Handling. It's not ideal to mix Queue errors with Endpoint errors. How you respond to each
     should be different.
7) #6 is one reason to keep the endpoint wires in line (plus it looks better IMHO - see my example)
) You "should" check the connection of your Network Streams and try to reconnect on error
    (See my example in "RT mod.vi" - BTW, there is a "Connected" property node available)
9) RT.vi - As mentioned in previous post, if Activity Loop is stopped, it can't restart without reboot. Also if
    Command Parser loop gets an error, you can't recover without reboot.

10) You aren't currently setting "expiration actions" on the Watchdog Configure vi.

       Check the example listed in the Watchdog Configure vi help.

Hope this helps,

steve