Connector pane pattern bug

LV2011, cant check other versions right now.
The Connector pane pattern window doesn't mark/show your currently selected pattern. Not a big bug, but i still classify it as such.
/Y
LabVIEW 8.2 - 2014
"Only dead fish swim downstream" - "My life for Kudos!" - "Dumb people repeat old mistakes - smart ones create new ones."
G# - Free award winning reference based OOP for LV

Off topic: Sorry I wasn't able to join for that dinner I had to leave for meeting in Germany the next day
On topic: IT's not a purely popularity but offcourse it is a big thing. If we would have a suggestion with 100000 kudos and one with 3. I think it would be just wrong not to go with the one most people like. However it might also be such a simple change that we can make a less popular but very fitting change be implemented. Exactly how this decision is made I cannot say as I'm not part of the R&D team, but I would guess they weight it something like this. Just look at the implementation of 2014 and see if you can find the idea exchange for this and you can see =)
Best Regards
Jonas Mäki
Applications Engineering
National Instruments

Similar Messages

Custom connector pane pattern

is it possible to create one at all when creating a SubVI?
annoyingly, there's no pattern for 5 either side (split into ten equal parts) and i'd quite like that!
is there a way or will I just have to use another pattern and just make the wiring look at if it's 5 either side?
thanks in advance,
Michael

There is now law that you must use all terminals. On the contrary, it is usually beneficial to plan ahead and use a pattern with a few more for future expansion.
In your case, use the third last pattern, it has 5 on each side. Just disregard the terminals on the bottom and top.
LabVIEW Champion . Do more with less code and in less time .

LabVIEW 2009 SP1 - Incorrect icon in connector pane palette

