Unwired or bad terminal

[ramanlvm]

Hello,

I am not an expert in labview. I prepared a labview VI and it is broken. When I try to run it then an error message appear "Merge signals: contains unwired or bad terminal". Kindly help me to resolve this error.

Thanks,

[RavensFan]

Grab the bottom of the merge signals function then drag it upwards.

Then start looking at the online LabVIEW tutorials
LabVIEW Introduction Course - Three Hours
LabVIEW Introduction Course - Six Hours

[Stephny]

Hello,

you had some terminals unwired where your signal splits and merges. I removed the unused terminals.

[Pete.Dunc]

Hi ramanlvm,

No access to LabVIEW to look at your code. Though you're looking for a merge signal function (image below) which either isn't connected or is partially connected.  You can expand/reduce the amount of inputs to this function by hovering over it and clicking the 'up/down'drag handles.

[0utlaw · Accepted solution]

Hello ramanlvm,

Try double-clicking on the error in the Error List window- it will highlight the merge signals primitive function, which it appears you're using to combine signals into a single file.  You're seeing this error because of one of the basic concepts of LabVIEW- a function requires that all inputs are available before it can execute. The merge signals primitive function is currently sized to accept 16 or so channels, but only six are wired. Because the dataflow requirement of all 16 inputs can never be met, the VI will not compile and run.

You need to resize the function to require only the inputs you are using. Left-click on the bottom of the merge signals function and drag it to resize.

I would also recommend taking a look at the Core LabVIEW self-paced online training tutorials, which you should have access to with a current NI support contract.

Best Regards,

[RavensFan]

I'm seeing a bug with the Split Signals function.  It seems like something I remember reading about before, but searching the forums, I can't find anything about it.

When I take the split signals function (which doesn't cause a broken run arrow in the user's VI because a function can have unused outputs), and shrink that up, I am left with a single unused output.  If I expand the split signals upwards from the top, then shrink it back down, I am left with an unused output at the top that I can't get rid of.

I saw this in LV 2012 on my work XP machine, and LV 2013 on my laptop.

[Hornless.Rhino]

---

@RavensFan wrote:

I'm seeing a bug with the Split Signals function.  It seems like something I remember reading about before, but searching the forums, I can't find anything about it.

When I take the split signals function (which doesn't cause a broken run arrow in the user's VI because a function can have unused outputs), and shrink that up, I am left with a single unused output.  If I expand the split signals upwards from the top, then shrink it back down, I am left with an unused output at the top that I can't get rid of.

I saw this in LV 2012 on my work XP machine, and LV 2013 on my laptop.

---

It gets worse.

Drop the split signal.

Create a constant for the input and a numeric output for the (currently) single output.

expand upwards, then try and shrink down, and as you saw you get a bonus output you can't remove.

then expand downwards, and shrink up. you now gain a bonus on the bottom too, and thus have 2 un-removable outputs.

LV(2013)

edit: you can of course disconnect the connected output, but that only lets you remove one of the bonuses.

[RavensFan]

Yes.  That is what I'm talking about.  It happens with a newly dropped function as well.

Even if you don't wire up the first output, if you stretch up then back down, or down then back up, you can't get back to one output, you are left with 2.  Two unused outputs just like if you had wired 1 or more outputs.

I think I had seen this mentioned in a thread before, but I can't find anything either by searching the forums or using the more reliable Google.

Tom L., can you investiage and see if a CAR had ever been issued for this behavior?  If not, do you agree there is a bug and a CAR should be issued?

EDIT:  Searching for "split signal" instead of "split signals", I found this thread http://forums.ni.com/t5/LabVIEW/split-signal-not-showing-multiple-outputs/m-p/1085543/highlight/true....  where I mention thinking there was a bug with the function.  But that entire thread is thin on details.

[0utlaw]

Hi RavensFan,

It looks like this was reported to R&D under CAR # 69549, but the decision has been made not to change the product because the extra terminal is cosmetic in many cases, no customers have contacted us directly to report this being an issue, and there is a simple and intuitive workaround. If you feel strongly about this, you can request that the CAR be updated and reevaluated. 

I agree that the current behavior of functionally shifting all outputs up one index when you resize upwards and needing to delete a wire and re-resize the node is unintuitive and addressing it may have merit.  I would also recommend that anyone that feels this needs more attention open a service request and ask that the CAR be updated with their information.

Best Regards,

[RavensFan]

Your message brings up a very interesting point, more particular to the "extra" output at the top.  If you stretch up from the top, if the wired output was originally the first signal, does it now become the second or third, ( or more)?  And if you shrink the top back down and you are stuck with the single output, is that output now the first signal and the first wired output is now the second?

You mention shifting all outputs up by one.  I think the workaround would be to deleted the topmost connected output wire, shrink the top of the node down one, then reconnect the output wire to the same output, but it is now the first output rather than the second.

Likewise the same could be done for the bottom, (delete bottom wire, shrink the bottom border up 1, then reconnect the bottom wire) but I agree with you there that an unused output terminal at the bottom is purely cosmetic and wouldn't have an effect on the order of the signals above it.