TCP - Multiple Connections Causing Lock-Ups - 2018

[DailyDose]

So, after much deliberation with a colleague, we discovered that the issue was the MAC address.  Both Micros were sharing the same MAC which of course caused many migraine.  Thank you all for your help.  The Lesson: It's always something simple.

[RavensFan]

Ouch.  I thought MAC addresses needed to be universally unique.  But since it is possible to spoof MAC addresses.  Who was the manufacturer of these devices, and do they have an explanation as to why the ports have the same MAC address?

[Mark_Yedinak]

Wow, those are tough issues to solve. Need better quality control on whoever is making the microcontrollers. You should never have duplicate MAC addresses.

[DailyDose]

No No No.... That one was entirely my fault.  I programmed the Micros with the same MAC.  One of those duh moments.

[rolfk]

All the LabVIEW TCP Nodes that have a timeout input and therefore can wait for an arbitrary amount of time before returning are so called asynchronous nodes. That means that LabVIEW will happily arbitrate multiple calls to the same node in parallel and NOT lock up other code calling the same type of node in parallel eventhough the node seems to be stuck while waiting for either completion, timeout or an error condition in the operation.

So those nodes are not the reason for your seeming lockup of your code and there must be something else that causes the problem.

I'm definitely with Mark on the use of FGV for the connection refnum. That is not a good idea and should be instead stored in the connection handler itself as a private data element either in a shift register (or if you use LabVIEW classes in the private data of the connection class). 

[DailyDose]

---

@rolfk wrote:

All the LabVIEW TCP Nodes that have a timeout input and therefore can wait for an arbitrary amount of time before returning are so called asynchronous nodes. That means that LabVIEW will happily arbitrate multiple calls to the same node in parallel and NOT lock up other code calling the same type of node in parallel eventhough the node seems to be stuck while waiting for either completion, timeout or an error condition in the operation.

So those nodes are not the reason for your seeming lockup of your code and there must be something else that causes the problem.

I'm definitely with Mark on the use of FGV for the connection refnum. That is not a good idea and should be instead stored in the connection handler itself as a private data element either in a shift register (or if you use LabVIEW classes in the private data of the connection class). 

---

So I'm pretty confident it was the queues that were locking up my code.  An established connection wasn't made and yet I would attempt to trigger events which were trying to queue things that weren't being dequeued.  I don't have this issue now, now that I have steady communication to both micros.  Nothing else has been changed. 

In regards to the FGV.  I went ahead and uploaded what I'm calling an FGV.  I'm starting to wonder if I'm misidentifying a FGV.

[RavensFan]

I'd call that a functional global variable.  Or another name would be an Action Engine  (see Ben's Action Engine Nugget) which would be a FGV that has more functionality to it.

Your VI has the characteristics of an FGV or Action Engine:

1.  Single cycle While Loop.

2.  Enum input for commands. 

3.  Uninitialized shift registers for storing data between calls (in this case the TCP/IP reference.)

For #2, it is a good idea to make that command enum input required.  Or at least the default value a safe setting such as the Read function.  The last thing you want is to drop that subVI somewhere, forget to wire up a constant to the command (perhaps you wanted a read), then spend hours trying to debug your code figuring out why you keep getting errors because you lost your reference when the "default" command ran.

[DailyDose]

---

@RavensFan wrote:

For #2, it is a good idea to make that command enum input required.  Or at least the default value a safe setting such as the Read function.  The last thing you want is to drop that subVI somewhere, forget to wire up a constant to the command (perhaps you wanted a read), then spend hours trying to debug your code figuring out why you keep getting errors because you lost your reference when the "default" command ran.

---

Yeah, I completely agree that I need to make the Action a requirement.  I just posted this, though, because of the general disagreement to use a FGV.  The reference is being stored and handled.  And only can be closed if I tell it to.  I guess the concern is using the wrong FGV or using the FGV in the wrong place?  One of those things if you pass the reference around in the main VI less chance of doing that?

[RavensFan]

If you are only trying to keep track of one connection, then this single FGV/action engine should be just fine.  I don't see how you would use it in the wrong place.

If you need to hold different connections, then you'd have to duplicate and rename the FGV for each one.  Or you'd need to design the FGV with an array or cluster in it to store multiple references and another required input to tell it which of the many references you are working with.