In LabVIEW 2009 SP1 (I don't have 2010 yet to check it) there seems to be a minor bug in the connector pane palette.
One of the connector patters appears twice, but when you select the second one, it shows up as the missing pattern.
I'd post an image, but that function seems to be broken getting through my company's proxy server. So image attached (I hope).
In LabVIEW 2009 SP1 (I don't have 2010 yet to check it) there seems to be a minor bug in the connector pane palette.
One of the connector patterns appears twice, but when you select the second one, it shows up as the missing pattern.
Troy
CLDEach snowflake in an avalanche pleads not guilty. - Stanislaw J. Lec
I haven't failed, I've found 10,000 ways that don't work - Thomas Edison
Beware of the man who won't be bothered with details. - William Feather
The greatest of faults is to be conscious of none. - Thomas Carlyle
Solved!
Go to Solution.
Attachments:
Connector pane.PNG ‏4 KB

Troy K wrote:
I guess everyone else is using "proper" connector patterns instead of these crazy non-standard ones.
So you must be using crazy non-standard connector panes, or you would not have discovered this bug. Right? Actuall this is a good catch for it to go unnoticed for this long.
- tbob
Inventor of the WORM Global

How do I dynamically open a VI and load values into its connector pane?

I'm trying to open a VI as a prompt to another VI without opening the second VI's front panel until the user clicks OK in the first window. The second VI takes inputs from the first thru its connector pane. How do I dynamically open the second VI?

I think what you mean is call by reference dynamically loading VI's
You can read up on it here
If you want to make a static call to the sub vi just set the Front Panel Options to "Open Front Panel when called"
See here for more info
Hope that answers your question

VI Reference type does not match VI connector pane

I am trying to use Open VI Reference in LabVIEW 8. I am getting error 1031 "VI Reference type does not match VI connector pane." I have a Type Specifier wired to the Type Sepcifier terminal, and I've gone in and selected Select VI Server Class / Browse, and selected the VIT that matches the input path.
My path is correct.
I wired 0x10 (16) to the options terminal so that I would be prompted if LabVIEW couldn't find the necessary subVI files.
I restarted my computer to make sure the old type specifer was not in memory.
Any thoughts on why I still get error 1031?
Thanks,
Kathy

Hi Kathy,
I am still investigating this problem, but right now I do have a workaround for you. If you open your template VI and drag its icon into the type specifier constant, and also drag it into the refnum indicator on the panel of your calling VI, the problem no longer occurs. For some reason the "Browse" operation is behaving differently than dragging the VI icon. I will continue investigating this and let you know what I find out.
Ben: There is no way to automatically update the type specifiers. I've seen people typedef their specifiers before, so they only have to change them in one place when the subVI connector pane changes. We already have this suggestion on file to consider for a future LabVIEW version.
-D
Darren Nattinger, CLA
LabVIEW Artisan and Nugget Penman

Get Control Reference From Connector Pane

I am trying to get a reference to a control associated with a specific index on the connector pane. I see that there is a method to assign a control to a terminal but not get control from a specific terminal. I know I can list all controls on the connector pane, but this doesn't tell me specifically where they are.
Edit: I see there are private methods for getting and setting properties which may have this info, but because these are undocumented and they are properties of a VI which is binary, I can't reverse engineer.
CLA, LabVIEW Versions 2010-2013
Solved!
Go to Solution.

GregFreeman wrote:
The disconnect I had was that the array of controls that the connector pane property node will return has null refnums for unwired terminals, but there are still references for every terminal on the pane.
For learning about the terminals on an object, a good tactic is to drop the object on a diagram and select Visible Items > Terminals:
If you see completely enclosed terminal rects (like in the subVI terminals), then reading the "Terminals[]" property of the object will return all of them, even the null data type ones. So for the subVI, you can see that there are 12 distinct terminal rects, so that's how many terminals the object has. But on the built-in function, there are only 6 enclosed terminal rects. So reading the "Terminals[]" property on the subVI will return 12 items, and reading it on the function will return 6.
Jacobson wrote:
Good find on the example VI...
I wrote it (along with about 400 other VIs in the examples folder), so it was pretty easy to find.
Darren Nattinger, CLA
LabVIEW Artisan and Nugget Penman

How do I get connector pane names programatically with ActiveX?

I am learning how to use LabVIEW's ActiveX automation to call LabVIEW VIs from Python.
The following code works as expected (the comments are a little too verbose, but they help):
# Example: calling LabVIEW from Python
# grab the LabVIEW ActiveX interface
# generated with the Python COM Makepy utility
import labview_pycom
# grab a handle to the LabVIEW 8 application
lv = labview_pycom.Application()
# open up a VI -- path, password, reserve handle (t/f)
vi = lv.GetVIReference(r"C:\Test VIs\Hex Adder.vi", "", True)
# call the VI with named parameters and corresponding values
# pass ALL parameters here -- input and output;
# - output parameter values are don't cares
# - will return names of all passed parameters and values
returns = vi.Call(["String", "String 2", "Sum", "hex Sum"], ["1", "2", 0, ""])
print returns
My Hex Adder.vi takes two strings "String" and "String 2", parses them into integers, and adds them. It outputs an integer, "Sum", and the sum as a string, "hex Sum".
Output:
((u'String', u'String 2', u'Sum', u'hex Sum'), (u'1', u'2', 3, u'00000003'))
I explicitly pass names of items on the connector pane in vi.call( ... ), and that's OK in this application. I want to know, though, what names and values I could pass, without dissecting the connector pane in LabVIEW.
Is it possible to ask LabVIEW, through a function call, the names of all the front panel controls or items on the connector pane? The GetControlValue(...) and SetControlValue(...) take named parameters -- but I want a list of the names they can take.
Thanks!
Matthew Ploguh

I am not sure if the ActiveX server exposes a method to get a VI's controls.
Why don't you just write a VI that uses "Open VI Reference" and the VI server properties to enumerate the controls on the VI? You can then call this VI from python to get the parameters of the VI that you really want to call.
Pramod
Message Edited by PramodS on 02-14-2008 05:30 AM

[svn:fx-trunk] 11250: Fixing proxy pattern bug in VideoPlayer.

Revision: 11250
Author:   [email protected]
Date:     2009-10-28 17:07:19 -0700 (Wed, 28 Oct 2009)
Log Message:
Fixing proxy pattern bug in VideoPlayer. I tried to save a few extra bytes by not keeping around an extra object, but I made a mistake with this code. It seems better just to follow the typical pattern and not worry about this extra savings, which probably cost more in code-size anyways.
Also changing VideoPlayer.thumbnailSource to mx_internal, rather than public. In VideoElement it's mx_internal, and that's what it should be here too.
QE notes: -
Doc notes: -
Bugs: SDK-23665
Reviewer: Deepa
Tests run: checkintests, mustella VideoPlayer
Is noteworthy for integration: No
Ticket Links:
    http://bugs.adobe.com/jira/browse/SDK-23665
Modified Paths:
    flex/sdk/trunk/frameworks/projects/spark/src/spark/components/VideoPlayer.as

Why do i get an empty output if i connect a control to the connector pane ?

hello everyone..
i must admit the behaviour of the following program somewhat blew my mind and made me doubt whether i had ever understood anything about programming in labview.
please have a look at the attached vi and it's subvi. i probe the output of debug.vi (result path) two times. once when it is connected as an indicator on the connector pane and once when it is not. then i run test.vi.
the prize question:
why don't i get identical values?
in the case "result path" is connected i get an empty path at some point. in the case "result path" is not connected i always get a value, something i thought should always be the case. what is happening?
Attachments:
test.vi ‏8 KB
debug.vi ‏9 KB
StateMachineStates.ctl ‏5 KB

There are a lot of questionable conde constructs that make very little sense.
Where do you actually probe the output (the subVI does not seem have any output connectors assigned)
Are the indicators big enough to avoid wrapping?
Why is the browse option set to "existing files", however, you are building a path from it. This will invariably give you an illegal path.
Instead of all these local variables, use a single feedback node.
Please provide an exact step-by-step procedure on what we should do to reproduce your observations. How can you possibly get a value in an indicator if it is not connected to anything?
LabVIEW Champion . Do more with less code and in less time .

Why cannot the block diagram view of a VI show the "connector pane" view in the UR corner, like the front panel view does?

Perhaps there is a good reason for this that I just haven't figured out. I haven't seen any questions about it searching the NI site, however.
But it just seems totally inconvenient to always have to go to the front panel to get to the connector pane view, especially if some of those connectors are hidden. Then I have to go to the block diagram, guess which control/indicator I want to unhide, go back to the FP to check it on the connector pane, then go back and hide it again, and repeat if necessary. Even if the C/I is visible on the FP, it's still an extra step or two.
When I'm building connections using the block diagrams and planning where to put connectors in subVIs so they would be easier to wire up (line up inputs/outputs on sides, not have to go top-to-bottom, etc.), it sure would be nice to be able to work totally in the block diagram realm.
Cameron
To err is human, but to really foul it up requires a computer.
The optimist believes we are in the best of all possible worlds - the pessimist fears this is true.
Profanity is the one language all programmers know best.
An expert is someone who has made all the possible mistakes.
To learn something about LabVIEW at no extra cost, work the online LabVIEW tutorial(s):
LabVIEW Unit 1 - Getting Started
Learn to Use LabVIEW with MyDAQ
Solved!
Go to Solution.

Yamaeda wrote:
Good idea, put it in Idea Exchange!
It has been there for a while already. No need to duplicate....
LabVIEW Champion . Do more with less code and in less time .

'Control terminals on connector pane not on top level block diagram.' comment on CLD report

Hello All
Could anybody enlighten me please , what does that comment mean on CLD report
'Control terminals on connector pane not on top level block diagram.
Does it mean that some terminals are hidden within some case structures and not showing on block diagram without going into case structures or by 'top level block diagram' it means
main.vi and controls on main.vi must also be connected to its connector pane?
Thank you
K.Waris
Solved!
Go to Solution.

For one thing it means that they run VI analyzer on your VIs since that is a verbatim warning that you receive. It simply means a terminal which is wired to the ConPane is not on the top level diagram, ie. inside a case structure.
As to why it is often not a good idea to do this read this classic thread:
http://forums.ni.com/t5/LabVIEW/case-structure-parameter-efficiency/m-p/382516#M191622

Cannot load connector pane

Has anyone else had this error before? I've asked tech support but they had not seen anything like it either.
System:
Windows 7 Professional (64 bit), LV2010 (v 10.0f4, 32 bit)
Repro Steps:
1) Create a new VI (any method)
2) Right-click on icon and select "show connector"
Expected Result:
Connector pane is displayed
Actual Results:
Error message - "LabVIEW: Cannot load connector pane"
Workaround:
Click OK on the error message. The connector pane then loads and everything works just fine.
This only happens the first time I open the connector pane on a VI; it never happens again after I've opened it (even after saves, etc). Tech support had me try the f4 patch, reinstalling/repair LV2010, and I even did a mass compile for good measure. It's not a real problem (I just click OK on the error and go about my business), but I am curious to see if anyone else has seen this kind of behavior before.
-Daniel
Solved!
Go to Solution.

