LabVIEW
TCP connection reset
Solved!
@smithmachine wrote:
Does anyone know why this is so buggy
Because you made it buggy 
.
You literally did not follow any of the commonly accepted guidelines:
+ Don't use sequence structures.
+ Wire from left to right.
+ Straighten wires.
+ Put a wait in a loop (the one on the left).
+ Use subVIs.
+ Make the code fit the screen.
+ Some more, I'm sure...
@smithmachine wrote:My problem is that the camera on the other computer within unity game engine stops rotating if I run the vi. for the second time and onwards.
That's hard to say without seeing the other side. What you're sending might be wrong or incomplete.
Can you rule the other side out?
Do you have anything that does work? A 3rd party program or test utility?
@smithmachine wrote:
and how I can solve it?
Structure your code. Probably not what you want to hear. And likely not a solution directly. But it will help and it is needed.
If the code was structured, you could for instance easily remove everything but the communication.
Debugging would be a lot easier.
And as a bonus: much more people are likely to help you with the problem.
Search LabVIEW like a graph!
@smithmachine wrote:
Sorry for not knowing the guidelines, this is the first time I'm working with LabVIEW.
That's OK, we all started at some point.
@smithmachine wrote:
I'll start with your comments first and I can go from there.
Or start with the (free) online courses. If you're a student, the university might have a subscription to the paid courses (core 1 and core 2).
Feel free to post your progress here though. It's rare that a beginner progresses in the right direction.
You can post the VI, that way we can modify things and send it back.
.jpeg){kind=link}
.jpeg){kind=link}
.jpeg){kind=link}
.jpeg){kind=link}
wiebe@CARYA wrote:
@smithmachine wrote:
Sorry for not knowing the guidelines, this is the first time I'm working with LabVIEW.
That's OK, we all started at some point.
@smithmachine wrote:
I'll start with your comments first and I can go from there.
Or start with the (free) online courses. If you're a student, the university might have a subscription to the paid courses (core 1 and core 2).
Feel free to post your progress here though. It's rare that a beginner progresses in the right direction.
You can post the VI, that way we can modify things and send it back.
What wiebe@CARYA is saying is that the university might have allow access to ONLINE versions of CORE 1 and CORE 2 (probably CORE 3 and a couple of others, too). They might not even know it; you might have to check with NI (be sure to have the LabVIEW serial number at hand). If they say the SSP is active, you should still ask permission of the university to use it.
@smithmachine wrote:
Thirdly, I really don't know how to create a data dependency so I can get rid of the flat sequence structure. I've tried getting rid of it because it said so in the basic guidelines. I tried deleting it, but then the while loops all run at once.
That's an easy one.
Wire an error wire though the code. That is the standard solution anyway.
Taste isn't the same for everyone, but I like my error wire straight. So it's the wire that is always perfectly horizontal.
Eventually you'd be better of using an event structure. Polling Booleans is a bit 2006. That does complicate things a bit, you'd need a third 'thing' running in parallel. So just consider it when you're a bit further.
You can start easy by merging cases that can be merged. Like the first two. The first sequence (reading Trail #) is an almost 'atomic' action. Why not execute it while the DAQ is initializing?
That does mean that the entire outer sequence structure (SS) is mostly obsolete. The initializing of the Booleans can still be tricky. A SS can still help, but do it like this. Put only the locals and constants in a SS. Wire one of the Booleans (or an error wire) to the other structures that need to be executed after the init. You'd still have a SS, but it's tiny.
wiebe@CARYA wrote:
Taste isn't the same for everyone, but I like my error wire straight. So it's the wire that is always perfectly horizontal.
About the only exception this rule for me is when parsing XML (or any other kind of cascading code like that). Then I like to keep the reference wires straight and offset the nodes so my open and close references line up.
@smithmachine wrote:
I took me a while to clean everything up and it's still not perfect but I thought I'll post my progress so far. I've attached the old vi. (SimpleOutput) and the new vi. (SimpleOutputTestingComments)
It is better already.
That the busy while loop could use some work. You can tell. Select just the loop, and perform an automatic diagram cleanup.
The automatic diagram cleanup gets the code to about 50% of 'good', your version is still a bit messier.
The TCPIP wire being overlapped by a double wire (and others) is very bad. It simply takes time to see what happens, and you should go for clarity in glimpse.
@smithmachine wrote:
First thing I noticed is that the other computer which I run Unity on freezes more frequently when I set the output rate to 100Hz, using an output rate of 50Hz seemed to produce more robust results. Do you what the underlying problem could be?
That could be Unity that is simply busy handling events?
If a producer produces more data than a consumer can consume, data must be thrown away, or there will be an increasing lag. I don't know if Unitiy can throw away the data, so it could be lagging.
Separating the DAQ updates and the Unity updates could make sense. Unity probably only needs 30 FPS to be smooth...
@smithmachine wrote:
Secondly, the new vi. doesn't produce a signal for some reason any more, I must have broken something but don't know what it is.
I can't see anything very obvious.
@smithmachine wrote:
Is there any way you could help me clean up the code?.
I think this is the way. 
