LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Transmitting a Byte Wirelessly

Solved!
Go to solution

Andrew,

 

Stop is a big part of the problem.

 

The event structure is a step in the right direction.  Generally you want to put the control terminals inside the event case.  This is especially true for booleans with latching action.  Next you should have an additional event case for Stop.  Put it inside it own Value Changed event case so that you do not need to push some other button to read the Stop. Also, you should remove the timeout case.  It never runs, so why have it?

 

This will work fine with latched booleans.

 

These relatively small changes will fix the button loop.  However, the way you have it set up now, the other two loops will run exactly one iteation each after the Stop button was pushed and then quit.  Consider using a notifier to pass the Stop information to the other loops.  If you want them to run in parallel, do not wire any output from any loop to any other loop.

 

Even with taking some time to read the detailed help for Notifiers, these fixes should not take more than a few hours at the most.

 

Lynn

0 Kudos
Message 21 of 38
(819 Views)

Is this what you were reffering to with the Button and stop configurations? I am looking into the notifiers also. I will get back with you. Thanks.

0 Kudos
Message 22 of 38
(813 Views)

Yes!

 

You do need to wire the TCP Connection ID (refnum) and error cluster through the stop case or the TCP Close Connection will fail because it will receive a default ID, which certainly will not be the one you want to close.  I think the Use Default if Unwired on tunnels from cases should be used very sparingly.  The Stop boolean is one of the few good uses.

 

Lynn

 

 

0 Kudos
Message 23 of 38
(809 Views)

Okay great! In addition I just added the notifier blocks. I am not sure what to input the "Notification ID" on the "Send Notification" block.

0 Kudos
Message 24 of 38
(806 Views)

Andrew,

 

The way you had the notifier refnum wired will work as far as sending a notification.  However, you do not want to release the notifier in the event structure before the other loops can run.  If is is released, there is no notification for the Wait no Notifications to wait for!

 

Also, you need to specify a wait time.  The default is -1, which means wait forever.  So the right side loops will never loop and never stop.

 

I have attached some fixes.  I am not completely sure that the overall behavior is what you want but the loops should run.  If you do not want the web stuff to run one more time after Stop, use the timed out? outputs from Wait on Notification and a case structure. 

 

Lynn

 

 

0 Kudos
Message 25 of 38
(797 Views)

Oh wow, now I see what you were talking about. That makes perfect sense! Yea the main thing is I need that "master" loop to stop and the broswer loops are secondary, which is exactly what this does. Thats a great set up! Although I am still getting the same error when the stop button is pressed. It's "Error 1 occured at Send Notification in Exmerimental...VI LabVIEW: An input parameter is invalid. For example, if the input is a path, the path might contain a character not allowed by the OS such as ? or @. NI-488: Command requires GPIB Controller to be Controller-In-Charge." What is this error about? Do I have a setting wrong somewhere? Today I am going to test this program with the software. With the exception of the "Stop" button issue I will see if it is sending data out correctly. Thank You.

 

Andrew

0 Kudos
Message 26 of 38
(789 Views)

Andrew,

 

I am not sure what is causing that error.  When I disable the web browser stuff so I can run the VI, I do not get any errors.  Oops.  I have automatic error handling turned off.  When I connect an error indicator to the Send Notification, I do see the error.

 

It took me a while, but I found it.  Run the VI with Highlight Execution turned on and with a probe connected to the notifer refnum inside the upper loop but outside the event structure.  At first the refnum will be valid and later it will be shown as an invalid refnum. Very strange, right?

 

Look at the lower loops.  The conditional terminals are set to Continue if True and wired to the error out of the Wait on Notification.  So, what happens?  The first time each loop runs the Wait on Notification times out and sends No Error fo the conditional terminal.  The boolean in No Error is False. So the loop ends after the first iteration. After both loops have run one time each, they end and the Release Notifier runs.  The next time the upper loop runs, the Notifier refnum is invalid, generating the error.  The fix? Change the conditional terminals to Stop if True and wire them to the Notification output rather than the error out.

 

Lynn

0 Kudos
Message 27 of 38
(781 Views)

Is this what you were meaning was the cause of that error? I connected it to the notifier output and I reconnected the error out to the Release notifier error in. This is what you mean correct? If so the stop buttonis acting really weird and not working. If you click it it will depress, although it will not work. The notifiers recieve a "True" to stop the loop, which is correct but the loop as far as I can tell is still looping.

 

The purpose of my program is to send data to a microcontroller, to which sends that information to a robot telling different motors which direction to move. This is my only problem left is with the known stop button issue.

 

Thank You Very Much,

Andrew

0 Kudos
Message 28 of 38
(777 Views)

Andrew,

 

It works fine for me.  I press Stop and the VI stops.  I had to disable the web browser stuff because that is not available in my system, but everything else works.

 

Did you choose the Switch Until Released mechanical action for the motor switches intentionally? Each click generates two Value Changed Events, sending 77 (depending on switch) once then 0. The time between the values being sent is how ling it takes the OS to do two consecutive TCP Writes.  This will have the 77 value on for very short times.

 

Lynn

0 Kudos
Message 29 of 38
(768 Views)
Yea that control loop works correctly. I know it comes on short, but I have corrected for that in my C code. My only issues are with the stop/notifier configuration. I see why you don't see it because the error comes from the notifier block in each of the browser loops. I wired them correctly right? I noticed that when I run my code that the browser does not load up. I thought maybe it was receiving a true and stopping the loop but it is receiving a false, which is correct I believe.
0 Kudos
Message 30 of 38
(764 Views)