So if you have some archaic line in your LabView.ini file (perhaps from way back in the 6/7/8.x days, and it's simply been copied over after each and every upgrade, then copied over to new PCs) and it looks something like this:
defaultConPane=4185
Then you could be trying to load a connector pane that does not exist. Perhaps it should have been 4815, or something else. In any case, delete said line and all is well.
http://digital.ni.com/public.nsf/allkb/279F064F0688C114862570900057678C

Resizing connector pane

Is there anyway to resize the connector pane, just for the easy handling while assigning connections? And it seems the maximum number of connection that one can have on a connector pane are limited to 24. Is there anyway to add more?
Does adding up more connection to the connector pane, slow down the vi?
Thanks,
Deepak
LAB View 2010 SP1

jcarmody wrote:
Take a look at this and this (by this person).
Thanks for the link. Pretty cool!
Reese, (former CLAD, future CLD)
Some people call me the Space Cowboy!
Some call me the gangster of love.
Some people call me MoReese!
...I'm right here baby, right here, right here, right here at home

Shading pattern bug with stitching functions

I am using Acrobat Professional 7 for Windows, but I don't believe the situation has changed in Acrobat 9.
I have a simple hand-crafted pdf that is designed to test shading patterns with extend regions when used with stitching (Type 3) functions. These behave according to the spec in most cases, but there is a special case where they don't. I've included the job at the end of this message.
The special case is where a Bounds entry is identical to one of the Domain values. The spec doesn't say what should happen for this case, but I might expect either the end child function would be ignored, or that it is used but the appropriate colour would be evaluated using it and applied to the extend region.
What in fact happens, is that the extend regions have their colour derived from evaluating 0 or 1 through the end child functions. This is true regardless of whether the shading domain includes zero. But, these are used the wrong way round.
This might seem like a specialised case that would never appear in the field from real world application, but that is not the case. I have dozens of such jobs from customers displaying exactly this problem with varying workarounds by producers such as (Agfa Apogee Normalizer), (Acrobat Distiller 6.0 \(Windows\)), (Adobe PDF library 7.77), (Creo Normalizer JTP ver. 3.1.6), (Adobe PDF Library 8.0).
In more detail, the job has one radial shading pattern using a stitching function with 6 child functions. The first child function coincides with the function domain, as do the last two child functions. The domain of the shading is a subset of the stitching function, arranged so that the end child functions should never be evaluated.
I believe the whole of the shading should be a solid cyan because the domain is 0.3 to 0.7. Only one of the child functions covers this range which is solid cyan. Acrobat displays the inner extended region as black which can only be explained by pushing 1 through the first child function, and the outer extended region is yellow which can only be explained by pushing 0 through the final child function.
I believe Acrobat should be using the shading domain limits for the extend regions. Instead, it is using 0 and 1. But worse, the values are being used the wrong way round.
This is my hand-crafted job for testing shading patterns with Type 3 functions. The job is hand crafted, and I haven't gone to the trouble of setting the xref table or setting the stream lengths, but Acrobat does repair the file and it behaves the same as other, real-world, jobs
%PDF-1.4
%âãÏÓ
1 0 obj
<<
/Type /Catalog
/Pages 2 0 R
>>
endobj
2 0 obj
<<
/Type /Pages
/Count 1
/Kids [4 0 R ]
>>
endobj
3 0 obj
<< % Info dictionary
/Title (FunctionType 3 boundary test)
/CreationDate (D:20051118000000-00'00')
/Author (John Jefferies)
>>
endobj
4 0 obj
<< % Page 1
/Type /Page
/Parent 2 0 R
/Resources 5 0 R
/MediaBox [0 0 300 300]
/Contents [6 0 R]
>>
endobj
5 0 obj
<< % Resources Groups
/Shading <<
/Radial 7 0 R
>>
/ProcSet [/PDF]
>>
endobj
6 0 obj
<< % Page contents
/Length 1
>>
stream
q 1 0 0 1 0 0 cm /Radial sh Q
endstream
endobj
7 0 obj
<< % Radial shading covering group
/ShadingType 3
/ColorSpace /DeviceCMYK
/BBox [0 0 300 300]
/Coords [150 150 30 150 150 175]
/Function 8 0 R
/Domain [0.3 0.7]
/Extend [true true]
>>
endobj
8 0 obj
<< % Function for shadings
/FunctionType 3
/Domain [0 1]
/Range [0 1 0 1 0 1 0 1]
/Functions [9 0 R 10 0 R 11 0 R 12 0 R 13 0 R 14 0 R]
/Bounds [0 0.25 0.25 1 1]
/Encode [0 1 0 1 0 1 0 1 0 1 0 1]
>>
endobj
9 0 obj
<< % Function for shadings: Red - Black
/FunctionType 2
/Domain [0 1]
/Range [0 1 0 1 0 1 0 1]
/C0 [0 1 1 0]
/C1 [0 0 0 1]
/N 1
>>
endobj
10 0 obj
<< % Function for shadings: Green
/FunctionType 2
/Domain [0 1]
/Range [0 1 0 1 0 1 0 1]
/C0 [1 0 1 0]
/C1 [1 0 1 0]
/N 1
>>
endob

Philip, thankyou for offering to look at this.
I have attached 'FunctionType 3 boundary.pdf' which was the original file I attempted to post. The file 'AcrOut Domain 0_3-0_7.png' makes it clear what I am seeing in Acrobat. I would also like to augment my original post a little to point out incompatibilities between Acrobat and CPSI.
1. From my PoV, compatibility between Acrobat and CPSI is important, so I've also attached a file that contains equivalent PostScript. On my Ricoh Aficio with CPSI (3016.203) inside it, the job is rendered in solid cyan as I would expect given that the domain of the shading is restricted to [0.3 0.7].
2. If the jobs are changed to make the shading domain [0 1] instead of [0.3 0.7], Acrobat displays a green ring (expected), and the inner extend region is now red (expected). The outer extend region remains yellow.
CPSI renders the job almost the same as Acrobat, but the outer extend region is painted in cyan, not yellow. An Nth reading of the PDF and PS specs has revealed a subtle difference; there is one sentence in the stitching function section of the PDF spec not present in the PS spec, it is "If the last bound, Bounds(k−2) , is equal to Domain(1) , then x′ is defined to be Encode(2i)". I take this to mean the outer extends region may have different color in the PDF and PS versions by design.
3. If the pdf job is changed to make the shading domain [0.01 0.99], Acrobat displays the inner extend in black as before (unexpected), otherwise the same as 2).
To summarise:
1. There appears to be a bug in Acrobat whereby it ignores domain of the shading when painting the extend regions.
2. There is an incompatibility between Acrobat and CPSI in the outer extends region when the final Bounds entry is equal to the Domain value. This may be by design.

Stand-alone application generates error with function 'Ramp Pattern' (bug in application builder?)

Hello,
in my program a main.vi links to a sub-VI via 'open VI reference' and 'invoke node'. In this sub-VI the function 'Ramp Pattern' is used. The program itself runs normally, but if I build a stand-alone application using application builder I get an error message 'error 1003 occurred ..'. I believe this error is directly related to the build specifications which are as follows: the main.vi is referenced in a main build specification, the sub-VI in its own specification where the target is a LLB.
I appended an example-program that exhibits the error (when executing 'Application.exe' and pressing 'calculate ramp'). The error does not occur when disabling the 'ramp pattern' function and rebuilding the application.
I would rate this to be a bug in the application builder and would appreciate any help on how to solve this problem. However, due to the structure of the whole program the sub-VI has to remain in its own LLB.
Attachments:
RampPattern.zip ‏198 KB

There can be reasons why a VI might appear broken when loaded from an executable. For example, if you have different versions of the same VI or enum that differ in such a way as to break the calling VI, that can cause a broken arrow when loaded from the executable. If you have DLLs being called and the runtime engine can't find the DLL, that can cause a broken arrow that you might not see otherwise. Finally, there is a bug related to a VI appearing broken when its not.
Mike...
Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion
"... after all, He's not a tame lion..."
Be thinking ahead and mark your dance card for NI Week 2015 now: TS 6139 - Object Oriented First Steps

Connector pane pattern bug

Similar Messages

Maybe you are looking for